科來：某運營商話務呼出系統偶發性訪問失敗分析

話務呼出系統可以有效提升外呼通話的接通率，是運營商內部重要的業務系統之一，同時也是提升品牌形象、提高寬帶服務質量的重要方式。偶發性訪問失敗會直接導致業務癱瘓，有損用戶服務體驗。

問題描述

短短一個月內，該業務系統出現偶發性訪問失敗數次，用戶通過很多手段排查定位此故障的真正原因依然未果。科來通過與用戶溝通并立刻在該系統服務器區出口部署科來網絡回溯分析系統（RAS），開始對該系統流量進行監測。

在部署科來網絡回溯分析系統（RAS）的幾天后，該系統再次出現大面積無法訪問，頁面無法正常打開。通過RAS提取出問題時段的系統服務器通信數據流量，我們終于發現導致用戶無法正常訪問話務呼出系統的直接原因。

分析結果

科來為用戶進行故障重現描述：原因并非是該業務系統內出現問題，而是網絡中數據庫部分出現故障間接導致本次大面積訪問失敗。由于數據庫出現故障造成無法及時斷開連接，導致數據庫的連接數撐爆。數據庫無法正常工作，所以才造成用戶無法正常訪問該系統應用。

方案價值

案例中對于業務系統故障的分析難點在于其特有的偶發性，因此存在較大分析難度。科來網絡回溯分析系統（RAS）能夠重現故障現象并從不易覺察的異常數據流量中發現問題突破點，對隱性故障問題實現精細化挖掘分析，快速發現故障點，清晰定位查明故障原因，為客戶解決故障問題、界定直接責任提供了準確的流量依據。

這也為我們積累了難得的運維經驗，有時業務系統的問題并非其自身原因，極有可能是與之相連的上下游部分出現問題間接導致故障的發生，運維過程需大局觀，不可單獨割裂只看復雜網絡中某一部分。

分析過程

1.配置回溯分析系統，在相關的業務訪問邏輯進行抓包分析：

營業廳→外網(130.XX.XX.46)→F5(130.XX.XX.27)→服務器(134.XX.XX.92-95)→數據庫(134.XX.XX.86)

圖1 業務系統存在大量訪問被重置

2.通過對該業務系統的監控分析，發現在發生故障的時間段存在大量訪問被重置的情況，如圖1所示。

通過對該時間段的會話分析，發現客戶端在與服務端建立三次握手，發送POST請求之后，服務端也回復了ACK進行確認。但等了幾秒甚至至幾百秒服務器都沒有數據響應，客戶端直接把會話斷開，直接回復了RST關閉會話，如圖2所示。

那么什么原因導致應用沒有回復數據響應呢?

通過對數據庫134.XX.XX.86的監控，應用需要向數據庫調用數據，是不是數據庫端出現問題?

圖2 客戶端關閉會話

在同一個時間點，發現數據出現了異常，數據庫的連接數比正常的情況下多了很多。數據庫一般是長連接，所以客戶端的連接數一般不會很多，會設定相關連接數上限，對單個客戶端連接數的上限設定為100個。

但通過對數據庫半個小時分析，發現服務器134.XX.XX.94半個小時的連接數達到了229個，134.XX.XX.93的連接數達到了132個，明顯超過了這個設定的100個連接數的上限值。

圖3 客戶端無法正常打開

所以，該段時間內的數據庫連接數很高，導致數據庫響應緩慢或者數據庫無法響應，間接就導致了客戶端去訪問應用，然后無法正常打開，如圖3所示。

通過對客戶端134.XX.XX.94訪問數據庫的會話進行詳細分析，客戶端發送請求之后，數據庫這一端沒有及時發送數據進行響應，等了264秒之后客戶端在發了fin中斷連接，然后需要再建新連接，但數據庫134.XX.XX.86這邊5分鐘之后才發響應數據以及fin包，該連接還保持著，這樣就導致數據庫134.XX.XX.86的連接數過多，數據庫無法正常響應數據。

圖4 數據庫監控圖

所以，通過以上分析，由于數據庫沒有及時斷開連接，數據庫端出現問題，導致客戶端的連接數超過上限。通過客戶反饋該時間段的數據庫的連接數已經超過正常值，由于數據庫無法正常響應數據，間接就導致客戶端無法正常調取數據及正常訪問應用，應用服務器的連接數就撐爆了連接池，數據庫監控如圖4所示。

解決方案

定位了問題發生的原因后，我們與該業務系統應用及數據的管理員進行溝通，請其升高(134.XX.XX.92-95)服務器的最大DB連接數配置，從而提高系統容錯瓶頸。

調整后，該系統恢復正常，同時應用(134.XX.XX.92-95)連接數恢復正常。

成都科來軟件有限公司

電話：400-6869-069 010-82601814

網址：www.colasoft.com.cn

論壇：www.csna.cn