摘要：摘要智能監(jiān)控是智能運(yùn)維的子領(lǐng)域，詳細(xì)分析。我和我的團(tuán)隊在阿里內(nèi)部的分工是橫向去看阿里巴巴業(yè)務(wù)指標(biāo)的監(jiān)控，我們就以這個話題展開。分享分為五個環(huán)節(jié)，從阿里巴巴不同的業(yè)態(tài)，特別是新的業(yè)態(tài)帶來的挑戰(zhàn)講起。

摘要：?智能監(jiān)控是智能運(yùn)維的子領(lǐng)域，詳細(xì)分析。

作者簡介

王肇剛：阿里巴巴全球運(yùn)行指揮中心高級技術(shù)專家

智能監(jiān)控是智能運(yùn)維的子領(lǐng)域，我們說的監(jiān)控，探討的更多是在監(jiān)控策略，因為可能從數(shù)據(jù)采集、日志收集、包括計算等等產(chǎn)生數(shù)據(jù)，再設(shè)定一些判斷的規(guī)則和策略，發(fā)送報警，這些都屬于監(jiān)控。

我和我的團(tuán)隊在阿里內(nèi)部的分工是橫向去看阿里巴巴業(yè)務(wù)指標(biāo)的監(jiān)控，我們就以這個話題展開。

分享分為五個環(huán)節(jié)，從阿里巴巴不同的業(yè)態(tài)，特別是新的業(yè)態(tài)帶來的挑戰(zhàn)講起。對于我們之前已有的基于機(jī)器學(xué)習(xí)算法這樣一個算法工程架構(gòu)，我們做了哪些增強(qiáng)應(yīng)對這些挑戰(zhàn)。

我們的監(jiān)控也從單一指標(biāo)監(jiān)控延展到多個指標(biāo)一起監(jiān)控。監(jiān)控完了之后，我們可能要分析定位，這時系統(tǒng)又能幫運(yùn)維工程師做什么，這是第四方面的話題。最后是對智能運(yùn)維整個領(lǐng)域做一些展望。

上圖是阿里巴巴不同的業(yè)態(tài)，有比較傳統(tǒng)的電商業(yè)態(tài)，右上角是國際電商，螞蟻金服還有阿里云。最近這段時間阿里在收購各種各樣的公司，也是商業(yè)的布局，我們會看到優(yōu)酷、釘釘?shù)鹊取?/p>

我們團(tuán)隊在阿里巴巴內(nèi)部是負(fù)責(zé)橫向的業(yè)務(wù)指標(biāo)監(jiān)控，這個有什么差異？

技術(shù)層面也是通過日志的采集流程計算看一個指標(biāo)下跌還是上漲，區(qū)別在于只要業(yè)務(wù)發(fā)生了不可用或者發(fā)生問題，我們希望都能夠發(fā)現(xiàn)，而不是說阿里巴巴本身的系統(tǒng)出問題了。

舉個例子，如果阿里巴巴一點異常都沒有，但是電信可能有問題，這個時候我們希望知道。

它是從對于業(yè)務(wù)數(shù)據(jù)量實時的監(jiān)控。因為阿里巴巴本身的業(yè)態(tài)是很豐富的，有這么多的業(yè)態(tài)，我們看到的數(shù)據(jù)也很豐富。

上邊這個圖，大家可能看到的這些 Logo，看到購物或云計算的一些業(yè)務(wù)，但是團(tuán)隊做智能運(yùn)維算法的同學(xué)，看到的就是右邊這種奇形怪狀的曲線。

我們團(tuán)隊在阿里內(nèi)部是橫向團(tuán)隊，第一環(huán)節(jié)就是需要能夠精確、及時的發(fā)現(xiàn)業(yè)務(wù)是否有異常。

為了達(dá)到這個目標(biāo)，我們引入了稱之為智能基線的系統(tǒng)，這個系統(tǒng)可以在網(wǎng)上搜索到。

這個系統(tǒng)效果還是不錯的，能夠在沒有任何閾值或者規(guī)則輸入的情況下，自覺做預(yù)測。同時有些業(yè)務(wù)發(fā)展比較迅速，我們可以比較好地在歷史的長期趨勢和短期的業(yè)務(wù)溝通之間，做出一個相對較優(yōu)的折中。

業(yè)務(wù)變化之后，假設(shè)你以前配了閾值還要改，智能基線不需要改。阿里巴巴幾千項業(yè)務(wù)指標(biāo)，通過人工的檢查驗收之后的準(zhǔn)確率是在80%以上，這個數(shù)字每周都不一樣。

而對比傳統(tǒng)的工程師通過傳統(tǒng)的靜態(tài)分段閾值或者環(huán)比的方式，準(zhǔn)確率可能只有 40% 左右。

大家可能也會看到特別對于業(yè)務(wù)量監(jiān)控，可能 10 條報警里面，4 條真的覺得有問題已經(jīng)不容易了。

阿里有很多不同的業(yè)態(tài)，所以一套系統(tǒng)解決所有問題還是挺難的，因為不同業(yè)態(tài)之間的差異還是非常大，數(shù)量級、波動、周期均有差異，包括現(xiàn)在有新零售業(yè)務(wù)，它是把線上線下的業(yè)務(wù)結(jié)合起來，而且非常強(qiáng)調(diào)線下。

比如盒馬鮮生有幾百家門店，這是個商業(yè)的嘗試，對于做運(yùn)維監(jiān)控的同學(xué)也帶來很多挑戰(zhàn)。

比如淘寶和天貓的某些交易量在分鐘級別是萬或十萬或更高的數(shù)量級，這個可能就是百或幾百，波動的量級和原始量級在一個量級上，這個就比較難處理。

包括周期性，對于一般的在線服務(wù)，是7X24小時提供服務(wù)，每天什么時間流量最低？國內(nèi)業(yè)務(wù)凌晨四點鐘最低，這個會受門店的開關(guān)門影響，因為零售是有時間的。

我們?nèi)绻€上刷淘寶下單點一下就行，線下不一樣，一對一排隊結(jié)賬。而且在量小的情況下，很多時候不能看單一指標(biāo)，許多指標(biāo)要一起看，所以就給我們之前的算法提出非常大的挑戰(zhàn)，我們需要做新的算法演進(jìn)。

大家可能會問為什么整這么復(fù)雜的算法。配監(jiān)控，配規(guī)則不就可以了嗎？

其實是可以的，但業(yè)務(wù)太復(fù)雜。作為一個橫向團(tuán)隊，算法工程師可能只有三四人，七八個人要面對阿里巴巴集團(tuán)成千上萬的業(yè)務(wù)監(jiān)控指標(biāo)，不可能了解每個指標(biāo)的所有細(xì)節(jié)，這個時候是沒有辦法用人，我們要用機(jī)器學(xué)習(xí)的方法去做。

接下來講講怎么用機(jī)器算法解決問題，這是一年半以前我們采取的架構(gòu)，我們能從業(yè)界很多文章上看到類似的架構(gòu)。

我們希望做一個基線擬合，這個曲線應(yīng)該是什么樣，我們說異常這兩個字就是異于平常。

我們第一步想知道正常的曲線是什么樣子，所以我們做基線擬合，我們用STL做這樣的方法，我們用比較傳統(tǒng)的 N-sigma 做調(diào)整。這種架構(gòu)其實能解決 60% 左右的問題，但是有些極端的情況解決不了，所以我們就把架構(gòu)做了演進(jìn)。

我們第二代的架構(gòu)做數(shù)據(jù)預(yù)處理，然后又做了比較簡單的滑動平均，數(shù)據(jù)有時候會缺點，不管是采集側(cè)的一些不穩(wěn)定因素，還是計算一側(cè)出現(xiàn)了問題，導(dǎo)致你希望一分鐘出一個數(shù)據(jù)點，但是最后還沒有算出來。

這種情況應(yīng)該從工程上解決，所以我們會在算法層面做一些腦部的算法策略，就是即使缺了能補(bǔ)回來，但是不能長時間缺數(shù)據(jù)。

下面的邏輯就走了機(jī)器學(xué)習(xí)的思路，我們對曲線做特征工程。我們之前的基線擬合的這種預(yù)測只是我們特征工程中一部分，對于重要的部分，我們也會把一些統(tǒng)計特征編碼進(jìn)去，當(dāng)然也會把一些時間特征編碼進(jìn)去。

因為我們知道很多電商的業(yè)務(wù)是有定期促銷的習(xí)慣，比如淘寶的交易量每天早晨十點一定會有階峰，大家不知道在搶什么東西。

算法層面怎么解決？我們把每天的這個時刻第幾小時第幾分鐘，通過熱度編碼的方式做到里面去，就可以讓算法學(xué)到這個時間點這樣一下可能是正常的。

我們后面采取了不同類型的統(tǒng)計學(xué)的判斷和做法，最后做成集成策略，大家可以理解為簡單的投票策略。

它其實給我們帶來了比較好的一些算法的效果，比如說基線擬合會更準(zhǔn)，對于不同類型的異常進(jìn)行判定。很多時候曲線有不一樣的異常，如果用 N-sigma 的方式，你的刻畫表現(xiàn)能力是不夠的。

即使是這樣，對于遇到的新零售業(yè)態(tài)，我們覺得還是不夠。因為你看剛才的算法能解決一般性的問題，但是對于曲線問題差異很大的時候，之前的預(yù)處理就需要增強(qiáng)，量級從十萬左右到幾百萬，你的預(yù)處理策略需要變化。很多曲線不具備周期性，或者周期性非常零亂。

比如我們有一個業(yè)務(wù)比較奇怪，大家在淘寶上有沒有充話費？這個是天、周、月三重周期，天的話基本沒有問題，周的話工作日和周末是有差異的，月這個周期，因為大部分人是在月末報警了或者月初充。

最后一個線下的業(yè)務(wù)對這種異常很敏感，在這種情況下我們用一套算法策略是解決不了不同問題的，所以我們做了第三次優(yōu)化。我們先引入了一層算法路由，希望能夠通過機(jī)器學(xué)習(xí)的方式，把不同的曲線歸到不同的算法路由里面去，這樣的話不同的曲線走不同的處理路徑，那么效果會很好。

我舉三個例子，比較周期性、非周期性、百分比的指標(biāo)等等，這些不同類型的指標(biāo)方法都不一樣。在這些不同的方法之后，我們還是覺得算法也許解決不了所有的問題，因為算法對于大多數(shù)運(yùn)維工程師來講，不見得那么方便去調(diào)參數(shù)，所以我們也開放了三個參數(shù)，我們會看它不同的抑制時間、發(fā)布策略和敏感度。

分開來看，算法路由，這個工作的目的就是說讓算法自動把數(shù)據(jù)分類，這一塊也不一定非得用算法，用人就可以，但是因為量太大，所以人工的成本很高。

這里我們用了深度學(xué)習(xí)的算法，上面那個圖是網(wǎng)絡(luò)的圖，我們使用了孿生網(wǎng)絡(luò)，兩邊都是LSTM，所以我們用了雙向的網(wǎng)絡(luò)結(jié)構(gòu)去把我們標(biāo)記為一樣和不一樣的，最終能夠區(qū)分開。

在這個基礎(chǔ)上，我們做了一個分類模型。這塊從技術(shù)層面來講，不用特別復(fù)雜的算法，我們用這個算法就是想探索一下，實際大家真正做的好的話，比如你用一般的分類方法，用我們最直接方法也可以達(dá)到類似的效果，但是我們這里嘗試了一下。

分好之后有個工程架構(gòu)，以前是說不同的算法場景走的處理邏輯都是一樣的，里面的參數(shù)可以不一樣，后面不同的處理邏輯像插件一樣可以去做組合，這個組合的變化頻度不會太快，但是一般變化成本都很低。

這樣以前是三條通路，我把插件的參數(shù)和順序和有沒有插件做一個變化。有了這個之后，對于阿里巴巴成千上萬條，但都是到萬這個級別，不會再多。

大家會想這個東西可能是從業(yè)務(wù)角度監(jiān)控的，從慣性思維來看，我們可能會是想監(jiān)控 CPU 或者某個接口調(diào)用的超時，這些也是可以的。

我們也探索了在系統(tǒng)級指標(biāo)或者非應(yīng)用級指標(biāo)做這個嘗試。它的周期性不太明顯，第二個這個指標(biāo)的變化跟業(yè)務(wù)行為關(guān)系不那么大，運(yùn)維的決策對它的曲線影響大于業(yè)務(wù)的影響。最后一個就是標(biāo)準(zhǔn)不統(tǒng)一，你覺得這個可能需要報警，別人可能覺得不需要報警。

我們采取了一種輕量級的方式去做檢測，可以做到自動學(xué)習(xí)。

它跟上面那套算法相比在于它比較輕，可以做成一個包的形式，嵌到監(jiān)控系統(tǒng)中去做監(jiān)測。它的效果如上圖右邊顯示，我們內(nèi)存中有奇形怪狀的異常，這個算法邏輯還是比較簡單的，不用太在意算法本身的框架，因為這些算法你可以替換成其他的算法，但可能需要考慮在數(shù)據(jù)進(jìn)來之前做比較好的預(yù)處理。

第二個可能你需要基于統(tǒng)計特征和那些曲線本身的特征，影響你的特征工程。最后孤立森林不是說基于用戶的標(biāo)注去做的，因為實際場景中我們不可能像做人臉識別這樣給我們標(biāo)注。

什么參數(shù)微調(diào)？第一個是說抑制報警的時間，這個很容易理解。第二個防抖動策略，這個也很容易理解，就跟過去 N 分鐘有 N 條報警是一樣的，所以我們概括成N/M。

最后一個是報警靈敏度。這個在我們市場環(huán)境中測試的效果大于70%，現(xiàn)在這個數(shù)字可能稍微好一些。

最終怎么評價算法？還是要看人標(biāo)的。比如說我們有十幾位同學(xué)評判，他們的標(biāo)準(zhǔn)也不統(tǒng)一。甚至一個人今天說這個點標(biāo)的對，第二天忘了再看一遍就說標(biāo)的不對。

所以說以上是我們介紹的關(guān)于單個指標(biāo)，不管是系統(tǒng)級的還是業(yè)務(wù)級的指標(biāo)，怎么通過機(jī)器學(xué)習(xí)的方法，做不用任何監(jiān)控閾值配置和維護(hù)成本的智能監(jiān)控。

剛才也提到了在新業(yè)態(tài)下，很多時候我們只看一個指標(biāo)是沒有辦法判定業(yè)務(wù)有沒有異常，或者我們發(fā)現(xiàn)指標(biāo)和指標(biāo)之間是有關(guān)聯(lián)的，這個在實踐當(dāng)中也會遇到。有時候兩個指標(biāo)都出了問題，這時這個信息能不能被利用，我們也做了探索。

這個東西有一個業(yè)務(wù)背景，就是我們剛才提到的看一個指標(biāo)不夠，我們經(jīng)常在一些業(yè)態(tài)里看到會監(jiān)控某一個業(yè)務(wù)的成功量、成功率、失敗的錯誤請求數(shù)幾個指標(biāo)相關(guān)變化。

有時候會發(fā)現(xiàn)指標(biāo)有異常傳播，這個傳播有幾種方向傳播。比如說在不同的業(yè)務(wù)之間傳播，比如因為兩個程序之間有關(guān)聯(lián)關(guān)系，A壞了B也影響了。

還有就是混合部署的情況，同一個集群布兩個業(yè)務(wù)，A被打爆，B也被壓死了，也有這樣的情況。

我們怎么做這個事情？分為兩步。第一步我們希望發(fā)現(xiàn)和維護(hù)相關(guān)的指標(biāo)，就是哪些指標(biāo)應(yīng)該有關(guān)聯(lián)的，發(fā)現(xiàn)之后要維護(hù)。一旦我們掌握這個信息之后就可以做兩個事情。

第一種我們能夠把這些相關(guān)指標(biāo)放在一起判定業(yè)務(wù)是不是異常，而不是只看一個指標(biāo)。

第二種我們單指標(biāo)能看的很準(zhǔn)，但這時候我想知道為什么會下跌，雖然給不出因果，但是可以給出相關(guān)。

業(yè)務(wù)指標(biāo)之間的相關(guān)性其實有不同的類型，比如上下游之間有監(jiān)控項，比如我們在阿里做過一個實際情況，大家看淘寶搜商品，如果出現(xiàn)異常大家就搜不了東西，我們的淘寶詳情頁的瀏覽量和下單量都會下降。不是說搜索的程序或者應(yīng)用服務(wù)掉了那個服務(wù)，它們之間沒有關(guān)聯(lián)，但是很多用戶習(xí)慣了搜而買。一但搜掛了，很多用戶不知道怎么買了。

所以這樣的關(guān)聯(lián)靠系統(tǒng)內(nèi)部是拿不到的。包括業(yè)務(wù)不同分量的監(jiān)控，比如河南省播放成功率和河北省播放成功率之間的關(guān)聯(lián)。

這種關(guān)聯(lián)我們怎么發(fā)現(xiàn)？一定是靠人工梳理，但是對于阿里的體量，一個是梳理不過來，第二個梳理以后過兩天又變了。阿里集團(tuán)可能每天的業(yè)務(wù)發(fā)布的頻次是千級別的，那怎么辦？還有第三種方式。

第一種利用 CMDB，我們通過CMDB看到哪些應(yīng)用之間可能相關(guān)。

第二個通過 時間序列相關(guān)性 發(fā)現(xiàn)了方法，這個跟剛才提到的卵生網(wǎng)絡(luò)的方法是類似的。但從實際來看，一般是在第一個檢測的基礎(chǔ)上，再在局部做第二個，而不是全局的檢測。

第三個我們利用關(guān)聯(lián)規(guī)則挖掘看哪些項經(jīng)常關(guān)聯(lián)報警。

我們可以通過算法發(fā)現(xiàn)這些關(guān)系，這三個方案其實是互補(bǔ)的方案。所以有了這三個方案后，就可以把很多相關(guān)的指標(biāo)放在一起監(jiān)控，方案取得了較好的效果。

在盒馬鮮生，基于我們上面做的新的算法，單指標(biāo)架構(gòu)和多指標(biāo)關(guān)聯(lián)架構(gòu)，能夠把監(jiān)控發(fā)現(xiàn)率和誤報量做非常好的提升，這就是我們在新業(yè)態(tài)下通過單個指標(biāo)的算法和多個指標(biāo)的算法取得關(guān)聯(lián)效果。

之前都是關(guān)于監(jiān)控的部分，監(jiān)控是為了發(fā)現(xiàn)問題，但是發(fā)現(xiàn)完了問題，很多時候是需要想怎么能夠解決問題的。我們在故障根因的推薦層面做過一些探索，但這個也只能是探索，供大家參考借鑒。

首先我們看一下故障原因分析問題的范圍和邊界，我也跟很多工程師交流過，凡是做運(yùn)維系統(tǒng)的工程師都有一個夢想，就是我想做一套系統(tǒng)，一旦我的業(yè)務(wù)出問題，告訴我問題原因在哪，這個非常理想化。

但在實際過程中，這個事情是非常難解決的，探索來說在阿里內(nèi)部也解決地不好。雖然解決的不好，我們也做了一些探索。

為了避免我們做的事情不符合我們老板或者客戶的預(yù)期，我們需要先把能做什么說清楚。我們很難做到淘寶交易量下跌了，我告訴你哪個代碼有bug，這個做不到，但是我們能做到縮小影響范圍。

這個為什么有價值？因為阿里巴巴有兩到三萬名工程師，半夜兩點出了問題，我打電話叫起來就是一個非常復(fù)雜的技術(shù)問題。

首先要從阿里巴巴幾萬個應(yīng)用程序里，先要看這個業(yè)務(wù)故障到底跟哪幾個應(yīng)用相關(guān)，這個都是非常典型的問題。

我們的目標(biāo)是能夠從站點、產(chǎn)品線和業(yè)務(wù)功能指標(biāo)出現(xiàn)問題的時候，能夠定位到應(yīng)用服務(wù)層，包括數(shù)據(jù)庫這層。這個架構(gòu)就是能夠鎖定這個范圍，然后之后的事情可能需要更細(xì)致的方式解決。

另外一個好處，我們可以對故障做一個結(jié)構(gòu)化的快照，除了阿里巴巴，我看到很多公司也會對故障做復(fù)盤做改進(jìn)措施，但是沒有形成很好的流程。

但是在阿里我看到過去大大小小非常嚴(yán)謹(jǐn)?shù)膹?fù)盤和故障記錄，包括非常多的細(xì)分的環(huán)節(jié)和字段，這個非常好，因為以后的故障可以從中學(xué)些東西。但是有個遺憾，這些東西全是用漢語寫成的，長篇大論幾千字。

人可以去讀，但是比如阿里有另外一個工作叫全鏈度壓測，我們要對去年的業(yè)務(wù)優(yōu)先進(jìn)行測試，這個時候我們要挖掘到底哪些有問題。挖不出來，為什么？都是漢字寫的。

漢字寫的話，它的表述、格式，都是很難被機(jī)器理解的。如果做的這件事情以后出故障，我們盡可能地把故障做一個結(jié)構(gòu)，這個不僅對這次故障的本身，對以后故障的防范都有非常大的價值。

怎么做？如上圖所示，我們會有一個主的抽象流程，當(dāng)我們的前面算法發(fā)現(xiàn)問題之后，我們會嘗試找到跟這個業(yè)務(wù)指標(biāo)相關(guān)的應(yīng)用和它的中間件以及數(shù)據(jù)庫，以及相關(guān)的網(wǎng)絡(luò)服務(wù)器IDC。

我們建立了一個囊括阿里主流的所有運(yùn)維相關(guān)事件的這樣一個數(shù)據(jù)倉庫，阿里內(nèi)部可能有自己的這種事件存儲的機(jī)制。

這個數(shù)據(jù)倉庫能夠告訴我們在哪些運(yùn)維的對象上發(fā)生了什么事情，最后我們對這個事情做一個排序和篩選，把可疑的挑出來。邏輯還是比較清晰的，但是真正做的時候發(fā)現(xiàn)有很多具體的環(huán)節(jié)需要考慮。

比如你怎么找到監(jiān)控項關(guān)聯(lián)應(yīng)用，淘寶交易下跌了，你怎么知道是阿里的幾萬個應(yīng)用中哪個應(yīng)用造成的問題？這個其實也是比較難的問題，我們也沒有解決太好，但是可以看到思路。

最直接來講，我們通過監(jiān)控系統(tǒng)本身的配置來得到。我們的業(yè)務(wù)指標(biāo)能畫成一張趨勢圖，能做監(jiān)控，因為背后有邏輯計算，有日志的采集等等。這些系統(tǒng)的工作，是因為加監(jiān)控的同學(xué)已經(jīng)把監(jiān)控怎么采集配置進(jìn)去了。但是它有失效的時候，比如說兩種情況。

一種發(fā)現(xiàn)業(yè)務(wù)環(huán)境非常強(qiáng)，ABC三個程序不斷做處理，最后把結(jié)果打到第四個程序上去了。所以你通過這個，能得到第四個應(yīng)用的名字，前三個應(yīng)用其實跟這個業(yè)務(wù)非常相關(guān)，但是你從這里讀不到，所以這是我們要解決的。

第二個有一些應(yīng)用本身是用來監(jiān)控的，比如阿里的客戶端，它會上報到某一些監(jiān)控系統(tǒng)，這時候監(jiān)控系統(tǒng)畫出來的曲線，其實跟監(jiān)控系統(tǒng)本身相關(guān)的，而不是跟產(chǎn)生監(jiān)控數(shù)據(jù)的應(yīng)用相關(guān)的。

這種情況下，這個方案就失效了。這個時候就需要通過人工配置的方式解決，目前是這兩種方式結(jié)合在用。

剛才說的第一個問題，我們也可以通過阿里巴巴的中間做的系統(tǒng)去解決這個問題，包括我們也可以通過算法，對于報警做平臺挖掘，可以挖掘出來像剛才搜索框下跌，導(dǎo)致交易量下跌的關(guān)系等等都可以挖掘出來，這個東西也是補(bǔ)充的方式。但是最核心的不是算法，最核心的是CMDB如果維護(hù)得好，比什么都好。

通過剛才那個思路，能夠把我們的業(yè)務(wù)指標(biāo)跟應(yīng)用結(jié)合起來，但是很多時候應(yīng)用經(jīng)常是無狀態(tài)的，狀態(tài)存儲在數(shù)據(jù)庫集群里面，這個時候還是經(jīng)常通過CMDB解決這個問題。

還有比較難的問題，就是網(wǎng)絡(luò)跟應(yīng)用程序的關(guān)系，有一個機(jī)房出問題了，經(jīng)常我們是混合部署的，所以這個時候問題其實是一個非常散的關(guān)聯(lián)，這個問題上我們解決的也不好，所以我們只能把這個信息當(dāng)成一個缺少的信息推薦出來，供大家去決策。

比如說不管阿里什么業(yè)務(wù)出了問題，我們都會把網(wǎng)絡(luò)最近出的一些異常點或者事情推送出來，提醒大家是不是這個問題，但是這塊很難做到精細(xì)的管理。

我們知道了哪些運(yùn)維實體跟業(yè)務(wù)有關(guān)聯(lián)之后，還要知道這些運(yùn)維實體上、程序上、集群上、網(wǎng)絡(luò)上發(fā)生了什么事情？那這個事情我們怎么知道？我們會建立一個在線的數(shù)據(jù)倉庫，它能夠不斷地抓取來自于各個運(yùn)維平臺和系統(tǒng)中的不同格式的事件。

這個抓取之后不是簡單放一塊存，還要建立關(guān)聯(lián)索引。阿里有很多不同的橫向縱向的系統(tǒng)，他們的數(shù)據(jù)格式的字段都不一樣。

我們嘗試做一個翻譯，在當(dāng)中找到了兩三個大家都能看懂的詞。比如釘釘應(yīng)用，這在阿里內(nèi)部非常穩(wěn)定的。第二個IP地址，這個也是很穩(wěn)定的。

但是這兩個之外，格式語言是不一樣的。我們把數(shù)據(jù)倉庫建好之后，輸入開始時間、結(jié)束時間和應(yīng)用列表三個關(guān)鍵詞，就可以查到這段時間內(nèi)實體發(fā)生了什么事情。我把事情都推薦出來是不是就解決了？還不夠。

我給大家分享一個數(shù)字，在阿里巴巴內(nèi)部，像這樣的事情一分鐘發(fā)生四千到六千次，也就是說一個故障如果持續(xù)了十分鐘，就是幾萬個事件，所以我們還要再做篩選。

這個時候就會通過一些方式做篩選，我們會根據(jù)哪些運(yùn)維實際上發(fā)生了報警，把這些實體的信息優(yōu)先放在前面。怎么知道有跳變？我們會對懷疑的對象做系統(tǒng)級指標(biāo)的掃描，掃描出來跳變就排到前面去，所以有了這個之后就可以相對精確地縮小范圍，當(dāng)阿里巴巴淘寶天貓有異常的時候，我就可以知道。

我們能夠從上面看到，最上面這個環(huán)節(jié)是同一個時間內(nèi)有多少業(yè)務(wù)的多少點在報警，紅顏色的時候，可能就是某些業(yè)務(wù)出現(xiàn)短暫的異常了。

我們會感覺 CMDB 加平臺化算法對報警壓縮合并，看到了集中在優(yōu)酷、集團(tuán)客戶體驗、菜鳥這三個業(yè)務(wù)功能上。

這個其實就是剛才講的多指標(biāo)關(guān)聯(lián)分析的作用，這時候我也不知道是不是因為它導(dǎo)致的，但是他們之間是相關(guān)的，這個可以幫助我們定位。

最后我們能夠根據(jù)剛才說的邏輯，把跟這個事情相關(guān)的前五個或者前十個應(yīng)用程序推薦給你。為什么推薦給你？要么它發(fā)生了一些驟變，要么發(fā)生了一些大的業(yè)務(wù)操作。

很多時候可能百分之五六十的業(yè)務(wù)故障，都是發(fā)布新功能或者改配置改錯導(dǎo)致的。做的比較好的地方，可能能夠做到70%以上的推薦準(zhǔn)確率。但是也有做的不好的，百分之三四十的準(zhǔn)確率。

因為阿里業(yè)務(wù)很復(fù)雜，每個環(huán)節(jié)每個業(yè)務(wù)都有不一樣的方式。但是這個方法，我認(rèn)為還是一個值得推廣和借鑒的大邏輯上的思路，這個就是我們介紹的監(jiān)控發(fā)現(xiàn)問題之后，我們在根因分析層面有哪些探索和思考。

最后希望能夠和大家一起探討一下在智能運(yùn)維領(lǐng)域現(xiàn)在與未來可以做什么事情。

運(yùn)維本質(zhì)上是解決在線服務(wù)運(yùn)行中的質(zhì)量、成本和效率三方面，運(yùn)維不是從上到下的思路，包括我也參與了白皮書的工作，我們也跟其他業(yè)界的同事探討這個問題，不是說有一個頂層規(guī)劃要怎么做，實際是在這些點所處的具體環(huán)節(jié)上，很多工程師開始嘗試用算法的方式解決問題，逐步匯集成一個數(shù)。

我們現(xiàn)在在上圖左邊那條路做了一些探索，已經(jīng)在業(yè)務(wù)中用起來了。最早的探索，其實在阿里內(nèi)部已經(jīng)穩(wěn)定運(yùn)行了接近兩年時間，也是效果在不斷演化演進(jìn)。

最近我們也在探索右邊這條路，就是無人值守相關(guān)的東西。出問題的時候很多人問淘寶的故障恢復(fù)了沒有，支付寶有沒有受影響。靠自然語言提出的問題，是不是可以通過機(jī)器人回答你，這個也是我們探索的。

當(dāng)然現(xiàn)在還不敢做全自動，還是我們列出來你再確認(rèn)一下，但已經(jīng)比你調(diào)出系統(tǒng)然后跟很多人溝通半天決策要方便一些。所以其實不僅是在質(zhì)量領(lǐng)域我們做智能化的監(jiān)控，智能化的根因分析，其實在節(jié)省人效率層面，也可以做一些探索。

中間這塊跟成本相關(guān)，這塊在阿里巴巴有很多團(tuán)隊做這樣的事情，也可以通過智能化的調(diào)度能夠做容量預(yù)測，優(yōu)化包括硬件采購的周期，預(yù)測你服務(wù)器增長怎么樣。或者在實施的時候，通過自動化的調(diào)度策略，節(jié)省服務(wù)器的資源。

所以其實智能運(yùn)維這個概念，在今天已經(jīng)不是個概念，它已經(jīng)在我們企業(yè)實際工作中，有非常多落地的點。希望今天我的分享，能給大家有一些借鑒和參考，我們一起建設(shè)智能運(yùn)維美好的明天。

說明：以上內(nèi)容為阿里高級技術(shù)專家王肇剛在 GOPS 2018 · 上海站的分享。

閱讀原文

本文來自云棲社區(qū)合作伙伴“高效運(yùn)維”，如需轉(zhuǎn)載請聯(lián)系原作者。