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

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

作者簡(jiǎn)介

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

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

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

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

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

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

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

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

舉個(gè)例子，如果阿里巴巴一點(diǎn)異常都沒有，但是電信可能有問題，這個(gè)時(shí)候我們希望知道。

它是從對(duì)于業(yè)務(wù)數(shù)據(jù)量實(shí)時(shí)的監(jiān)控。因?yàn)榘⒗锇桶捅旧淼臉I(yè)態(tài)是很豐富的，有這么多的業(yè)態(tài)，我們看到的數(shù)據(jù)也很豐富。

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

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

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

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

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

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

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

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

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

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

包括周期性，對(duì)于一般的在線服務(wù)，是7X24小時(shí)提供服務(wù)，每天什么時(shí)間流量最低？國(guó)內(nèi)業(yè)務(wù)凌晨四點(diǎn)鐘最低，這個(gè)會(huì)受門店的開關(guān)門影響，因?yàn)榱闶凼怯袝r(shí)間的。

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

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

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

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

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

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

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

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

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

因?yàn)槲覀冎篮芏嚯娚痰臉I(yè)務(wù)是有定期促銷的習(xí)慣，比如淘寶的交易量每天早晨十點(diǎn)一定會(huì)有階峰，大家不知道在搶什么東西。

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

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

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

即使是這樣，對(duì)于遇到的新零售業(yè)態(tài)，我們覺得還是不夠。因?yàn)槟憧磩偛诺乃惴芙鉀Q一般性的問題，但是對(duì)于曲線問題差異很大的時(shí)候，之前的預(yù)處理就需要增強(qiáng)，量級(jí)從十萬(wàn)左右到幾百萬(wàn)，你的預(yù)處理策略需要變化。很多曲線不具備周期性，或者周期性非常零亂。

比如我們有一個(gè)業(yè)務(wù)比較奇怪，大家在淘寶上有沒有充話費(fèi)？這個(gè)是天、周、月三重周期，天的話基本沒有問題，周的話工作日和周末是有差異的，月這個(gè)周期，因?yàn)榇蟛糠秩耸窃谠履﹫?bào)警了或者月初充。

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

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

分開來看，算法路由，這個(gè)工作的目的就是說讓算法自動(dòng)把數(shù)據(jù)分類，這一塊也不一定非得用算法，用人就可以，但是因?yàn)榱刻螅匀斯さ某杀竞芨摺?br>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

業(yè)務(wù)指標(biāo)之間的相關(guān)性其實(shí)有不同的類型，比如上下游之間有監(jiān)控項(xiàng)，比如我們?cè)诎⒗镒鲞^一個(gè)實(shí)際情況，大家看淘寶搜商品，如果出現(xiàn)異常大家就搜不了東西，我們的淘寶詳情頁(yè)的瀏覽量和下單量都會(huì)下降。不是說搜索的程序或者應(yīng)用服務(wù)掉了那個(gè)服務(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)我們?cè)趺窗l(fā)現(xiàn)？一定是靠人工梳理，但是對(duì)于阿里的體量，一個(gè)是梳理不過來，第二個(gè)梳理以后過兩天又變了。阿里集團(tuán)可能每天的業(yè)務(wù)發(fā)布的頻次是千級(jí)別的，那怎么辦？還有第三種方式。

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

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

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

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

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

之前都是關(guān)于監(jiān)控的部分，監(jiān)控是為了發(fā)現(xiàn)問題，但是發(fā)現(xiàn)完了問題，很多時(shí)候是需要想怎么能夠解決問題的。我們?cè)诠收细虻耐扑]層面做過一些探索，但這個(gè)也只能是探索，供大家參考借鑒。

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

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

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

這個(gè)為什么有價(jià)值？因?yàn)榘⒗锇桶陀袃傻饺f(wàn)名工程師，半夜兩點(diǎn)出了問題，我打電話叫起來就是一個(gè)非常復(fù)雜的技術(shù)問題。

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

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

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

但是在阿里我看到過去大大小小非常嚴(yán)謹(jǐn)?shù)膹?fù)盤和故障記錄，包括非常多的細(xì)分的環(huán)節(jié)和字段，這個(gè)非常好，因?yàn)橐院蟮墓收峡梢詮闹袑W(xué)些東西。但是有個(gè)遺憾，這些東西全是用漢語(yǔ)寫成的，長(zhǎng)篇大論幾千字。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

因?yàn)榘⒗飿I(yè)務(wù)很復(fù)雜，每個(gè)環(huán)節(jié)每個(gè)業(yè)務(wù)都有不一樣的方式。但是這個(gè)方法，我認(rèn)為還是一個(gè)值得推廣和借鑒的大邏輯上的思路，這個(gè)就是我們介紹的監(jiān)控發(fā)現(xiàn)問題之后，我們?cè)诟蚍治鰧用嬗心男┨剿骱退伎肌?/p> 五、智能運(yùn)維在故障治理領(lǐng)域的未來規(guī)劃

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

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

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

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

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

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

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

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

閱讀原文

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