从自动化到智能化，网易杭研的AIOps探索与实践
本文由作者授權發布，未經許可，請勿轉載。
作者：席晶晶，網易杭州研究院運維與賬號中心工程師
?
一、運維面臨問題與挑戰
眼下，隨著信息化、數字化的深入發展，技術飛速迭代，應用服務也不斷升級，企業面臨的運維壓力也越來越大，傳統運維受到了前所未有的挑戰。
（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陣營，一起努力。
總結
以上是生活随笔為你收集整理的从自动化到智能化，网易杭研的AIOps探索与实践的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 九度OJ 1177：查找 （字符串操作）
- 下一篇： 如何听清楚、说明白--《结构思考力》