作者簡介

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

面對不同運(yùn)營商、不同線路特性的運(yùn)維管理和靈活多變業(yè)務(wù)需求，基于監(jiān)控精細(xì)化、自動化、操作便捷化標(biāo)準(zhǔn)下做到對故障快速響應(yīng)和處理的目標(biāo)，我們開發(fā)了一套針對呼叫中心話務(wù)監(jiān)控管理平臺——Horus系統(tǒng)。

攜程呼叫中心原先有一套監(jiān)控?cái)y程所有的呼入呼出話務(wù)的監(jiān)控系統(tǒng)，不過在使用過程中，系統(tǒng)存在以下問題：

圖1：原有監(jiān)控痛點(diǎn)

Horus系統(tǒng)對這些問題進(jìn)行了針對性的處理，目前通過以下功能可以自動發(fā)現(xiàn)并及時(shí)準(zhǔn)確的進(jìn)行告警：

圖2：Horus系統(tǒng)特點(diǎn)

系統(tǒng)架構(gòu)圖：

圖3：系統(tǒng)架構(gòu)圖

Horus系統(tǒng)主要由以下模塊組成：

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

2. 存儲模塊：從Hermes獲取數(shù)據(jù)，并存儲到文件數(shù)據(jù)庫Hickwall，將監(jiān)控項(xiàng)索引存儲到Mysql DB中；

3. 故障檢測：從Hermes獲取已采集的數(shù)據(jù)并調(diào)用數(shù)據(jù)分析模塊進(jìn)行故障檢測；

4. 數(shù)據(jù)分析：根據(jù)歷史數(shù)據(jù)分析生成告警規(guī)則，檢測當(dāng)前數(shù)據(jù)，生成檢測結(jié)果和告警信息；

5. 告警聚合：將告警進(jìn)行聚合，聚合后的告警信息返回Hermes；

6. 告警通知：從Hermes調(diào)取告警信息，執(zhí)行告警通知，并將告警通知存入DB；

7. 自動測試：調(diào)用語音機(jī)器人”功能，執(zhí)行自動測試任務(wù)；

8. 監(jiān)控展示/配置：執(zhí)行用戶和系統(tǒng)的交互；

系統(tǒng)邏輯圖：

圖4：系統(tǒng)邏輯圖

整體方案主要結(jié)合以下幾個(gè)方式進(jìn)行設(shè)計(jì)：

• 正態(tài)分布

• 周期屬性

• 差分統(tǒng)計(jì)

• 特征分析

• 數(shù)據(jù)關(guān)聯(lián)

• 自動測試

自動檢測

• 算法原理：

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

1.閾值分析

將歷史數(shù)據(jù)結(jié)合正態(tài)分布生成閾值上下限，再計(jì)算越界次數(shù)，生成閾值分析策略。為了提高閾值準(zhǔn)確性，我們將歷史數(shù)據(jù)區(qū)分工作日、雙休日以及節(jié)假日。同時(shí)考慮周期屬性，將數(shù)據(jù)按時(shí)間片再細(xì)分，對比每天同時(shí)刻數(shù)據(jù)，縮小偏差。

2. 變化率分析

根據(jù)數(shù)據(jù)變化的趨勢，利用差分統(tǒng)計(jì)計(jì)算前后點(diǎn)之間的變化率，和自身數(shù)據(jù)前后趨勢作比較，生成變化率分析策略。

3.跌零檢測

對當(dāng)前數(shù)據(jù)進(jìn)行跌零檢測，結(jié)合損失話務(wù)量和跌零次數(shù)判斷是否告警。

4.自動告警邏輯：

根據(jù)以上三個(gè)策略對實(shí)時(shí)的監(jiān)控?cái)?shù)據(jù)進(jìn)行檢測：

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

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

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

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

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

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

• 話務(wù)量監(jiān)控

• 成功率監(jiān)控

• 周期性特征取值

• 小話務(wù)量的離散數(shù)據(jù)

• 關(guān)聯(lián)數(shù)據(jù)告警

• 長期小幅下跌

• 話務(wù)量自動檢測：

某號碼話務(wù)量在一個(gè)時(shí)間段數(shù)據(jù)陡降，連續(xù)2個(gè)點(diǎn)低于閾值下限，同時(shí)變化率大于門限值，觸發(fā)告警。

• 成功率自動檢測：

成功率的檢測不僅僅是檢測是否低于某固定指標(biāo)，也是需要根據(jù)不同業(yè)務(wù)的特性以及不同時(shí)間段進(jìn)行監(jiān)控。針對容量類或成功率等特殊監(jiān)控類型，我們基于歷史數(shù)據(jù)進(jìn)行閾值分析，生成動態(tài)的閾值上限或下限規(guī)則，即能滿足告警要求。

• 周期性特征取值：

因業(yè)務(wù)類型不同，部分話務(wù)數(shù)據(jù)存在陡升陡降情況。針對此類數(shù)據(jù)，我們采用特征分析的方法，自動發(fā)現(xiàn)其特征規(guī)律，減少誤告。

例如某監(jiān)控項(xiàng)在每周固定時(shí)間段有一個(gè)數(shù)據(jù)突升，我們通過特征分析發(fā)現(xiàn)了這個(gè)規(guī)律，作為后期告警檢測時(shí)的重要參考，避免誤告。

• 小話務(wù)量的離散數(shù)據(jù)

小業(yè)務(wù)量監(jiān)控項(xiàng)一直以來都是業(yè)務(wù)監(jiān)控的盲區(qū)，因?yàn)闃I(yè)務(wù)量小導(dǎo)致告警規(guī)則難以確定。對此我們采用了數(shù)據(jù)聚合的策略，從數(shù)據(jù)量和業(yè)務(wù)形態(tài)兩方面入手，自動分析監(jiān)控項(xiàng)特征并打上標(biāo)簽，通過不同聚合維度對監(jiān)控項(xiàng)進(jìn)行檢測和告警。

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

• 關(guān)聯(lián)告警

話務(wù)監(jiān)控項(xiàng)之間往往存在著一定的關(guān)聯(lián)性，我們通過將2個(gè)或多個(gè)相關(guān)的監(jiān)控項(xiàng)自動關(guān)聯(lián)，以減少誤告避免漏告。

下圖我們將傳真請求總量、傳真發(fā)送總量進(jìn)行關(guān)聯(lián)。以下紅色圓點(diǎn)請求總量增加，但發(fā)送總量沒有變化，因此進(jìn)行告警，而后面的請求總量增加，同時(shí)發(fā)送總量也增加，系統(tǒng)關(guān)聯(lián)后，不進(jìn)行告警。

圖11：關(guān)聯(lián)告警

• 長期小幅下跌

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

圖12：長期小幅下跌

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

自動測試功能的實(shí)現(xiàn)基于我們的另一款產(chǎn)品語音機(jī)器人”。針對話務(wù)量，成功率等監(jiān)控項(xiàng)，獲取疑似告警發(fā)生后，系統(tǒng)會調(diào)用語音機(jī)器人”功能，根據(jù)測試用例進(jìn)行自動測試，將測試結(jié)果返回后插入到告警信息中，并告知運(yùn)維負(fù)責(zé)人該告警為誤告。

圖13：自動測試報(bào)告

監(jiān)控系統(tǒng)發(fā)出告警之后，可能會引申出另一個(gè)問題，那就是告警風(fēng)暴。告警風(fēng)暴通常發(fā)生于以下兩種情況：

1、系統(tǒng)發(fā)生大型故障，多個(gè)監(jiān)控項(xiàng)同時(shí)發(fā)生告警

2、單個(gè)監(jiān)控項(xiàng)連續(xù)發(fā)生告警

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

這里有兩個(gè)規(guī)則：

1、同一通知組，1分鐘內(nèi)同時(shí)發(fā)生的不同告警合并成一個(gè)通知內(nèi)；

2、同一監(jiān)控項(xiàng)，30分鐘內(nèi)的告警只通知一次，不再重復(fù)通知；

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

• 便捷接入

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

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

圖14：采集配置

Step2：自動校驗(yàn)，生成監(jiān)控項(xiàng)

圖15：生成監(jiān)控項(xiàng)

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

圖16：全局配置

• 可視化編輯

圖表編輯頁面，可同時(shí)完成圖表命名、監(jiān)控項(xiàng)選擇、添加上周曲線、添加基線、修改顏色和編輯告警規(guī)則等典型場景下的常用操作

圖17：可視化編輯

• 運(yùn)維大屏

梳理各類運(yùn)維數(shù)據(jù)，投放到大屏上進(jìn)行綜合展示

圖18：運(yùn)維大屏

• 自動語音通知

對于告警通知，我們在郵件通知的基礎(chǔ)上增加了電話通知功能。在告警發(fā)生后，調(diào)用語音機(jī)器人”模塊向系統(tǒng)負(fù)責(zé)人手機(jī)發(fā)起呼叫，通過文本轉(zhuǎn)語音模塊將告警內(nèi)容自動轉(zhuǎn)化成語音及時(shí)通知應(yīng)用負(fù)責(zé)人。運(yùn)維人員在聽取告警內(nèi)容后，如暫時(shí)無需處理或暫時(shí)無需關(guān)注，可通過按鍵進(jìn)行屏蔽”或誤告”等操作，避免系統(tǒng)一直告警。

告警通知采用自動升級機(jī)制，如三次系統(tǒng)負(fù)責(zé)人不接聽電話，自動升級至其主管，如主管不接電話，自動升級至更高級別管理人員。（升級機(jī)制可通過參數(shù)配置）

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

將新監(jiān)控系統(tǒng)命名為Horus，寓意該系統(tǒng)能夠像古埃及神話中的Horus神一樣，擁有敏銳的鷹眼，及時(shí)準(zhǔn)確地發(fā)現(xiàn)業(yè)務(wù)數(shù)據(jù)上的異常。Horus系統(tǒng)也是我們從傳統(tǒng)業(yè)務(wù)監(jiān)控轉(zhuǎn)向自動化業(yè)務(wù)監(jiān)控的一款突破性產(chǎn)品，針對高度復(fù)雜業(yè)務(wù)實(shí)現(xiàn)面向用戶體驗(yàn)、面向業(yè)務(wù)可用性的實(shí)時(shí)監(jiān)測和自動告警，讓業(yè)務(wù)監(jiān)控更加簡潔、自動和高效。