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