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