从自动化到智能化，网易杭研的AIOps探索与实践
本文由作者授權(quán)發(fā)布，未經(jīng)許可，請勿轉(zhuǎn)載。
作者：席晶晶，網(wǎng)易杭州研究院運(yùn)維與賬號中心工程師
?
一、運(yùn)維面臨問題與挑戰(zhàn)
眼下，隨著信息化、數(shù)字化的深入發(fā)展，技術(shù)飛速迭代，應(yīng)用服務(wù)也不斷升級，企業(yè)面臨的運(yùn)維壓力也越來越大，傳統(tǒng)運(yùn)維受到了前所未有的挑戰(zhàn)。
（1）?運(yùn)維內(nèi)容：傳統(tǒng)的互聯(lián)網(wǎng)運(yùn)維的內(nèi)容僅是關(guān)注軟硬件、網(wǎng)絡(luò)、應(yīng)用系統(tǒng)及基礎(chǔ)設(shè)備的運(yùn)維，而當(dāng)前將面臨數(shù)十萬臺主機(jī)、容器，復(fù)雜的網(wǎng)絡(luò)環(huán)境，以及復(fù)雜的部署環(huán)境：私有云、公有云、跨IDC混合部署。
（2）?運(yùn)維工具：傳統(tǒng)的互聯(lián)網(wǎng)運(yùn)維盡管也利用了工具實(shí)現(xiàn)了部分工作的自動化，但主要依賴人力，工作量較大，并效率低下，業(yè)務(wù)快速增長，技術(shù)飛速迭代，意味著工具也要順勢升級。
（3）?運(yùn)維模式：7*24小時服務(wù)模式，PE\SA\DBA 成為了“救火式”英雄，監(jiān)聽著成千上萬的監(jiān)控指標(biāo)，一旦故障出現(xiàn)，SA、PE、DBA、開發(fā)童鞋齊上陣，被故障牽著走，被動性強(qiáng)且風(fēng)險高。
面對新的挑戰(zhàn)，網(wǎng)易杭州研究院運(yùn)維服務(wù)團(tuán)隊(duì)不僅要打造信息化、數(shù)字化的綜合管理體系，為企業(yè)帶來全方位IT運(yùn)維服務(wù)，同時還要提供定制化、專業(yè)化、全鏈路、無死角的運(yùn)維解決方案。在大數(shù)據(jù)時代下，我們借助機(jī)器學(xué)習(xí)、數(shù)據(jù)倉庫、大數(shù)據(jù)平臺等大數(shù)據(jù)技術(shù)手段，將運(yùn)維產(chǎn)生的數(shù)據(jù)進(jìn)行分析、處理，得出最佳運(yùn)維策略，以期實(shí)現(xiàn)對故障的事先干預(yù)，將風(fēng)險降低到最低，從而降低運(yùn)維成本，提升運(yùn)維效率，最終實(shí)現(xiàn)運(yùn)維智能化。
?
二、AIOps 現(xiàn)狀、定位以及我們的理解
AIOps即智能運(yùn)維，是 Gartner 在2016年提出的概念，真正火起來是在這兩年，這個概念提出后，各大廠都已經(jīng)先后利用AIOps理念培養(yǎng)智能運(yùn)維人才梯隊(duì)，建設(shè)智能運(yùn)維平臺、打造智能運(yùn)維體系。Gartner預(yù)測到2020年，將近50%的企業(yè)將會在他們的業(yè)務(wù)和 IT 運(yùn)維方面采用 AIOps 。高效運(yùn)維發(fā)起人蕭田國在《AIOps實(shí)施之路》中指出了AIOps在效率提升、質(zhì)量保障、成本優(yōu)化提出了系列可應(yīng)用方向以及實(shí)施AIOps需要具備的能力。
?
AIOps應(yīng)用場景
智能運(yùn)維應(yīng)用場景主要包括如下幾個方面。
AIOps應(yīng)用場景
AIOps人員結(jié)構(gòu)的轉(zhuǎn)變
智能運(yùn)維也會帶來人員結(jié)構(gòu)的變化，如下圖所示。
?
AIOps人員結(jié)構(gòu)的轉(zhuǎn)變
網(wǎng)易杭研于2018年正式加入智能運(yùn)維大營，擁抱變化，以實(shí)現(xiàn)全鏈路、無死角智能運(yùn)維體系為目標(biāo)，旨在利用AI的能力解決運(yùn)維行業(yè)的問題：
1.解決重復(fù)造輪子的問題；
2.解決運(yùn)維效率仍然低下的問題；
3.運(yùn)維的數(shù)據(jù)沒有得到合理應(yīng)用的問題。
故障管理全場景圖
上圖為故障管理全場景圖，該圖從服務(wù)部署、故障發(fā)生、故障發(fā)現(xiàn)、故障止損、根因診斷、故障恢復(fù)、故障關(guān)閉，完整的闡述應(yīng)用監(jiān)控的故障管理生命周期。
?
網(wǎng)易杭研實(shí)施中的智能運(yùn)維產(chǎn)品形態(tài)
?
網(wǎng)易杭研實(shí)施中的智能運(yùn)維產(chǎn)品形態(tài)
當(dāng)前網(wǎng)易杭研實(shí)施中的智能運(yùn)維產(chǎn)品形態(tài)如上圖，主要包括五大模塊：
·??故障預(yù)警：通過算法計算KPI曲線變化趨勢，故障前發(fā)出故障預(yù)警；
·??故障告警：能對周期性變化指標(biāo)進(jìn)行預(yù)測和異常檢測，且有告警分級；
·??告警合并：支持按照合適的維度對告警進(jìn)行合并，展現(xiàn)概況信息；
·??根因分析：智能對故障根因進(jìn)行分析，給出最可能的原因，輔助人做決策；
·??故障自愈：可以根據(jù)故障原因選擇合適的故障自愈策略并執(zhí)行，自動解決故障。
三、網(wǎng)易杭研AIOps實(shí)戰(zhàn)場景-智能監(jiān)控
筆者自接觸智能運(yùn)維以來，也是三千煩勞絲，如何讓運(yùn)維“智能”起來？如何讓AIOps結(jié)合網(wǎng)易現(xiàn)有運(yùn)維體系實(shí)施落地? 又如何推進(jìn)AIOps發(fā)展? 種種挑戰(zhàn)考驗(yàn)著我們的團(tuán)隊(duì)。經(jīng)過1年來不斷探索、研究、試錯，我們首先在監(jiān)控方面突破，下面介紹如何從0到1建設(shè)AIOps應(yīng)用-智能監(jiān)控系統(tǒng)的心路歷程。
?
3.1 運(yùn)維監(jiān)控現(xiàn)狀
隨著互聯(lián)網(wǎng)，特別是移動互聯(lián)網(wǎng)的高速發(fā)展，web服務(wù)已經(jīng)深入到社會的各個領(lǐng)域，人們使用互聯(lián)網(wǎng)搜索，購物，付款，娛樂等等。因此，保障web服務(wù)的穩(wěn)定已經(jīng)變的越來越重要。運(yùn)維人員通過監(jiān)控各種各樣的關(guān)鍵性能指標(biāo)（KPI）來判斷服務(wù)、系統(tǒng)是否穩(wěn)定，因?yàn)镵PI如果發(fā)生異常，往往意味著與其相關(guān)的應(yīng)用發(fā)生了問題。這些KPI可能包括：基礎(chǔ)KPI及服務(wù)KPI，服務(wù)KPI是指能夠反映Web服務(wù)的規(guī)模、質(zhì)量的性能指標(biāo)，例如，網(wǎng)頁響應(yīng)時間，網(wǎng)頁訪問量，連接錯誤數(shù)量等。基礎(chǔ)KPI是指能夠反映機(jī)器（服務(wù)器、路由器、交換機(jī)）健康狀態(tài)的性能指標(biāo)，例如，磁盤使用率，CPU使用率，內(nèi)存使用率，磁盤IO，網(wǎng)卡吞吐率等。
這些KPI數(shù)據(jù)表現(xiàn)為時序序列，即一條指標(biāo)曲線（后文統(tǒng)一稱KPI曲線）。由此問題轉(zhuǎn)化為對曲線的異常判斷，KPI曲線可以簡單分類下面三種類型：
周期型：
隨機(jī)型：
平穩(wěn)型：
在網(wǎng)易杭研基于基礎(chǔ)設(shè)施管理的CMDB系統(tǒng)-哨兵系統(tǒng)，通過哨兵 Agent將數(shù)據(jù)實(shí)時/采樣的傳輸至哨兵服務(wù)端進(jìn)行可視化及報警監(jiān)控。監(jiān)控系統(tǒng)主要采用規(guī)則判定的報警方式，設(shè)定上限、下限閾值，觸發(fā)規(guī)則則發(fā)出報警，隨著業(yè)務(wù)集成越來越多，體量也越來越大，規(guī)則報警也到了其瓶頸，主要有以下痛點(diǎn)：
（1）需要頻繁調(diào)整閾值
case1：隨著業(yè)務(wù)變化，已有的閾值適用性變差，當(dāng)業(yè)務(wù)發(fā)生變動時，報警規(guī)則也需要及時調(diào)整；
case2：夜間與白天范圍不一樣，工作日與周末不一樣，統(tǒng)一的閾值適用性較差。
（2）覆蓋范圍有限
傳統(tǒng)的方式，需要針對指標(biāo)的每一項(xiàng)進(jìn)行設(shè)定報警規(guī)則，比如在DubboProviderCollector，每個方法對應(yīng)的調(diào)用集群的量不一，需要獨(dú)立配置報警規(guī)則，那么配置將會相當(dāng)耗時且繁瑣，并且很多Dubbo服務(wù)接口都是隨業(yè)務(wù)隨時新增或下線，很容易被忽視。
（3）無效報警過多
閾值規(guī)則報警的方式，往往會出現(xiàn)這樣的情況，當(dāng)閾值設(shè)定的太高，異常很難被發(fā)現(xiàn)，當(dāng)閾值設(shè)定的太低，則會造成大量報警，造成報警風(fēng)暴，真正有用的報警消息淹沒在風(fēng)暴中。
?
3.2 算法引入
針對上述痛點(diǎn)，我們思考如何利用算法來突破傳統(tǒng)的閾值報警局限性，于是調(diào)研了業(yè)界使用的各種異常檢測算法。較為常見的算法包括邏輯回歸、關(guān)聯(lián)關(guān)系挖掘、聚類、決策樹、隨機(jī)森林、支持向量機(jī)、蒙特卡洛樹搜索、隱式馬爾科夫、多示例學(xué)習(xí)、遷移學(xué)習(xí)、卷積神經(jīng)網(wǎng)絡(luò)等，以及數(shù)學(xué)算法類：K-Sigma，Grubbs，Turkey，MeanPercent，Value，AR，MR，ARIMA。
通用異常檢測流程：
曾想使用一種或一類算法來解決所有KPI曲線的預(yù)測，而碰到業(yè)務(wù)情況遠(yuǎn)比我們想象要復(fù)雜，例如：首先面臨各種不同曲線表現(xiàn)特征不一，同一類型的算法很難做到召回率整體提升；其二，在同樣類型Dubbo調(diào)用異常 KPI曲線波動情況，在一些產(chǎn)品是可以接受的，但是在其他產(chǎn)品可能是不能接受的異常，可能在某業(yè)務(wù)在意的指標(biāo)，在其他產(chǎn)品無需在意；第三，盡管想做到一個模型泛化兼容所有場景，但是所需特征工程工作量巨大，特征也很多。
有人說采用投票的方法，用一大堆算法同時預(yù)測，對于結(jié)果進(jìn)行投票，少數(shù)服從多數(shù)，這種方式也是存在一定的缺陷，本身每個算法適用性不一樣，那么勢必在影響投票結(jié)果。網(wǎng)易杭研采用的是分類算法，即在不同的場景下采用一類算法進(jìn)行預(yù)測，以減少誤判率，我們調(diào)研和使用了上述部分算法：
機(jī)器學(xué)習(xí)類：
特征工程是機(jī)器學(xué)習(xí)中一塊重要的環(huán)節(jié)，針對單一KPI表現(xiàn)的數(shù)據(jù)形態(tài)將逐一轉(zhuǎn)換為數(shù)據(jù)特征，如下將數(shù)據(jù)特征歸類如下5個方面：
1.統(tǒng)計特征 ：描述樣本內(nèi)相關(guān)的數(shù)學(xué)表現(xiàn)，例如：方差、均值、中位數(shù)、斜率、偏度、峰度等重要指標(biāo)；
2.擬合特征 ：獲取曲線的動態(tài)特征，根據(jù)曲線平穩(wěn)或不平穩(wěn)，采用不同模型獲取預(yù)測值與實(shí)際值的差；
3.周期特征：利用滑動窗口，傅里葉轉(zhuǎn)換，獲取曲線中可能存在的季節(jié)性、周期性特征；
4.分類特征：基于曲線變換、小波變換、主成分分析等方式 獲取曲線分類特征；
5.業(yè)務(wù)特征：KPI具有業(yè)務(wù)集群效應(yīng)，工作日郵箱訪問量，周末游戲訪問量等業(yè)務(wù)特征。
由于篇幅有限，這里就不枚舉所有特征。
數(shù)學(xué)算法類：
（1）恒定閾值類算法
恒定閾值的含義是表示均值基本恒定，標(biāo)準(zhǔn)差與均值比約等于0（即KPI曲線近似一條直線）。
（2）突升突降類算法
突變的含義是發(fā)生了均值漂移
空間轉(zhuǎn)換:
（3）同比算法
適用于周期性數(shù)據(jù)表現(xiàn)，每天同時刻的數(shù)據(jù)分布相似
參數(shù)估計：求正態(tài)分布的均值、方差
?
3.3 功能設(shè)計
（1）KPI 管理
·??標(biāo)注打標(biāo)：提供標(biāo)注打標(biāo)的功能，標(biāo)記/取消標(biāo)記為正負(fù)樣本，標(biāo)記后樣本自動轉(zhuǎn)存樣本庫
·??樣本管理：提供樣本管理功能，檢索、圖示、編輯、刪除等功能
·??異常查詢：經(jīng)API檢測后的時間序列（僅異常）入庫存儲，提供管理功能，分頁查詢、檢索、放縮等
（2）模型管理
·??模型管理：提供模型管理功能
·??模型訓(xùn)練：支持自定義模型訓(xùn)練
（通過PE或開發(fā)標(biāo)注的異常KPI，正常KPI訓(xùn)練符合自己業(yè)務(wù)的模型，或使用開放的通用模型）
（3）KPI異常檢測
·??基于數(shù)學(xué)統(tǒng)計算法集成
·??基于機(jī)器學(xué)習(xí)算法集成
（4）多維度報警聚合
·??按產(chǎn)品維度合并
·??按應(yīng)用維度合并
·??按集群維度合并
·??按單機(jī)維度合并
·??按業(yè)務(wù)類型合并
·??按報警接收人維度合并
（5）反饋系統(tǒng)
·??用戶標(biāo)記、報警關(guān)閉
3.4 架構(gòu)設(shè)計
我們將整個智能監(jiān)控系統(tǒng)分為7個核心功能模塊，每個模塊承擔(dān)異常檢測流程中相應(yīng)功能，整體架構(gòu)上做到模塊之間相互獨(dú)立，通過數(shù)據(jù)流信號、RPC進(jìn)行模塊通信。
序號模塊名稱1配置管理中心配置庫、模型庫、標(biāo)注庫 相關(guān)配置與管理（含UI）2流式計算中心KPI預(yù)處理、KPI聚合、KPI分發(fā)3數(shù)據(jù)存儲&讀取中心用于讀寫KPI時序數(shù)據(jù)4消息中心數(shù)據(jù)→ 消息 用于觸發(fā)模型計算、插值計算5算法中心異常檢測、模型訓(xùn)練6報警處理中心用于解析異常KPI及發(fā)送報警內(nèi)容至哨兵報警中心7反饋系統(tǒng)用于反饋報警是否有效，反饋于模型提升
系統(tǒng)架構(gòu)如下：
網(wǎng)易杭研智能監(jiān)控系統(tǒng)架構(gòu)?
數(shù)據(jù)架構(gòu)如下：
網(wǎng)易杭研智能監(jiān)控數(shù)據(jù)架構(gòu)?
3.5 難題
前面介紹了網(wǎng)易杭研智能監(jiān)控系統(tǒng)的在智能監(jiān)控系統(tǒng)中整體功能及架構(gòu)設(shè)計，下面簡單聊聊我們碰到一些問題以及解決思路：
（1）實(shí)時計算問題
問題描述：
1期采用的是Spark Streaming實(shí)時計算框架，通過直連Kafka獲取數(shù)據(jù)源，但是在實(shí)際生產(chǎn)中，由于數(shù)據(jù)源是采樣收集（有1分鐘采樣，有2分鐘采樣），發(fā)現(xiàn)每1分鐘會有流量尖刺現(xiàn)象，隨著KPI數(shù)量增多，尖刺更明顯。
分析：
經(jīng)分析，發(fā)現(xiàn)Spark Streaming 并非是實(shí)時的數(shù)據(jù)抽取Kafka的數(shù)據(jù)。然而在Spark Streaming在實(shí)時計算中不能支持實(shí)時讀取數(shù)據(jù)，而是在窗口結(jié)束時一次性抽取，造成了一次抽取大量數(shù)據(jù)，造成網(wǎng)絡(luò)波動異常，流量尖刺。
解決方案：
由于Spark流式計算本質(zhì)上是微批處理，盡管使用各種手段（限制抽取數(shù)據(jù)大小、減少窗口大小），仍然指標(biāo)不治本，由此嘗試找Spark的替代方案，我們調(diào)研了Flink，經(jīng)測試Flink能夠完美的解決實(shí)時抽取的問題，并在數(shù)據(jù)延時方面處理有一項(xiàng)不到的效果，顯著提高了數(shù)據(jù)準(zhǔn)確度。
（2）性能問題
問題描述：
系統(tǒng)在1期時，為了實(shí)時計算歷史特征（周期性，同比等），算法計算的輸入是360個數(shù)據(jù)點(diǎn)（當(dāng)前時間區(qū)間的120個點(diǎn)，前一天同區(qū)間的120個點(diǎn)，7天前同區(qū)間的120個點(diǎn)），歷史數(shù)據(jù)存儲在HBase（作為TSDB存在）中，但是隨著KPI數(shù)量增長（當(dāng)前已有10萬級），三個時間段分布在不同的HBase Key（Key 設(shè)計：keyId + DayHour， Column設(shè)計：minute）中，意味著每次計算需要查詢3次HBase，當(dāng)KPI到達(dá)20萬級時，需要查詢60萬次，由于前期采用的還是Spark Steaming模式計算，QPS超過20w，HBase出現(xiàn)明顯延遲。
分析：
由于算法所需數(shù)據(jù)點(diǎn)甚大，實(shí)時計算抽取歷史數(shù)據(jù)成為瓶頸，團(tuán)隊(duì)的攻城獅們自然想到的是減少算法數(shù)據(jù)需求，最好是用實(shí)時的1個數(shù)據(jù)點(diǎn)進(jìn)行計算，但對于算法來說是完全不可能實(shí)現(xiàn)的，其一，一個點(diǎn)的輸入完全構(gòu)建不了任何特征，算法無從獲知曲線形態(tài)，不知道同環(huán)比等，只會退化到傳統(tǒng)的閾值計算；其二，1期所有特征工程基于360個計算，計算點(diǎn)過度減少相當(dāng)于1期的算法工作全部推翻重做。經(jīng)過大量討論論證，得出如下解決方案：
解決方案：
1.算法輸入精簡，由360個數(shù)據(jù)點(diǎn)更改為當(dāng)前時間區(qū)間的60個點(diǎn)，部分實(shí)時特征轉(zhuǎn)為離線計算特征，通過內(nèi)存加載，無需實(shí)時進(jìn)行計算，既保留當(dāng)前曲線的數(shù)據(jù)特征，又能減少實(shí)時計算模塊的需求；
2.去HBase改為Redis，將60個緩存至Redis中，采用pipeline方法，進(jìn)行頭尾操作（新數(shù)據(jù)點(diǎn)插入頭部，舊的數(shù)據(jù)點(diǎn)從尾部剔除）。
AIOps前行的路上荊棘叢生，類似的難題還有很多，很多方法也不一定是最優(yōu)方案，好在大家愿意嘗試，愿意試錯。
?
四、總結(jié)與展望
網(wǎng)易杭研智能監(jiān)控系統(tǒng)經(jīng)歷了2期的開發(fā)，當(dāng)前智能監(jiān)控系統(tǒng)2.0已上線，算法召回率在70%左右，報警覆蓋度100%，報警配置成本節(jié)省90%，傳媒、考拉、URS、云閱讀、網(wǎng)易金融等產(chǎn)品先后接入智能監(jiān)控報警（排名不分先后），也多次及時的探測到異常事故及時止損，減少損失。?
當(dāng)前系統(tǒng)也存在很多不足：
1.算法召回率不高，仍需要專家經(jīng)驗(yàn)與算法的結(jié)合；
2.當(dāng)前智能監(jiān)控系統(tǒng)只能基于單KPI計算，不滿足多KPI計算；
3.依賴數(shù)據(jù)源的豐富，缺乏全鏈路監(jiān)控。?
智能監(jiān)控是AIOps中冰山一角，除了解決當(dāng)前不足以外，我們還有很多工作要做，例如根因分析、場景監(jiān)控、故障診斷、故障自愈等等，AIOps之路任重而道遠(yuǎn)，期待廣大志同道合的operator加入AIOps陣營，一起努力。
總結(jié)
以上是生活随笔為你收集整理的从自动化到智能化，网易杭研的AIOps探索与实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 九度OJ 1177：查找 （字符串操作）
- 下一篇： AI 趋势