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

一、網(wǎng)易游戲AIOPS落地線路圖

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

二、異常檢測  

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

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

1、業(yè)務(wù)黃金指標(biāo)

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

1）樣本構(gòu)建

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

2）預(yù)處理

預(yù)處理模塊包含曲線分類、缺失標(biāo)準(zhǔn)化處理以及特征計算三個部分。曲線分類采用LSTM+CNN的方式實現(xiàn)，將待檢測KPI分成3類（穩(wěn)定、不穩(wěn)定、不檢測），分類準(zhǔn)確率可達(dá)到93%+。線性和前值填充的方式進(jìn)行缺失值處理，并max-min歸一化。特征包含統(tǒng)計特征、擬合特征、分類特征、濾波特征、自定義特征等，構(gòu)建近500維特征?？紤]到無效特征問題，需要進(jìn)行特征選擇，再進(jìn)行建模。  

3）算法模型

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

4）可視化

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

通過有監(jiān)督模型的方式可達(dá)到高準(zhǔn)召率的檢測效果，線上檢測效果可達(dá)到90%+，可滿足用戶的需求。

2、性能指標(biāo)

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

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

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

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

無監(jiān)督的檢測模型，準(zhǔn)召率可達(dá)到80%+，基本可達(dá)到用戶預(yù)期。通過圖文告警的方式告警，幫助用戶快速確認(rèn)報警的正確性。

3、文本數(shù)據(jù)

業(yè)務(wù)的高速發(fā)展，對系統(tǒng)穩(wěn)定性提出了更高的要求，各個系統(tǒng)每天產(chǎn)生大量的日志：

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

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

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

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

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

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

三、故障定位

在標(biāo)準(zhǔn)的故障處理流程中，故障定位一般可分為兩個階段：

• 故障止損前：可以快速獲得可用于止損決策的信息，做出相應(yīng)的止損操作使得服務(wù)恢復(fù)。
• 故障止損后：進(jìn)一步找到導(dǎo)致故障的深層次原因，確定故障根因，將線上環(huán)境恢復(fù)到正常狀態(tài)。  

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

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

1、資源  

資源維度可區(qū)分機(jī)器、網(wǎng)絡(luò)渠道、SaaS進(jìn)行分析給出異常信息。  

1）機(jī)器

對最近20min內(nèi)所有metric進(jìn)行異常檢測，計算異常檢測分?jǐn)?shù)。再基于越早發(fā)生的異常越有可能是根因、指標(biāo)異常越嚴(yán)重越可能是根因、機(jī)器故障越嚴(yán)重越可能是根因幾個準(zhǔn)則進(jìn)行排序，給出topN異常機(jī)器。

2）網(wǎng)絡(luò)/渠道

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

3）saas

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

2、代碼

代碼問題直接可通過日志分類和異常檢測發(fā)現(xiàn)，給出topN異常模板。

3、人為操作

人為部分主要是變更事件，與變更系統(tǒng)聯(lián)動，關(guān)聯(lián)到故障發(fā)生前的變更事件，并異常提醒。

4、歷史故障

除了分析機(jī)器、代碼等問題，還有一個比較有效定位故障根因的方式就是關(guān)聯(lián)歷史故障。如果本次故障與歷史故障異常表現(xiàn)相似，那么大概率是相同的原因?qū)е?，故可以歷史故障原因作為本次故障根因的推薦。計算當(dāng)前故障與歷史故障的Tanimoto系數(shù)，推薦Tanimoto值最大且超過閾值的topN故障以及其根因。

整體的故障定位流程，檢測到故障的發(fā)生，基于拓?fù)滟Y源、代碼、人為因素、歷史故障這幾個角度出發(fā)，采用不同的方式進(jìn)行根因分析。如檢測到游戲在線人數(shù)下降，出發(fā)故障定位流程，檢測到機(jī)器A 網(wǎng)絡(luò)連接異常，告警出網(wǎng)絡(luò)問題，人工進(jìn)行排查出公網(wǎng)故障導(dǎo)致。

圖片