攜程新一代呼叫中心話務監控平台

一、攜程呼叫中心話務概況

攜程作為中國最大的OTA，和國內外近十家電信運營商展開合作，目前擁有語音線路通道10000+，包括傳統語音線路以及基於軟交換平台的SIP線路，每天的話務量更是以百萬計。從業務類型來說，又可以分為人工呼入呼出、自動呼入呼出和自動轉呼等等。

面對不同運營商、不同線路特性的運維管理和靈活多變業務需求，基於監控精細化、自動化、操作便捷化標準下做到對故障快速響應和處理的目標，我們開發了一套針對呼叫中心話務監控管理平台——Horus系統。

二、原有監控痛點

攜程呼叫中心原先有一套監控攜程所有的呼入呼出話務的監控系統，不過在使用過程中，系統存在以下問題：

三、Horus系統特點

Horus系統對這些問題進行了針對性的處理，目前通過以下功能可以自動發現並及時準確的進行告警：

四、Horus系統架構

系統架構圖：

Horus系統主要由以下模塊組成：

1. 採集模塊：從數據源採集數據，輸送到消息中間件Hermes，支持DB及API方式採集；
2. 存儲模塊：從Hermes獲取數據，並存儲到文件資料庫Hickwall，將監控項索引存儲到Mysql DB中；
3. 故障檢測：從Hermes獲取已採集的數據並調用數據分析模塊進行故障檢測；
4. 數據分析：根據歷史數據分析生成告警規則，檢測當前數據，生成檢測結果和告警信息；
5. 告警聚合：將告警進行聚合，聚合後的告警信息返回Hermes；
6. 告警通知：從Hermes調取告警信息，執行告警通知，並將告警通知存入DB；
7. 自動測試：調用「語音機器人」功能，執行自動測試任務；
8. 監控展示/配置：執行用戶和系統的交互；

系統邏輯圖：

五、Horus系統解決方案

整體方案主要結合以下幾個方式進行設計：

• 正態分布
• 周期屬性
• 差分統計
• 特徵分析
• 數據關聯
• 自動測試

自動檢測

• 演算法原理：

自動檢測是Horus系統的核心功能，我們的做法是對海量歷史數據進行採集和處理，按照以上幾個方案形成3種智能化檢測策略。

1. 閾值分析

將歷史數據結合正態分布生成閾值上下限，再計算越界次數，生成閾值分析策略。為了提高閾值準確性，我們將歷史數據區分工作日、雙休日以及節假日。同時考慮周期屬性，將數據按時間片再細分，對比每天同時刻數據，縮小偏差。

2. 變化率分析

根據數據變化的趨勢，利用差分統計計算前後點之間的變化率，和自身數據前後趨勢作比較，生成變化率分析策略。

3. 跌零檢測

對當前數據進行跌零檢測，結合損失話務量和跌零次數判斷是否告警。

4. 自動告警邏輯：

根據以上三個策略對實時的監控數據進行檢測：

1、先進行跌零檢測，如判斷數據跌零且滿足累計損失話務量或次數條件，則告警；

2、如果數據未跌零，則進行閾值分析和變化率分析，部分場景再結合累計影響話務量以及是否為節假日判斷，滿足條件則告警，否則不告；

閾值分析&變化率分析示意圖如下：

1、Point-A1的值超過閾值下限，且該點與前一點的變化率C-Rate1大於變化率門限，所以該點為異常點。

2、Point-B1的值超過閾值上限，但該點與前一點Point-B2的變化率C-Rate2小於變化率門限，所以該點判斷為正常點。

六、業務應用場景：

• 話務量監控
• 成功率監控
• 周期性特徵取值
• 小話務量的離散數據
• 關聯數據告警
• 長期小幅下跌

• 話務量自動檢測：

某號碼話務量在一個時間段數據陡降，連續2個點低於閾值下限，同時變化率大於門限值，觸發告警。

• 成功率自動檢測：

成功率的檢測不僅僅是檢測是否低於某固定指標，也是需要根據不同業務的特性以及不同時間段進行監控。針對容量類或成功率等特殊監控類型，我們基於歷史數據進行閾值分析，生成動態的閾值上限或下限規則，即能滿足告警要求。

• 周期性特徵取值：

因業務類型不同，部分話務數據存在陡升陡降情況。針對此類數據，我們採用特徵分析的方法，自動發現其特徵規律，減少誤告。

例如某監控項在每周固定時間段有一個數據突升，我們通過特徵分析發現了這個規律，作為後期告警檢測時的重要參考，避免誤告。

• 小話務量的離散數據

小業務量監控項一直以來都是業務監控的盲區，因為業務量小導致告警規則難以確定。對此我們採用了數據聚合的策略，從數據量和業務形態兩方面入手，自動分析監控項特徵並打上標籤，通過不同聚合維度對監控項進行檢測和告警。

圖9的常規時間序列圖中，該監控項的數據是離散的，傳統方法無法有效監控起來。經過聚合之後，圖10的數據被聚合成1小時維度的，這樣形態就變得很有規律，可以進行檢測和告警。當然，聚合之後雖然可以解決檢測和告警的問題，但展示和監控維度都變成1小時，從問題發生到告警觸發時延有所延長。

• 關聯告警

話務監控項之間往往存在著一定的關聯性，我們通過將2個或多個相關的監控項自動關聯，以減少誤告避免漏告。

下圖我們將傳真請求總量、傳真發送總量進行關聯。以下紅色圓點請求總量增加，但發送總量沒有變化，因此進行告警，而後面的請求總量增加，同時發送總量也增加，系統關聯後，不進行告警。

• 長期小幅下跌

對於某些長期小幅下跌的問題，傳統方式無法有效檢測，通過聚合之後閾值和累計影響話務量的檢測，可以有效發出告警。

七、告警篩查

告警檢測依賴的是歷史數據分析，而業務也有其隨機性，因此不可避免的存在誤告的可能。對此，我們採用自動測試方式對告警進行篩查。

自動測試功能的實現基於我們的另一款產品「語音機器人」。針對話務量，成功率等監控項，獲取疑似告警發生後，系統會調用「語音機器人」功能，根據測試用例進行自動測試，將測試結果返回後插入到告警信息中，並告知運維負責人該告警為誤告。

八、告警聚合

監控系統發出告警之後，可能會引申出另一個問題，那就是告警風暴。告警風暴通常發生於以下兩種情況：

1、系統發生大型故障，多個監控項同時發生告警

2、單個監控項連續發生告警

針對告警風暴，我們的做法是將大量重複的、或同類的告警壓縮為一條真正有意義的告警，為運維人員提供甄選之後的最重要的告警。

這裡有兩個規則：

1、同一通知組，1分鐘內同時發生的不同告警合併成一個通知內；

2、同一監控項，30分鐘內的告警只通知一次，不再重複通知；

用戶也可以查看聚合之前的告警以及他們的時間序列關係。實際使用中，告警壓縮率可以達到95%以上。

九、其他功能

• 便捷接入

提供API、DB和插件等多種方式，3步完成接入。

Step1：配置採集信息，包括監控對象分類、採集名稱和採集方式等

Step2：自動校驗，生成監控項

Step3：確定圖表需要接入的菜單名稱，同時完成啟用告警、告警通知組等全局配置

• 可視化編輯

圖表編輯頁面，可同時完成圖表命名、監控項選擇、添加上周曲線、添加基線、修改顏色和編輯告警規則等典型場景下的常用操作

• 運維大屏

梳理各類運維數據，投放到大屏上進行綜合展示

• 自動語音通知

對於告警通知，我們在郵件通知的基礎上增加了電話通知功能。在告警發生後，調用「語音機器人」模塊向系統負責人手機發起呼叫，通過文本轉語音模塊將告警內容自動轉化成語音及時通知應用負責人。運維人員在聽取告警內容後，如暫時無需處理或暫時無需關注，可通過按鍵進行「屏蔽」或「誤告」等操作，避免系統一直告警。

告警通知採用自動升級機制，如三次系統負責人不接聽電話，自動升級至其主管，如主管不接電話，自動升級至更高級別管理人員。（升級機制可通過參數配置）

十、後續規劃

Horus系統投入生產後，接入的監控項type已達17種，不同的業務類型引出了更多的問題和需求。後續我們會繼續通過大數據分析、AI等人工智慧技術不斷優化監控平台,並在用戶界面提供更多便捷、個性化的操作體驗和展示效果。當然從傳統業務監控到全面自動化業務監控必將是一個持久的過程。

十一、總結

將新監控系統命名為Horus，寓意該系統能夠像古埃及神話中的Horus神一樣，擁有敏銳的鷹眼，及時準確地發現業務數據上的異常。Horus系統也是我們從傳統業務監控轉向自動化業務監控的一款突破性產品，針對高度複雜業務實現面向用戶體驗、面向業務可用性的實時監測和自動告警，讓業務監控更加簡潔、自動和高效。

【作者簡介】攜程通信技術中心，主要負責攜程呼叫中心日常運維，包括配置管理和監控平台開發，目前主要在呼叫中心運維自動化方向探索和演進。

更多來自攜程技術人的一手乾貨，歡迎搜索關注「攜程技術中心」微信公號。

推薦閱讀：