導(dǎo)語：伴隨著各類高新技術(shù)的出現(xiàn)，“人工智能”一詞越來越多地出現(xiàn)在人們的日常生活中，而運(yùn)維朋友常聽到與自身工作息息相關(guān)的便是智能運(yùn)維了。
但在當(dāng)前，國內(nèi)大部分的智能運(yùn)維并沒有完全落地，整個(gè)行業(yè)處在一個(gè)初期的探索階段。因此，很多運(yùn)維人或多或少都有這樣的疑問：一個(gè)傳統(tǒng)企業(yè)的智能運(yùn)維之路該如何走？AIOps 的架構(gòu)設(shè)計(jì)與組成究竟從哪里落地？今天，小編就為大家?guī)砹巳罩疽桩a(chǎn)品總監(jiān)饒琛琳對于智能運(yùn)維平臺建設(shè)的演講分享實(shí)錄。
本篇分享，主要從運(yùn)維需求的源頭出發(fā)，逐步推導(dǎo)出 AIOps 的架構(gòu)設(shè)計(jì)與組成，在推導(dǎo)過程中，饒琛琳詳細(xì)介紹了時(shí)序預(yù)測、異常檢測、模式概要的分析原理與實(shí)現(xiàn)方式的具體場景，以及對應(yīng)的開源項(xiàng)目選擇。實(shí)錄詳情如下，還等什么，快來收干貨吧！
今天分享的是數(shù)據(jù)驅(qū)動的智能運(yùn)維平臺，可以看到，標(biāo)題有兩個(gè)點(diǎn)，第一個(gè)是平臺，第二個(gè)是數(shù)據(jù)驅(qū)動。主要是分享平臺本身的主件架構(gòu)，重點(diǎn)放在一些與數(shù)據(jù)分析相關(guān)的細(xì)節(jié)，包括對異常檢測、時(shí)序預(yù)測、模塊聚類等場景的剖析。
我在參與編寫《企業(yè)級 AIOps 實(shí)施建議》白皮書期間，與騰訊、華為手機(jī)的一些朋友在討論“智能運(yùn)維”時(shí)候，得到了一個(gè)比較有趣說法：我們可以把 AIOps 進(jìn)行分級，像“異常檢測”這樣的細(xì)節(jié)點(diǎn)，就認(rèn)為它是一個(gè)原子場景，不用再細(xì)分，或者是引用周志華教授的說法，稱其為“學(xué)件”，這種學(xué)件，類似于程序中的 API 或公共庫，可以放到四海而皆準(zhǔn)；再往上層就是類似于“根因分析”的串聯(lián)應(yīng)用，通過多種算法、多個(gè)原子場景組建出來的串聯(lián)組合場景；再往上便是更高級的場景，最終達(dá)到終極 AIOps 。今天分享的皆是原子場景的使用方式。
怎么構(gòu)建一個(gè) AIOps 平臺？我們先要確定目的，然后再談如何達(dá)到目的。
在定義 AIOps 時(shí)畫了一張圖，除了中間有機(jī)器學(xué)習(xí)、BigData、Platform 外，外層的內(nèi)容就是監(jiān)管控，這也就是做 AIOps 的目的。只不過是在做監(jiān)管控時(shí)，要使用一些新的方式，以減輕運(yùn)維的工作量。
與傳統(tǒng)運(yùn)維相比，智能運(yùn)維可以更靈活、更易用，并且快速探索數(shù)據(jù)。比如有 1000 臺服務(wù)器，如果沒有一個(gè)統(tǒng)一的平臺，要發(fā)現(xiàn)問題會非常麻煩。
探索和實(shí)驗(yàn)平臺是什么意思呢？這其實(shí)是總結(jié)了運(yùn)維人員的一個(gè)工作狀態(tài)：猜測、試錯(cuò)，如果試錯(cuò)不對，再進(jìn)行下一次試錯(cuò)，即一個(gè)探索發(fā)現(xiàn)的過程。如果這個(gè)過程執(zhí)行不夠快，就意味著解決故障的速度會慢下來。因此，我認(rèn)為，這個(gè)快慢問題對于運(yùn)維來說非常重要的一個(gè)點(diǎn)。
從實(shí)際情況來看，AIOps 平臺里應(yīng)該有哪些東西？我覺得下面的描述很有趣，數(shù)據(jù)湖，即存儲采集數(shù)據(jù)，還有自動化系統(tǒng)、記錄系統(tǒng)、交互系統(tǒng)、監(jiān)控生態(tài)圈。
將這幾個(gè)系統(tǒng)拆分一下，我們可以發(fā)現(xiàn)，監(jiān)控系統(tǒng)和交互系統(tǒng)在運(yùn)維的分類中比較混淆。一般來說，監(jiān)控系統(tǒng)負(fù)責(zé)的只是把數(shù)據(jù)抓下來，然后去判斷是不是有問題，但是實(shí)際上監(jiān)控系統(tǒng)還要負(fù)責(zé)一個(gè)重要的流程，也就是這個(gè)問題和其他問題有沒有聯(lián)系？應(yīng)該把這個(gè)問題發(fā)給誰？發(fā)送時(shí)只能告訴有這么一個(gè)問題，還是描述更多信息？這段流程要比數(shù)據(jù)采集部分更重要。要做好支撐運(yùn)維目的的平臺，就需要將其單獨(dú)拆分考慮。
這張幻燈看起來好像和 AI 沒有太大的關(guān)系，只要具備這些系統(tǒng)，就可以承認(rèn)這是一個(gè) Ops 平臺了，但是在這個(gè)平臺中，AI 是什么？
下圖是阿里云 AI 平臺的一張截圖，類似于這種的機(jī)器學(xué)習(xí) Web 平臺，市面上應(yīng)該有三四十種，但這種平臺對運(yùn)維來說并沒有實(shí)際的意義。
我們運(yùn)維人真正需要的是機(jī)器學(xué)習(xí)在運(yùn)維工作中的運(yùn)用。AppDynamics 的 2016 年度總結(jié)中提出一些對于 APM 廠商來說可以做出的 AI 場景，可以對這些內(nèi)容進(jìn)行拆解，得出運(yùn)維人的真正需求。
我這里提供一種很好的拆解方式，下圖是《 Google SRE book 》書中的一張圖，對于運(yùn)維人員來說，最重要的還是要去解決底層需求，包括監(jiān)控、事件響應(yīng)、根因分析、CICD、容量規(guī)劃、部署，將這張圖與上圖中 AI 應(yīng)用場景進(jìn)行對照，便會得到從技術(shù)到需求應(yīng)用之間的關(guān)系。
從對應(yīng)的關(guān)系中可以看出，很多鏈條是相通的，而最終的目的都是要做好一個(gè)監(jiān)控，即最底層的需求。此外，還有一條鏈?zhǔn)恰案蚍治?智能報(bào)警-自動化”。也就是上面的鏈條發(fā)現(xiàn)故障，最后一條鏈發(fā)出報(bào)警，并明確后續(xù)流程。
下面主要聊一下兩個(gè)大鏈條里幾個(gè)最常見、比較好入手的場景。第一個(gè)是時(shí)序預(yù)測，預(yù)測這個(gè)話題非常大。在與客戶交流時(shí)，也會被問到一些離譜的預(yù)測需求，但真正可落地的需求，還是那些數(shù)據(jù)量足夠大、細(xì)，且全面，同時(shí)預(yù)測的是比較細(xì)致情況的需求。
即使是靠譜的未來預(yù)測需求，也依然是太大的話題。例如下圖，有了時(shí)序數(shù)據(jù)，以紅框?yàn)辄c(diǎn)，中間的藍(lán)線是數(shù)據(jù)實(shí)際情況，剩下三條線是用了三種不同的預(yù)測算法得到的預(yù)測結(jié)果，你會發(fā)現(xiàn)依然千差萬別。
因此，即便有數(shù)據(jù)，在要求不高的情況下，能不能做依然是一個(gè)需要?jiǎng)澐值膯栴}。
回到運(yùn)維領(lǐng)域，下面幾張圖是大家比較常見到的序列，對于四種常見的序列情況我們可以想到它應(yīng)該怎么走，這時(shí)就可以想辦法讓機(jī)器去想。
對于以上幾張圖來說，可以用統(tǒng)計(jì)學(xué)上的辦法去做時(shí)序預(yù)測，也就是指數(shù)平滑，從一階、二階、三階持續(xù)運(yùn)算，α、β、γ 會越來越多。
如果有 100 萬條這樣的線，依次去配 α、β、γ，那工作量將會非常浩大。就這么幾個(gè)參數(shù)、十幾條線，可能就要花費(fèi)兩三個(gè)月的時(shí)間來做，如果說所有的監(jiān)控指標(biāo)全這么做，那肯定是不現(xiàn)實(shí)的。
在此基礎(chǔ)上，就可以考慮用一些減輕人工作量的辦法，我們可以用各種不同統(tǒng)計(jì)學(xué)里的函數(shù)確定情況，最后獲取一個(gè)相對最好的MSE，確定最佳參數(shù)，這樣工作量就會減輕一些。
對于時(shí)序預(yù)測的開源選擇有很多，除了剛才講到的 RRDtool 、Holt-Winters 外，還有 Facebook、hawkular 的開源項(xiàng)目。
前面講的對自動化調(diào)參的過程，很多具體的細(xì)節(jié)來自 Redhat 項(xiàng)目，雖然主項(xiàng)目已經(jīng)沒有更新，但是這個(gè)子項(xiàng)目還是推薦大家看一下。
第二個(gè)場景是異常檢測。其實(shí)預(yù)測本身就是異常檢測的一種方式，但異常檢測并不只是這種方式。例如下面這兩種，雖然是比較離譜的情況，但并不代表在長時(shí)間維度下不會出現(xiàn)，這種情況應(yīng)用任何平滑的方法，對這條線的異常檢測都沒有任何意義。
再如下面這種線，在不同的障礙階段差別很大，但用平均值的話，整個(gè)這一段中平均值都在一條線上，根本無法判斷這條線的任何區(qū)別。
此外，異常檢測還要考慮一個(gè)最基本的同環(huán)比，也要考慮同比的魯棒性。
這里可以介紹一下 datadog 的異常檢測，提供 4 種檢測方法， Basic 采用的是四分位方法，Agile 用的是 SARIMA 算法，Robust 用的是趨勢分解，Adaptive 在我看起來，采用的是 sigma 標(biāo)準(zhǔn)差。
下面是在不同場景下，這四種不同算法對這一條線是否異常的判斷，我們可以看到，如果不需要對本身業(yè)務(wù)的理解，單純就是一個(gè)算法，一切都正常，如第一個(gè)想過對比，但在實(shí)際工作中卻不太可能。
所以當(dāng)我們真的要去做異常檢測時(shí)，必須對業(yè)務(wù)要有一定的了解，明白 metric 這條線背后代表的含義，才能對各種算法進(jìn)行選擇，這個(gè)地方?jīng)]有萬能鑰匙。
對于異常檢測的開源庫選擇，有些是原子的，有些是組合的。Etsy 的 skyline 是比較高級的場景，里面帶有數(shù)據(jù)存儲、異常檢測分析、告警等；Twitter、Netflix、Numenta 是純粹的機(jī)器學(xué)習(xí)算法庫，沒有任何附加內(nèi)容；Yahoo 的 egads 庫可以算是異常檢測的原子場景，比 Twitter 和 Netflix 層級稍高。
第三個(gè)要講的是數(shù)據(jù)概要-文本聚類。我們知道，前面講的兩類都是監(jiān)控 metric 情況，但是一些故障單純看 metric 是無法找出故障的。在排障過程中可以看幾條線，包括時(shí)間相關(guān)性或者時(shí)序聚類，也可以做根因分析，但這些還不足夠。
我這邊可以提供的是另外一條思路，日志易是一款日志分析產(chǎn)品，企業(yè)有各種各樣的系統(tǒng)，產(chǎn)生各種各樣的日志，如果通過ETL的方式把日志收集起來，可能要寫上萬個(gè)表達(dá)式，是不可能完成的任務(wù)。
我們可以看到下圖有四行日志的輸出代碼，可以看出日志格式和種類是有限的。假如這四行代碼打了 1000 萬條，其實(shí)也就是這四行代碼打的而已。如果從人的理解上看，這四行代碼就說了兩件事：1. 有一個(gè) User 登錄了，2. 定義了一個(gè)常量。我們要干的是什么？就是把 1000 萬行代碼反推到四個(gè)不同的日志樣式。
另外一個(gè)細(xì)節(jié)，在處理自然語言時(shí)，逗號還是分號沒有任何意義，我們關(guān)注的是文本，但日志里面的每一個(gè)符號都很關(guān)鍵，是一個(gè)獨(dú)特的聚類聚合方式。如果我們不想上機(jī)器學(xué)習(xí)技術(shù)，只想先跨出第一步，就可以利用這個(gè)特性，除去文本，留下這堆標(biāo)點(diǎn)符號。
替換之后，留下的內(nèi)容也足夠反映出一些信息。例如下面這個(gè)實(shí)例，這個(gè)思科的 ASA 日志情況，進(jìn)行處理后，得到了一些一模一樣的標(biāo)點(diǎn)符號，我們就可以推測應(yīng)該是同樣的內(nèi)容，這個(gè)是最簡單的方式，因?yàn)楸容^粗略，所以推測得也不是特別有效。
可以再往前一步，加上一點(diǎn)聚類的東西，先走 TFIDF ，提取一些文本的特征值，再走一個(gè) DBSCAN ，拿每個(gè)聚類的樣本情況來看。當(dāng)看到某個(gè)樣本不太對，就單獨(dú)把這個(gè)樣本拿出來，調(diào)整參數(shù)，將聚類里的日志重新聚類，再觀察一下情況。
聚類的思路是相通的，先提取，做聚類，聚類出來有問題，再切分一個(gè)小類。但是實(shí)際上線使用的話，還是有很多問題需要考慮的。用 DBScan 聚類的運(yùn)行時(shí)間比較長，是一個(gè)偏離線運(yùn)行狀態(tài)，而且占用的資源也多。
除了這類算法上的問題，還有一個(gè)思路上的問題，單純只是完全的聚類，沒有辦法合適地判斷邏輯代碼，也就不足以達(dá)到知道它的原始代碼是什么樣的目的。
這里我們參考一下日本電器美國實(shí)驗(yàn)室曾經(jīng)發(fā)表的一篇論文，他們的算法叫 HLAer，原理是不直接上一大堆文本的聚類方式，而是反過來去推導(dǎo)。
我們做的是運(yùn)維日志，大多數(shù)情況下，運(yùn)維日志有很多東西不需要耗費(fèi) CPU 處理。第一個(gè)，像 Num、Date、IP、ID 等都是運(yùn)維 IT 日志里一定會出現(xiàn)的，但在關(guān)注模式時(shí)不會關(guān)注這些。因此，可以在開始就把這些信息替換，節(jié)省工作量。
第二個(gè)是對齊，對齊也是耗資源的，如何減少對齊的時(shí)候強(qiáng)行匹配資源呢？可以開始先走一個(gè)距離極其小的聚類，這樣每一類中的原始文本差異非常小。此時(shí)意味著第二步得到的最底層聚類去做對齊時(shí)，在這個(gè)類里的對齊耗損就會非常小，可以直接做模式發(fā)現(xiàn)。
到第四步的時(shí)候，雖然還是聚類，但是消耗的資源已經(jīng)非常少，因?yàn)榻o出的數(shù)據(jù)量已經(jīng)很小，可以快速完成整個(gè)速度的迭代。
這是一個(gè)事例，首先將兩條日志去做分層，再去做一個(gè)發(fā)現(xiàn)，然后去做一個(gè)對齊和一個(gè)模式發(fā)現(xiàn)。通過這種方式，可以把所有日志一層一層往上推，最終把整個(gè)結(jié)果全部推導(dǎo)出來。
比如一開始給出的是 15 種，覺得不合適，往下走一層，看 13、14 是怎么樣的，還不合適，再往下走一層，看 9、10、11、12 是什么，總有一層是合適的，就可以把前面的 8 條日志得到一個(gè)樹狀結(jié)構(gòu)。
當(dāng)然，為了方便使用，可以提前中止結(jié)構(gòu)樹生成，不一定要推到頂上那個(gè)點(diǎn)。一般會在提前、合適的情況下，終止這個(gè)數(shù)的生成，從機(jī)器辦法來說，可以記錄下每一層剩下多少個(gè)這樣的模式，找到拐點(diǎn)，這個(gè)拐點(diǎn)能夠證明再往下已經(jīng)不方便合并即可，但是這種方式計(jì)算量比較大。
因此，目前會選擇一個(gè)簡單但是對肉眼比較合適的方式，即每一行都有分詞，如果一行里面分了 20 個(gè)，其中，要被替換成新的東西超過了 5%，覺得不太合適看，這個(gè)時(shí)候就可以停下來了。
