導(dǎo)語(yǔ)：伴隨著各類高新技術(shù)的出現(xiàn),，“人工智能”一詞越來(lái)越多地出現(xiàn)在人們的日常生活中，而運(yùn)維朋友常聽(tīng)到與自身工作息息相關(guān)的便是智能運(yùn)維了,。

但在當(dāng)前,，國(guó)內(nèi)大部分的智能運(yùn)維并沒(méi)有完全落地，整個(gè)行業(yè)處在一個(gè)初期的探索階段,。因此,，很多運(yùn)維人或多或少都有這樣的疑問(wèn)：一個(gè)傳統(tǒng)企業(yè)的智能運(yùn)維之路該如何走？AIOps 的架構(gòu)設(shè)計(jì)與組成究竟從哪里落地,？今天,，小編就為大家?guī)?lái)了日志易產(chǎn)品總監(jiān)饒琛琳對(duì)于智能運(yùn)維平臺(tái)建設(shè)的演講分享實(shí)錄。

本篇分享,，主要從運(yùn)維需求的源頭出發(fā),，逐步推導(dǎo)出 AIOps 的架構(gòu)設(shè)計(jì)與組成，在推導(dǎo)過(guò)程中,，饒琛琳詳細(xì)介紹了時(shí)序預(yù)測(cè),、異常檢測(cè)、模式概要的分析原理與實(shí)現(xiàn)方式的具體場(chǎng)景,，以及對(duì)應(yīng)的開(kāi)源項(xiàng)目選擇,。實(shí)錄詳情如下，還等什么,，快來(lái)收干貨吧,！

講在前面

今天分享的是數(shù)據(jù)驅(qū)動(dòng)的智能運(yùn)維平臺(tái)，可以看到,，標(biāo)題有兩個(gè)點(diǎn),，第一個(gè)是平臺(tái)，第二個(gè)是數(shù)據(jù)驅(qū)動(dòng),。主要是分享平臺(tái)本身的主件架構(gòu),，重點(diǎn)放在一些與數(shù)據(jù)分析相關(guān)的細(xì)節(jié)，包括對(duì)異常檢測(cè),、時(shí)序預(yù)測(cè),、模塊聚類等場(chǎng)景的剖析。

我在參與編寫(xiě)《企業(yè)級(jí) AIOps 實(shí)施建議》白皮書(shū)期間,，與騰訊,、華為手機(jī)的一些朋友在討論“智能運(yùn)維”時(shí)候，得到了一個(gè)比較有趣說(shuō)法：我們可以把 AIOps 進(jìn)行分級(jí),，像“異常檢測(cè)”這樣的細(xì)節(jié)點(diǎn),，就認(rèn)為它是一個(gè)原子場(chǎng)景，不用再細(xì)分,，或者是引用周志華教授的說(shuō)法,，稱其為“學(xué)件”，這種學(xué)件,，類似于程序中的 API 或公共庫(kù),，可以放到四海而皆準(zhǔn)；再往上層就是類似于“根因分析”的串聯(lián)應(yīng)用,，通過(guò)多種算法,、多個(gè)原子場(chǎng)景組建出來(lái)的串聯(lián)組合場(chǎng)景；再往上便是更高級(jí)的場(chǎng)景,，最終達(dá)到終極 AIOps ,。今天分享的皆是原子場(chǎng)景的使用方式。

談?wù)?AIOps

怎么構(gòu)建一個(gè) AIOps 平臺(tái),？我們先要確定目的,，然后再談如何達(dá)到目的,。

在定義 AIOps 時(shí)畫(huà)了一張圖，除了中間有機(jī)器學(xué)習(xí),、BigData,、Platform 外，外層的內(nèi)容就是監(jiān)管控,，這也就是做 AIOps 的目的,。只不過(guò)是在做監(jiān)管控時(shí)，要使用一些新的方式,，以減輕運(yùn)維的工作量,。

與傳統(tǒng)運(yùn)維相比，智能運(yùn)維可以更靈活,、更易用,，并且快速探索數(shù)據(jù)。比如有 1000 臺(tái)服務(wù)器,，如果沒(méi)有一個(gè)統(tǒng)一的平臺(tái),，要發(fā)現(xiàn)問(wèn)題會(huì)非常麻煩。

探索和實(shí)驗(yàn)平臺(tái)是什么意思呢,？這其實(shí)是總結(jié)了運(yùn)維人員的一個(gè)工作狀態(tài)：猜測(cè),、試錯(cuò)，如果試錯(cuò)不對(duì),，再進(jìn)行下一次試錯(cuò),，即一個(gè)探索發(fā)現(xiàn)的過(guò)程。如果這個(gè)過(guò)程執(zhí)行不夠快,，就意味著解決故障的速度會(huì)慢下來(lái),。因此，我認(rèn)為,，這個(gè)快慢問(wèn)題對(duì)于運(yùn)維來(lái)說(shuō)非常重要的一個(gè)點(diǎn),。

從實(shí)際情況來(lái)看，AIOps 平臺(tái)里應(yīng)該有哪些東西,？我覺(jué)得下面的描述很有趣,，數(shù)據(jù)湖，即存儲(chǔ)采集數(shù)據(jù),，還有自動(dòng)化系統(tǒng),、記錄系統(tǒng)、交互系統(tǒng),、監(jiān)控生態(tài)圈,。

將這幾個(gè)系統(tǒng)拆分一下，我們可以發(fā)現(xiàn)，監(jiān)控系統(tǒng)和交互系統(tǒng)在運(yùn)維的分類中比較混淆,。一般來(lái)說(shuō),，監(jiān)控系統(tǒng)負(fù)責(zé)的只是把數(shù)據(jù)抓下來(lái)，然后去判斷是不是有問(wèn)題,，但是實(shí)際上監(jiān)控系統(tǒng)還要負(fù)責(zé)一個(gè)重要的流程,，也就是這個(gè)問(wèn)題和其他問(wèn)題有沒(méi)有聯(lián)系？應(yīng)該把這個(gè)問(wèn)題發(fā)給誰(shuí),？發(fā)送時(shí)只能告訴有這么一個(gè)問(wèn)題，還是描述更多信息,？這段流程要比數(shù)據(jù)采集部分更重要,。要做好支撐運(yùn)維目的的平臺(tái)，就需要將其單獨(dú)拆分考慮,。

這張幻燈看起來(lái)好像和 AI 沒(méi)有太大的關(guān)系,，只要具備這些系統(tǒng)，就可以承認(rèn)這是一個(gè) Ops 平臺(tái)了,，但是在這個(gè)平臺(tái)中,，AI 是什么？

下圖是阿里云 AI 平臺(tái)的一張截圖,，類似于這種的機(jī)器學(xué)習(xí) Web 平臺(tái),，市面上應(yīng)該有三四十種，但這種平臺(tái)對(duì)運(yùn)維來(lái)說(shuō)并沒(méi)有實(shí)際的意義,。

我們運(yùn)維人真正需要的是機(jī)器學(xué)習(xí)在運(yùn)維工作中的運(yùn)用,。AppDynamics 的 2016 年度總結(jié)中提出一些對(duì)于 APM 廠商來(lái)說(shuō)可以做出的 AI 場(chǎng)景，可以對(duì)這些內(nèi)容進(jìn)行拆解,，得出運(yùn)維人的真正需求,。

我這里提供一種很好的拆解方式，下圖是《 Google SRE book 》書(shū)中的一張圖,，對(duì)于運(yùn)維人員來(lái)說(shuō),，最重要的還是要去解決底層需求，包括監(jiān)控,、事件響應(yīng),、根因分析、CICD,、容量規(guī)劃,、部署，將這張圖與上圖中 AI 應(yīng)用場(chǎng)景進(jìn)行對(duì)照,，便會(huì)得到從技術(shù)到需求應(yīng)用之間的關(guān)系,。

從對(duì)應(yīng)的關(guān)系中可以看出，很多鏈條是相通的,，而最終的目的都是要做好一個(gè)監(jiān)控,，即最底層的需求,。此外，還有一條鏈?zhǔn)恰案蚍治?智能報(bào)警-自動(dòng)化”,。也就是上面的鏈條發(fā)現(xiàn)故障,，最后一條鏈發(fā)出報(bào)警，并明確后續(xù)流程,。

典型應(yīng)用場(chǎng)景

下面主要聊一下兩個(gè)大鏈條里幾個(gè)最常見(jiàn),、比較好入手的場(chǎng)景。第一個(gè)是時(shí)序預(yù)測(cè),，預(yù)測(cè)這個(gè)話題非常大,。在與客戶交流時(shí)，也會(huì)被問(wèn)到一些離譜的預(yù)測(cè)需求,，但真正可落地的需求,，還是那些數(shù)據(jù)量足夠大、細(xì),，且全面,，同時(shí)預(yù)測(cè)的是比較細(xì)致情況的需求。

即使是靠譜的未來(lái)預(yù)測(cè)需求,，也依然是太大的話題,。例如下圖，有了時(shí)序數(shù)據(jù),，以紅框?yàn)辄c(diǎn),，中間的藍(lán)線是數(shù)據(jù)實(shí)際情況，剩下三條線是用了三種不同的預(yù)測(cè)算法得到的預(yù)測(cè)結(jié)果,，你會(huì)發(fā)現(xiàn)依然千差萬(wàn)別,。

因此，即便有數(shù)據(jù),，在要求不高的情況下,，能不能做依然是一個(gè)需要?jiǎng)澐值膯?wèn)題。

回到運(yùn)維領(lǐng)域,，下面幾張圖是大家比較常見(jiàn)到的序列,，對(duì)于四種常見(jiàn)的序列情況我們可以想到它應(yīng)該怎么走，這時(shí)就可以想辦法讓機(jī)器去想,。

對(duì)于以上幾張圖來(lái)說(shuō),，可以用統(tǒng)計(jì)學(xué)上的辦法去做時(shí)序預(yù)測(cè)，也就是指數(shù)平滑,，從一階,、二階、三階持續(xù)運(yùn)算，α,、β,、γ 會(huì)越來(lái)越多。

如果有 100 萬(wàn)條這樣的線,，依次去配 α,、β、γ,，那工作量將會(huì)非常浩大,。就這么幾個(gè)參數(shù)、十幾條線,，可能就要花費(fèi)兩三個(gè)月的時(shí)間來(lái)做,，如果說(shuō)所有的監(jiān)控指標(biāo)全這么做，那肯定是不現(xiàn)實(shí)的,。

在此基礎(chǔ)上，就可以考慮用一些減輕人工作量的辦法,，我們可以用各種不同統(tǒng)計(jì)學(xué)里的函數(shù)確定情況,，最后獲取一個(gè)相對(duì)最好的MSE，確定最佳參數(shù),，這樣工作量就會(huì)減輕一些,。

對(duì)于時(shí)序預(yù)測(cè)的開(kāi)源選擇有很多，除了剛才講到的 RRDtool ,、Holt-Winters 外,，還有 Facebook、hawkular 的開(kāi)源項(xiàng)目,。

前面講的對(duì)自動(dòng)化調(diào)參的過(guò)程,，很多具體的細(xì)節(jié)來(lái)自 Redhat 項(xiàng)目，雖然主項(xiàng)目已經(jīng)沒(méi)有更新,，但是這個(gè)子項(xiàng)目還是推薦大家看一下,。

第二個(gè)場(chǎng)景是異常檢測(cè)。其實(shí)預(yù)測(cè)本身就是異常檢測(cè)的一種方式,，但異常檢測(cè)并不只是這種方式,。例如下面這兩種，雖然是比較離譜的情況,，但并不代表在長(zhǎng)時(shí)間維度下不會(huì)出現(xiàn),，這種情況應(yīng)用任何平滑的方法，對(duì)這條線的異常檢測(cè)都沒(méi)有任何意義,。

再如下面這種線,，在不同的障礙階段差別很大，但用平均值的話，整個(gè)這一段中平均值都在一條線上,，根本無(wú)法判斷這條線的任何區(qū)別,。

此外，異常檢測(cè)還要考慮一個(gè)最基本的同環(huán)比,，也要考慮同比的魯棒性,。

這里可以介紹一下 datadog 的異常檢測(cè)，提供 4 種檢測(cè)方法,， Basic 采用的是四分位方法,，Agile 用的是 SARIMA 算法，Robust 用的是趨勢(shì)分解,，Adaptive 在我看起來(lái),，采用的是 sigma 標(biāo)準(zhǔn)差。

下面是在不同場(chǎng)景下,，這四種不同算法對(duì)這一條線是否異常的判斷,，我們可以看到，如果不需要對(duì)本身業(yè)務(wù)的理解,，單純就是一個(gè)算法,，一切都正常，如第一個(gè)想過(guò)對(duì)比,，但在實(shí)際工作中卻不太可能,。

所以當(dāng)我們真的要去做異常檢測(cè)時(shí)，必須對(duì)業(yè)務(wù)要有一定的了解,，明白 metric 這條線背后代表的含義,，才能對(duì)各種算法進(jìn)行選擇，這個(gè)地方?jīng)]有萬(wàn)能鑰匙,。

對(duì)于異常檢測(cè)的開(kāi)源庫(kù)選擇,，有些是原子的，有些是組合的,。Etsy 的 skyline 是比較高級(jí)的場(chǎng)景,，里面帶有數(shù)據(jù)存儲(chǔ)、異常檢測(cè)分析,、告警等,；Twitter、Netflix,、Numenta 是純粹的機(jī)器學(xué)習(xí)算法庫(kù),，沒(méi)有任何附加內(nèi)容；Yahoo 的 egads 庫(kù)可以算是異常檢測(cè)的原子場(chǎng)景,，比 Twitter 和 Netflix 層級(jí)稍高,。

第三個(gè)要講的是數(shù)據(jù)概要-文本聚類,。我們知道，前面講的兩類都是監(jiān)控 metric 情況,，但是一些故障單純看 metric 是無(wú)法找出故障的,。在排障過(guò)程中可以看幾條線，包括時(shí)間相關(guān)性或者時(shí)序聚類,，也可以做根因分析,，但這些還不足夠。

我這邊可以提供的是另外一條思路,，日志易是一款日志分析產(chǎn)品,，企業(yè)有各種各樣的系統(tǒng)，產(chǎn)生各種各樣的日志,，如果通過(guò)ETL的方式把日志收集起來(lái),，可能要寫(xiě)上萬(wàn)個(gè)表達(dá)式，是不可能完成的任務(wù),。

我們可以看到下圖有四行日志的輸出代碼,，可以看出日志格式和種類是有限的。假如這四行代碼打了 1000 萬(wàn)條,，其實(shí)也就是這四行代碼打的而已,。如果從人的理解上看，這四行代碼就說(shuō)了兩件事：1. 有一個(gè) User 登錄了,，2. 定義了一個(gè)常量。我們要干的是什么,？就是把 1000 萬(wàn)行代碼反推到四個(gè)不同的日志樣式,。

另外一個(gè)細(xì)節(jié)，在處理自然語(yǔ)言時(shí),，逗號(hào)還是分號(hào)沒(méi)有任何意義,，我們關(guān)注的是文本，但日志里面的每一個(gè)符號(hào)都很關(guān)鍵,，是一個(gè)獨(dú)特的聚類聚合方式,。如果我們不想上機(jī)器學(xué)習(xí)技術(shù)，只想先跨出第一步,，就可以利用這個(gè)特性,，除去文本，留下這堆標(biāo)點(diǎn)符號(hào),。

替換之后,，留下的內(nèi)容也足夠反映出一些信息,。例如下面這個(gè)實(shí)例,，這個(gè)思科的 ASA 日志情況,，進(jìn)行處理后，得到了一些一模一樣的標(biāo)點(diǎn)符號(hào),，我們就可以推測(cè)應(yīng)該是同樣的內(nèi)容，這個(gè)是最簡(jiǎn)單的方式,，因?yàn)楸容^粗略,，所以推測(cè)得也不是特別有效。

可以再往前一步,，加上一點(diǎn)聚類的東西,，先走 TFIDF ，提取一些文本的特征值,，再走一個(gè) DBSCAN ,，拿每個(gè)聚類的樣本情況來(lái)看。當(dāng)看到某個(gè)樣本不太對(duì),，就單獨(dú)把這個(gè)樣本拿出來(lái),，調(diào)整參數(shù)，將聚類里的日志重新聚類,，再觀察一下情況,。

聚類的思路是相通的，先提取,，做聚類,，聚類出來(lái)有問(wèn)題，再切分一個(gè)小類,。但是實(shí)際上線使用的話,，還是有很多問(wèn)題需要考慮的。用 DBScan 聚類的運(yùn)行時(shí)間比較長(zhǎng),，是一個(gè)偏離線運(yùn)行狀態(tài),，而且占用的資源也多。

除了這類算法上的問(wèn)題,，還有一個(gè)思路上的問(wèn)題,，單純只是完全的聚類，沒(méi)有辦法合適地判斷邏輯代碼,，也就不足以達(dá)到知道它的原始代碼是什么樣的目的,。

這里我們參考一下日本電器美國(guó)實(shí)驗(yàn)室曾經(jīng)發(fā)表的一篇論文，他們的算法叫 HLAer,，原理是不直接上一大堆文本的聚類方式,，而是反過(guò)來(lái)去推導(dǎo)。

我們做的是運(yùn)維日志,，大多數(shù)情況下,，運(yùn)維日志有很多東西不需要耗費(fèi) CPU 處理。第一個(gè),，像 Num,、Date,、IP、ID 等都是運(yùn)維 IT 日志里一定會(huì)出現(xiàn)的,，但在關(guān)注模式時(shí)不會(huì)關(guān)注這些,。因此，可以在開(kāi)始就把這些信息替換,，節(jié)省工作量,。

第二個(gè)是對(duì)齊，對(duì)齊也是耗資源的,，如何減少對(duì)齊的時(shí)候強(qiáng)行匹配資源呢,？可以開(kāi)始先走一個(gè)距離極其小的聚類，這樣每一類中的原始文本差異非常小,。此時(shí)意味著第二步得到的最底層聚類去做對(duì)齊時(shí),，在這個(gè)類里的對(duì)齊耗損就會(huì)非常小，可以直接做模式發(fā)現(xiàn),。

到第四步的時(shí)候,，雖然還是聚類，但是消耗的資源已經(jīng)非常少,，因?yàn)榻o出的數(shù)據(jù)量已經(jīng)很小,，可以快速完成整個(gè)速度的迭代。

這是一個(gè)事例,，首先將兩條日志去做分層,，再去做一個(gè)發(fā)現(xiàn)，然后去做一個(gè)對(duì)齊和一個(gè)模式發(fā)現(xiàn),。通過(guò)這種方式,，可以把所有日志一層一層往上推，最終把整個(gè)結(jié)果全部推導(dǎo)出來(lái),。

比如一開(kāi)始給出的是 15 種，覺(jué)得不合適,，往下走一層,，看 13、14 是怎么樣的,，還不合適,，再往下走一層，看 9,、10,、11、12 是什么,，總有一層是合適的,，就可以把前面的 8 條日志得到一個(gè)樹(shù)狀結(jié)構(gòu),。

當(dāng)然，為了方便使用,，可以提前中止結(jié)構(gòu)樹(shù)生成,，不一定要推到頂上那個(gè)點(diǎn)。一般會(huì)在提前,、合適的情況下,，終止這個(gè)數(shù)的生成，從機(jī)器辦法來(lái)說(shuō),，可以記錄下每一層剩下多少個(gè)這樣的模式,，找到拐點(diǎn)，這個(gè)拐點(diǎn)能夠證明再往下已經(jīng)不方便合并即可,，但是這種方式計(jì)算量比較大,。

因此，目前會(huì)選擇一個(gè)簡(jiǎn)單但是對(duì)肉眼比較合適的方式,，即每一行都有分詞,，如果一行里面分了 20 個(gè)，其中,，要被替換成新的東西超過(guò)了 5%,，覺(jué)得不太合適看，這個(gè)時(shí)候就可以停下來(lái)了,。