在大資料時代下，我們藉助機器學習、資料倉庫、大資料平臺等大資料技術手段，將運維產生的資料進行分析、處理，得出最佳運維策略，以期實現對故障的事先干預，將風險降低到最低，從而降低運維成本，提升運維效率，最終實現運維智慧化。本文分享網易杭州研究院在這個領域的實踐經驗。

本文由作者授權釋出，未經許可，請勿轉載。

作者：席晶晶，網易杭州研究院運維與賬號中心工程師

一、運維面臨問題與挑戰

眼下，隨著資訊化、數字化的深入發展，技術飛速迭代，應用服務也不斷升級，企業面臨的運維壓力也越來越大，傳統運維受到了前所未有的挑戰。

（1） 運維內容：傳統的網際網路運維的內容僅是關注軟硬體、網路、應用系統及基礎裝置的運維，而當前將面臨數十萬臺主機、容器，複雜的網路環境，以及複雜的部署環境：私有云、公有云、跨IDC混合部署。

（2） 運維工具：傳統的網際網路運維儘管也利用了工具實現了部分工作的自動化，但主要依賴人力，工作量較大，並效率低下，業務快速增長，技術飛速迭代，意味著工具也要順勢升級。

（3） 運維模式：7*24小時服務模式，PE\SA\DBA 成為了“救火式”英雄，監聽著成千上萬的監控指標，一旦故障出現，SA、PE、DBA、開發童鞋齊上陣，被故障牽著走，被動性強且風險高。


面對新的挑戰，網易杭州研究院運維服務團隊不僅要打造資訊化、數字化的綜合管理體系，為企業帶來全方位IT運維服務，同時還要提供定製化、專業化、全鏈路、無死角的運維解決方案。在大資料時代下，我們藉助機器學習、資料倉庫、大資料平臺等大資料技術手段，將運維產生的資料進行分析、處理，得出最佳運維策略，以期實現對故障的事先干預，將風險降低到最低，從而降低運維成本，提升運維效率，最終實現運維智慧化。

二、AIOps 現狀、定位以及我們的理解

AIOps即智慧運維，是 Gartner 在2016年提出的概念，真正火起來是在這兩年，這個概念提出後，各大廠都已經先後利用AIOps理念培養智慧運維人才梯隊，建設智慧運維平臺、打造智慧運維體系。Gartner預測到2020年，將近50%的企業將會在他們的業務和 IT 運維方面採用 AIOps 。高效運維發起人蕭田國在《AIOps實施之路》中指出了AIOps在效率提升、質量保障、成本優化提出了系列可應用方向以及實施AIOps需要具備的能力。

AIOps應用場景

智慧運維應用場景主要包括如下幾個方面。

AIOps應用場景

AIOps人員結構的轉變

智慧運維也會帶來人員結構的變化，如下圖所示。

AIOps人員結構的轉變

網易杭研於2018年正式加入智慧運維大營，擁抱變化，以實現全鏈路、無死角智慧運維體系為目標，旨在利用AI的能力解決運維行業的問題：

1.解決重複造輪子的問題；
2.解決運維效率仍然低下的問題；
3.運維的資料沒有得到合理應用的問題。

故障管理全場景圖

上圖為故障管理全場景圖，該圖從服務部署、故障發生、故障發現、故障止損、根因診斷、故障恢復、故障關閉，完整的闡述應用監控的故障管理生命週期。

網易杭研實施中的智慧運維產品形態

 

網易杭研實施中的智慧運維產品形態

當前網易杭研實施中的智慧運維產品形態如上圖，主要包括五大模組：

·  故障預警：通過演算法計算KPI曲線變化趨勢，故障前發出故障預警；
·  故障告警：能對週期性變化指標進行預測和異常檢測，且有告警分級；
·  告警合併：支援按照合適的維度對告警進行合併，展現概況資訊；
·  根因分析：智慧對故障根因進行分析，給出最可能的原因，輔助人做決策；
·  故障自愈：可以根據故障原因選擇合適的故障自愈策略並執行，自動解決故障。

三、網易杭研AIOps實戰場景-智慧監控

筆者自接觸智慧運維以來，也是三千煩勞絲，如何讓運維“智慧”起來？如何讓AIOps結合網易現有運維體系實施落地? 又如何推進AIOps發展? 種種挑戰考驗著我們的團隊。經過1年來不斷探索、研究、試錯，我們首先在監控方面突破，下面介紹如何從0到1建設AIOps應用-智慧監控系統的心路歷程。

3.1 運維監控現狀

隨著網際網路，特別是移動網際網路的高速發展，web服務已經深入到社會的各個領域，人們使用網際網路搜尋，購物，付款，娛樂等等。因此，保障web服務的穩定已經變的越來越重要。運維人員通過監控各種各樣的關鍵效能指標（KPI）來判斷服務、系統是否穩定，因為KPI如果發生異常，往往意味著與其相關的應用發生了問題。這些KPI可能包括：基礎KPI及服務KPI，服務KPI是指能夠反映Web服務的規模、質量的效能指標，例如，網頁響應時間，網頁訪問量，連線錯誤數量等。基礎KPI是指能夠反映機器（伺服器、路由器、交換機）健康狀態的效能指標，例如，磁碟使用率，CPU使用率，記憶體使用率，磁碟IO，網絡卡吞吐率等。

這些KPI資料表現為時序序列，即一條指標曲線（後文統一稱KPI曲線）。由此問題轉化為對曲線的異常判斷，KPI曲線可以簡單分類下面三種類型：

週期型：


隨機型：


平穩型：


在網易杭研基於基礎設施管理的CMDB系統-哨兵系統，通過哨兵 Agent將資料實時/取樣的傳輸至哨兵服務端進行視覺化及報警監控。監控系統主要採用規則判定的報警方式，設定上限、下限閾值，觸發規則則發出報警，隨著業務整合越來越多，體量也越來越大，規則報警也到了其瓶頸，主要有以下痛點：

（1）需要頻繁調整閾值

case1：隨著業務變化，已有的閾值適用性變差，當業務發生變動時，報警規則也需要及時調整；
case2：夜間與白天範圍不一樣，工作日與週末不一樣，統一的閾值適用性較差。

（2）覆蓋範圍有限

傳統的方式，需要針對指標的每一項進行設定報警規則，比如在DubboProviderCollector，每個方法對應的呼叫叢集的量不一，需要獨立配置報警規則，那麼配置將會相當耗時且繁瑣，並且很多Dubbo服務介面都是隨業務隨時新增或下線，很容易被忽視。

（3）無效報警過多

閾值規則報警的方式，往往會出現這樣的情況，當閾值設定的太高，異常很難被發現，當閾值設定的太低，則會造成大量報警，造成報警風暴，真正有用的報警訊息淹沒在風暴中。

3.2 演算法引入

針對上述痛點，我們思考如何利用演算法來突破傳統的閾值報警侷限性，於是調研了業界使用的各種異常檢測演算法。較為常見的演算法包括邏輯迴歸、關聯關係挖掘、聚類、決策樹、隨機森林、支援向量機、蒙特卡洛樹搜尋、隱式馬爾科夫、多示例學習、遷移學習、卷積神經網路等，以及數學演算法類：K-Sigma，Grubbs，Turkey，MeanPercent，Value，AR，MR，ARIMA。

通用異常檢測流程：


曾想使用一種或一類演算法來解決所有KPI曲線的預測，而碰到業務情況遠比我們想象要複雜，例如：首先面臨各種不同曲線表現特徵不一，同一型別的演算法很難做到召回率整體提升；其二，在同樣型別Dubbo呼叫異常 KPI曲線波動情況，在一些產品是可以接受的，但是在其他產品可能是不能接受的異常，可能在某業務在意的指標，在其他產品無需在意；第三，儘管想做到一個模型泛化相容所有場景，但是所需特徵工程工作量巨大，特徵也很多。

有人說採用投票的方法，用一大堆演算法同時預測，對於結果進行投票，少數服從多數，這種方式也是存在一定的缺陷，本身每個演算法適用性不一樣，那麼勢必在影響投票結果。網易杭研採用的是分類演算法，即在不同的場景下采用一類演算法進行預測，以減少誤判率，我們調研和使用了上述部分演算法：

機器學習類：


特徵工程是機器學習中一塊重要的環節，針對單一KPI表現的資料形態將逐一轉換為資料特徵，如下將資料特徵歸類如下5個方面：

1.統計特徵 ：描述樣本內相關的數學表現，例如：方差、均值、中位數、斜率、偏度、峰度等重要指標；
2.擬合特徵 ：獲取曲線的動態特徵，根據曲線平穩或不平穩，採用不同模型獲取預測值與實際值的差；
3.週期特徵：利用滑動視窗，傅立葉轉換，獲取曲線中可能存在的季節性、週期性特徵；
4.分類特徵：基於曲線變換、小波變換、主成分分析等方式 獲取曲線分類特徵；
5.業務特徵：KPI具有業務叢集效應，工作日郵箱訪問量，週末遊戲訪問量等業務特徵。
由於篇幅有限，這裡就不列舉所有特徵。

數學演算法類：

（1）恆定閾值類演算法

恆定閾值的含義是表示均值基本恆定，標準差與均值比約等於0（即KPI曲線近似一條直線）。


（2）突升突降類演算法

突變的含義是發生了均值漂移

空間轉換:


（3）同比演算法

適用於週期性資料表現，每天同時刻的資料分佈相似

引數估計：求正態分佈的均值、方差

3.3 功能設計

（1）KPI 管理
·  標註打標：提供標註打標的功能，標記/取消標記為正負樣本，標記後樣本自動轉存樣本庫
·  樣本管理：提供樣本管理功能，檢索、圖示、編輯、刪除等功能
·  異常查詢：經API檢測後的時間序列（僅異常）入庫儲存，提供管理功能，分頁查詢、檢索、放縮等
（2）模型管理
·  模型管理：提供模型管理功能
·  模型訓練：支援自定義模型訓練
（通過PE或開發標註的異常KPI，正常KPI訓練符合自己業務的模型，或使用開放的通用模型）
（3）KPI異常檢測
·  基於數學統計演算法整合
·  基於機器學習演算法整合
（4）多維度報警聚合
·  按產品維度合併
·  按應用維度合併
·  按叢集維度合併
·  按單機維度合併
·  按業務型別合併
·  按報警接收人維度合併
（5）反饋系統
·  使用者標記、報警關閉

3.4 架構設計

我們將整個智慧監控系統分為7個核心功能模組，每個模組承擔異常檢測流程中相應功能，整體架構上做到模組之間相互獨立，通過資料流訊號、RPC進行模組通訊。

序號模組名稱1配置管理中心配置庫、模型庫、標註庫 相關配置與管理（含UI）2流式計算中心KPI預處理、KPI聚合、KPI分發3資料儲存&讀取中心用於讀寫KPI時序資料4訊息中心資料→ 訊息 用於觸發模型計算、插值計算5演算法中心異常檢測、模型訓練6報警處理中心用於解析異常KPI及傳送報警內容至哨兵報警中心7反饋系統用於反饋報警是否有效，反饋於模型提升

系統架構如下：
網易杭研智慧監控系統架構  資料架構如下：
網易杭研智慧監控資料架構 

3.5 難題

前面介紹了網易杭研智慧監控系統的在智慧監控系統中整體功能及架構設計，下面簡單聊聊我們碰到一些問題以及解決思路：

（1）實時計算問題
問題描述：
1期採用的是Spark Streaming實時計算框架，通過直連Kafka獲取資料來源，但是在實際生產中，由於資料來源是取樣收集（有1分鐘取樣，有2分鐘取樣），發現每1分鐘會有流量尖刺現象，隨著KPI數量增多，尖刺更明顯。
分析：
經分析，發現Spark Streaming 並非是實時的資料抽取Kafka的資料。然而在Spark Streaming在實時計算中不能支援實時讀取資料，而是在視窗結束時一次性抽取，造成了一次抽取大量資料，造成網路波動異常，流量尖刺。
解決方案：
由於Spark流式計算本質上是微批處理，儘管使用各種手段（限制抽取資料大小、減少視窗大小），仍然指標不治本，由此嘗試找Spark的替代方案，我們調研了Flink，經測試Flink能夠完美的解決實時抽取的問題，並在資料延時方面處理有一項不到的效果，顯著提高了資料準確度。

（2）效能問題
問題描述：
系統在1期時，為了實時計算曆史特徵（週期性，同比等），演算法計算的輸入是360個數據點（當前時間區間的120個點，前一天同區間的120個點，7天前同區間的120個點），歷史資料儲存在HBase（作為TSDB存在）中，但是隨著KPI數量增長（當前已有10萬級），三個時間段分佈在不同的HBase Key（Key 設計：keyId + DayHour， Column設計：minute）中，意味著每次計算需要查詢3次HBase，當KPI到達20萬級時，需要查詢60萬次，由於前期採用的還是Spark Steaming模式計算，QPS超過20w，HBase出現明顯延遲。
分析：
由於演算法所需資料點甚大，實時計算抽取歷史資料成為瓶頸，團隊的攻城獅們自然想到的是減少演算法資料需求，最好是用實時的1個數據點進行計算，但對於演算法來說是完全不可能實現的，其一，一個點的輸入完全構建不了任何特徵，演算法無從獲知曲線形態，不知道同環比等，只會退化到傳統的閾值計算；其二，1期所有特徵工程基於360個計算，計算點過度減少相當於1期的演算法工作全部推翻重做。經過大量討論論證，得出如下解決方案：
解決方案：
1.演算法輸入精簡，由360個數據點更改為當前時間區間的60個點，部分實時特徵轉為離線計算特徵，通過記憶體載入，無需實時進行計算，既保留當前曲線的資料特徵，又能減少實時計算模組的需求；
2.去HBase改為Redis，將60個快取至Redis中，採用pipeline方法，進行頭尾操作（新資料點插入頭部，舊的資料點從尾部剔除）。
AIOps前行的路上荊棘叢生，類似的難題還有很多，很多方法也不一定是最優方案，好在大家願意嘗試，願意試錯。

四、總結與展望

網易杭研智慧監控系統經歷了2期的開發，當前智慧監控系統2.0已上線，演算法召回率在70%左右，報警覆蓋度100%，報警配置成本節省90%，傳媒、考拉、URS、雲閱讀、網易金融等產品先後接入智慧監控報警（排名不分先後），也多次及時的探測到異常事故及時止損，減少損失。 
當前系統也存在很多不足：
1.演算法召回率不高，仍需要專家經驗與演算法的結合；
2.當前智慧監控系統只能基於單KPI計算，不滿足多KPI計算；
3.依賴資料來源的豐富，缺乏全鏈路監控。 
智慧監控是AIOps中冰山一角，除了解決當前不足以外，我們還有很多工作要做，例如根因分析、場景監控、故障診斷、故障自愈等等，AIOps之路任重而道遠，期待廣大志同道合的operator加入AIOps陣營，一起努力。