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

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

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

講在前面

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

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

談?wù)?AIOps

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

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

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

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

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

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

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

下圖是阿里云 AI 平臺的一張截圖，類似于這種的機器學(xué)習(xí) Web 平臺，市面上應(yīng)該有三四十種，但這種平臺對運維來說并沒有實際的意義。

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

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

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

典型應(yīng)用場景

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

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

因此，即便有數(shù)據(jù)，在要求不高的情況下，能不能做依然是一個需要劃分的問題。

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

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

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

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

對于時序預(yù)測的開源選擇有很多，除了剛才講到的 RRDtool 、Holt-Winters 外，還有 Facebook、hawkular 的開源項目。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

因此，目前會選擇一個簡單但是對肉眼比較合適的方式，即每一行都有分詞，如果一行里面分了 20 個，其中，要被替換成新的東西超過了 5%，覺得不太合適看，這個時候就可以停下來了。