傳統(tǒng)的呼叫中心主要依靠單一的電話呼入方式為客戶提供簡(jiǎn)單的服務(wù)，隨著IT技術(shù)和通訊技術(shù)的飛速發(fā)展，這種單一的電話方式已經(jīng)不能滿足客戶的需要，為順應(yīng)時(shí)代發(fā)展，客服系統(tǒng)涉及到的產(chǎn)品、技術(shù)和服務(wù)模式也在不斷的改革創(chuàng)新，現(xiàn)在的呼叫中心可以通過WEB、微信、APP、文字、視頻、傳真等多種渠道聯(lián)絡(luò)手段為客戶提供服務(wù)，以此更好的滿足客戶不斷變化的深層次需求。依托大數(shù)據(jù)、云計(jì)算和互聯(lián)網(wǎng)技術(shù)的快速發(fā)展，人工智能技術(shù)應(yīng)運(yùn)而生，并被快速應(yīng)用到呼叫中心領(lǐng)域，智能語音、機(jī)器人、語音識(shí)別、語義分析等產(chǎn)品的出現(xiàn)，有效降低了客服中心的人力成本，新技術(shù)、新產(chǎn)品引入的同時(shí)，客服系統(tǒng)的維護(hù)變得越來越復(fù)雜，目前各大銀行的客服系統(tǒng)涉及到的產(chǎn)品大約均在20個(gè)左右，維護(hù)難度之大可想而知，對(duì)于客服系統(tǒng)運(yùn)維人員來說也面臨著巨大的挑戰(zhàn)。
二、客服系統(tǒng)監(jiān)控發(fā)展歷程
客服系統(tǒng)的特點(diǎn)是，廠商多、產(chǎn)品多、專有設(shè)備多，監(jiān)控手段單一，G行針對(duì)客服系統(tǒng)的監(jiān)控經(jīng)歷了三個(gè)階段：
第一階段：基礎(chǔ)監(jiān)控+人工巡檢
客服系統(tǒng)建設(shè)初期，僅包括應(yīng)用、系統(tǒng)、中間件、數(shù)據(jù)庫等標(biāo)準(zhǔn)監(jiān)控，專有設(shè)備只能通過ping的方式獲取主機(jī)狀態(tài)，對(duì)于專有設(shè)備的資源占用情況運(yùn)維人員只能通過人工巡檢的方式查看，設(shè)備運(yùn)行風(fēng)險(xiǎn)較高。
第二階段：腳本輔助監(jiān)控
通過腳本的方式，獲取部分指標(biāo)寫入臨時(shí)文件，統(tǒng)一監(jiān)控平臺(tái)再通過定期輪詢的方式查看文件內(nèi)容，發(fā)現(xiàn)關(guān)鍵字，再通過短信方式推送告警給運(yùn)維人員。腳本輔助方式雖然增加了中繼組狀態(tài)、媒體資源、系統(tǒng)資源使用率等重要指標(biāo)監(jiān)控，但覆蓋范圍有限，獲取方式不靈活，實(shí)效性較差。
第三階段：專業(yè)平臺(tái)監(jiān)控
通過代理、接口、syslog、snmp等采集方式收集日志與告警信息，實(shí)時(shí)展示客服系統(tǒng)運(yùn)行狀態(tài)和關(guān)鍵指標(biāo)數(shù)據(jù)。監(jiān)控采集方式由被動(dòng)的輪詢式告警轉(zhuǎn)變?yōu)橹鲃?dòng)推送的流式告警，專業(yè)監(jiān)控平臺(tái)雖然可以解決80%的告警需求，但還有一些特殊化的需求還不能覆蓋，比如陡增突降告警、同比環(huán)比等復(fù)雜的需要經(jīng)過統(tǒng)計(jì)運(yùn)算的告警、智能化故障診斷及業(yè)務(wù)關(guān)聯(lián)影響分析等。
三、客服智能監(jiān)控分析平臺(tái)建設(shè)
G行目前正在進(jìn)行客服智能監(jiān)控分析平臺(tái)建設(shè)，在平臺(tái)建設(shè)之前，G行從業(yè)務(wù)視角、科技運(yùn)維等角度深度挖掘客服智能監(jiān)控要解決的核心問題：
從業(yè)務(wù)視角考慮，客服智能監(jiān)控分析平臺(tái)需要解決的核心問題主要有如下幾個(gè)方面：
- 支持關(guān)鍵KPI指標(biāo)和運(yùn)營(yíng)能力指標(biāo)實(shí)時(shí)展示，包括坐席KPI指標(biāo)、渠道話務(wù)量統(tǒng)計(jì)、區(qū)域話務(wù)量統(tǒng)計(jì)等
- 支持話務(wù)量按日預(yù)測(cè)及實(shí)時(shí)矯正二次預(yù)測(cè)功能
- 支持客服重點(diǎn)交易、熱點(diǎn)業(yè)務(wù)、投訴、輿情等數(shù)據(jù)實(shí)時(shí)展示
- 對(duì)惡意呼叫進(jìn)行核實(shí)與屏蔽，可實(shí)時(shí)展示異常掛機(jī)數(shù)據(jù)，分析掛機(jī)原因
從科技運(yùn)維角度考慮，客服智能監(jiān)控分析平臺(tái)需要解決如下問題：
- 覆蓋客服產(chǎn)品監(jiān)控盲區(qū)，涉及PBX、IVR、CTI、媒體網(wǎng)關(guān)等特殊設(shè)備的監(jiān)控，監(jiān)控指標(biāo)包括中繼利用率、媒體資源使用率、IVR并發(fā)量、CTI鏈路消息數(shù)、CTI鏈路狀態(tài)、媒體網(wǎng)關(guān)狀態(tài)等
- 實(shí)現(xiàn)對(duì)客服人工智能產(chǎn)品的監(jiān)控，包括ASR、TTS、機(jī)器人等產(chǎn)品的并發(fā)量、許可使用量等數(shù)據(jù)的實(shí)時(shí)統(tǒng)計(jì)與展示
- 為容量管理提供有效的、準(zhǔn)確的數(shù)據(jù)支撐
- 指導(dǎo)運(yùn)維人員快速定位、快速恢復(fù)生產(chǎn)問題
- 支持對(duì)歷史發(fā)生的事件進(jìn)行復(fù)盤、推演、溯源
- 智能診斷、智能分析故障對(duì)業(yè)務(wù)的影響
基于上述監(jiān)控體系指標(biāo)和功能需求，整體框架示意圖如下所示：
客服智能監(jiān)控分析平臺(tái)自下而上的架構(gòu)如下：
- 數(shù)據(jù)采集層：負(fù)責(zé)監(jiān)控分析數(shù)據(jù)采集與預(yù)處理策略執(zhí)行。數(shù)據(jù)采集層支持多協(xié)議，以實(shí)現(xiàn)異構(gòu)數(shù)據(jù)源的采集。采集模塊支持分布式水平擴(kuò)展，以滿足大規(guī)模、高時(shí)效數(shù)據(jù)的采集需求。
- 數(shù)據(jù)存儲(chǔ)層：采用高速緩存中間件Redis實(shí)現(xiàn)對(duì)復(fù)雜或操作代價(jià)較高的實(shí)時(shí)數(shù)據(jù)進(jìn)行緩存，以保障實(shí)時(shí)數(shù)據(jù)的高頻訪問效率。采用Elasticsearch實(shí)現(xiàn)離線數(shù)據(jù)存儲(chǔ)，支持高吞吐數(shù)據(jù)寫入以及大規(guī)模數(shù)據(jù)存儲(chǔ)，存儲(chǔ)和查詢性能可線性擴(kuò)展。配置數(shù)據(jù)則采用關(guān)系型數(shù)據(jù)庫Oracle實(shí)現(xiàn)持久化存儲(chǔ)，提供事務(wù)型數(shù)據(jù)處理。
- 分析與計(jì)算層：實(shí)現(xiàn)分析規(guī)則和算法計(jì)算。分析規(guī)則包括告警觸發(fā)規(guī)則、告警處理規(guī)則、容量分析規(guī)則、關(guān)聯(lián)分析規(guī)則等。通過模式匹配引擎分析流式數(shù)據(jù)中的時(shí)序與依賴關(guān)系，實(shí)現(xiàn)數(shù)據(jù)關(guān)聯(lián)分析。匹配規(guī)則可動(dòng)態(tài)配置以適應(yīng)復(fù)雜多變的業(yè)務(wù)需求，通過歷史數(shù)據(jù)的對(duì)比和分析，實(shí)現(xiàn)閾值的動(dòng)態(tài)調(diào)節(jié)。
- 業(yè)務(wù)展現(xiàn)層：實(shí)現(xiàn)業(yè)務(wù)功能展示。通過Spring Cloud微服務(wù)實(shí)現(xiàn)業(yè)務(wù)模塊標(biāo)準(zhǔn)化，支持按需彈性擴(kuò)展，通過Spring Security提供統(tǒng)一的權(quán)限和登錄控制，通過Portal提供視圖的組件化管理，實(shí)現(xiàn)業(yè)務(wù)視圖的靈活定制化。
采集與處理流程
隨著業(yè)務(wù)的發(fā)展和智能化平臺(tái)的引入，監(jiān)控對(duì)象的分類和數(shù)量越來越多，各類數(shù)據(jù)，如指標(biāo)數(shù)據(jù)、分析數(shù)據(jù)、日志、告警等更是指數(shù)級(jí)倍增。因此，一方面數(shù)據(jù)采集與處理流程應(yīng)實(shí)現(xiàn)各類數(shù)據(jù)的統(tǒng)一轉(zhuǎn)譯和結(jié)構(gòu)化處理，使得數(shù)據(jù)可識(shí)別、可使用；另一方面客服智能監(jiān)控平臺(tái)除了關(guān)注運(yùn)行數(shù)據(jù)外，還需要深入到運(yùn)營(yíng)業(yè)務(wù)流程中，匯集整合客服業(yè)務(wù)運(yùn)營(yíng)和系統(tǒng)運(yùn)行的各類數(shù)據(jù)，形成完備的數(shù)據(jù)集合，完成數(shù)據(jù)互聯(lián)。采集與處理設(shè)計(jì)方案需具備低耦合、高內(nèi)聚、彈性擴(kuò)展等特點(diǎn)，才能滿足高并發(fā)、高時(shí)效、大規(guī)模數(shù)據(jù)處理的需求。
分析模型與計(jì)算
客服智能監(jiān)控分析平臺(tái)中的分析模型和計(jì)算能力是實(shí)現(xiàn)智能運(yùn)維的關(guān)鍵點(diǎn)，分析模型決定了監(jiān)控分析結(jié)果的有效性和深度，計(jì)算能力是保障智能監(jiān)控分析目標(biāo)得以實(shí)現(xiàn)的首要因素。從話務(wù)異常分析、容量分析、故障關(guān)聯(lián)影響分析、故障復(fù)盤推演等方面設(shè)計(jì)模型，并不斷優(yōu)化，達(dá)成智能化監(jiān)控的目標(biāo)。
場(chǎng)景實(shí)踐與思考
1、告警關(guān)聯(lián)分析
客服系統(tǒng)是一個(gè)復(fù)雜的有機(jī)體，每個(gè)組件的故障不再是孤立的事件，有可能影響到業(yè)務(wù)的可用性或者客戶的訪問體驗(yàn)，因此基于組件間的業(yè)務(wù)依賴和數(shù)據(jù)流向構(gòu)建組件關(guān)系圖譜，可實(shí)現(xiàn)故障的關(guān)聯(lián)影響分析，判斷出故障的影響范圍和程度，為運(yùn)維工作的處理決策提供數(shù)據(jù)支撐。
當(dāng)組件出現(xiàn)故障時(shí)，依據(jù)組件間的關(guān)系類型，系統(tǒng)可以判斷出關(guān)聯(lián)組件的可用性或容量是否會(huì)受到影響，可計(jì)算出此影響是否會(huì)傳導(dǎo)到業(yè)務(wù)層或其他組件上。
2、運(yùn)營(yíng)數(shù)據(jù)關(guān)聯(lián)分析
運(yùn)維工作的目標(biāo)是保障業(yè)務(wù)的可用性和連續(xù)性，當(dāng)業(yè)務(wù)存在異常時(shí)，可基于客服系統(tǒng)正常運(yùn)行模型的匹配來識(shí)別。以呼叫日志分析模型為例，當(dāng)運(yùn)營(yíng)監(jiān)控中顯示隊(duì)列排隊(duì)人數(shù)較多時(shí)，有可能是坐席比較繁忙，人手不夠?qū)е拢灿锌赡苁强头到y(tǒng)自身原因?qū)е潞艚袩o法正常分配給坐席，我們可以通過呼叫日志分析模型檢測(cè)電話呼叫是否存在異常，當(dāng)呼叫日志流流入計(jì)算框架時(shí)，檢測(cè)到與正常呼叫日志不匹配時(shí)，則可判斷為客服系統(tǒng)異常。
3、故障復(fù)盤與推演
故障發(fā)生時(shí)，運(yùn)維人員大都是優(yōu)先處理故障，盡快恢復(fù)系統(tǒng)正常使用，如果事后不對(duì)故障進(jìn)行復(fù)盤分析的話，再次發(fā)生故障時(shí)，運(yùn)維人員仍然不能快速識(shí)別出同類故障，影響故障處置效率。智能監(jiān)控分析平臺(tái)在告警發(fā)生時(shí)，不但可以識(shí)別出故障并生成告警信息，還會(huì)保留故障相關(guān)的周邊信息，以時(shí)序方式記錄故障的上下文場(chǎng)景和組件間關(guān)聯(lián)告警信息，并支持以電影放映的模式，將故障發(fā)生前后的各種相關(guān)數(shù)據(jù)進(jìn)行回放和推演，以便發(fā)現(xiàn)故障發(fā)生的規(guī)律，優(yōu)化故障分析模型，為運(yùn)維人員快速定位故障原因提供工具支撐。
下一階段建設(shè)目標(biāo)
數(shù)據(jù)是一切運(yùn)維的基礎(chǔ)，也是智能監(jiān)控分析和數(shù)據(jù)驅(qū)動(dòng)運(yùn)維的關(guān)鍵資源，未來幾年，客服智能監(jiān)控分析平臺(tái)的智能化程度將會(huì)持續(xù)加深，數(shù)據(jù)也將變得更加連貫和立體�？头悄鼙O(jiān)控平臺(tái)下一步將在業(yè)務(wù)探測(cè)、趨勢(shì)預(yù)測(cè)、動(dòng)態(tài)閥值、智能告警方面進(jìn)行更深入的研究與嘗試。
