本次分享主要介紹如下幾點(diǎn)：

• AIOps路線規(guī)劃
• ?異常檢測?
• 平臺化建設(shè)
• 故障管理智能化

AIOps即智能運(yùn)維，是 Gartner 在2016年提出的概念。最初的定義是Algorithm IT Operations，指通過機(jī)器學(xué)習(xí)，數(shù)據(jù)倉庫以及大數(shù)據(jù)等技術(shù)手段，將人工智能應(yīng)用于運(yùn)維領(lǐng)域，基于運(yùn)維產(chǎn)生的數(shù)據(jù)（日志，監(jiān)控，應(yīng)用等）進(jìn)行分析決策，得出最佳的運(yùn)維策略，并隨著技術(shù)的成熟，最終走向無人化運(yùn)維。

一、AIOps路線規(guī)劃

1、AIOps能力階段

羅馬非一日建成，根據(jù)之前發(fā)布的企業(yè)級AIOps實(shí)施白皮書指出AIOps的發(fā)展主要有以下的五個階段，這個在我們目前的實(shí)踐過程也確實(shí)得到了驗證。

• 開始嘗試應(yīng)用AI能力，還無較為成熟的單點(diǎn)應(yīng)用。
• 具備單場景的AI運(yùn)維能力，可以初步形成供內(nèi)部使用的學(xué)件。
• 有由多個單場景AI運(yùn)維模塊串聯(lián)起來的流程化AI運(yùn)維能力，可以對外提供可靠的運(yùn)維AI學(xué)件。
• 主要運(yùn)維場景均已實(shí)現(xiàn)流程化免干預(yù)AI運(yùn)維能力，可以對外提供供可靠的AIOps服務(wù)。
• 有核心中樞AI，可以在成本、質(zhì)量、效率間從容調(diào)整，達(dá)到業(yè)務(wù)不同生命周期對三個方面不同的指標(biāo)要求，可實(shí)現(xiàn)多目標(biāo)下的最優(yōu)或按需最優(yōu)。

網(wǎng)易游戲智能運(yùn)維團(tuán)隊于2018年開始進(jìn)行算法研究以及具體落地場景的選擇，后續(xù)在在線人數(shù)、異常檢測、日志異常檢測方面嘗試單點(diǎn)應(yīng)用突破，并取得顯著的成效。目前通過串聯(lián)各維度運(yùn)維信息和報警信息來進(jìn)村后故障發(fā)現(xiàn)和故障自愈的目的，達(dá)到多個單場景AI運(yùn)維模塊串聯(lián)的流程化AI運(yùn)維能力。

這里的學(xué)件指的是AI運(yùn)維組件，由南京大學(xué)周志華老師原創(chuàng)，是指模型+規(guī)約，具有可重用、可演進(jìn)、可了解的特性。

AIOps階段

2、人員結(jié)構(gòu)

相較于Devops，AIOps的人員結(jié)構(gòu)肯定也發(fā)生了一些變化，最顯著的變化就是加入了算法工程師這個角色。有的團(tuán)隊會傾向于叫算法開發(fā)研發(fā)工程師，也就是既具備算法的能力也具備平臺開發(fā)能力的工程師。當(dāng)然如果一個算法工程師能夠具備良好的工程能力，這個對于整體的團(tuán)隊發(fā)展肯定是有正向影響的。但很抱歉，一個團(tuán)隊里要求每個算法工程師都具備良好的工程能力其實(shí)是比較困難的，特別的是在招人的時候會發(fā)現(xiàn)，算法和工程還是有一定割裂的。

所以我們團(tuán)隊的配置，更多是下面這三個角色：運(yùn)維工程師，也可以說是我們的用戶，他們負(fù)責(zé)向算法工程師提供具體的業(yè)務(wù)場景及需求，挖掘潛在的智能化場景，同時向平臺研發(fā)工程提供平臺開發(fā)的場景需求。另外就是平臺研發(fā)工程師與算法工程師，一個主要負(fù)責(zé)工程化以及平臺化的建設(shè)，懂一點(diǎn)算法，但其主要職責(zé)更多偏向工程開發(fā)。而算法工程師則注重算法對應(yīng)業(yè)務(wù)的調(diào)研，開發(fā)以及調(diào)優(yōu)，這種結(jié)構(gòu)也是為做到術(shù)業(yè)有專攻的目的。

實(shí)際合作下來，這種合作方式極大地提升了業(yè)務(wù)開發(fā)的效率，但也存在一定技術(shù)盲區(qū)的問題。

3、業(yè)務(wù)領(lǐng)域

1）時間序列異常檢測

時間序列數(shù)據(jù)是按時間順序排列的、隨時間變化且相互關(guān)聯(lián)的數(shù)據(jù)序列。由于運(yùn)維場景的特殊性，運(yùn)維數(shù)據(jù)天生便與時間序列密切相關(guān)。AIOps提供的時間序列智能分析的能力，即是通過研究歷史數(shù)據(jù)的變化趨勢和內(nèi)在性質(zhì)，來實(shí)現(xiàn)時間序列預(yù)測，異常數(shù)據(jù)監(jiān)測等無需人工參與的智能分析功能。

2）故障定位與根因分析

隨著微服務(wù)的發(fā)展，業(yè)務(wù)組網(wǎng)愈加復(fù)雜，問題的定界定位分析變得尤為困難。故障的識別和診斷是運(yùn)維場景中智能分析的核心部分。AIOps提供的故障識別和根因定位能力，即是通過數(shù)據(jù)挖掘的手段，綜合故障數(shù)據(jù)和人工經(jīng)驗自動提取故障特征，自動定位故障。

3）文本處理分析

文本的處理有廣闊的空間。AIOps提供了范圍極廣的文本處理分析的能力，涵蓋信息提取，語義分析，智能搜索，對話系統(tǒng)等領(lǐng)域，提供可直接應(yīng)用于產(chǎn)品策略的NLP技術(shù)能力。

4）聚類與相似性分析

將物理或抽象對象的集合分成由類似的對象組成的多個類的過程被稱為聚類。聚類即是根據(jù)某種相似性進(jìn)行抽象的過程。AIOps提供的聚類和相似性分析服務(wù)，能夠使用有監(jiān)督或無監(jiān)督算法，結(jié)合統(tǒng)計學(xué)特征，對給定格式的數(shù)據(jù)進(jìn)行相似性聚類，從而極大的降低數(shù)據(jù)的識別和處理成本。

二、異常檢測

1、問題

傳統(tǒng)的靜態(tài)閾值目前已經(jīng)難以適配多變的業(yè)務(wù)場景，閾值過高會遺漏告警，閾值過低會引發(fā)告警風(fēng)暴。時間序列指標(biāo)的異常檢測，不同于傳統(tǒng)的靜態(tài)閾值，用戶不需要自己手動配置。AIOps通過機(jī)器學(xué)習(xí)算法結(jié)合人工標(biāo)注結(jié)果，實(shí)現(xiàn)自動學(xué)習(xí)閾值，自動調(diào)節(jié)參數(shù)，提高告警的精確度和召回率。異常檢測能夠更適配業(yè)務(wù)多樣化的需求，覆蓋更多的異常類型。

2、適用場景

1）異常閾值難以定義

• 難以明確定義正常、異常數(shù)據(jù)，沒有明顯的閾值界限。
• 在不同的時間段有不同的閾值。
• 有一些數(shù)據(jù)的異常突變沒有達(dá)到預(yù)定義的閾值。
• 需要識別的異常是與歷史數(shù)據(jù)的某種表現(xiàn)模式的異常，無法設(shè)置閾值來檢測。

2）人工配置成本高

• 不同的曲線配置不同的閾值，曲線很多的情況下人工配置成本很高。
• 隨著業(yè)務(wù)變化，預(yù)定義的閾值需要隨之變化，運(yùn)維成本高。
• 本身含有噪聲，難以區(qū)分噪聲和異常數(shù)據(jù)，需要花費(fèi)大量人力檢測。

對于異常檢測，其實(shí)網(wǎng)上很多文檔或者書籍都給出了一些常用的算法或者工具，我們這方面相應(yīng)用的也是這些算法或工具，當(dāng)然了也做了許多相應(yīng)的算法優(yōu)化和調(diào)整，我這里給出一些我們團(tuán)隊的在這方面的思考跟策略。

在模型是線上我們選擇統(tǒng)計+規(guī)則的無監(jiān)督方案，主要優(yōu)勢在于：

• 無監(jiān)督無數(shù)據(jù)標(biāo)注成本
• 統(tǒng)計+規(guī)則的方式可解釋性強(qiáng)
• 模型預(yù)測時延較低
• 受曲線時間粒度的影響較小 

3）毛刺異常

毛刺異常表現(xiàn)為在某個時刻，KPI曲線上突然出現(xiàn)的一個不具有周期性的局部極大值毛刺。如果僅用KPI的幅值進(jìn)行閾值判斷，很多時候無法準(zhǔn)確找到異常值，因為KPI值本身也可能存在一定的趨勢。使用一階差分可以有效去除趨勢項，使得異常能夠暴露出來。此外，SR算法對于此類的異常也具有較好的檢測效果。

4）突升突降異常

突升突降異常表現(xiàn)為當(dāng)KPI曲線上出現(xiàn)異常突升或突降，并未馬上恢復(fù)，KPI的值持續(xù)保持在該異常值附近的異常。這是一種持續(xù)異常，很多業(yè)務(wù)如在線人數(shù)、CPU使用率等都非常關(guān)注這類的異常。識別此類的異常可通過異常點(diǎn)兩端窗口內(nèi)的均值偏移來識別。

但是由于KPI本身具有趨勢和周期，正常點(diǎn)兩端窗口也存在均值偏移。此時，可以使用STL對時間序列進(jìn)行分解，然后對殘差部分進(jìn)行均值偏移的計算，即可降低趨勢項和季節(jié)項帶來的誤報。另外，大毛刺也會產(chǎn)生均值偏移，容易產(chǎn)生誤報。因此在計算兩端窗口均值前，用esd檢驗來進(jìn)行異常值的去除，這樣可以去除大毛刺對均值的影響，減少模型的誤報。

5）頻率變化異常

頻率異常表現(xiàn)為持續(xù)的毛刺異常，此時曲線的震蕩加大，也屬于一種持續(xù)異常。雖然此類曲線比較少見，但是也是業(yè)務(wù)比較關(guān)心的異常類型。

可以使用窗口內(nèi)一階差分異常計數(shù)值來進(jìn)行判定。

3、異常判定方法

在設(shè)計出各類檢測模型后，需要根據(jù)模型的輸出進(jìn)行異常判定，從而確定當(dāng)前點(diǎn)是否為異常。針對瞬時異常和持續(xù)異常，需要使用不同的方法進(jìn)行異常判定。

1）分布法

根據(jù)對數(shù)據(jù)分布的假設(shè)，設(shè)定閾值，適用于瞬時異常的判定。我們使用3sigma和箱型圖來判定瞬時異常，經(jīng)測試，在大部分曲線上具有較魯棒的判定結(jié)果。

2）業(yè)務(wù)計數(shù)閾值法

根據(jù)業(yè)務(wù)需求，設(shè)定計數(shù)閾值，適用于持續(xù)異常的判定。我們?yōu)槌掷m(xù)異常設(shè)定計數(shù)閾值，如果異常計數(shù)超過該閾值的時候，就進(jìn)行報警。如魯棒回歸時統(tǒng)計實(shí)際曲線和預(yù)測曲線差值異常的計數(shù)；如窗口內(nèi)一階差分異常的計數(shù)等均可直接通過計數(shù)閾值來判斷。

此外，為了融合不同模型的輸出，得到更魯棒的判定結(jié)果，可以把分布法、業(yè)務(wù)計數(shù)閾值法通過線性轉(zhuǎn)換轉(zhuǎn)化為0-1之間的分?jǐn)?shù)，此時模型融合可以通過分?jǐn)?shù)加權(quán)的方式得到，融合分?jǐn)?shù)超過0.5的即為異常，可以在不同的曲線中保持較優(yōu)的異常判定效果，也具有較強(qiáng)的魯棒性。

三、平臺化建設(shè)

AIOps本身也是一個迭代式的開發(fā)模式，在平臺化期間我們也遇到了一些問題。首先是算法和工程邊界比較模糊，算法工程師希望能夠?qū)Ｗ⑺惴ǖ拈_發(fā)和調(diào)優(yōu)，不想花過多的時間在工程上。還有就是算法包跟工程強(qiáng)耦合，算法的每次調(diào)優(yōu)和參數(shù)變化都需要工程配合發(fā)版。

我們希望算法，工程能夠更好的解耦，既能滿足算法快速迭代的的需求，也能滿足工程平臺開發(fā)穩(wěn)定性的要求。

另外我們還發(fā)現(xiàn)AIOps使用到的數(shù)據(jù)可能是多種多樣的，就異常檢測一個場景來說，基礎(chǔ)指標(biāo)數(shù)據(jù)、日志數(shù)據(jù)、模板數(shù)據(jù)都不同。

擴(kuò)展到故障定位可能還需要用到配置相關(guān)的數(shù)據(jù)，比如業(yè)務(wù)拓?fù)渚W(wǎng)絡(luò)拓?fù)涞腃MDB數(shù)據(jù)，甚至再結(jié)合到異常事件，變更事件這一類事件信息數(shù)據(jù)等等。

1、系統(tǒng)架構(gòu)設(shè)計

基于以上的問題和目標(biāo)，我們設(shè)計如圖所示的五層系統(tǒng)架構(gòu)，其核心目標(biāo)是可按需加載不同的算法，編排不同的檢測流程，在保障高可用的同時，達(dá)到提供多種服務(wù)類型但是又能統(tǒng)一管理，各個業(yè)務(wù)之間甚至進(jìn)程之間隔離，通過統(tǒng)一的平臺進(jìn)行調(diào)度，為了節(jié)省資源，對算力進(jìn)行動態(tài)調(diào)整，保證整個服務(wù)的運(yùn)行效率。

1）數(shù)據(jù)接入層

最下面的數(shù)據(jù)接入層負(fù)責(zé)對各類監(jiān)控指標(biāo)，系統(tǒng)日志，業(yè)務(wù)日志以及業(yè)務(wù)指標(biāo)進(jìn)行實(shí)時的采集。對于系統(tǒng)及業(yè)務(wù)指標(biāo)，可以通過我們監(jiān)控團(tuán)隊自主開發(fā)的agent進(jìn)行數(shù)據(jù)收集，一般在各服務(wù)器初始化的時候就會自動安裝配置。

2）數(shù)據(jù)層

由上面數(shù)據(jù)接入層采集到的數(shù)據(jù)會寫入到HDFS進(jìn)行持久，同時該層也會負(fù)責(zé)將采集到的數(shù)據(jù)進(jìn)行預(yù)處理、ETL、聚合等等。為了提高性能和可用性，指標(biāo)數(shù)據(jù)會根據(jù)冷熱數(shù)據(jù)的區(qū)別分別存儲在TSDB和Redis中，而我們的檢測用到的歷史數(shù)據(jù)就是從這里面獲取的。

3）服務(wù)層

這里主要通過離線的方式對模型進(jìn)行模型訓(xùn)練，將訓(xùn)練完成的模型上傳到S3上進(jìn)行存儲，當(dāng)模型迭代或者算法策略變更時，算法工程師可以自主的完成全鏈路的開發(fā)測試，不需要平臺工程師的接入。由于模型是從平臺框架中抽離出來出來的，可以進(jìn)行獨(dú)立的配置和管理，更進(jìn)一步的降低了算法和工程的耦合。另外當(dāng)有新的業(yè)務(wù)場景接入的時候，算法和工程師可以通過約定接口的方式，各自獨(dú)立進(jìn)行代碼開發(fā)，各自上線。

4）應(yīng)用層

區(qū)別于網(wǎng)絡(luò)服務(wù)的應(yīng)用層，這里更多是指各個不同的saas平臺的功能性應(yīng)用，基礎(chǔ)運(yùn)維負(fù)責(zé)反應(yīng)真是的指標(biāo)波動情況，通過數(shù)據(jù)層對數(shù)據(jù)進(jìn)行聚合，目前我們監(jiān)控團(tuán)隊已經(jīng)做到了秒級監(jiān)控的數(shù)據(jù)展示。而AIOps平臺也是嵌入在這一層里面的，其主要的功能是通過實(shí)時流，任務(wù)調(diào)度等方式，通過調(diào)用相應(yīng)的模型對數(shù)據(jù)進(jìn)行各種算法檢測。

5）展示層

用于檢測結(jié)果展示，已單個事件或數(shù)據(jù)圖譜形式展示。

2、檢測流程設(shè)計

這里主要介紹一下應(yīng)用層的檢測平臺內(nèi)部實(shí)現(xiàn)思路，整體的一個數(shù)據(jù)流向如這張圖所示。用戶會在我們的運(yùn)維門戶網(wǎng)站上建立相應(yīng)的檢測任務(wù)，并將配置同步到flink規(guī)則數(shù)據(jù)庫中進(jìn)行保存，這個時候agent會采集相應(yīng)的指標(biāo)數(shù)據(jù)發(fā)送到flink里進(jìn)行預(yù)處理，flink根據(jù)規(guī)則數(shù)據(jù)庫中配置對數(shù)據(jù)進(jìn)行前置的過濾與預(yù)處理。

處理后的數(shù)據(jù)還會經(jīng)過一個算法編排的模塊，這個模塊主要是根據(jù)之前用戶的配置以及我們預(yù)設(shè)的匹配規(guī)則，為檢測的數(shù)據(jù)增加上一些編排，任務(wù)，策略相關(guān)的信息，這類信息決定了算法所用到的模型，歷史數(shù)據(jù)，特征等信息。隨后根據(jù)這些信息，動態(tài)的加載模型進(jìn)行調(diào)用并輸出結(jié)果。

算法模型作為算法的抽象，可通過注冊上傳的方式將模型上傳至S3種進(jìn)行存儲，注冊完成后的算法模型會相應(yīng)的生成編排，訓(xùn)練的組件。平臺與組件之間，通過定義算法的唯一標(biāo)識，接口，輸入輸出類進(jìn)行交互。平臺調(diào)度引擎會根據(jù)上述配置，動態(tài)的加載相應(yīng)的算法模型進(jìn)行檢測調(diào)度。

具體檢測架構(gòu)實(shí)現(xiàn)思路如圖所示，首先算法模型作為一個可插拔的算法包存在服務(wù)當(dāng)中，每個算法包擁有獨(dú)立的線程資源，利用python的類加載方式可根據(jù)需要進(jìn)行下載和更新，實(shí)現(xiàn)算法模型的熱部署。

框架本身相當(dāng)于一個調(diào)度管理工具，負(fù)責(zé)加載不同版本的算法，執(zhí)行算法路由以及策略計算。同時我們設(shè)計一套相關(guān)的編排調(diào)度協(xié)議，將具體的參數(shù)配置及編排模式開放給工程師自己進(jìn)行定義，進(jìn)一步解耦了算法和工程，業(yè)務(wù)和平臺之間的關(guān)聯(lián)。

如一些業(yè)務(wù)場景往往需要用到歷史數(shù)據(jù)，歷史數(shù)據(jù)的獲取跟預(yù)處理其實(shí)算法工程師并不在意，這類的操作一般都交給平臺工程師來處理。

我們在平臺內(nèi)部將歷史數(shù)據(jù)獲取的邏輯進(jìn)行了抽象化，具體業(yè)務(wù)數(shù)據(jù)的獲取和存儲由平臺工程師根據(jù)業(yè)務(wù)需要編寫相應(yīng)的輸入輸出，算法調(diào)用模塊通過協(xié)議獲取一些關(guān)鍵的參數(shù)與配置，內(nèi)部自動調(diào)用這些具體的類和方法獲取數(shù)據(jù)，并將數(shù)據(jù)傳遞給模型進(jìn)行檢測。

其實(shí)在對歷史數(shù)據(jù)獲取和處理的過程中，歷史數(shù)據(jù)的抽取往往會成為瓶頸，比如算法可能需要7～8天的歷史數(shù)據(jù)作為輸入，那隨著檢測數(shù)量的增加，這對于TSDB是有巨大壓力的，再加上計算歷史特征可能需要的輸入量不盡相同，冷熱數(shù)據(jù)，讀寫分離都能以解決，對我們平臺內(nèi)部也維護(hù)了一套歷史數(shù)據(jù)的內(nèi)存存儲，通過pipeline加數(shù)據(jù)壓縮的方式進(jìn)行歷史數(shù)據(jù)緩存。同時將部分的計算特征通過內(nèi)存進(jìn)行存儲，減少實(shí)時計算模塊的壓力。

這里是我們抽象化類圖的實(shí)現(xiàn)方式，基礎(chǔ)類里面提供了存儲，編排，更新等基本操作，平臺開發(fā)工程師根據(jù)業(yè)務(wù)場景自行定義數(shù)據(jù)以來，通過組合這些獨(dú)立的功能，從而滿足各種不同的業(yè)務(wù)需求。

在用戶體驗方面我也做出了一定的改變，首先是異常標(biāo)注的方式，我看許多的平臺都是以事件和同環(huán)比的形式展示出來，因為我們本來就有了一個報警平臺兄弟系統(tǒng)，而且實(shí)際使用下來發(fā)現(xiàn)這種單個事件同環(huán)比的形式很容易給用戶造成誤解，所以我們用像grafna的大圖形式進(jìn)行異常的展示和標(biāo)注。

另外其實(shí)用戶反饋和標(biāo)注是很重要的，很大程度上決定了模型的調(diào)優(yōu)，提升算法的準(zhǔn)確性，有的時候用戶其實(shí)挺懶的，往往疏忽了標(biāo)注這件事，我們通過內(nèi)部的消息工具popo，直接將檢測結(jié)果與標(biāo)注鏈接發(fā)送給用戶，培養(yǎng)用戶標(biāo)注的好習(xí)慣。

四、故障管理智能化

隨著游戲及系統(tǒng)架構(gòu)的日漸復(fù)雜，運(yùn)維人員收到的報警信息也變得多種多樣，在面對故障時，紛雜的報警信息令運(yùn)維人員一時難以理清邏輯，甚至顧此失彼，無法在第一時間解決最核心的問題。在與我們程序與SRE交流過程中，我們發(fā)現(xiàn)他們面對故障主要存在以下痛點(diǎn)：

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

眾所周知，業(yè)務(wù)指標(biāo)是最直觀反應(yīng)故障情況的手段，日志記錄是記錄應(yīng)用程序運(yùn)行狀態(tài)的重要工具。我們希望在保留細(xì)節(jié)的同時，將上述泛化的報警信息通過聚類的方式進(jìn)行概括，使得在報警發(fā)出后，結(jié)合指標(biāo)、日志、tracing、變更事件等信息，通過故障傳播鏈關(guān)聯(lián)起來，找到最有可能造成故障的原因。

業(yè)務(wù)指標(biāo)是整個故障定位的觸發(fā)源，我們選擇了游戲SLO中的重要指標(biāo)，按照群組的維度進(jìn)行分類。由于SLO業(yè)務(wù)指標(biāo)毛刺較多，直接用普通的毛刺無監(jiān)督模型會產(chǎn)生較多的誤報，只有異常持續(xù)抬升或者下降一段時間，才能被認(rèn)為是異常，因此SLO異常檢測模型使用抬升異常檢測。

抬升異常檢測主要由兩個模型構(gòu)成，一個是均值偏移模型，另一個是預(yù)測均偏移模型，最終的結(jié)果會融合兩個模型的輸入輸出。

1）均值偏移模型

• 計算左右兩側(cè)給定數(shù)量的均值差。
• 當(dāng)差值大于或者小于一定閾值時，則認(rèn)為出現(xiàn)抬升異常。

2）均值預(yù)測偏移模型

• 先用左側(cè)、右側(cè)給定數(shù)量的點(diǎn)分別進(jìn)行線性回歸，預(yù)測右、左兩側(cè)給定數(shù)量的點(diǎn)的值。
• 再將其與右、左兩側(cè)真實(shí)值作差。 
• 對這些差值求均值。 
• 當(dāng)該均值大于或小于一定閾值時，則認(rèn)為出現(xiàn)抬升異常。

在業(yè)務(wù)指標(biāo)異常后，啟動故障定位，開始機(jī)器指標(biāo)異常檢測及排序。通過異常分?jǐn)?shù)排序的方式得出最有可能的異常根因。

• 當(dāng)業(yè)務(wù)指標(biāo)出現(xiàn)異常的時候，在當(dāng)前時間點(diǎn)往前推的20min的區(qū)間內(nèi)對所有指標(biāo)進(jìn)行毛刺異常檢測，計算異常檢測分?jǐn)?shù)。 
• 異常檢測分?jǐn)?shù)乘上時間衰減系數(shù)，作為根因分?jǐn)?shù)，即越早發(fā)生的異常越有可能是根因。 
• 輸出20min內(nèi)根因分?jǐn)?shù)的最大值作為該指標(biāo)的根因分?jǐn)?shù)，然后在機(jī)器名范圍內(nèi)進(jìn)行排序，在僅考慮單根因的前提下，異常最多的機(jī)器作為根因機(jī)器，其中指標(biāo)的異常按照根因分?jǐn)?shù)排序輸出指標(biāo)根因列表。

在對機(jī)器指標(biāo)進(jìn)行異常根因排序的同時，我們還會掃描相關(guān)saas的機(jī)器指標(biāo)與報警信息，最終結(jié)合日志異常檢測及分類，將根因結(jié)果展示給用戶。

Q&A

Q1: 上智能化運(yùn)維前期規(guī)劃上有什么好的方向及規(guī)劃建議？

A1：首先智能運(yùn)維不是一個一蹴而就的過程，是作為一個長期演進(jìn)的系統(tǒng)存在，其根基還是運(yùn)維自動化，數(shù)據(jù)收集，分析，監(jiān)控等基礎(chǔ)運(yùn)維工具。在前期規(guī)劃上需要解決的問題包括海量數(shù)據(jù)的存儲，分析與處理，數(shù)據(jù)倉庫的搭建，基礎(chǔ)監(jiān)控的實(shí)踐經(jīng)驗等。好的數(shù)據(jù)往往比模型更具有價值。在完成上述基礎(chǔ)建設(shè)后，可與具體業(yè)務(wù)人員了解其最關(guān)注的SLO，通過這方面進(jìn)行異常檢測建設(shè)。在模型選擇方面，盡管有監(jiān)督的標(biāo)注成本會很高，但有監(jiān)督模型比無監(jiān)督模型更加容易貼近業(yè)務(wù)需求，在后期更新迭代上占有絕對優(yōu)勢。

Q2：AIOps基礎(chǔ)肯定是大量的歷史監(jiān)控數(shù)據(jù)，數(shù)據(jù)的收集規(guī)則與建模規(guī)則你們怎么設(shè)計？

A2：目前我們已基本完全采用了prometheus的接入方式，并在此基礎(chǔ)上建設(shè)了數(shù)據(jù)采集中心。其主要收集規(guī)則基于收集器與適配器模式，用戶通過收集器進(jìn)行數(shù)據(jù)上傳，適配器對數(shù)據(jù)進(jìn)行重新組裝直接發(fā)送到相應(yīng)的消息隊列中等待存儲。數(shù)據(jù)模型統(tǒng)一使用json標(biāo)識，數(shù)據(jù)格式則采用prometheus的數(shù)據(jù)格式。

Q3：日志的采集規(guī)則，您能講講嗎？現(xiàn)在日志檢測的思路的是怎樣的？

A3：用戶通過我們自定義的client定義相關(guān)日志指標(biāo)，自行采集數(shù)據(jù)，sdk單獨(dú)開啟進(jìn)程定期讀取內(nèi)存中數(shù)據(jù)，組裝成日志格式，由我們這邊的日志團(tuán)隊進(jìn)行數(shù)據(jù)收集。具體數(shù)據(jù)格式如上一個問題。對于容器日志收集的方法，一般是通過以下幾種方法：

• 容器內(nèi)收集日志：容器進(jìn)程自行寫出；agent收集。
• 容器外部收集：docker logs api及docker log-dr；日志收集agent；掛載volumes；自行開發(fā)agent。

我們目前日異常檢測算法主要依賴日志智能分類算法，需要在獲得日志實(shí)時分類模板后，根據(jù)各模板的日志量的歷史數(shù)據(jù)使用3sigma與箱線圖進(jìn)行異常判定，從而發(fā)現(xiàn)其中的異常模式，并將對應(yīng)的異常通過告警發(fā)送給用戶。

Q4：做告警收斂，都有哪些思路，哪些效果比較好？

A4：告警收斂的方式主要有幾種：

• 基于預(yù)設(shè)好的規(guī)則進(jìn)行收斂。比如A、B報警來自于相同機(jī)器/模塊，就將AB收斂合并。 
• 基于報警時間/報警次數(shù)的收斂。如將5min內(nèi)報警合并發(fā)送。 

以上兩種是策略型，可以將部分的報警進(jìn)行收斂，但不能得到報警之間的關(guān)聯(lián)性。

• 基于拓?fù)涫諗俊８鶕?jù)拓?fù)浣Y(jié)構(gòu)將報警進(jìn)行關(guān)聯(lián)，達(dá)到收斂效果。 可以得到報警之間的關(guān)聯(lián)性，利于排障。但一般比較難獲取到拓?fù)洹?/li>
• 基于關(guān)聯(lián)規(guī)則挖掘的收斂。根據(jù)歷史報警信息，挖掘出頻繁同步出現(xiàn)報警規(guī)則，進(jìn)行合并。 可以得到報警之間的關(guān)聯(lián)性，但依舊沒有形成故障現(xiàn)場，有一定的排障效果，并不依賴于拓?fù)洹?/li>
• 構(gòu)建報警知識圖譜，進(jìn)行收斂。理想化方式，效果最佳。但需要拓?fù)浜蜌v史數(shù)據(jù)積累，和專家知識，較難實(shí)現(xiàn)。

Q5：基于互聯(lián)網(wǎng)電商應(yīng)用監(jiān)控的動態(tài)閾值算法怎么選型？

A5：主要可分為有監(jiān)督選型和無監(jiān)督選型：

• 有監(jiān)督異常檢測的方案可采用先利用CNN+AutoEncoder模型對曲線進(jìn)行分類，并建立無監(jiān)督模型來抽樣找出異常樣本，從而建立起樣本庫。并利用建立在經(jīng)驗基礎(chǔ)上選取的一系列特征，作為有監(jiān)督模型的數(shù)據(jù)輸入。最后，使用集成模型對數(shù)據(jù)進(jìn)行訓(xùn)練來以保證模型的穩(wěn)定性。
• 無監(jiān)督異常檢測的方案采用通過建立包括3-sigma，百分位數(shù)分布和箱型圖等的集成模型，計算對歷史數(shù)據(jù)中特征的多個分布來判斷該特征在當(dāng)前的異常可能性，然后把不同特征計算出來的異常分?jǐn)?shù)，按比例結(jié)合起來，與按照經(jīng)驗設(shè)定的異常閾值比較，檢測異常。