2020年全球運維大會-全球最大呼叫平臺監(jiān)控實踐課件

全球最大呼叫平臺監(jiān)控實踐之路

全球最大呼叫平臺監(jiān)控實踐之路1目錄背景-全國集中維護、全球最大1出路-選擇開源2轉型-幾個問題3蛻變-AIOPS在監(jiān)控報警方面的嘗試4

目錄背景-全國集中維護、全球最大1出路-選擇開源2轉型-幾個2中移在線公司移動全網集中服務提供者移動全網業(yè)務后臺集中處理者移動全網渠道運營集中支撐者201431省呼叫業(yè)務完成劃轉奠定全網集中化運營基礎2016實現(xiàn)盈利業(yè)務發(fā)展和改革創(chuàng)新初見成效全集團首批入選國資委國企改革“雙百行動”三家公司之一2018201710月注冊成立全集團集中化、專業(yè)化運營試驗田發(fā)展歷程

中移在線公司移動全網集中服務提供者移動全網業(yè)務后臺集中處理3傳統(tǒng)呼叫中心傳統(tǒng)呼叫中心是基于PBX、專用硬件排隊機、硬件語音板卡等專用設備組成的客服系統(tǒng)。軟硬一體，不夠靈活建設成本高、周期長、維護升級困難無法滿足多渠道多媒體互聯(lián)網相關增值業(yè)務的融合無法實現(xiàn)多客服中心坐席跨網協(xié)同無法快速響應業(yè)務需求缺點排隊機CTIIVR應用PSTN/PLMNPBX坐席坐席

傳統(tǒng)呼叫中心傳統(tǒng)呼叫中心是基于PBX、專用硬件排隊機、硬件語4新形態(tài)呼叫中心語音坐席視頻坐席互聯(lián)網坐席熱線互聯(lián)網新形態(tài)下的呼叫中心質量管控大數(shù)據(jù)平臺支持客戶全渠道交互智能質檢智能導航智能應答轉人工智能知識庫坐席助手語音客服視頻客服在線客服智能IVR智能運營運營管理呼叫平臺統(tǒng)一排隊統(tǒng)一路由統(tǒng)一監(jiān)控純軟件：全媒體CTI、IVR、互聯(lián)網接入網關、軟交換、中繼網關、媒體加速服務、用戶終端富媒體：支持傳統(tǒng)語音、文本、圖片、視頻、短語音、微信、微博智能化：與人工智能（AI）、大數(shù)據(jù)技術結合，應用于IVR、機器人應答、質檢、外呼等集中化：接續(xù)、CRM、分析、質檢、話務監(jiān)控等集中化特征

新形態(tài)呼叫中心語音坐席視頻坐席互聯(lián)網坐席熱線互聯(lián)網新形5在線公司:

全球最大呼叫中心河南江蘇北京我們面臨的運維挑戰(zhàn)多難高用戶多,

IT規(guī)模接近一線互聯(lián)網企業(yè)9億用戶,

超1億微信粉絲，月服務超億次，微博矩陣粉絲3038萬（居行業(yè)首位），10086APP超五千萬用戶量20000+服務器50000+Tomcat業(yè)務變化快，運維環(huán)境復雜支撐全國營銷活動，總部/分公司/省公司多級協(xié)同日均上線

17

次，日處理

206

例工單技術新：微服務/云計算/容器

…要求高，提供電信級服務99.99%

的可靠性15秒接通要求7*24

小時保障

在線公司:全球最大呼叫中心河南江蘇北京我們面臨的運維挑戰(zhàn)多6轉變運維思路，適應新的時代挑戰(zhàn)為了支持業(yè)務快速上線和高效運維。在線公司監(jiān)控系統(tǒng)需具備敏捷、集中、自動、智能的關鍵能力。自動敏捷之前能力建設智能現(xiàn)在監(jiān)控能力周粒度提供監(jiān)控能力分鐘級提供按專業(yè)劃分的“煙囪式監(jiān)控”混合集中化監(jiān)控手工添加基于策略的自動化閉環(huán)依賴專家經驗基于AI和大數(shù)據(jù)的自動識別集中

轉變運維思路，適應新的時代挑戰(zhàn)為了支持業(yè)務快速上線和高效運維7目錄1234背景-全國集中維護、全球最大出路-選擇開源轉型-幾個問題蛻變-AIOPS在監(jiān)控報警方面的嘗試

目錄1234背景-全國集中維護、全球最大出路-選擇開源轉型-8統(tǒng)一監(jiān)控平臺：開源工具+二次開發(fā)，自主核心可控監(jiān)控管理Grafana統(tǒng)一門戶ITSM運維平臺自動化平臺CMDB統(tǒng)一告警平臺統(tǒng)一事件分析告警告警接口性能看板告警事件管理短信郵件工單信息故障定位或修復場景業(yè)務看板根因分析業(yè)務建模業(yè)務模型和配置數(shù)據(jù)被管環(huán)境Java

App.NET

AppPHP,Python,

NodeJS應用系統(tǒng)客服系統(tǒng)監(jiān)控（I2000）應用性能監(jiān)控（APM）告警信息場景執(zhí)行調用性能看板業(yè)務看板業(yè)務數(shù)據(jù)PrometheusmetricElasticSearch數(shù)據(jù)庫數(shù)據(jù)庫監(jiān)控（Prometheus）基礎架構監(jiān)控（Zabbix）CTI/UAP系統(tǒng)服務器、網絡、存儲、虛擬化環(huán)境等告警看板Kafka實時融合監(jiān)控：引入業(yè)界開源工具，進行二次開發(fā)與封裝，形成核心自主可控、穩(wěn)定高效、海量秒級的監(jiān)控能力?？缬?跨廠商/跨層的IT/CT實時融合監(jiān)控。有豐富的管理對象。多樣靈活的數(shù)據(jù)展現(xiàn)形式，可以靈活配置，適應不同場景，快速定制。監(jiān)控數(shù)據(jù)

統(tǒng)一監(jiān)控平臺：開源工具+二次開發(fā)，自主核心可控監(jiān)控管理Gra9統(tǒng)一監(jiān)控平臺：集中建設、統(tǒng)一管控、邊緣節(jié)點標準化為了更快速的建立監(jiān)控能力、更全面的管控系統(tǒng)質量，在線服務公司統(tǒng)一監(jiān)控平臺采用了總部集中建設、統(tǒng)一管控，分公司標準化接入的建設模式。全網集中：總部負責監(jiān)控能力建設、邊緣節(jié)點的標準化，所有監(jiān)控數(shù)據(jù)的上收、分析、展現(xiàn)與通知。分公司提供資源，遵照標準化、封裝后的監(jiān)控模板進行監(jiān)控資源的維護與管理。

統(tǒng)一監(jiān)控平臺：集中建設、統(tǒng)一管控、邊緣節(jié)點標準化為了更快速的10一些小總結：半年時間2萬200

萬90

萬30

萬主機監(jiān)控項觸發(fā)器報警84400+5451.3KProxyDashBoard用戶數(shù)動作

一些小總結：半年時間2萬200萬90萬30萬主機監(jiān)控11一些小總結：廣泛、豐富、多樣、靈活

一些小總結：廣泛、豐富、多樣、靈活12網絡設備類型與廠家存活/丟包/時延CPU/內存占用率snmp狀態(tài)溫度端口狀態(tài)出/入口帶寬利用率出/入口丟、錯包接口類型設備狀態(tài) 網卡狀態(tài) 設備信息端口描述軟件版本系統(tǒng)名稱光功率光模塊接收功率網絡協(xié)議光模塊發(fā)送 BGP對等體功率 連接狀態(tài)ospf鄰居狀態(tài)vrrp虛擬路由狀態(tài)網絡監(jiān)控指標SNMP一些小總結：廣泛、豐富、多樣、靈活

網絡設備類型與廠家存活/丟包/時延CPU/內存占用率sn13一些小總結：廣泛、豐富、多樣、靈活看板可靈活制定，分鐘級完成配置。圖表多樣化展現(xiàn)：折線圖、柱狀圖、餅圖、區(qū)域圖、拓撲圖等。

一些小總結：廣泛、豐富、多樣、靈活看板可靈活制定，分鐘級完成14主機參數(shù)內核參數(shù)TCP協(xié)議棧參數(shù)信號量/IO（Zabbix啟動失敗不釋放信號集）數(shù)據(jù)庫CPU/內存/IO連接（最大連接數(shù)、超時時長）數(shù)據(jù)一致性強烈建議采用數(shù)據(jù)庫SSD硬盤WEBNginx參數(shù)Php參數(shù)php.ini：max_input_vars（影響模板應用大批量主機失?。㈱abbix視具體需求配置啟動模塊和進程數(shù)禁用自動發(fā)現(xiàn)，采用腳本調用api實現(xiàn)禁用housekeeper，啟用數(shù)據(jù)庫表分區(qū)禁用server直連agent配置參數(shù)優(yōu)化defines.inc.php：QUEUE_DETAIL_ITEM_COUNT（定義監(jiān)控項隊列檢索限制，影響消息隊列積壓顯示）一些小總結：zabbix系統(tǒng)優(yōu)化

主機參數(shù)數(shù)據(jù)庫WEBZabbix一些小總結：zabbix系統(tǒng)15一些小總結：zabbix系統(tǒng)優(yōu)化二、Preprocessing

manager

負荷長期為100%三、Zabbix

server主機反復重啟，卻無法啟動成功問題現(xiàn)象與影響一、大量消息隊列積壓（超過20萬），且呈現(xiàn)雪崩效應問題定位與解決方案一、zabbix官網對于pre-process耗盡的說明：二、解決方案：1、在zabbix

server所在主機再單獨部署一個proxy節(jié)點。2、將之前由zabbix

server直接監(jiān)控的所有proxy所在主機的agent節(jié)點，全部轉到新增proxy管理。3、降低server的pollers、java

pollers、pingers、trappers等進程數(shù)配置。4、增加zabbix

server的自監(jiān)控項配置項及告警（

Pre-process進程占用率及zabbix_server.log的異常關鍵字告警）。

一些小總結：zabbix系統(tǒng)優(yōu)化二、Preprocessin16Zabbix配置的同步機制Zabbix的配置表比較多，大容量局點關聯(lián)查詢sql耗時很長如數(shù)據(jù)庫控制sql執(zhí)行時間的max_execution_time配置不合理，會導致無法將相應配置表數(shù)據(jù)同步到zabbix

server以及proxy的cache，從而導致出現(xiàn)大量監(jiān)控項無法正常采集及消息隊列積壓現(xiàn)象。以下為zabbix_server.log相應日志：數(shù)據(jù)庫sql執(zhí)行超時配置建議根據(jù)現(xiàn)網的數(shù)據(jù)庫IO處理性能以及局點規(guī)模合理配置數(shù)據(jù)庫超時相關參數(shù)，將max_execution_time設置為超過目前zabbix

server同步配置sql執(zhí)行時長的2倍以上，并定期檢查zabbix_server.log日志的相應執(zhí)行時長，或者增加自監(jiān)控告警。一些小總結：zabbix系統(tǒng)優(yōu)化

Zabbix配置的同步機制Zabbix的配置表比較多，大容量17目錄1234背景-全國集中維護、全球最大出路-選擇開源轉型-幾個問題蛻變-AIOPS在監(jiān)控告警方面的嘗試

目錄1234背景-全國集中維護、全球最大出路-選擇開源轉型-18問題一：200w監(jiān)控指標，業(yè)務出了問題仍然不知道治理范圍應用系統(tǒng)管理業(yè)務質量管理客戶體驗管理能力擴展基礎設施管理基礎設施性能管理(PM)基礎設施故障管理(FM)用戶問題管理用戶感知管理業(yè)務問題管理業(yè)務質量管理以業(yè)務質量和客戶體驗為核心，以可管控、可視化、可度量為目標。全網集中建設、集中管控、邊緣節(jié)點標準化接入。軟件監(jiān)控+硬件監(jiān)控一網打盡，運維數(shù)據(jù)統(tǒng)一、融合、流動，建立多層次度量體系。以用戶體驗出發(fā)，建立端到端全鏈路監(jiān)控，告警+投訴預警+客服聯(lián)動形成完整閉環(huán)管理。運維保障應用性能管理(PM)應用故障管理(FM)流程及自動化管理

問題一：200w監(jiān)控指標，業(yè)務出了問題仍然不知道治理范圍應19業(yè)務及應用質量可感知，是監(jiān)控的核心ServerOSDBJVMMQWEB面向基礎架構的監(jiān)控只能發(fā)現(xiàn)約30%的問題從用戶體驗出發(fā)面向應用的監(jiān)控能發(fā)現(xiàn)約70%的問題最終用戶體驗應用程序基礎架構梳理業(yè)務系統(tǒng)核心功能模塊梳理功能模塊的核心監(jiān)控指標評審監(jiān)控指標的提取方式及有效性監(jiān)控看板制作在強化基礎設置監(jiān)控的基礎上，補充應用性能監(jiān)控和業(yè)務質量監(jiān)控能力，保障業(yè)務的穩(wěn)定性和客戶感知。應用性能監(jiān)控 業(yè)務質量監(jiān)控參考Google

SRE五項黃金指標1：速率：請求速率，請每秒請求數(shù)量。2：錯誤：

錯誤率，即每秒錯誤數(shù)量。3：延遲：

響應時間，包括隊列/

等待時間，以毫秒為單位。4：飽和度：即過載程度，指標與資源利用率相關，也可通過隊列深度進行直接衡量。5：利用率：

資源或系統(tǒng)的繁忙程度，通常表示為

0%

至

100%。應用性能監(jiān)控將前臺頁面與后端服務以及用戶網絡環(huán)境真正串聯(lián)，做到端到端全鏈路、代碼級監(jiān)控。用戶體驗評分

前端交互體驗 網絡切片 應用調用拓撲

代碼定位追蹤

業(yè)務及應用質量可感知，是監(jiān)控的核心ServerOSDBJ20問題二：海量的日志是否有利用價值？對于亞健康狀態(tài)，異常日志比系統(tǒng)故障更早出現(xiàn)。由于海量日志存儲在海量網元中，不同廠商日志標準不統(tǒng)一且可讀性差，往往很難鑒別真正觸發(fā)異常的日志。挑戰(zhàn)海量日志保存在海量網元中，缺乏統(tǒng)一視圖不同廠商設備的日志缺乏統(tǒng)一標準，可讀性差XXXX@%#&(*(

￥%……—*XXXX@#$%&*(%#@#$%CXXXX@!#$*^#$!@%$*(*(^XXXXERROR*&^%$#$*()*^日志統(tǒng)一采集，統(tǒng)一呈現(xiàn)，異廠商設備日志統(tǒng)一查詢針對異常日志進行統(tǒng)計，實時推送異常日志告警，提升亞健康網絡問題定位效率①跨廠商設備日志統(tǒng)一查詢②異常日志統(tǒng)計③異常日志分析與告警推送統(tǒng)一日志分析Syslog網絡設備(

Huawei,

HP,

IBM,…)Logstash一體化客服系統(tǒng)精準扶貧實名制 語音管控…價值Cloud

OS

問題二：海量的日志是否有利用價值？挑戰(zhàn)海量日志保存在海量網21問題三：一個業(yè)務監(jiān)控需要添加2480萬個監(jiān)控項？監(jiān)控內容接口平臺類型（

4）：接入接口，接入渠道，轉接接口，轉接渠道系統(tǒng)編碼（31）：為各省分公司的編碼監(jiān)控項類型(8）：調用總數(shù)，成功率，平均耗時，失敗率，失敗數(shù)，大于1s比率，大于3s比率，大于5s比率監(jiān)控項名稱（500+）：從業(yè)務數(shù)據(jù)庫實時查詢監(jiān)控項名稱錯誤碼（50+）：業(yè)務指標的錯誤碼類型 （4*31*8*500*50=2480萬）監(jiān)控項類型大：千萬級監(jiān)控項組合，zabbix方案暫無法實現(xiàn)（包括監(jiān)控配置和展示）圖形展示篩選條件要求可配置，動態(tài)關聯(lián)：zabbix解決方案暫無法實現(xiàn)（個性化tag無法關聯(lián)查詢）。難點說明解決方案利用prometheus靈活的自定義babel功能實現(xiàn)數(shù)據(jù)采集和動態(tài)圖形展示

問題三：一個業(yè)務監(jiān)控需要添加2480萬個監(jiān)控項？監(jiān)控內容接22監(jiān)控平臺架構的改進與優(yōu)化管控資源對象運維數(shù)據(jù)分析平臺上層運維場景應用CMDB數(shù)據(jù)庫企業(yè)資源數(shù)據(jù)監(jiān)控底層能力平臺PrometheusAPMHadoop離線數(shù)據(jù)分析運維數(shù)據(jù)分析內部用戶物理設備云平臺 網絡一體化客服業(yè)務監(jiān)控客服設備監(jiān)控。。。容量管理自動化擴縮容。。。故障決策系統(tǒng)自動化切換。。。Zabbix外部客戶日志 容器云

業(yè)務監(jiān)控

數(shù)據(jù)庫 應用 中間件日志平臺規(guī)則數(shù)據(jù)機器學習數(shù)據(jù)Flink實時數(shù)據(jù)處理運維數(shù)據(jù)分析

監(jiān)控平臺架構的改進與優(yōu)化管控資源對象運維數(shù)據(jù)分析平臺上層23大型互聯(lián)網公司基礎資源多，業(yè)務廣，線上變更頻繁，監(jiān)控配置任務量大監(jiān)控添加不是一蹴而就，需要反復調整，重復工作量大開源工具使用門檻高，大多沒有好用的web界面，需要培訓才能靈活使用中移在線公司業(yè)務/工作人員遍布全國各省，基礎資源達到上萬級別，業(yè)務變更頻繁，統(tǒng)一管理難度系數(shù)高痛點應對方案12監(jiān)控能力標準化、流程化、模塊化二次開發(fā)、

3自動化配置界面化數(shù)據(jù)展示界面化問題四：加不完的監(jiān)控需求？

大型互聯(lián)網公司基礎資源多，業(yè)務廣，線上變更頻繁，監(jiān)控配置任24中移在線監(jiān)控的歷程（摸著石頭過河）1需求分析與功能驗證23全網推廣性能調優(yōu)典型問題與4軟件bug處理規(guī)范化制定與整改5運維界面化與自動化欲速則不達沒有規(guī)范化的交付，質量無法保證返工意味著效率降低3倍以上12需求分析與功能驗證標準與規(guī)范制定3性能調優(yōu)典型問題與軟件bug處理4批量推廣5運維界面化與自動化建議流程（標準先行，質量與效率并重）模板、主機群組、主機名，主機顯示名、動作名稱、展板內容等等需求交付/變更流程，問題處理流程，例行會議與周報一點感悟

中移在線監(jiān)控的歷程（摸著石頭過河）1需求分析與功能驗證225現(xiàn)在的數(shù)字2.4

萬主機99

萬觸發(fā)器1.3K動作614

萬監(jiān)控項198

萬報警Proxy92800+ 975DashBoard 用戶數(shù)

現(xiàn)在的數(shù)字2.4萬99萬1.3K614萬198萬報警26目錄1234背景-全國集中維護、全球最大出路-選擇開源轉型-幾個問題蛻變-AIOPS在監(jiān)控告警方面的嘗試

目錄1234背景-全國集中維護、全球最大出路-選擇開源轉型-27當前的主要矛盾是：海量的告警和有限的專家告警要“少而精”，不要重復和誤報監(jiān)控要“多而全”，一個問題都不能放過！614萬+

監(jiān)控指標，99萬+

報警閾值，

198萬+

告警/天，

2000+

短信/每人每天運維主管工程師小明VS.

當前的主要矛盾是：海量的告警和有限的專家告警要“少而精”，28經過分析，閾值正確設定是平衡“多而全”和“少而精”的關鍵手段之一告警正常告警誤報漏報缺少壓縮&關聯(lián)閾值不合理：80%監(jiān)控能力不足：10%人員配置失誤：10%無法設定閾值：70%無監(jiān)控：30%

經過分析，閾值正確設定是平衡“多而全”和“少而精”的關鍵手段29閾值設定從依靠專家經驗向智能動態(tài)設定演進專家依靠經驗設定規(guī)則閾值通過大數(shù)據(jù)分析設定固定閾值通過智能分析動態(tài)設定智能動態(tài)閾值

閾值設定從依靠專家經驗向智能動態(tài)設定演進專家依靠經驗設定通30基于結構化的時序數(shù)據(jù)，通過AI預測擬合曲線，進行異常檢測歷史數(shù)據(jù)分析歷史數(shù)據(jù)讀取和清洗數(shù)據(jù)抽取ETL斷點修復數(shù)據(jù)間隔調整自相關性分析毛刺檢測統(tǒng)計異常檢測，用于過濾毛刺型異常Moving

Average移動平均濾波(ARIMA)Exponential

Smoothing指數(shù)平滑濾波

(Holt-Winters)N*sigma統(tǒng)計檢測指標預測LSTM（長短期記憶）預測算法孤立森林（IsolationForest）日同比（Day

overDaymethod）箱線圖（Box-whisker

plot）異常判定途徑一：N-sigma方差途徑二：專家標記

基于結構化的時序數(shù)據(jù)，通過AI預測擬合曲線，進行異常檢測歷史31智能化運維并不是我們想象的那樣遙不可及告警覆蓋率提升到95%告警配置人力下降60%告警準確率提升到80%數(shù)據(jù)算法計算海量數(shù)據(jù)源（性能指標、日志、告警）可以迭代預測、迭代標注……TensorFlow等成熟算法庫針對不同場景，可選擇不同算法，如LSTM用于趨勢預測、ARIMA用于回歸過濾異常輕量化虛擬機部署，4C32G即可起步

智能化運維并不是我們想象的那樣遙不可及告警覆蓋率提升到9532未來讓智能化在更多運維領域落地開花智能故障發(fā)現(xiàn)日志異常檢測、告警壓縮&關聯(lián)、告警規(guī)則生成、容量管理、性能管理等深度廣度

未來讓智能化在更多運維領域落地開花智能故障發(fā)現(xiàn)日志異常檢測33系統(tǒng)架構師、運維開發(fā)、應用運維、數(shù)據(jù)庫運維、大數(shù)據(jù)運維、數(shù)據(jù)分析、容器云開發(fā)、云計算開發(fā)、JAVA開發(fā)享受互聯(lián)網般技術挑戰(zhàn)國企穩(wěn)定待遇鄭州、北京、上海、深圳研發(fā)中心，31省會城市與客戶交互產生的海量數(shù)據(jù)，包括語音、文本、圖像等數(shù)據(jù)公司年輕、人員年輕、扁平化管理

系統(tǒng)架構師、運維開發(fā)、應用運維、數(shù)據(jù)庫運維、大數(shù)據(jù)運維、數(shù)據(jù)34謝謝

謝謝35全球最大呼叫平臺監(jiān)控實踐之路

全球最大呼叫平臺監(jiān)控實踐之路36目錄背景-全國集中維護、全球最大1出路-選擇開源2轉型-幾個問題3蛻變-AIOPS在監(jiān)控報警方面的嘗試4

目錄背景-全國集中維護、全球最大1出路-選擇開源2轉型-幾個37中移在線公司移動全網集中服務提供者移動全網業(yè)務后臺集中處理者移動全網渠道運營集中支撐者201431省呼叫業(yè)務完成劃轉奠定全網集中化運營基礎2016實現(xiàn)盈利業(yè)務發(fā)展和改革創(chuàng)新初見成效全集團首批入選國資委國企改革“雙百行動”三家公司之一2018201710月注冊成立全集團集中化、專業(yè)化運營試驗田發(fā)展歷程

中移在線公司移動全網集中服務提供者移動全網業(yè)務后臺集中處理38傳統(tǒng)呼叫中心傳統(tǒng)呼叫中心是基于PBX、專用硬件排隊機、硬件語音板卡等專用設備組成的客服系統(tǒng)。軟硬一體，不夠靈活建設成本高、周期長、維護升級困難無法滿足多渠道多媒體互聯(lián)網相關增值業(yè)務的融合無法實現(xiàn)多客服中心坐席跨網協(xié)同無法快速響應業(yè)務需求缺點排隊機CTIIVR應用PSTN/PLMNPBX坐席坐席

傳統(tǒng)呼叫中心傳統(tǒng)呼叫中心是基于PBX、專用硬件排隊機、硬件語39新形態(tài)呼叫中心語音坐席視頻坐席互聯(lián)網坐席熱線互聯(lián)網新形態(tài)下的呼叫中心質量管控大數(shù)據(jù)平臺支持客戶全渠道交互智能質檢智能導航智能應答轉人工智能知識庫坐席助手語音客服視頻客服在線客服智能IVR智能運營運營管理呼叫平臺統(tǒng)一排隊統(tǒng)一路由統(tǒng)一監(jiān)控純軟件：全媒體CTI、IVR、互聯(lián)網接入網關、軟交換、中繼網關、媒體加速服務、用戶終端富媒體：支持傳統(tǒng)語音、文本、圖片、視頻、短語音、微信、微博智能化：與人工智能（AI）、大數(shù)據(jù)技術結合，應用于IVR、機器人應答、質檢、外呼等集中化：接續(xù)、CRM、分析、質檢、話務監(jiān)控等集中化特征

新形態(tài)呼叫中心語音坐席視頻坐席互聯(lián)網坐席熱線互聯(lián)網新形40在線公司:

全球最大呼叫中心河南江蘇北京我們面臨的運維挑戰(zhàn)多難高用戶多,

IT規(guī)模接近一線互聯(lián)網企業(yè)9億用戶,

超1億微信粉絲，月服務超億次，微博矩陣粉絲3038萬（居行業(yè)首位），10086APP超五千萬用戶量20000+服務器50000+Tomcat業(yè)務變化快，運維環(huán)境復雜支撐全國營銷活動，總部/分公司/省公司多級協(xié)同日均上線

17

次，日處理

206

例工單技術新：微服務/云計算/容器

…要求高，提供電信級服務99.99%

的可靠性15秒接通要求7*24

小時保障

在線公司:全球最大呼叫中心河南江蘇北京我們面臨的運維挑戰(zhàn)多41轉變運維思路，適應新的時代挑戰(zhàn)為了支持業(yè)務快速上線和高效運維。在線公司監(jiān)控系統(tǒng)需具備敏捷、集中、自動、智能的關鍵能力。自動敏捷之前能力建設智能現(xiàn)在監(jiān)控能力周粒度提供監(jiān)控能力分鐘級提供按專業(yè)劃分的“煙囪式監(jiān)控”混合集中化監(jiān)控手工添加基于策略的自動化閉環(huán)依賴專家經驗基于AI和大數(shù)據(jù)的自動識別集中

轉變運維思路，適應新的時代挑戰(zhàn)為了支持業(yè)務快速上線和高效運維42目錄1234背景-全國集中維護、全球最大出路-選擇開源轉型-幾個問題蛻變-AIOPS在監(jiān)控報警方面的嘗試

目錄1234背景-全國集中維護、全球最大出路-選擇開源轉型-43統(tǒng)一監(jiān)控平臺：開源工具+二次開發(fā)，自主核心可控監(jiān)控管理Grafana統(tǒng)一門戶ITSM運維平臺自動化平臺CMDB統(tǒng)一告警平臺統(tǒng)一事件分析告警告警接口性能看板告警事件管理短信郵件工單信息故障定位或修復場景業(yè)務看板根因分析業(yè)務建模業(yè)務模型和配置數(shù)據(jù)被管環(huán)境Java

App.NET

AppPHP,Python,

NodeJS應用系統(tǒng)客服系統(tǒng)監(jiān)控（I2000）應用性能監(jiān)控（APM）告警信息場景執(zhí)行調用性能看板業(yè)務看板業(yè)務數(shù)據(jù)PrometheusmetricElasticSearch數(shù)據(jù)庫數(shù)據(jù)庫監(jiān)控（Prometheus）基礎架構監(jiān)控（Zabbix）CTI/UAP系統(tǒng)服務器、網絡、存儲、虛擬化環(huán)境等告警看板Kafka實時融合監(jiān)控：引入業(yè)界開源工具，進行二次開發(fā)與封裝，形成核心自主可控、穩(wěn)定高效、海量秒級的監(jiān)控能力。跨域/跨廠商/跨層的IT/CT實時融合監(jiān)控。有豐富的管理對象。多樣靈活的數(shù)據(jù)展現(xiàn)形式，可以靈活配置，適應不同場景，快速定制。監(jiān)控數(shù)據(jù)

統(tǒng)一監(jiān)控平臺：開源工具+二次開發(fā)，自主核心可控監(jiān)控管理Gra44統(tǒng)一監(jiān)控平臺：集中建設、統(tǒng)一管控、邊緣節(jié)點標準化為了更快速的建立監(jiān)控能力、更全面的管控系統(tǒng)質量，在線服務公司統(tǒng)一監(jiān)控平臺采用了總部集中建設、統(tǒng)一管控，分公司標準化接入的建設模式。全網集中：總部負責監(jiān)控能力建設、邊緣節(jié)點的標準化，所有監(jiān)控數(shù)據(jù)的上收、分析、展現(xiàn)與通知。分公司提供資源，遵照標準化、封裝后的監(jiān)控模板進行監(jiān)控資源的維護與管理。

統(tǒng)一監(jiān)控平臺：集中建設、統(tǒng)一管控、邊緣節(jié)點標準化為了更快速的45一些小總結：半年時間2萬200

萬90

萬30

萬主機監(jiān)控項觸發(fā)器報警84400+5451.3KProxyDashBoard用戶數(shù)動作

一些小總結：半年時間2萬200萬90萬30萬主機監(jiān)控46一些小總結：廣泛、豐富、多樣、靈活

一些小總結：廣泛、豐富、多樣、靈活47網絡設備類型與廠家存活/丟包/時延CPU/內存占用率snmp狀態(tài)溫度端口狀態(tài)出/入口帶寬利用率出/入口丟、錯包接口類型設備狀態(tài) 網卡狀態(tài) 設備信息端口描述軟件版本系統(tǒng)名稱光功率光模塊接收功率網絡協(xié)議光模塊發(fā)送 BGP對等體功率 連接狀態(tài)ospf鄰居狀態(tài)vrrp虛擬路由狀態(tài)網絡監(jiān)控指標SNMP一些小總結：廣泛、豐富、多樣、靈活

網絡設備類型與廠家存活/丟包/時延CPU/內存占用率sn48一些小總結：廣泛、豐富、多樣、靈活看板可靈活制定，分鐘級完成配置。圖表多樣化展現(xiàn)：折線圖、柱狀圖、餅圖、區(qū)域圖、拓撲圖等。

一些小總結：廣泛、豐富、多樣、靈活看板可靈活制定，分鐘級完成49主機參數(shù)內核參數(shù)TCP協(xié)議棧參數(shù)信號量/IO（Zabbix啟動失敗不釋放信號集）數(shù)據(jù)庫CPU/內存/IO連接（最大連接數(shù)、超時時長）數(shù)據(jù)一致性強烈建議采用數(shù)據(jù)庫SSD硬盤WEBNginx參數(shù)Php參數(shù)php.ini：max_input_vars（影響模板應用大批量主機失?。㈱abbix視具體需求配置啟動模塊和進程數(shù)禁用自動發(fā)現(xiàn)，采用腳本調用api實現(xiàn)禁用housekeeper，啟用數(shù)據(jù)庫表分區(qū)禁用server直連agent配置參數(shù)優(yōu)化defines.inc.php：QUEUE_DETAIL_ITEM_COUNT（定義監(jiān)控項隊列檢索限制，影響消息隊列積壓顯示）一些小總結：zabbix系統(tǒng)優(yōu)化

主機參數(shù)數(shù)據(jù)庫WEBZabbix一些小總結：zabbix系統(tǒng)50一些小總結：zabbix系統(tǒng)優(yōu)化二、Preprocessing

manager

負荷長期為100%三、Zabbix

server主機反復重啟，卻無法啟動成功問題現(xiàn)象與影響一、大量消息隊列積壓（超過20萬），且呈現(xiàn)雪崩效應問題定位與解決方案一、zabbix官網對于pre-process耗盡的說明：二、解決方案：1、在zabbix

server所在主機再單獨部署一個proxy節(jié)點。2、將之前由zabbix

server直接監(jiān)控的所有proxy所在主機的agent節(jié)點，全部轉到新增proxy管理。3、降低server的pollers、java

pollers、pingers、trappers等進程數(shù)配置。4、增加zabbix

server的自監(jiān)控項配置項及告警（

Pre-process進程占用率及zabbix_server.log的異常關鍵字告警）。

一些小總結：zabbix系統(tǒng)優(yōu)化二、Preprocessin51Zabbix配置的同步機制Zabbix的配置表比較多，大容量局點關聯(lián)查詢sql耗時很長如數(shù)據(jù)庫控制sql執(zhí)行時間的max_execution_time配置不合理，會導致無法將相應配置表數(shù)據(jù)同步到zabbix

server以及proxy的cache，從而導致出現(xiàn)大量監(jiān)控項無法正常采集及消息隊列積壓現(xiàn)象。以下為zabbix_server.log相應日志：數(shù)據(jù)庫sql執(zhí)行超時配置建議根據(jù)現(xiàn)網的數(shù)據(jù)庫IO處理性能以及局點規(guī)模合理配置數(shù)據(jù)庫超時相關參數(shù)，將max_execution_time設置為超過目前zabbix

server同步配置sql執(zhí)行時長的2倍以上，并定期檢查zabbix_server.log日志的相應執(zhí)行時長，或者增加自監(jiān)控告警。一些小總結：zabbix系統(tǒng)優(yōu)化

Zabbix配置的同步機制Zabbix的配置表比較多，大容量52目錄1234背景-全國集中維護、全球最大出路-選擇開源轉型-幾個問題蛻變-AIOPS在監(jiān)控告警方面的嘗試

目錄1234背景-全國集中維護、全球最大出路-選擇開源轉型-53問題一：200w監(jiān)控指標，業(yè)務出了問題仍然不知道治理范圍應用系統(tǒng)管理業(yè)務質量管理客戶體驗管理能力擴展基礎設施管理基礎設施性能管理(PM)基礎設施故障管理(FM)用戶問題管理用戶感知管理業(yè)務問題管理業(yè)務質量管理以業(yè)務質量和客戶體驗為核心，以可管控、可視化、可度量為目標。全網集中建設、集中管控、邊緣節(jié)點標準化接入。軟件監(jiān)控+硬件監(jiān)控一網打盡，運維數(shù)據(jù)統(tǒng)一、融合、流動，建立多層次度量體系。以用戶體驗出發(fā)，建立端到端全鏈路監(jiān)控，告警+投訴預警+客服聯(lián)動形成完整閉環(huán)管理。運維保障應用性能管理(PM)應用故障管理(FM)流程及自動化管理

問題一：200w監(jiān)控指標，業(yè)務出了問題仍然不知道治理范圍應54業(yè)務及應用質量可感知，是監(jiān)控的核心ServerOSDBJVMMQWEB面向基礎架構的監(jiān)控只能發(fā)現(xiàn)約30%的問題從用戶體驗出發(fā)面向應用的監(jiān)控能發(fā)現(xiàn)約70%的問題最終用戶體驗應用程序基礎架構梳理業(yè)務系統(tǒng)核心功能模塊梳理功能模塊的核心監(jiān)控指標評審監(jiān)控指標的提取方式及有效性監(jiān)控看板制作在強化基礎設置監(jiān)控的基礎上，補充應用性能監(jiān)控和業(yè)務質量監(jiān)控能力，保障業(yè)務的穩(wěn)定性和客戶感知。應用性能監(jiān)控 業(yè)務質量監(jiān)控參考Google

SRE五項黃金指標1：速率：請求速率，請每秒請求數(shù)量。2：錯誤：

錯誤率，即每秒錯誤數(shù)量。3：延遲：

響應時間，包括隊列/

等待時間，以毫秒為單位。4：飽和度：即過載程度，指標與資源利用率相關，也可通過隊列深度進行直接衡量。5：利用率：

資源或系統(tǒng)的繁忙程度，通常表示為

0%

至

100%。應用性能監(jiān)控將前臺頁面與后端服務以及用戶網絡環(huán)境真正串聯(lián)，做到端到端全鏈路、代碼級監(jiān)控。用戶體驗評分

前端交互體驗 網絡切片 應用調用拓撲

代碼定位追蹤

業(yè)務及應用質量可感知，是監(jiān)控的核心ServerOSDBJ55問題二：海量的日志是否有利用價值？對于亞健康狀態(tài)，異常日志比系統(tǒng)故障更早出現(xiàn)。由于海量日志存儲在海量網元中，不同廠商日志標準不統(tǒng)一且可讀性差，往往很難鑒別真正觸發(fā)異常的日志。挑戰(zhàn)海量日志保存在海量網元中，缺乏統(tǒng)一視圖不同廠商設備的日志缺乏統(tǒng)一標準，可讀性差XXXX@%#&(*(

￥%……—*XXXX@#$%&*(%#@#$%CXXXX@!#$*^#$!@%$*(*(^XXXXERROR*&^%$#$*()*^日志統(tǒng)一采集，統(tǒng)一呈現(xiàn)，異廠商設備日志統(tǒng)一查詢針對異常日志進行統(tǒng)計，實時推送異常日志告警，提升亞健康網絡問題定位效率①跨廠商設備日志統(tǒng)一查詢②異常日志統(tǒng)計③異常日志分析與告警推送統(tǒng)一日志分析Syslog網絡設備(

Huawei,

HP,

IBM,…)Logstash一體化客服系統(tǒng)精準扶貧實名制 語音管控…價值Cloud

OS

問題二：海量的日志是否有利用價值？挑戰(zhàn)海量日志保存在海量網56問題三：一個業(yè)務監(jiān)控需要添加2480萬個監(jiān)控項？監(jiān)控內容接口平臺類型（

4）：接入接口，接入渠道，轉接接口，轉接渠道系統(tǒng)編碼（31）：為各省分公司的編碼監(jiān)控項類型(8）：調用總數(shù)，成功率，平均耗時，失敗率，失敗數(shù)，大于1s比率，大于3s比率，大于5s比率監(jiān)控項名稱（500+）：從業(yè)務數(shù)據(jù)庫實時查詢監(jiān)控項名稱錯誤碼（50+）：業(yè)務指標的錯誤碼類型 （4*31*8*500*50=2480萬）監(jiān)控項類型大：千萬級監(jiān)控項組合，zabbix方案暫無法實現(xiàn)（包括監(jiān)控配置和展示）圖形展示篩選條件要求可配置，動態(tài)關聯(lián)：zabbix解決方案暫無法實現(xiàn)（個性化tag無法關聯(lián)查詢）。難點說明解決方案利用prometheus靈活的自定義babel功能實現(xiàn)數(shù)據(jù)采集和動態(tài)圖形展示

問題三：一個業(yè)務監(jiān)控需要添加2480萬個監(jiān)控項？監(jiān)控內容接57監(jiān)控平臺架構的改進與優(yōu)化管控資源對象運維數(shù)據(jù)分析平臺上層運維場景應用CMDB數(shù)據(jù)庫企業(yè)資源數(shù)據(jù)監(jiān)控底層能力平臺PrometheusAPMHadoop離線數(shù)據(jù)分析運維數(shù)據(jù)分析內部用戶物理設備云平臺 網絡一體化客服業(yè)務監(jiān)控客服設備監(jiān)控。。。容量管理自動化擴縮容。。。故障決策系統(tǒng)自動化切換。。。Zabbix外部客戶日志 容器云

業(yè)務監(jiān)控

數(shù)據(jù)庫 應用 中間件日志平臺規(guī)則數(shù)據(jù)機器學習數(shù)據(jù)Flink實時數(shù)據(jù)處理運維數(shù)據(jù)分析

監(jiān)控平臺架構的改進與優(yōu)化管控資源對象運維數(shù)據(jù)分析平臺上層58大型互聯(lián)網公司基礎資源多，業(yè)務廣，線上變更頻繁，監(jiān)控配置任務量大監(jiān)控添加不是一蹴而就，需要反復調整，重復工作量大開源工具使用門檻高，大多沒有好用的web界面，需要培訓才能靈活使用中移在線公司業(yè)務/工作人員遍布全國各省，基礎資源達到上萬級別，業(yè)務變更頻繁，統(tǒng)一管理難度系數(shù)高痛點應對方案12監(jiān)控能力標準化、流程化、模塊化二次開發(fā)、

3自動化配置界面化數(shù)據(jù)展示界面化問題四：加不完的監(jiān)控需求？

大型互聯(lián)網公司基礎資源多，業(yè)務廣，線上變更頻繁，監(jiān)控配置任59中移在線監(jiān)控的歷程（摸著石頭過河）1需求分析與功能驗證23全網推廣性能調優(yōu)典型問題與4軟件bug處理規(guī)范化制定與整改5運維界面化與自動化欲速則不達沒有規(guī)范化的交付，質量無法保證返工意味著效率降低3倍以上12需求分析與功能驗證標準與規(guī)范制定3性能調優(yōu)典型問題與軟件bug處理4批量推廣