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

問題描述

短短一個月內，該業(yè)務系統(tǒng)出現(xiàn)偶發(fā)性訪問失敗數(shù)次，用戶通過很多手段排查定位此故障的真正原因依然未果?？苼硗ㄟ^與用戶溝通并立刻在該系統(tǒng)服務器區(qū)出口部署科來網(wǎng)絡回溯分析系統(tǒng)（RAS），開始對該系統(tǒng)流量進行監(jiān)測。

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

分析結果

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

方案價值

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

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

分析過程

1.配置回溯分析系統(tǒng)，在相關的業(yè)務訪問邏輯進行抓包分析：

營業(yè)廳→外網(wǎng)(130.XX.XX.46)→F5(130.XX.XX.27)→服務器(134.XX.XX.92-95)→數(shù)據(jù)庫(134.XX.XX.86)

圖1 業(yè)務系統(tǒng)存在大量訪問被重置

2.通過對該業(yè)務系統(tǒng)的監(jiān)控分析，發(fā)現(xiàn)在發(fā)生故障的時間段存在大量訪問被重置的情況，如圖1所示。

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

那么什么原因導致應用沒有回復數(shù)據(jù)響應呢?

通過對數(shù)據(jù)庫134.XX.XX.86的監(jiān)控，應用需要向數(shù)據(jù)庫調用數(shù)據(jù)，是不是數(shù)據(jù)庫端出現(xiàn)問題?

圖2 客戶端關閉會話

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

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

圖3 客戶端無法正常打開

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

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

圖4 數(shù)據(jù)庫監(jiān)控圖

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

解決方案

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

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

成都科來軟件有限公司

電話：400-6869-069 010-82601814

網(wǎng)址：www.colasoft.com.cn

論壇：www.csna.cn