作者簡介

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

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

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

圖1：原有監控痛點

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

圖2：Horus系統特點

系統架構圖：

圖3：系統架構圖

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

1. 采集模塊：從數據源采集數據，輸送到消息中間件Hermes，支持DB及API方式采集；

2. 存儲模塊：從Hermes獲取數據，并存儲到文件數據庫Hickwall，將監控項索引存儲到Mysql DB中；

3. 故障檢測：從Hermes獲取已采集的數據并調用數據分析模塊進行故障檢測；

4. 數據分析：根據歷史數據分析生成告警規則，檢測當前數據，生成檢測結果和告警信息；

5. 告警聚合：將告警進行聚合，聚合后的告警信息返回Hermes；

6. 告警通知：從Hermes調取告警信息，執行告警通知，并將告警通知存入DB；

7. 自動測試：調用語音機器人”功能，執行自動測試任務；

8. 監控展示/配置：執行用戶和系統的交互；

系統邏輯圖：

圖4：系統邏輯圖

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

• 正態分布

• 周期屬性

• 差分統計

• 特征分析

• 數據關聯

• 自動測試

自動檢測

• 算法原理：

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

1.閾值分析

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

2. 變化率分析

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

3.跌零檢測

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

4.自動告警邏輯：

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

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

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

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

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

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

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

• 話務量監控

• 成功率監控

• 周期性特征取值

• 小話務量的離散數據

• 關聯數據告警

• 長期小幅下跌

• 話務量自動檢測：

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

• 成功率自動檢測：

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

• 周期性特征取值：

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

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

• 小話務量的離散數據

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

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

• 關聯告警

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

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

圖11：關聯告警

• 長期小幅下跌

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

圖12：長期小幅下跌

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

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

圖13：自動測試報告

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

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

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

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

這里有兩個規則：

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

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

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

• 便捷接入

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

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

圖14：采集配置

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

圖15：生成監控項

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

圖16：全局配置

• 可視化編輯

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

圖17：可視化編輯

• 運維大屏

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

圖18：運維大屏

• 自動語音通知

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

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

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

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