企業(yè)AIOps實(shí)踐之路

1、企業(yè)AIOps實(shí)踐之路1/27目錄1.背景介紹BACKGROUND INFORMATION2/272.企業(yè)AIOps體系規(guī)劃THE PLANNING OF AIOPS SYSTEM3.企業(yè)AIOps實(shí)踐THE PRACTICE OF AIOPS4.未來藍(lán)圖THE FUTURE BLUEPRINT1.背景介紹：線上的復(fù)雜性系統(tǒng)和服務(wù)的復(fù)雜性4000+系統(tǒng)，數(shù)量還在增加。2. 系統(tǒng)間調(diào)用方式復(fù)雜：大部分使用RSF，也有其他 的方式如HESSIAN，ESB等。1. 多數(shù)據(jù)中心，每個數(shù)據(jù)中心會劃分多個邏輯機(jī)房和部署環(huán)境。2. 服務(wù)器規(guī)模11w+，例如，一個中心的緩存服務(wù)器就有 可能有上千臺。3. 服務(wù)

2、器類型復(fù)雜性：cloudstack,openstack,vmware,kvm,k8s下docker，swarm下的docker。3. 蘇寧業(yè)務(wù)的復(fù)雜：既有線上新業(yè)務(wù)又有線下老業(yè)務(wù)，這些業(yè)務(wù)系統(tǒng)之間會有大量的關(guān)聯(lián)。5/27基礎(chǔ)環(huán)境的復(fù)雜性：1.背景介紹：線上運(yùn)維困境大量運(yùn)維人員隨著業(yè)務(wù)規(guī)模地不斷擴(kuò)大， 需要眾多的運(yùn)維人員參與 到業(yè)務(wù)支撐，運(yùn)維成本不 斷上升。問題排查困難業(yè)務(wù)系統(tǒng)之間交互復(fù)雜， 業(yè)務(wù)流程長，導(dǎo)致出現(xiàn)線上 問題時，需要更多時間定 位問題,業(yè)務(wù)損失極大。缺少知識積累對過往運(yùn)維過程中問題解 決依賴特定人的經(jīng)驗(yàn)，當(dāng) 人員變更的情況下， 這些 經(jīng)驗(yàn)缺少有效的復(fù)用。缺少預(yù)警能力只能根據(jù)問題發(fā)生

3、后去解 決問題，很難在問題出現(xiàn) 前進(jìn)行預(yù)警而避免發(fā)生問 題。AIOps4/27目錄1.背景介紹BACKGROUND INFORMATION5/272.企業(yè)AIOps體系規(guī)劃THE PLANNING OF AIOPS SYSTEM3.企業(yè)AIOps實(shí)踐THE PRACTICE OF AIOPS4.未來藍(lán)圖THE FUTURE BLUEPRINT2.企業(yè)AIOps體系規(guī)劃：發(fā)展歷程SNMON監(jiān)控系統(tǒng)20132014Zabbix 基礎(chǔ)設(shè)施監(jiān)控20152016海量日志分析平臺 調(diào)用鏈監(jiān)控異常監(jiān)管系統(tǒng) 鏈路監(jiān)控大盤 智能告警平臺20172018Prometheus基礎(chǔ)設(shè)施監(jiān)控 瀏覽器端性能監(jiān)控面向用戶體

4、驗(yàn)監(jiān)控 態(tài)勢感知告警引擎流式異常檢測 根因分析算法 故障識別與應(yīng)急AIOps中臺建設(shè) 多維度時間序列存儲 無人化智能監(jiān)控體系2019AIOps6/27=數(shù)據(jù)+分析APP性能監(jiān)控服務(wù)端性能監(jiān)控+算法2.企業(yè)AIOps體系規(guī)劃：藍(lán)圖9/27精準(zhǔn)告警日志監(jiān)控用戶體驗(yàn)監(jiān)控影響用戶異常分析多維度融合監(jiān)控平臺多維度監(jiān)控分析異常監(jiān)控日志分析配置變更事件應(yīng)用發(fā)布事件動態(tài)趨勢海量日志 實(shí)時分析異常告警端側(cè)監(jiān)控移動端性能監(jiān)控PC端性能監(jiān)控Http請求劫持分析頁面性能JS錯誤慢頁面AJAX請求地域崩潰卡頓服務(wù)端性能監(jiān)控調(diào)用鏈監(jiān)控堆內(nèi)存堆外內(nèi)存鏈路分析依賴分析GC線程系統(tǒng)拓?fù)浞治龇?wù)品質(zhì)分析SQLRedis服務(wù)來源流

5、向基礎(chǔ)設(shè)施監(jiān)控中間件監(jiān)控網(wǎng)絡(luò)監(jiān)控主機(jī)監(jiān)控Web ServerMQ虛擬網(wǎng)絡(luò)虛擬機(jī)Java RuntimeKafka物理網(wǎng)絡(luò)物理機(jī)CacheDatabase容器監(jiān)控IDC動環(huán)數(shù)據(jù)數(shù)據(jù)、事件智能告警平臺定向發(fā)送決策分析平臺Ai系統(tǒng) 專家系統(tǒng)服務(wù)契約管理服務(wù)管理系統(tǒng)服務(wù)依賴管理 服務(wù)狀態(tài)管理 業(yè)務(wù)碼語義管理分析+算法中臺業(yè)務(wù)會員統(tǒng)一任務(wù) 調(diào)度平臺IT平臺故障識別與應(yīng)急 遠(yuǎn)程服務(wù)調(diào)用 框架平臺WAF平臺 2.企業(yè)AIOps體系規(guī)劃：架構(gòu)Service 1Service NDatabasehttprsfjdbcTrace指標(biāo)事件事件分析存儲ElasticsearchDruid.ioTrace分析存儲Fli

6、nk流式處理ElasticsearchHBase指標(biāo)分析存儲PrometheusthanosM3DbPullOpenTracing 標(biāo)準(zhǔn)上報指標(biāo)Tag關(guān)聯(lián)Tag關(guān)聯(lián)態(tài)勢感知 告警引擎+智能告警平臺配置/事件 變更接入多策略 采樣管理Tag元數(shù)據(jù) 管理決策分析系統(tǒng)異常檢測 For AIOps動態(tài)告警 閾值算法RequestsKafkaKafkaFlume Agent調(diào)用鏈AgentPrometheus Agent依賴數(shù)據(jù)RCA（根本原因）分析監(jiān)控閉環(huán)自動應(yīng)急干預(yù)處理告警 無人化干預(yù)多維度融合監(jiān)控平臺基于對話式任務(wù)型監(jiān)控機(jī)器人自然語言處理OCR圖像識別監(jiān)控知識圖譜無人化監(jiān)控與干預(yù)異常事件與體驗(yàn)的監(jiān)

7、控根因定位AI賦能交互場景（豆芽） 10/27應(yīng)急干預(yù)準(zhǔn)則數(shù) 據(jù) 采 集算法A I O P S數(shù) 據(jù) 處 理目錄1.背景介紹BACKGROUND INFORMATION9/272.企業(yè)AIOps體系規(guī)劃THE PLANNING OF AIOPS SYSTEM3.企業(yè)AIOps實(shí)踐THE PRACTICE OF AIOPS4.未來藍(lán)圖THE FUTURE BLUEPRINT3.企業(yè)AIOps實(shí)踐：多源數(shù)據(jù)整合多源數(shù)據(jù)整合事件、Trace基礎(chǔ)設(shè)施/端側(cè)性 能指標(biāo)業(yè)務(wù)相 關(guān)數(shù)據(jù)用戶行 為數(shù)據(jù)10/273.企業(yè)AIOps實(shí)踐：異常檢測體系架構(gòu)數(shù) 據(jù) 處 理準(zhǔn)則數(shù) 據(jù) 采 集算法A I O P SAPM

8、 Trace統(tǒng)計基礎(chǔ)設(shè)施指標(biāo)APM性能指標(biāo)監(jiān)控數(shù)據(jù)源分布式文件存儲（OSS）海量小文件持久化存儲高可用性高伸縮性時間序列存儲集群PrometheusthanosM3Db實(shí)時消息通道業(yè)務(wù)監(jiān)控指標(biāo)事件/日志Kafka集群Kafka集群Kafka集群實(shí)時/離線存儲數(shù)據(jù)歸檔數(shù)據(jù)載入Grok ExporterGrok ExporterPULL多種業(yè)務(wù)數(shù)據(jù)上報PULL流式數(shù)據(jù)處理Flink（JAVA）Faust（Python）流式機(jī)器學(xué)習(xí)模型流式異常檢測算法RunMAD（基于滑動窗口的絕對中位差）DBScan（無監(jiān)督式空間聚類算法）模型輸出離線異常檢測模型特征處理PandasSk-learn預(yù)測算法(Pr

9、ophet)趨勢預(yù)測季節(jié)性預(yù)測突變點(diǎn)告警動態(tài)閾值（上下振幅）未來預(yù)測的時間序列AD-Exporter子系統(tǒng)集成PULL多維度融合監(jiān)控系統(tǒng)：異常檢測能力構(gòu)建異常檢測自定義監(jiān)控視圖構(gòu)建異常檢測告警模型參數(shù)設(shè)置監(jiān)控子系統(tǒng)態(tài)勢告警引擎智能告警平臺根因分析模型修正模型修正13/273.企業(yè)AIOps實(shí)踐：根因分析線上環(huán)境兩種類型的異常繁殖：同一個物理機(jī)上的多個虛機(jī)存在資源爭搶造 成一個虛機(jī)上的異常（資源利用率）繁殖到 其他的虛機(jī)，引發(fā)服務(wù)調(diào)用的異常。服務(wù)調(diào)用鏈路的多個服務(wù)組件間的異常繁殖，與資源爭搶無關(guān)，例如：錯誤的配置變更、 發(fā)布導(dǎo)致回退等。構(gòu)建VCG與APG：海量的服務(wù)調(diào)用，需要可伸縮的圖數(shù)據(jù)庫做

10、構(gòu)建的支撐（JanusGraph）?；趦煞N類型的異常繁殖，構(gòu)建依賴關(guān)系圖 最終從VCG-APG。相 似 度 計 算 ： 基 于 PearsonCorrelationCoefficient定義相似度函數(shù)。隨機(jī)游走算法：高的相似度未必是真正的根因，通過隨機(jī)游走確定最大概率的根因列表。SPM Request TracingInfra Metrics Data Collection構(gòu)建VCG（VM 通信圖）構(gòu)建APG（異常 繁殖圖）檢索CMDBCMDB主數(shù)據(jù)數(shù)據(jù)采集子系統(tǒng)History TSDB相似度計算隨機(jī)游走根因定位子系統(tǒng)異常提交源異常檢測告警提交請求排名后的根因列表配置變更列表+輸出：多維度融

11、合監(jiān)控系統(tǒng)12/27核心思想?yún)⒖迹篟oot Cause Analysis of Anomalies of Multitier Services in Public CloudsIEEE/ACM 20183.企業(yè)AIOps實(shí)踐：根因分析多維度融合監(jiān)控的智能化運(yùn)維生成服務(wù)調(diào)用拓?fù)鋱D，直觀展現(xiàn)各種服務(wù)之 間的調(diào)用關(guān)系鏈。確定疑似根因，對服務(wù)調(diào)用發(fā)生的異常定位 到具體服務(wù)和責(zé)任人，有效提升問題排查效 率。實(shí)時展示拓?fù)鋱D中各服務(wù)歷史錯誤次數(shù)，以 及各種服務(wù)相關(guān)的性能指標(biāo)。服務(wù)調(diào)用拓?fù)鋵?shí)現(xiàn)層層下鉆功能，從服務(wù)到 方法調(diào)用的全鏈路問題定位與分析。反饋根因分析結(jié)果，持續(xù)優(yōu)化根因分析算法。13/273.企業(yè)AI

12、Ops實(shí)踐：業(yè)務(wù)智能告警背景體量大：現(xiàn)在易購四級頁每天產(chǎn)生的業(yè)務(wù)日志數(shù)據(jù)在100T以上，業(yè)務(wù)監(jiān)控都是多維度實(shí)時監(jiān)控，核心數(shù)據(jù)以1分鐘為周期， 一般監(jiān)控的數(shù)據(jù)以5分鐘或1小時為周期，監(jiān)控目標(biāo)非常多，按人工維護(hù)這些監(jiān)控的閾值、啟停等幾乎是很難達(dá)到；變化多：易購四級頁監(jiān)控對象及指標(biāo)變化也非常多，業(yè)務(wù)指標(biāo)也有周期性變化的特點(diǎn)，在日常的促銷活動或大促活動期間，這些監(jiān)控對象及指標(biāo)也是經(jīng)常調(diào)整相關(guān)策略，這樣一來，人工設(shè)定的靜態(tài)報警閾值準(zhǔn)確性就很難保障了。迭代快：在不同的時期，易購經(jīng)常也會上不同的促銷活動，監(jiān)控的對象和指標(biāo)維度變化比較頻繁，采用當(dāng)前這種傳統(tǒng)的靜 態(tài)報警閾值不能快速的反映線上實(shí)時的業(yè)務(wù)健康情況；

13、待解決的問題類似于四級頁商品無貨的場景，業(yè)務(wù)上希望能夠監(jiān)控到什么品類、什么品牌、什么經(jīng)銷渠道、什么地區(qū)等比較細(xì)顆粒度的維度監(jiān)控，這樣就能針對性的做好商品無貨的運(yùn)維了，當(dāng)前拿到的商品無貨的維度監(jiān)控比較粗；當(dāng)前對于商品無貨的監(jiān)控采用的是傳統(tǒng)的人工維護(hù)靜態(tài)閾值，運(yùn)維成本比較高，而且告警短信過多，一天幾百條短信，無 法判斷哪些是有效告警，對運(yùn)維工作造成很大困擾；報警發(fā)出之后，無后續(xù)處理方案。在業(yè)務(wù)快速迭代的同時，關(guān)于各業(yè)務(wù)監(jiān)控指標(biāo)的普通告警或嚴(yán)重級別的健康度標(biāo)準(zhǔn)是什么？如果在沒有人工干預(yù)的情況下，告警自動恢復(fù)之后，是否能夠提供系統(tǒng)自動恢復(fù)的告警，其中的自動恢復(fù)的評判依據(jù)也比較難給出。14/273.企業(yè)

14、AIOps實(shí)踐：業(yè)務(wù)智能告警業(yè)務(wù)智能告警的優(yōu)勢一般系統(tǒng)告警只是根據(jù)系統(tǒng)層面出現(xiàn)的問題告知相關(guān)運(yùn)維人員，保證系統(tǒng)的正常運(yùn)行。而業(yè)務(wù)智能告警是在系統(tǒng)穩(wěn)定運(yùn)行 下，根據(jù)業(yè)務(wù)在不同時間段的波動狀況告知業(yè)務(wù)人員，保證業(yè)務(wù)的正常運(yùn)營。自動進(jìn)行任一維度的業(yè)務(wù)范圍的監(jiān)控配置，并且確定監(jiān)控指標(biāo)。通過動態(tài)增長率的變更而設(shè)定相應(yīng)的閾值生成告警事件。這種方式的告警更加精確，響應(yīng)性更好。15/273.企業(yè)AIOps實(shí)踐：日志流量智能降級背景在雙十一期間或者壓測期間，會出現(xiàn)日志流量暴增的情況，遠(yuǎn)遠(yuǎn)超出日志平臺的處理能力。面對這個情況如果不進(jìn)行有效的降級話，勢必會導(dǎo)致日志系統(tǒng)出現(xiàn)大規(guī)模的延遲，影響用戶定位問題。解決方案之前

15、我們給的解決方案人工查詢?nèi)罩玖髁?，發(fā)現(xiàn)超出平臺的處理能力就手動按照top20的系統(tǒng)直接丟棄日志流量。 這 樣 做 有 兩 個 問 題 ： 1）對于壓測這樣的場景，用戶就是需要看日志量暴增的這些日志，用于看壓測效果和壓測中出現(xiàn)的問題2）需要大量的人為操作因此采用了下面的優(yōu)化方案。1）自動偵測日志流量。如果發(fā)現(xiàn)流量激增，實(shí)時獲取流量排名靠前的系統(tǒng)，并結(jié)合歷史數(shù)據(jù)進(jìn)行判斷是否是正常流量2）篩選出需要降級的流量后，將異常流量分流（備注）到慢通道，慢慢消費(fèi)，不影響主通道。備注：我們分析發(fā)現(xiàn)蘇寧這邊的系統(tǒng)一般都是分布式，并且每個節(jié)點(diǎn)承擔(dān)的流量基本一致，也就是說產(chǎn)生的日志基本是類似的。 簡單的說，如果用戶有

16、1000臺服務(wù)器，通過查看其中100臺大概就能定位問題。因此我們會預(yù)先準(zhǔn)備多個日志通道，其中一個是主通道，一個是慢通道，我們會將100臺機(jī)器的流量放入到主通道中，保證用戶可以檢索到數(shù)據(jù)，然后將另外 900臺放入到慢通道中。16/27資源爭搶識別指標(biāo)：cpu總平均steal time大于30%。1G 帶 寬 低 于 800Mbps ， 或 低 于200000pps，并且同機(jī)房ping延遲達(dá)到5ms或較平時增長10倍。10G 帶寬 低于 3000Mbps ， 或低于 400000pps，并且同機(jī)房ping延遲達(dá) 到2ms或較平時增長10倍以上則認(rèn)為 是資源爭搶。HDDio 低 于 200MB/s,

17、 或 低 于600rw/s,util 達(dá)到100% ， 并且awaittime達(dá)到5ms或較平時增長10倍以上 則認(rèn)為是資源爭搶。SSDio 低 于 400MB/s, 或 低 于10000rw/s,util 達(dá) 到 100% ， 并 且 await time達(dá)到2ms或較平時增長10 倍以上則認(rèn)為是資源爭搶3.企業(yè)AIOps實(shí)踐：資源爭搶自動識別17/273.企業(yè)AIOps實(shí)踐：面向用戶體驗(yàn)的無人化智能解決方案用戶維度，生成用戶畫像，全面復(fù)現(xiàn)用戶在任一場景中的軌跡，深入感知用戶的體驗(yàn)。并觸發(fā)相對應(yīng)的用戶關(guān)懷。產(chǎn)品維度，提供任一 場景下的用戶體驗(yàn)分 析，給出用戶體驗(yàn)感 知的趨勢曲線，全面刻畫產(chǎn)品

18、的體驗(yàn)狀況，定位到具體的負(fù)責(zé)人。能力維度，用戶的體 驗(yàn)感知都能溯源、定 位至對應(yīng)的產(chǎn)品能力 環(huán)節(jié)，通過全覆蓋的串聯(lián)分析鏈路能快速、精準(zhǔn)定位用戶體驗(yàn)觸 點(diǎn)關(guān)聯(lián)的前中后臺系 統(tǒng)。運(yùn)營維度，通過態(tài)勢 感知引擎和機(jī)器學(xué)習(xí) 算法構(gòu)成的智能告警 能捕捉任何用戶體驗(yàn) 的變化狀態(tài)，及時了 解產(chǎn)品健康狀況，決 策產(chǎn)品異常治理方向 及目標(biāo)。18/273.企業(yè)AIOps實(shí)踐：面向用戶體驗(yàn)的無人化智能解決方案搶購總是卡死頁面加載慢圖片無法顯示監(jiān)控系統(tǒng)運(yùn)維人員消費(fèi)者失去耐心運(yùn)維介入運(yùn)維人員通過登錄監(jiān)控 系統(tǒng)觀察到系統(tǒng)出現(xiàn)的 異常情況。定位問題根據(jù)監(jiān)控系統(tǒng)給出的異 常信息，定位問題所在。解決問題相關(guān)研發(fā)人員需要開會 討論并確定解決問題的 方案。持續(xù)觀察運(yùn)維和研發(fā)人員需要持 續(xù)觀察評估解決方案在 線上的運(yùn)行效果。消費(fèi)者數(shù)據(jù)采集告警通知19/273.企業(yè)AIOps實(shí)踐：面向用戶體驗(yàn)的無人化智能解決方案業(yè)務(wù)人員自然語言處理從自然語言中提取 相關(guān)的關(guān)鍵詞并進(jìn) 行語義分析， 識別 用戶的指令操作。根據(jù)交流積累生成 相應(yīng)的知識圖譜， 機(jī)器人通過自學(xué)習(xí) 形成運(yùn)維人員畫像。用戶畫像通過群組方式與機(jī) 器人交流， 根據(jù)上 下文交流信息識別 并進(jìn)行目標(biāo)任務(wù)。目標(biāo)任務(wù)協(xié)同通過OCR文本識別， 提取目標(biāo)多層特征 數(shù)據(jù)， 實(shí)現(xiàn)對監(jiān)控 趨勢的預(yù)判。多源數(shù)據(jù)