前一段時間我們公司的mail系統客戶，一直反映我們的mail系統有問題，銷售、客服人員以及運維人員都搞不定。具體的症狀大體是這樣：“通過webmail系統收發郵件非常慢，很多時候直接斷掉了”。這個客戶是我們的一個大客戶，屬於中字頭的公司，態度強硬，巨牛。運維人員反映說：客戶的網絡是光纖接入，速度非常快，ping值不超過5ms，而且沒有丟包現象，所以應該不是網絡的原因。
所有人反映的情況，似乎都直接指向了產品有問題。事實上，這麼多客戶都沒有問題，爲什麼唯獨它們有問題的，這個道理根本就無法說通，詢問他們是不是網絡有變動，他們矢口否認，堅持是我們的產品有問題。我作爲產品的研發者，竟然成了第一責任人，在這種情形下，被迫擔當了一回“超級客服”。我相信有因纔有果，計算機程序只能按照人的意志運行，它絕不會騙人。
某天下午，我跟公司的銷售來到了客戶現場，進行問題排查，過程如下所述。我把這個過程寫下來，只是爲大家提供一種做事的方式。
排查過程如下：
--------------------------------------------------------------------
用戶環境問題排查
1、客戶演示操作過程，問題可以重現，說明他們提出的問題確實存在。
2、與網管協商，將我攜帶的筆記本配置完整後，接入他們的內網。
3、我通過我的賬號（主要便於我們排查），發現問題依然存在。
這一步證明：不是用戶機器環境的問題，而是網絡環境可能存在問題。
-------------------------------------------------------------------
網速排查：
1、使用ping工具進行網速測試，ping xxx.xxx.xxx.xxx -t -l 1500 ,經一段時間測試，僅丟一個包，丟包率爲0，包反饋時間在10ms左右，說明網速很快，鏈路正常。
--------------------------------------------------------------------
用戶環境問題排查
1、客戶演示操作過程，問題可以重現，說明他們提出的問題確實存在。
2、與網管協商，將我攜帶的筆記本配置完整後，接入他們的內網。
3、我通過我的賬號（主要便於我們排查），發現問題依然存在。
這一步證明：不是用戶機器環境的問題，而是網絡環境可能存在問題。
-------------------------------------------------------------------
網速排查：
1、使用ping工具進行網速測試，ping xxx.xxx.xxx.xxx -t -l 1500 ,經一段時間測試，僅丟一個包，丟包率爲0，包反饋時間在10ms左右，說明網速很快，鏈路正常。
2、再登錄我的賬號，問題重現。
這一步證明：不是因爲網絡環境不穩定造成的問題。
--------------------------------------------------------------------
病毒排查：
我最初懷疑可能是arp欺騙，以至於傳輸過程中的數據包被轉向，或被篡改。
1、使用arp -a命令列出目前本機緩存的地址映射表，然後開啓防火牆，屏蔽掉除網關ip(10.135.1.254)之外的所有其它ip地址，防止造成干擾。
2、與網管人員協商拿到網關的mac地址，使用arp -s 來綁定網關ip地址和mac地址，防止網關mac地址被篡改。
結果問題依然存在。
這一步證明：不是因爲arp欺騙造成。
---------------------------------------------------------------------
程序應用層排查
1、使用httpwatch進行應用層數據的監控分析。結果發現數據發送一部分後斷掉，沒有收到服務器的迴應。
2、切換到舊版mail系統，進行發送數據的測試，發現結果一樣，問題也依然存在。
這一步證明：新mail的程序沒有問題。客戶端（瀏覽器）因爲收不到服務器端的響應，所以處於等待狀態。
---------------------------------------------------------------------
系統網絡層排查
1、使用sniffer（輕量級的minisniffer）進行網絡層數據抓包。經長時間抓取的數據進行對比分析，發現異常情況：每一次郵件數據發出部分後，間隔一段時間，網關要求重新發送。也就說第一次發送的數據被網關（或者網關之後的設備）判定丟失或不合法，網關要求客戶機再次發送，客戶機發送後鏈路斷掉。
這一部證明：因爲我們的服務器是正常的，所以問題肯定出現在網關和目的機之間的鏈路。
這一步證明：不是因爲網絡環境不穩定造成的問題。
--------------------------------------------------------------------
病毒排查：
我最初懷疑可能是arp欺騙，以至於傳輸過程中的數據包被轉向，或被篡改。
1、使用arp -a命令列出目前本機緩存的地址映射表，然後開啓防火牆，屏蔽掉除網關ip(10.135.1.254)之外的所有其它ip地址，防止造成干擾。
2、與網管人員協商拿到網關的mac地址，使用arp -s 來綁定網關ip地址和mac地址，防止網關mac地址被篡改。
結果問題依然存在。
這一步證明：不是因爲arp欺騙造成。
---------------------------------------------------------------------
程序應用層排查
1、使用httpwatch進行應用層數據的監控分析。結果發現數據發送一部分後斷掉，沒有收到服務器的迴應。
2、切換到舊版mail系統，進行發送數據的測試，發現結果一樣，問題也依然存在。
這一步證明：新mail的程序沒有問題。客戶端（瀏覽器）因爲收不到服務器端的響應，所以處於等待狀態。
---------------------------------------------------------------------
系統網絡層排查
1、使用sniffer（輕量級的minisniffer）進行網絡層數據抓包。經長時間抓取的數據進行對比分析，發現異常情況：每一次郵件數據發出部分後，間隔一段時間，網關要求重新發送。也就說第一次發送的數據被網關（或者網關之後的設備）判定丟失或不合法，網關要求客戶機再次發送，客戶機發送後鏈路斷掉。
這一部證明：因爲我們的服務器是正常的，所以問題肯定出現在網關和目的機之間的鏈路。
-------------------------------------------------------------------------
在這個環節有問題，我可是沒法再追查了，只有他們的網管纔有這個權力。我就與用戶進行交流，最後才得知：最近他們上了一套上網代理系統。這是他們網絡環境唯一的變化，它出現的位置完全符合我判定的環節，出現問題的時間也靠譜。
在這個環節有問題，我可是沒法再追查了，只有他們的網管纔有這個權力。我就與用戶進行交流，最後才得知：最近他們上了一套上網代理系統。這是他們網絡環境唯一的變化，它出現的位置完全符合我判定的環節，出現問題的時間也靠譜。
於是，我與網管協商，是否可以將代理系統暫停幾分鐘，以便我們進行測試。網管雖然不願意這麼做，但最終還是給出另一個途徑，調出一個沒有經過代理系統的ip地址。
經過ip地址變換後，發現問題消失，一切正常。重新回到原ip地址,問題重現。
終於證明：問題出現在代理系統上。
問題終於解決，超級客服耗費了4個多小時。客戶啊，你可夠混的，真想抽丫的。
以上解決問題的方法，專業術語稱爲“隔離分析”，感謝朋友們的指點。