最近一兩年的時候，寫程式碼的時間逐漸減少，除了負責幾個小系統之外，更多的時間用在解決客戶問題上。接觸的問題多了，發現真的是什麼樣的問題都有可能發現在客戶環境上，當然，這不能一味地說系統的問題。系統確實存在不足的地方，但是，有時候環境、客戶人為操作等很多因素，都會帶來或小或大的問題。下面列舉一下接觸客戶問題以來，碰到的十大棘手問題。呵呵，說是棘手，也不一定很棘手的，但不少問題要解決起來肯定是有些麻煩的。

1、偶爾出現的

偶爾再現的問題，也就是不穩定重現，有時會有問題，有時沒問題。這種問題真的很讓人糾結，所以把它放在第一位。此類問題可能不一定是很難，但是卻很考驗你的耐性、注意力及解決問題時所考慮到的寬度和廣度。舉一個例子，有客戶說，伺服器從其它機器上取回來的資料，有時候會少幾條，有時卻不會少。根據這種場景，如果有客戶在使用你的系統，也報了這樣的問題，應該怎樣處理呢？

2、關於某個數是怎麼計算出來的

這個可能不算什麼驗證，不過有時候卻很耗時。如果這個模組是自己開發的，具體計算公式、邏輯自己都比較清楚的，那這個就不算問題，也不用花多少時間。

3、與其它工具對比的

某一次，客戶問我，怎麼你係統算出來的記憶體使用率與Linux上自帶的工具不一樣呢？與第二條類似，需要對系統使用的計算規則及其它第三方系統都比較熟悉。還有一次，客戶問我為什麼Linux Cache不計入到已使用記憶體中， 這個由於客戶不熟悉Linux系統，如果自己也不熟悉，那就不知道怎麼解釋了。

4、系統整合方面的

與第三方系統整合時，經常會碰到一些麻煩的問題，比如資料丟失，或整合時工作不正常之類。給我印象最深的就是SSO（單點登入）的功能了，與AD做了整合，有時候在客戶環境就會報AD使用者不能正常登入。有時候客戶在AD伺服器那邊修改了資料，導致儲存在我們系統這邊的資料出現重複記錄。有時還會碰到什麼跨域訪問之類的問題或需求。

5、協議方面的

通過某協議跟目標機器建立連線，會出現連線失敗導致不能收集資料，連線不穩定，個別查詢出問題，增加連線數容易導致連線中斷等各種各樣的問題。比如通過WMI容易出現佔用資源過多的情況，連線多增多的情況會出現嚴重效能問題。再比如WinRM引數比較多，有些客戶喜歡搞搞研究的，不小心改了某個引數，導致資料不能收集，但客戶又沒那麼老實或是想不起來改了什麼，只好下功夫去慢慢排查了。協議方面的知道如果經常使用還好，如果有一段時間不使用，下一次再使用，感覺就什麼都記不起來了那樣。

6、是否會對其它模組造成影響的

這型別的問題說難倒沒有那麼難，但還是有些麻煩。比如，如果客戶想在平臺刪除某個子系統的一條物件，但是又擔心會影響到歷史資料或是其它資料，來跟你確認能不能刪除，會不會帶來其它不良影響的。由於子系統不是你負責的，你可能也不那麼清楚裡面的邏輯，這種情況下即使你知道不會對其它模組或其它資料造成影響的，也還是打上十二分精神，小心謹慎，因為，如果連同其它資料也一起被刪除了，那後果會不會有點嚴重呢，畢竟客戶有說明了。當然，即使客戶沒特別說明，我們也是要萬分謹慎的。

7、客戶安全規定的

這個也不算會很難的，但是這裡不得不說的是，有些客戶的內部規定實在很強大啊。比如說，有些客戶內部規定，重啟個服務，拿個系統日誌，做個什麼引數更改之類的，都要走審批流程，這樣一來一回，一個星期過去了，才順利拿到系統日誌，最後不得不說，時間都去那裡了。還有些客戶的敏感部門，安全意識實在太強大了，不給你檢查系統的，系統日誌也不直接提供給你，他們可能會把一些資訊，如機器名稱、IP等他們認為敏感的資料，清除之後，再把這樣的日誌給你，這樣的日誌，分析起來無形中增加了困難。

8、跟客戶環境相關的

這個不用解釋，相信很多人都會遇到，就是這樣的問題只有客戶環境才有，咱們是無法重現的。最近一個客戶報上一個問題，說有300多個子系統連線上伺服器，就經常出現子系統連線中斷的情況，導致有些資料不能正常收集。哎，這種情況我們可以花費了好大的精力，搭建環境、模組場景來測試，結果就是不能重現客戶的問題。沒辦法，把所有相關的人叫在一起，對著客戶的日誌，一條一條地分析，是不是有資源佔用了，是不是LOCK有問題啊。。。這樣的問題，給你碰上一個你就知道什麼感受了。

9、前後兩個版本表現不一致的

這型別的也很容易理解，就是新版本和舊版本在某些功能上的表現會有些差異。當然，如果這種差異確實是個問題，而且客戶不接受的，那還是自己的事情沒做好，系統相容性沒做好，那就老老實實地給客戶解決問題吧。給我印象最深的就是，我手上的一個生成報表的功能，客戶一直在使用舊版本了，後來為了升級JDK，就想著升級我們的報表工具，升級完成後，對比舊系統和新系統生成的報表，發現在新系統上生成的報表，有一列某些內容向右移動了幾個畫素的位置，這時候如果在那個地方顯示的內容多了一些，就會出現內容重疊的問題，大部分情況是沒問題的，這個問題真不容易發現，在舊系統上就不存在這個問題，所以還是我們的工作沒做好。這個問題，我可以連線花了一週的時間，查詢問題，對比程式碼，最後終於給我找出來了，畢竟不是所有東西都是自己負責的，需要些時間是處理這個問題也是正常的。

10、有需要開網路會議卻又在“相反”時區的

雖然這種情況不多，但有時候時間上確實有些不好安排。有些客戶在白天12點時，我們是晚上1點，碰到這樣的客戶要跟我們開會時，只好減少睡眠了。有一次，好不容易協調好時間，下等6點半開會的，結果網路慢得要命，遠端操作客戶機子時，點選一下滑鼠都要等上好幾秒才有反應，本來計劃要開一個小時的會議，結果給拖到了快9點鐘，下次吸取了教訓，先吃飯飯再開會。還有一次，本來說是早上6點開會的，結果改了時間，提前半個小時，發了郵件我沒看到，技術支援和其它區域的開會就跟客戶在開著，6點的時候鬧鐘一叫，馬上起來，結果發現會議都差不多開會了。。。

除了這型別的問題，當然還有其它各種各樣的問題，比如記憶體溢位、資料庫資料過多等問題，這些問題雖然也很難解決，但是我覺得不少這問題，都會有一條主線，順著這條主線，從上到少，解決起來有種水到渠成的感覺，有個別的這種問題解決起來還很輕鬆。除了以上列舉的問題，我相信，以後總會有其它形形色色的問題等著我，當然，我們開發的也要主動出擊，測試的也要加把勁，多覆蓋各種各樣的場景，降低問題發生在客戶的可能性，這樣，才是解決問題的根本之道，這樣，客戶使用起來也比較輕鬆，也就會越來越喜歡使用我們的產品。