根據 Gartner 的最新闡釋，智能運維（AIOps）意指整合大數據和機器學習能力，通過松耦合、可擴展方式去提取和分析數據量（volume）、種類（variety）和速度（velocity）這三個維度不斷增長的 IT 數據，進而為 IT 運維管理產品提供支撐。AIOps 圍繞質量保障、成本管理和效率提升的基本運維場景，逐步構建智能化運維場景。在質量保障方面，保障現網穩定運行細分為異常檢測、故障診斷、故障預測、故障自愈等基本場景；在成本管理方面，細分為資源優化，容量規劃，性能優化等基本場景；在效率方面，分為智能變更、智能問答，智能決策等基本場景。

一、網易游戲AIOPS落地線路圖

2016年開始, 網易游戲在AIOps這條道路上持續探索，力求實現從人工運維到智能化運維的轉變。從2016年開始組建智能監控團隊，構建智能運維平臺，一直到現在，落地了異常檢測、預測、關聯分析、下鉆分析、日志分析、運維機器人、故障定位、故障預警等。除此之外，還有很多其他功能，如火焰圖分析、硬件預測、CDN文件發布等，都取得不錯的實踐效果。

二、異常檢測  

異常檢測是研究AIOps的必經之路，后續很多場景功能都以異常檢測為基礎，屬于不得不解決的問題。異常檢測指通過 AI 算法，自動、實時、準確地從監控數據中發現異常，為后續的診斷、“自愈”提供基礎。相比傳統閾值配置成本高、誤報多、場景覆蓋少的問題，異常檢測有易配置、準確率高、場景覆蓋面廣、自動更新等優點。

對于異常檢測，其實網上很多文檔或者書籍都給出了一些算法或者工具，但在實際運用的過程中，會發現效果往往不是很好，究其原因是這些算法只能有效地針對一些特定的場景、以及需要做很多的優化來適配實際的場景。為了更好地在實際場景中落地，我們對算法做了一些調整優化，并結合業務需求對指標進行劃分，達到更好的檢測效果。我們將異常檢測根據指標類型劃分成了三種場景----業務黃金指標（如游戲在線人數）、性能指標（如cpu使用率）、文本數據（如日志），采用不同的檢測算法。

1、業務黃金指標

業務黃金指標的特性是周期性強、曲線波動小、指標量級小、準確率和召回率要求高。我們知道有監督模型具有高準召率、高擴展性的優點，因此我們考慮采用有監督模型對業務黃金指標進行異常檢測。然而有監督模型需要大量的標注數據，但對異常檢測項目很難收集到足夠的異常數據。那應該如何去解決和平衡這兩者之間的關系呢？我們從樣本構建到報警可視化，構建了一整套的檢測框架。

1）樣本構建

考慮到樣本收集困難問題，我們的樣本主要來自兩個方面——歷史KPI數據集和線上用戶標注數據。首先，抽樣部分KPI數據集，采用簡單無監督檢測模型如Iforest檢測得到異常score，通過不等比例分層抽樣篩選出疑似異常樣本和正常樣本，進行人工標注，并劃分成訓練集和測試集用戶模型訓練和測試。功能上線后，收集用戶標注數據，用于模型優化。用戶標注的數據僅會作用于本項目，避免不同用戶異常認知差異導致的錯誤報警問題。還有一點需要注意，當歷史異常數據不足時候，可以通過異常生成的方式生成樣本，如加噪聲、設計抖動模式等方式。

2）預處理

預處理模塊包含曲線分類、缺失標準化處理以及特征計算三個部分。曲線分類采用LSTM+CNN的方式實現，將待檢測KPI分成3類（穩定、不穩定、不檢測），分類準確率可達到93%+。線性和前值填充的方式進行缺失值處理，并max-min歸一化。特征包含統計特征、擬合特征、分類特征、濾波特征、自定義特征等，構建近500維特征。考慮到無效特征問題，需要進行特征選擇，再進行建模。  

3）算法模型

模型主要采用常見模型，如RF\XGB\GBDT等，再用LR進行集成，進行檢測。

4）可視化

可視化部分包含圖文告警、快速標注、異常視圖三個模塊。通過圖文形式進行報警，在報警消息中加上快速標注鏈接，用戶在收到報警后可以快速確認是否有異常發生并標注。

通過有監督模型的方式可達到高準召率的檢測效果，線上檢測效果可達到90%+，可滿足用戶的需求。

2、性能指標

有監督檢測模型可以很好地對業務黃金指標進行檢測，但并不適合性能指標場景。如上面所說，性能指標量級大、指標類型復雜、周期不定等。若依舊考慮采用有監督模型，需要花費巨大的標注成本和訓練成本，對于大規模部署的業務很不友好。因此，我們采用無監督模型來檢測性能類型指標。

我們按異常類型進行劃分，劃分成毛刺、漂移、高頻、線型趨勢四種類型，分別采用不同的檢測模型進行檢測，用戶可以根據自己的需求進行選擇報警類型。

• 毛刺類型：毛刺異常是最常見的一種類型，可以采用差分和SR算法進行檢測，都有不錯的效果。  
• 漂移類型：漂移問題，首先需要進行STL周期分解，分解出周期、趨勢和殘差項。然后采用均值漂移和魯棒回歸算法進行檢測。
  
• 高頻類型：高頻是毛刺的一種變種，有時不關心順時的抖動，但是持續抖動時候就需要關注了。因此，采用的檢測算法也會比較類型，可以采用多步差分進行檢測。
  
• 線性趨勢類型：線性趨勢主要是為了監控內存泄漏類型問題，可以先進行STL分解，在LR回歸和MK檢測進行趨勢檢測。
  

最后，均需要進行周期抑制的步驟，避免周期性的誤報問題。

無監督的檢測模型，準召率可達到80%+，基本可達到用戶預期。通過圖文告警的方式告警，幫助用戶快速確認報警的正確性。

3、文本數據

業務的高速發展，對系統穩定性提出了更高的要求，各個系統每天產生大量的日志：

• 系統有潛在異常，但被淹沒在海量日志中，有的項目警量最多可達每日1w+，如何合并告警。
• 故障出現后，日志報警量級太大，難以定位。
  
• 新版本上線，系統行為有變化，卻無法感知。
  

這些問題，歸根到底，是日志信息太多、格式多樣，不能很好歸類。日志智能分析基于大數據和AI算法，提供實時日志智能分類，以及日志指標異常檢測等功能。利用模型根據日志文本的相似性進行歸類，自動提取對應的日志模版。如下圖，可以從兩條日志中提取出模板。

目前業界日志分類的算法相對成熟，有很多的算法都可以達到不錯的效果。一次分類我們采用drain算法，然后Spell進行二次分類，解決一次分類長度不同日志分在不同模板的問題。

得到日志模板后，可以基于日志模板數量進行異常檢測。智能異常檢測會對比不同時間段的分類日志數量，利用機器學習模型自動識別突變或者和歷史趨勢不一致的日志類型，并發出告警信息：

• 根據歷史兩天日志分布情況訓練模型，學習正常日志波動周期。
• 從日志整體分布分析，減少單類日志小抖動造成的誤報。
  
• 自動選取影響分布最大的topN類日志。
  

與指標異常檢測不同，日志異常檢測可以檢測到代碼類型異常，對程序排障有重大幫助。此外，日志分類可以對日志治理也要很大的幫助，新項目/服務上線時候通過審查日志模板，可以根據需求整理、刪除無效日志。

三、故障定位

在標準的故障處理流程中，故障定位一般可分為兩個階段：

• 故障止損前：可以快速獲得可用于止損決策的信息，做出相應的止損操作使得服務恢復。
• 故障止損后：進一步找到導致故障的深層次原因，確定故障根因，將線上環境恢復到正常狀態。  

在游戲場景中，隨著游戲及系統架構的日漸復雜，運維人員收到的報警信息也變得多種多樣，在面對故障時，紛雜的報警信息令運維人員一時難以理清邏輯，甚至顧此失彼，無法在第一時間解決最核心的問題：

• 游戲架構日漸復雜，出現故障后排查鏈路比較長。
• 故障產生后，往往會引發多個報警，但是這些報警比較零散，沒有按照一定的規則去分類和可視化。導致排查過程中需要人工先去梳理，和過濾報警。
  
• 目前故障定位依賴人工經驗，這些經驗難以被復用。
  

1、資源  

資源維度可區分機器、網絡渠道、SaaS進行分析給出異常信息。  

1）機器

對最近20min內所有metric進行異常檢測，計算異常檢測分數。再基于越早發生的異常越有可能是根因、指標異常越嚴重越可能是根因、機器故障越嚴重越可能是根因幾個準則進行排序，給出topN異常機器。

2）網絡/渠道

采用Adtributor算法，按區域、運營商等維度進行下鉆分析，給出topN異常維度。

3）saas

目前我們SaaS有比較完善的報警，直接可獲取異常結果進行匯總。

2、代碼

代碼問題直接可通過日志分類和異常檢測發現，給出topN異常模板。

3、人為操作

人為部分主要是變更事件，與變更系統聯動，關聯到故障發生前的變更事件，并異常提醒。

4、歷史故障

除了分析機器、代碼等問題，還有一個比較有效定位故障根因的方式就是關聯歷史故障。如果本次故障與歷史故障異常表現相似，那么大概率是相同的原因導致，故可以歷史故障原因作為本次故障根因的推薦。計算當前故障與歷史故障的Tanimoto系數，推薦Tanimoto值最大且超過閾值的topN故障以及其根因。

整體的故障定位流程，檢測到故障的發生，基于拓撲資源、代碼、人為因素、歷史故障這幾個角度出發，采用不同的方式進行根因分析。如檢測到游戲在線人數下降，出發故障定位流程，檢測到機器A 網絡連接異常，告警出網絡問題，人工進行排查出公網故障導致。

圖片