今天是3.15， 最近處理阿里旺旺的一些客戶問題有了些感受，一直想記錄一下，難得今天有寫東西的興致，就落筆談談處理阿里旺旺消費者問題的一些經驗吧。
我們的旺旺已經有了崩潰處理系統，當阿里旺旺客戶端崩潰時，可以將現場的崩潰信息發送到服務器用來事後定位問題，但還是會有一些功能性的非崩潰的問題會出現。這個時候，客戶一般通過會先找到客服，然後客服再找工程師來解決問題。
確定現場
旺旺是什麼版本的？操作系統是什麼版本的？出問題時使用的是哪個網站的什麼帳號？進行了哪些操作？有沒有一些其他異常情況？出錯時的日誌拿回來了沒有？在解決問題之前必須要能看到或者收集現場，否則花力氣去解決問題都是沒有意義的。
這個步驟一般有經驗的客服同事都會替我們工程師事先收集好，工程師也可以請客服同事向客戶幫忙收集一些額外信息。接下來工程師要做的就是根據這些現場來做一些準備。
詳細準備
客戶一般會允許工程師遠程到她/他的機器上一到兩次來定位問題，因此在遠程前做好詳細的準備是非常重要的。機會可能只有一次！
我認爲的詳細準備是：日誌的分析, 用來做驗證的測試，驗證通過後對應的解決方案， 創造環境自己先驗證以及準備相關工具來幫助定位問題等。
首先我要說說日誌的重要性。
最近組內做的代碼review我提到最多的就是出錯的日誌沒有打。我發現很多工程師都不太愛寫出錯日誌信息，有些時候遇到一個錯誤，直接return掉就完事了，包括我自己。以前一直認爲太多的註釋對代碼美觀影響太大，又或代碼某些地方基本上不太可能出現錯誤，或者出現錯誤程序運行下去也沒有用了，於是乎就乾脆不寫。據幾次我和同事處理客戶問題的經驗來看，有幾次便是因爲出錯時的日誌信息不夠豐富，非常難定位問題，最後花了相當大的代價。 對於商業程序，日誌的確可以不用過多，但是該加的地方一定要加，譬如出錯，重要的流程記錄等等，嚴格一點的， 日誌也可以review一下。
我們的旺旺平臺運用了大量的COM技術，由於其複雜和特殊，HRESULT的返回值真可以說是性命攸關。任何一個hr的值都該判斷一下，出錯的地方更要加上日誌等等。
準備在客戶機器上做驗證的測試方案。
有些時候我們分析完了日誌和現場，有了幾個懷疑點。根據這些懷疑點，我們可以準備做幾個測試方案，用來驗證我們的判斷。同時準備驗證通過後對應的解決方案，畢竟解決當前這個客戶的當前這個問題是最重要的！因此這個步驟一定要詳細準備。
創造環境自己預先驗證模擬
準備好解決方案後，我一般會在自己設置的環境上先做一下驗證，譬如用戶的問題操作系統是xp sp3,那麼可以先在一個sp3的系統上先驗證一下。就算沒有合適的環境，熟悉一下操作步驟，這樣等真正遠程到客戶機器上去時也能不慌不忙，心中有數。
請別的同事review一下方案
這點也很關鍵，最近有一次我事先詳細準備了測試方案以及對應的解決辦法，但是還是由於個人粗心，在修改代碼編譯出客戶能用的組件時，有個地方沒有注意細節，導致第一次遠程用戶機器時雖然已經能驗證我的判斷，卻不能解決。條件允許的情況下，找個好心腸的同事來review一下你的方案看來也是非常有幫助的。
工具
可以準備一些適當的小工具，到時候傳到用戶機器上，用來幫助查找問題。客戶端這邊譬如spy++,apispy, process explorer, DependencyWalker, tcp view , filemon, regmon(或者process monitor)等等, 選取一兩個對自己查找問題有幫助的工具。
放鬆，不緊張
遠程到用戶的機器後，操作一般都比本地機器操作緩慢很多，據我自己經驗，一定要放鬆，不要緊張
不要太相信客戶，相信自己的判斷力
這是最後一條，也是最重要的一條。我有兩次就栽在這個上面。有一次一個阿里旺旺插件開發商的技術人員告訴我插件模擬的訂購信息拿不到了，而其他人的機器上不會出現這樣的問題。於是我和他一起，用了很多方法來定位他的問題，最後發現是他描述的情況和真實發生的情況不符，他自己可能也沒注意到。如果中間相信自己的判斷力，早一點做一些懷疑假設，也許不會消耗那麼多無謂的時間，畢竟時間就是生命:) .