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

• AIOps路線規(guī)劃
• ?異常檢測(cè)?
• 平臺(tái)化建設(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è)級(jí)AIOps實(shí)施白皮書指出AIOps的發(fā)展主要有以下的五個(gè)階段，這個(gè)在我們目前的實(shí)踐過程也確實(shí)得到了驗(yàn)證。

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

網(wǎng)易游戲智能運(yùn)維團(tuán)隊(duì)于2018年開始進(jìn)行算法研究以及具體落地場(chǎng)景的選擇，后續(xù)在在線人數(shù)、異常檢測(cè)、日志異常檢測(cè)方面嘗試單點(diǎn)應(yīng)用突破，并取得顯著的成效。目前通過串聯(lián)各維度運(yùn)維信息和報(bào)警信息來進(jìn)村后故障發(fā)現(xiàn)和故障自愈的目的，達(dá)到多個(gè)單場(chǎng)景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ā)生了一些變化，最顯著的變化就是加入了算法工程師這個(gè)角色。有的團(tuán)隊(duì)會(huì)傾向于叫算法開發(fā)研發(fā)工程師，也就是既具備算法的能力也具備平臺(tái)開發(fā)能力的工程師。當(dāng)然如果一個(gè)算法工程師能夠具備良好的工程能力，這個(gè)對(duì)于整體的團(tuán)隊(duì)發(fā)展肯定是有正向影響的。但很抱歉，一個(gè)團(tuán)隊(duì)里要求每個(gè)算法工程師都具備良好的工程能力其實(shí)是比較困難的，特別的是在招人的時(shí)候會(huì)發(fā)現(xiàn)，算法和工程還是有一定割裂的。

所以我們團(tuán)隊(duì)的配置，更多是下面這三個(gè)角色：運(yùn)維工程師，也可以說是我們的用戶，他們負(fù)責(zé)向算法工程師提供具體的業(yè)務(wù)場(chǎng)景及需求，挖掘潛在的智能化場(chǎng)景，同時(shí)向平臺(tái)研發(fā)工程提供平臺(tái)開發(fā)的場(chǎng)景需求。另外就是平臺(tái)研發(fā)工程師與算法工程師，一個(gè)主要負(fù)責(zé)工程化以及平臺(tái)化的建設(shè)，懂一點(diǎn)算法，但其主要職責(zé)更多偏向工程開發(fā)。而算法工程師則注重算法對(duì)應(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í)間序列異常檢測(cè)

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

2）故障定位與根因分析

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

3）文本處理分析

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

4）聚類與相似性分析

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

二、異常檢測(cè)

1、問題

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

2、適用場(chǎng)景

1）異常閾值難以定義

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

2）人工配置成本高

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

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

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

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

3）毛刺異常

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

4）突升突降異常

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

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

5）頻率變化異常

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

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

3、異常判定方法

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

1）分布法

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

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

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

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

三、平臺(tái)化建設(shè)

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

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

另外我們還發(fā)現(xiàn)AIOps使用到的數(shù)據(jù)可能是多種多樣的，就異常檢測(cè)一個(gè)場(chǎng)景來說，基礎(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è)計(jì)

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

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

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

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

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

3）服務(wù)層

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

4）應(yīng)用層

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

5）展示層

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

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

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

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

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

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

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

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

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

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

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

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

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

四、故障管理智能化

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

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

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

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

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

1）均值偏移模型

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

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

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

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

• 當(dāng)業(yè)務(wù)指標(biāo)出現(xiàn)異常的時(shí)候，在當(dāng)前時(shí)間點(diǎn)往前推的20min的區(qū)間內(nèi)對(duì)所有指標(biāo)進(jìn)行毛刺異常檢測(cè)，計(jì)算異常檢測(cè)分?jǐn)?shù)。 
• 異常檢測(cè)分?jǐn)?shù)乘上時(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)根因列表。

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

Q&A

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

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

Q2：AIOps基礎(chǔ)肯定是大量的歷史監(jiān)控?cái)?shù)據(jù)，數(shù)據(jù)的收集規(guī)則與建模規(guī)則你們?cè)趺丛O(shè)計(jì)？

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

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

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

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

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

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

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

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

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

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

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

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

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