筆者單位客服系統(tǒng)運行中頻繁出現(xiàn)卡頓現(xiàn)象:每個坐席在不定時段都會出現(xiàn),具有一定的普遍性。經(jīng)過簡短分析,認為有兩種可能,一是網(wǎng)絡(luò)問題造成的,二是軟件系統(tǒng)本身造成。
首先檢查網(wǎng)絡(luò),在不同坐席的電腦上Ping網(wǎng)關(guān)一段時間,都發(fā)現(xiàn)有丟包現(xiàn)象,于是斷定是網(wǎng)絡(luò)丟包造成的系統(tǒng)卡頓。接下來結(jié)合該系統(tǒng)的網(wǎng)絡(luò)架構(gòu)與各種監(jiān)控工具進行追查,尋找問題的解決方式。下面介紹網(wǎng)絡(luò)檢查,排除故障的過程。
使用Ping大包的方式查看網(wǎng)絡(luò)是否有丟包現(xiàn)象。很多時候普通Ping不丟包,而Ping大包時則發(fā)現(xiàn)開始丟包,證明網(wǎng)絡(luò)確實存在問題。
圖1 客服系統(tǒng)網(wǎng)絡(luò)架構(gòu)圖
-l后的參數(shù)(size)為數(shù)據(jù)包,范圍0到65500,與-l一起使用,控制每次Ping發(fā)送的字節(jié)數(shù)。不使用這套參數(shù)時,默認Ping發(fā)送數(shù)據(jù)包為32byte。-t參數(shù)表示一直Ping,直到手動終止。使用Ctrl + C可以立刻終止,并提供這段時間的Ping包統(tǒng)計信息,包括發(fā)送包數(shù)、接受包數(shù)、丟失包數(shù)、丟失率等信息。
用兩臺坐席電腦分別Ping內(nèi)網(wǎng)核心交換機(即內(nèi)網(wǎng)網(wǎng)關(guān))若干小時,獲取數(shù)據(jù)進行分析:Ping大包丟失率達到20%,Ping普通包丟失率3%。說明網(wǎng)絡(luò)質(zhì)量不佳,傳輸數(shù)據(jù)量越大丟包率越高。另外提供佐證,當把客服核心交換機組下帶的幾路視頻監(jiān)控線路去除掉時,Ping大包的丟包率有明顯下降。
公司的網(wǎng)絡(luò)管理軟件已經(jīng)對客服系統(tǒng)核心交換機組進行流量監(jiān)控。調(diào)出最近的數(shù)據(jù),對客服核心交換機組的三臺交換機進行分析。
客服交換機組的級聯(lián)方式如圖1所示。其中交換機B與C直接連接到A上,而A則通過光纖收發(fā)器連接到機房的內(nèi)網(wǎng)核心交換機上。系統(tǒng)對A、B、C的級聯(lián)接口都進行了流量監(jiān)控。分析這些接口的流量監(jiān)控圖,發(fā)現(xiàn)交換機A的上聯(lián)口最能反映出問題所在(如圖2)。上聯(lián)口錯包數(shù)非常多,丟包數(shù)也非常多。當把幾路客服視頻監(jiān)控重新連接上之后,在流速與帶寬利用率曲線圖中有明顯的波峰,但峰值并不高——帶寬利用率不到15%,可分析出此次網(wǎng)絡(luò)問題并非是帶寬不足造成的。交換機A的錯包問題,在其他幾個交換機是不存在的,在A本身的下聯(lián)口中也不存在。初步定位交換機A上聯(lián)口有問題。
圖2 客服核心交換機A流量監(jiān)控圖
圖3 局域網(wǎng)抓包信息
根據(jù)上一步的分析對交換機組進行逐一排查,進行驗證,找到問題原因。
首先,將筆記本分別連接在交換機B與C上,Ping內(nèi)網(wǎng)核心交換機,發(fā)現(xiàn)都有丟包。然后連接到交換機A上繼續(xù)Ping,同樣有丟包,且發(fā)現(xiàn)這幾次測試的丟包率與普通坐席Ping的丟包率接近。因此,可排除交換機B與C損壞所致。
然后,將筆記本直接連接客服端的光纖收發(fā)器電口上,Ping依舊丟包,且丟包率與上面幾次測試都接近??梢曰緮喽ǚ墙粨Q機組的設(shè)備問題,而是光的收發(fā)與傳輸問題。
使用光功率計分別測量機房與客服兩處的光纖收發(fā)器一發(fā)一收的光功率,并計算出光衰減,機房到客服光衰減為-5db;客服到機房光衰減為-6db;根據(jù)此數(shù)據(jù)判斷,光衰減在正常范圍之內(nèi)。但經(jīng)過光纖收發(fā)器之后就有丟包,推斷是光纖收發(fā)器有問題。
因現(xiàn)在的內(nèi)網(wǎng)核心交換機與客服核心交換機A都具有光口,可以直接使用光模塊連接,于是棄用光纖收發(fā)器,改用兩個千兆光模塊直連光纖,并開啟全雙工模式。命令:
speed 1000
duplex full
更換光模塊后,再Ping包,發(fā)現(xiàn)沒有丟包現(xiàn)象發(fā)生。測光功率,計算光衰減,也有一定改善。問題基本解決。
運維人員繼續(xù)觀察,使用坐席電腦Ping 24小時,然后追查LOG,發(fā)現(xiàn)沒有丟包現(xiàn)象。查看流量監(jiān)控圖,發(fā)現(xiàn)錯包數(shù)為0,丟包數(shù)幾乎為0。至此,故障完全排除。
現(xiàn)實的排除故障過程中,懷疑過是否因為局域網(wǎng)里出現(xiàn)網(wǎng)絡(luò)風(fēng)暴。于是使用WireShark工具,進行網(wǎng)絡(luò)抓包然后分析數(shù)據(jù)。
經(jīng)過對抓取數(shù)據(jù)的分析,確實網(wǎng)絡(luò)中有一些壞包、錯包,但這種數(shù)據(jù)不多,也沒有網(wǎng)絡(luò)風(fēng)暴(如圖3中黑色數(shù)據(jù)行),可以判斷不是這個原因所致。