案例背景

某航空公司華南客服中心，客服人員用客服系統(tǒng)接電話時經(jīng)常出現(xiàn)接聽失敗的現(xiàn)象，由于客服服務器位于北京數(shù)據(jù)中心，中間涉及的網(wǎng)絡設備較多，一直未能定位到故障原因。

故障現(xiàn)象

如下拓撲所示，每個客服人員桌面都會有一臺電腦跟電話機，一天中會出現(xiàn)幾次偶發(fā)故障，故障發(fā)生時，用電腦上的客服軟件接聽用戶電話失敗，如果及時改用座機接聽則可成功，我們用科來網(wǎng)絡回溯分析系統(tǒng)在華南客服中心廣域網(wǎng)出口抓包分析。

故障規(guī)律摸索

客服人員可以用電腦和座機接聽電話，電腦接聽電話失敗時，改用座機可以成功接聽。

規(guī)律分析：電腦與座機是連接同一個hub上，座機可以成功接聽電話說明網(wǎng)絡連接正常，需要從電腦客服軟件的角度分析問題。

故障發(fā)生時間段主要集中在中午午休后及凌晨時段，重置電腦的客服軟件后也能恢復正常。

規(guī)律分析：這兩個時間段的特點就是接聽的電話數(shù)量比較少，很可能是空閑時間太長，電腦客服軟件某些連接被終端了。

排障思路

重現(xiàn)故障，在科來網(wǎng)絡回溯分析系統(tǒng)將客服的電腦與北京服務器之間的通信流量進行回溯、分析，尋找故障原因。

故障重現(xiàn)

在深圳客服中心尋找一臺客服電腦，首先驗證該客服電腦、座機都能正常接聽電話；然后從16：12開始閑置該客服電腦，超過半個小時候，16：48再撥打該客戶座機，接聽失敗，故障成功重現(xiàn)。

IP會話分析

客服電腦的IP為10.110.22.21，與北京的兩臺服務器有通信流量，分別是：

10.10.176.51，經(jīng)確認為客服軟件界面的服務器

10.10.203.155，經(jīng)確認為客服軟件控制插件的服務器

軟件界面連接分析

從客服電腦10.10.22.21與服務器10.10.176.51通信的TCP幾乎時序圖可以看到，兩者采用了長連接的機制，在空閑的時間，客戶端每隔幾秒鐘就會發(fā)送一個GET的請求與服務器保持連接。

從16：12分至16：48分，每個6分鐘客戶端與服務器就跟新一次TCP連接，未曾中斷過，因此軟件界面一直能夠正常顯示。

控制插件連接分析

從客服電腦10.10.22.21與服務器10.10.203.155在16：12分至16：48期間只有3對TCP連接一直保持，如果這三對TCP連接沒有采用長連接的傳輸機制，很可能會因為空閑太長時間而被網(wǎng)絡中的防火墻等設備中斷連接。

果然，客戶端在空閑的2090秒（34分鐘）的時間內(nèi)沒有發(fā)送任何保持連接的數(shù)據(jù)包，等到客服電腦重新發(fā)起接聽電話請求的時候，客戶端的請求已經(jīng)無法到達服務器端，一直在發(fā)起重傳的請求，***客服人員看到請求超時的告警提示。

故障原因分析

大部分防火墻都會將空閑時間超過30分鐘的TCP連接斷開，而控制進程在空閑的34分鐘內(nèi)沒有采用長連接機制保持連接，所以被防火墻中斷了，再有電話接入的時候便會出現(xiàn)接聽失敗的現(xiàn)象。

解決問題建議

修改防火墻的策略：增長訪問北京10.10.203.155的TCP連接的空閑時間。（注：該策略實施后，偶發(fā)故障出現(xiàn)的次數(shù)明顯下降）

優(yōu)化客服控制插件程序設置，能從根本上解決問題。