大家上午好，非常榮幸，能有這個(gè)機(jī)會(huì)，跟這么多的運(yùn)維人一起交流智能運(yùn)維。最近這兩年運(yùn)維里面有一個(gè)很火的一個(gè)詞叫做AIOps(智能運(yùn)維)。我本人是老運(yùn)維了，在2000年左右讀博的時(shí)候就在做運(yùn)維相關(guān)的科研。在2005年的時(shí)候加入了AT&T研究院, title 是Senior Researcher 和Principal Researcher，實(shí)際上是一個(gè)五線運(yùn)維工程師。

從那個(gè)時(shí)候開始，我就開始用一些機(jī)器學(xué)習(xí)、人工智能的技術(shù)來解決AT&T的運(yùn)維問題了，有不少智能運(yùn)維的嘗試，并發(fā)表了不少先關(guān)論文和專利。但是在世界范圍內(nèi)關(guān)注智能運(yùn)維的人還是相對(duì)較少。

讓我感到非常開心的是，這兩年隨著人工智能大潮來臨，基于人工智能的智能運(yùn)維（AIOps）開始火爆起來了,得到了更廣泛的關(guān)注，并且有一小部分人一往無前的投入到AIOps中去了。我個(gè)人也多次分享過不少具體案例。 

但是更多的人都還在持觀望態(tài)度，因?yàn)榇蠹覂?nèi)心中還存在一個(gè)無法回避的問題：AIOps到底在自己的場(chǎng)景下怎么落地？所以我今天不再具體案例，而是要跟大家分享我認(rèn)為的AIOps落地應(yīng)該遵循的路線圖。既有技術(shù)路線圖，也有戰(zhàn)略路線圖。這雖然不是唯一的一個(gè)路線圖，但這是我今后十年會(huì)不斷努力、專注和迭代的一個(gè)方向，希望為那些對(duì)AIOps感興趣的朋友們提供一些借鑒意義。

運(yùn)維在人類未來的生產(chǎn)生活中的作用會(huì)越來越重要。預(yù)計(jì)到2020年全球?qū)⒂?00億到1000億的設(shè)備，這些設(shè)備會(huì)承載無數(shù)的服務(wù)，涵蓋互聯(lián)網(wǎng)、金融、物聯(lián)網(wǎng)、智能制造、電信、電力網(wǎng)絡(luò)、政府等等的生產(chǎn)生活的方方面面。

這些硬件和軟件都是人造出來的，都是不完美的。運(yùn)維要做的是保障業(yè)務(wù)能夠可靠高速高效安全的運(yùn)轉(zhuǎn)，因?yàn)樗鼤?huì)直接影響到業(yè)務(wù)的收益和成本。目前已有運(yùn)維方法的主要難點(diǎn)是突發(fā)故障的發(fā)現(xiàn)、止損、修復(fù)和規(guī)避，也是我們要解決的關(guān)鍵問題。這些難點(diǎn)導(dǎo)致我們運(yùn)維人有很多痛點(diǎn)。

我相信在座的各位都看到過這幅圖，我們運(yùn)維人是全年365天7×24小時(shí)的救火，我們壓力山大。在過去的三個(gè)月里，我走訪了大概幾十家跟運(yùn)維相關(guān)的單位，我經(jīng)常聽到的描述是我們的壓力很大、我們?cè)诓煌５谋冲?、我們的日子是如履薄冰、幸福指?shù)低、不知道下一秒會(huì)發(fā)生什么、睡不了安穩(wěn)覺，還有人略帶夸張的說我們做運(yùn)維就是把腦袋別在褲腰帶上。但是從這些描述我們能體會(huì)到我們運(yùn)維人目前的工具還不足，因此如果人工智能能幫助我們的話，運(yùn)維的生產(chǎn)力將得到極大的提高。

最早先運(yùn)維處于手工階段時(shí)，可能每天需要“祈禱”不要發(fā)生故障。在實(shí)現(xiàn)自動(dòng)化運(yùn)維后，我們實(shí)現(xiàn)了不少自動(dòng)化腳本，把很多已知任務(wù)像流水線一樣串起來，就像特斯拉電動(dòng)機(jī)車流水線一樣。

但是，很多故障都是突發(fā)的。在故障突發(fā)時(shí)，我們會(huì)把所有相關(guān)的人糾集到一個(gè)作戰(zhàn)室，然后大家在一起拼命的想搞清楚問題的原因。我們的目標(biāo)是兩分鐘就能搞定，實(shí)際上有可能需要一個(gè)半小時(shí)。在解決問題的過程中，每一分每一秒都在給業(yè)務(wù)帶來持續(xù)損失。

在處理突發(fā)故障時(shí)，我們主要關(guān)心三個(gè)問題（也是領(lǐng)導(dǎo)最關(guān)心的問題）：發(fā)生了什么，怎么解決，多長(zhǎng)時(shí)間能解決。由人力來回答這些問題效率低、不準(zhǔn)確、不及時(shí)。因?yàn)槲覀円獙?duì)付的這個(gè)系統(tǒng)實(shí)在是太復(fù)雜了。AIOps提高運(yùn)維生產(chǎn)力的一種方式就是把處理突發(fā)故障時(shí)的人力分析盡可能的都替換成機(jī)器來做。

我們現(xiàn)在來看看復(fù)雜度的來源。下圖展示的是對(duì)一個(gè)互聯(lián)網(wǎng)公司來說最不可控的部分——越來越復(fù)雜接入網(wǎng)絡(luò)。這是當(dāng)時(shí)AT&T的一個(gè)網(wǎng)絡(luò)拓?fù)鋱D，左上角的iPhone連接到互聯(lián)網(wǎng)的話，經(jīng)歷的這個(gè)網(wǎng)絡(luò)設(shè)備的種類有十幾種，數(shù)量幾十個(gè)。

數(shù)據(jù)中心的系統(tǒng)也在不斷的演進(jìn)，其規(guī)模復(fù)雜度、變更頻率非常大，技術(shù)更新也非常的快。網(wǎng)絡(luò)中心的拓?fù)湓絹碓烬嫶?，像上圖所示，微軟Azure數(shù)據(jù)中心大概半年就會(huì)更新一次拓?fù)浣Y(jié)構(gòu)，然后底層會(huì)逐漸融入SDN、NFV這樣的技術(shù)。

與此同時(shí)，軟件的規(guī)模、調(diào)用關(guān)系、變更頻率也在逐漸增大。上圖是前兩天騰訊視頻的朋友提供的軟件模塊之間的調(diào)用，非常復(fù)雜。同時(shí)，由于持續(xù)集成、敏捷開發(fā)、DevOps，每一個(gè)模塊隨時(shí)都可能發(fā)生變化，隨時(shí)都可能給我們帶來故障，也就是說整個(gè)云計(jì)算也在不斷地發(fā)生變化。容器、持續(xù)交付、軟件架構(gòu)、工程方法也在不斷的演進(jìn)，會(huì)不斷的給我運(yùn)維工作帶來挑戰(zhàn)。

所以說，這么龐大、復(fù)雜、多變的軟硬件系統(tǒng)，它的軟硬件故障的放生是不可能避免的，但是我們運(yùn)維需要保障上層的業(yè)務(wù)可靠高速高效安全的運(yùn)轉(zhuǎn)。那遇到突發(fā)故障的時(shí)候我們?cè)趺茨軠?zhǔn)確快速的決策呢？如果要靠人力去維護(hù)一些規(guī)則，那是顯然不可行的。

那怎么辦呢？運(yùn)維大數(shù)據(jù)。我們現(xiàn)在有非常多的監(jiān)控工具，采集存儲(chǔ)了海量的、價(jià)值極高的各種監(jiān)控?cái)?shù)據(jù)。我們希望當(dāng)遇到突發(fā)事件的時(shí)候，能夠基于這些數(shù)據(jù)快速準(zhǔn)確做出決策。而處理海量、高速、多樣的數(shù)據(jù)并產(chǎn)生高價(jià)值，正是機(jī)器學(xué)習(xí)的專長(zhǎng)。也就是說，采用機(jī)器學(xué)習(xí)技術(shù)是運(yùn)維的一個(gè)必然的走向。

我們希望在將來會(huì)有一個(gè)自動(dòng)決策的CPU，大大的提升我們運(yùn)維的效率，要真正能做到不光是雙11的時(shí)候我們能夠喝茶來保證的運(yùn)維，而是在日常365天7×24小時(shí)都能夠喝著茶，把運(yùn)維工作做好。那么將來的愿景是什么樣子呢？現(xiàn)有監(jiān)控提供數(shù)據(jù)采集，AIOps的引擎做出決策建議，少數(shù)運(yùn)維專家最終決策，執(zhí)行自動(dòng)化腳本進(jìn)行故障止損、修復(fù)、規(guī)避等操作。

具體而言，AIOps引擎 中的“異常檢測(cè)”模塊在檢測(cè)到異常之后可以將報(bào)警第一時(shí)間報(bào)給運(yùn)維人員，達(dá)到“故障發(fā)現(xiàn)”的效果；“異常定位”模塊達(dá)到“故障止損”的效果，它會(huì)給出一些止損的建議，運(yùn)維專家看到這個(gè)定位之后也許他不知道根因，但是他知道怎么去根據(jù)已有的預(yù)案來進(jìn)行止損，然后再執(zhí)行自動(dòng)化的腳本。

如果是軟件上線導(dǎo)致的問題我們回卷，如果業(yè)務(wù)不允許回卷就趕緊發(fā)布更新版本；如果是容量不夠了，那我們動(dòng)態(tài)擴(kuò)容；如果部分軟硬件出問題了，我們切換一下流量等等。AIOps引擎中的“根因分析”模塊會(huì)找出故障的根因，從而對(duì)其進(jìn)行修復(fù)。 

如果根因是硬件出了問題，像慢性病一樣的問題，那我們可以讓我們的運(yùn)維人員去修復(fù)。同時(shí)，AIOps 引擎中的“異常預(yù)測(cè)模塊”能夠提前預(yù)測(cè)性能瓶頸、容量不足、故障等，從而實(shí)現(xiàn)“故障規(guī)避”。比如，如果我們預(yù)測(cè)出來了設(shè)備故障的話，那么可以更新設(shè)備；如果說我們發(fā)現(xiàn)性能上的瓶頸是代碼導(dǎo)致的，那就交給研發(fā)人員去修改。

核心的AIOps的引擎會(huì)積累一個(gè)知識(shí)庫，從里邊不斷的學(xué)習(xí)。也就是說監(jiān)控?cái)?shù)據(jù)會(huì)給AIOps提供訓(xùn)練數(shù)據(jù)的基礎(chǔ)，然后專家會(huì)反饋一部分專家知識(shí)，上圖是我展望的AIOps大概的體系結(jié)構(gòu)，這里面關(guān)鍵的一點(diǎn)是，我們還是離不開運(yùn)維專家的。最終的止損、規(guī)避的決策、軟件的代碼修復(fù)以及設(shè)備的更換還是要靠人來做的，但是機(jī)器把絕大部分工作都做了，包括異常檢測(cè)、異常定位、根因分析、異常預(yù)測(cè)。

AIOps前景聽起來很美好，那為什么還是有不少人持觀望態(tài)度呢？這是因?yàn)槿藗冊(cè)趯?shí)踐AIOps的時(shí)候，往往容易踩到一個(gè)陷阱里面，也就是說想用直接應(yīng)用標(biāo)準(zhǔn)的機(jī)器學(xué)習(xí)算法，通過黑盒的方法直接解決我們運(yùn)維問題，這種做法通常是行不通的。

我舉一個(gè)異常檢測(cè)的例子。通過這個(gè)例子來說明在實(shí)踐中AIOps真正被應(yīng)用起來會(huì)面臨什么樣的挑戰(zhàn)。

關(guān)于“故障發(fā)現(xiàn)”問題，運(yùn)維界的現(xiàn)狀是漏報(bào)誤報(bào)多、故障發(fā)現(xiàn)不及時(shí)。這是因?yàn)槲覀兊谋O(jiān)控指標(biāo)非常多，異常的種類也非常多，因此設(shè)置靜態(tài)閾值是不能滿足需求的。我們有很多時(shí)序數(shù)據(jù)分析的算法，理論上可以做異常檢測(cè)，但是他們往往適用場(chǎng)景不明確，比如上圖的KPI三條曲線，人們往往并不清楚應(yīng)該采用哪個(gè)算法、使用什么參數(shù)。

此外，數(shù)據(jù)中可能還有缺失，處理不當(dāng)就會(huì)導(dǎo)致異常檢測(cè)準(zhǔn)確率很低。因此，現(xiàn)實(shí)中的異常檢測(cè)實(shí)踐中經(jīng)常出現(xiàn)的情形是，上周出現(xiàn)了漏報(bào)誤報(bào)，那我本周就調(diào)整一下閾值，但是根據(jù)這一個(gè)個(gè)case來決定靜態(tài)閾值的話，容易丟西瓜撿芝麻，導(dǎo)致出現(xiàn)新的、可能是更嚴(yán)重的誤報(bào)漏報(bào)。

還有，以往有算法解決了算法上述普適性問題，但是基于監(jiān)督學(xué)習(xí)的?？墒牵趯?shí)踐中，異常標(biāo)注難以批量獲得，只有一些零星的case。如果讓業(yè)務(wù)人員去進(jìn)行標(biāo)注的話，會(huì)非常麻煩，因?yàn)樗麄冎挥幸恍v史的case。而標(biāo)注一條KPI曲線，往往需要反反復(fù)復(fù)調(diào)整矯正，耗時(shí)耗力。

另外一個(gè)挑戰(zhàn)是，你可能需要同時(shí)開始監(jiān)控幾百萬、幾千萬的KPI，怎么快速給他們選擇算法呢？另外，可能一條曲線的模式經(jīng)過一次軟件變更之后發(fā)生巨變，算法參數(shù)就失效了，導(dǎo)致出現(xiàn)大量的誤報(bào)。

最后的結(jié)論是，任何一個(gè)算法都無法同時(shí)解決上面的挑戰(zhàn)，那AIOps到底怎么解決這個(gè)問題呢，怎在“故障發(fā)現(xiàn)”這個(gè)痛點(diǎn)上真正落地呢？我們首先要明確目前的AI擅長(zhǎng)什么，不擅長(zhǎng)什么。

我們看一下清華大學(xué)張鈸院士的觀點(diǎn)。張鈸院士80多歲了，經(jīng)歷了人工智能的起起伏伏。他的演講中經(jīng)常提到，AI可以解決不少問題，但是它目前的能力是有一定的范圍的。人工智能在解決很多類型問題時(shí)不管多么復(fù)雜都能做到，甚至超過人類的水平。

這些問題的特點(diǎn)是什么呢？有充足的數(shù)據(jù)和知識(shí)，問題定義很清楚，已經(jīng)明確了輸入輸出是什么，以及單領(lǐng)域。我們回過頭來看上面我們的“異常檢測(cè)”問題，我們基本可以體會(huì)到要想一步到位解決異常檢測(cè)的所有挑戰(zhàn)，是不現(xiàn)實(shí)的，因?yàn)檫@個(gè)整體問題已經(jīng)復(fù)雜到AI不擅長(zhǎng)解決的程度。

那么AIOps中“異常檢測(cè)”到底如何落地呢？很簡(jiǎn)單，我們的方法論就是庖丁解牛。

當(dāng)你剛開始接觸異常檢測(cè)這一問題時(shí)，你看到的就是一頭全牛。但是，當(dāng)你深入了解了異常檢測(cè)之后，你就會(huì)目無全牛。你看到的是它的經(jīng)脈。然后，你就不用困擾于具體的技術(shù)細(xì)節(jié)，而是要根據(jù)它的經(jīng)脈，閉著眼睛就可以根據(jù)腦海中的圖把這個(gè)牛給解剖了。每一刀都能夠切中要害，游刃有余。

其實(shí)我們做異常檢測(cè)這個(gè)事情也是一樣的，我們只需要把前面的挑戰(zhàn)都逐一的分解開，個(gè)個(gè)擊破。剛才我們那些問題混雜在一起，這東西聽起來就搞不定，但是如果我們能夠把它們分解開，每一個(gè)變成了AI善于解決的問題，讓它封閉住讓它well-defined，那異常檢測(cè)就變得可解了。

上圖中左上子圖所示， 我們先做一個(gè)無監(jiān)督的異常檢測(cè)，為什么呢？因?yàn)閯偛耪f了，標(biāo)注數(shù)據(jù)很難大批量獲得，那我們先用一個(gè)無監(jiān)督的異常檢測(cè)作為初篩，一旦有了這個(gè)無監(jiān)督異常檢測(cè)，那我們?cè)偬峁┮粋€(gè)非常友好的界面，然后在上面我們的運(yùn)維人員可以零星的把他們碰到的case在上面標(biāo)注一下，然后我們提供基于算法的工具自動(dòng)搜索跟它標(biāo)注出來的異常區(qū)間類似的，達(dá)到舉一反百、甚至舉一反千的效果，讓它的標(biāo)注工作能夠被充分利用，讓它的標(biāo)注開銷非常非常低，如右中子圖所示。之后就可以采用已有的有監(jiān)督的異常檢測(cè)，解決算法和參數(shù)的普適性問題（左中子圖）。

同時(shí)，如果遇到右下子圖的那個(gè)KPI曲線的模式的突變的話，我們首先判斷新模式是否跟老模式屬于同一類型，然后自動(dòng)通過遷移學(xué)習(xí)自動(dòng)調(diào)整算法參數(shù)。最后，如左下子圖所示，為了對(duì)大量的KPI自動(dòng)地分配檢測(cè)算法， 我們先把海量的KPI進(jìn)行分類。即使有幾百萬條曲線，其類別也不會(huì)太多。我們?cè)诿恳活惱锩嬲业降湫偷乃惴ǎ缓髮?duì)同一類里的每根曲線進(jìn)行微調(diào)。

那我們把這個(gè)稍微梳理一下，最底下的是機(jī)器學(xué)習(xí)算法，最上面的是我們要做的這樣一個(gè)自適應(yīng)的異常檢測(cè)系統(tǒng)，中間我們有一些技術(shù)層就是前面那頁具體要解決的問題，下面還有一個(gè)智能運(yùn)維的算法層，，所以我通過這個(gè)小的實(shí)例來說明一下我的idea，就是說我們要把這個(gè)技術(shù)進(jìn)行分解，把我們要解決的復(fù)雜問題庖丁解牛分解成實(shí)際上是AI善于解決的問題。

通過上面這個(gè)例子，我們可以看到，一個(gè)在實(shí)踐中看起來非常難的異常檢測(cè)問題，通過刨丁解牛的方法，可以分解成一系列問題的時(shí)候，它每一個(gè)都變成用AI方法可解了。

我們面對(duì)的不再是運(yùn)維應(yīng)用場(chǎng)景與標(biāo)準(zhǔn)機(jī)器學(xué)習(xí)算法之間巨大的鴻溝，而是在中間加入了AIOps基礎(chǔ)算法層，和AIOps關(guān)鍵技術(shù)層。

其中關(guān)鍵技術(shù)層解決的是前一幅圖中的挑戰(zhàn)，而基礎(chǔ)算法層為關(guān)鍵技術(shù)層和最終的運(yùn)維場(chǎng)景提供基礎(chǔ)的算法支撐。

如上圖圖所示。比如說剛才提到的我們需要對(duì)海量KPI進(jìn)行異常檢測(cè)的話，就需要對(duì)它進(jìn)行聚類。KPI聚類的問題就是一個(gè)單獨(dú)的問題。如果把這一問題拎出來，你會(huì)發(fā)現(xiàn)這個(gè)問題其實(shí)很抽象，輸入是若干條曲線，輸出是按照曲線形狀的分類。

這個(gè)問題對(duì)于做算法的人來說非?？山?，非常well-defined，只要給了數(shù)據(jù)，人工智能肯定能搞定這個(gè)KPI聚類算法，并且AI算法專家并不需深入理解運(yùn)維場(chǎng)景就能研究這個(gè)問題。圖中的每個(gè)問題都是一個(gè)AI比較擅長(zhǎng)解決的問題，但是他們之間還有一些先后依賴關(guān)系。也就是說，我們提供了一個(gè)落地AIOps中的“自適應(yīng)異常檢測(cè)”的一個(gè)技術(shù)路線圖。

上圖是AIOps的整體路線圖。包含了異常檢測(cè)、異常定位、根因分析和異常預(yù)測(cè)。原來實(shí)踐AIOps遇到困難的原因是試圖通過底層的標(biāo)準(zhǔn)機(jī)器學(xué)習(xí)算法解決最上層的運(yùn)維應(yīng)用，這種方法論解決不了實(shí)際問題很正常，因?yàn)檫@種方法是吧問題當(dāng)做一整頭牛來處理。后面我們對(duì)故障止損、故障修復(fù)、故障預(yù)測(cè)再簡(jiǎn)單做一下庖丁解牛。

在故障報(bào)出來之后，我們希望它能夠有一些定位功能。那定位到什么粒度呢？定位的粒度足以實(shí)施運(yùn)維專家提前準(zhǔn)備好的修復(fù)預(yù)案，從而可以執(zhí)行自動(dòng)化的腳本進(jìn)行回卷、動(dòng)態(tài)擴(kuò)縮、切流量等等。

如右上子圖所示，如果是變更導(dǎo)致了業(yè)務(wù)的異常，那運(yùn)維人員把這個(gè)變更回卷一下就好了，如果業(yè)務(wù)不允許回卷（如涉及到用戶交易）那么就需要快速部署更新過的新版本。把這個(gè)問題定義分解出來，那我們的預(yù)期是很清楚的——智能運(yùn)維的算法需要告訴運(yùn)維人員哪個(gè)變更導(dǎo)致了這個(gè)業(yè)務(wù)的巨變。我們之前也和百度在這方面合作過一個(gè)案例。

再以左上子圖的單指標(biāo)多維度監(jiān)控為例。例如，運(yùn)維人員需要監(jiān)控流量的異常，并需要在數(shù)據(jù)中心、運(yùn)營(yíng)商、用戶類型、瀏覽器等各個(gè)維度進(jìn)行監(jiān)控。一旦總流量出現(xiàn)了異常，它可能在各個(gè)維度都會(huì)出現(xiàn)報(bào)警。我們需要快速定位到具體哪些維度的組合導(dǎo)致了總流量的異常。比如，如果我們定位到根因是某個(gè)數(shù)據(jù)中心的某個(gè)集群的流量出現(xiàn)了異常，那我們就可以把該數(shù)據(jù)中心的流量切換掉就可以解決問題。

同理，在右中子圖中，當(dāng)業(yè)務(wù)指標(biāo)發(fā)生劇烈波動(dòng)時(shí)，我們找到該業(yè)務(wù)的哪些模塊的哪些指標(biāo)也同時(shí)發(fā)生了波動(dòng)，并根據(jù)關(guān)聯(lián)程度進(jìn)行排序，給出最可能的根因位置，供運(yùn)維人員進(jìn)行定位。在左中子圖中，一個(gè)不完善組粒度的故障樹也能起到故障定位的效果。另外，還可以對(duì)故障進(jìn)行最粗粒度的故障定界，確定是網(wǎng)絡(luò)、服務(wù)器、存儲(chǔ)、還是用戶的問題，快速明確責(zé)任單位，便于止損，如右下子圖所示。最后，還可以判斷故障是否為容量不足導(dǎo)致，以便迅速做出動(dòng)態(tài)擴(kuò)容決策。

以上都是來源于實(shí)際的各種故障止損需求。由于問題定義得相對(duì)清晰， 都可以通過AI來解決。

根因分析的前提是報(bào)警（要求異常檢測(cè)部分要報(bào)準(zhǔn)），下一步就是構(gòu)建故障樹。由于軟件模塊之間的依賴關(guān)系太復(fù)雜，因此故障樹的構(gòu)建非常難。對(duì)所有的報(bào)警信息進(jìn)行兩兩關(guān)聯(lián)的計(jì)算量過大。

一種思路是構(gòu)建一個(gè)故障樹的超集，通過模塊調(diào)用鏈獲得模塊之間的邏輯調(diào)用關(guān)系，通過配置信息獲得物理模塊之間的物理關(guān)聯(lián)，比如共享機(jī)器資源、網(wǎng)絡(luò)資源等。這兩部分一起構(gòu)成一個(gè)可能的故障樹，這棵樹是真正故障樹的一個(gè)超集。

之后我們對(duì)這個(gè)超集中的每個(gè)邊進(jìn)行聯(lián)動(dòng)分析、聯(lián)動(dòng)分析，對(duì)這棵樹進(jìn)行剪枝，構(gòu)成最終的故障傳播關(guān)系。這種方法的覆蓋面廣，計(jì)算開銷大大降低，并且是AI擅長(zhǎng)解決的問題。當(dāng)我們擁有了故障傳播關(guān)系，并它比較全而且準(zhǔn)的話，根因分析就變得可行了。當(dāng)發(fā)生故障時(shí)，依據(jù)準(zhǔn)確的報(bào)警， 順著故障傳播樹就能找到根因，從而進(jìn)行故障修復(fù)。

性能瓶頸預(yù)測(cè)、容量預(yù)測(cè)、故障預(yù)測(cè)等異常預(yù)測(cè)是故障規(guī)避的經(jīng)典場(chǎng)景，如上圖所示。 性能瓶頸被預(yù)測(cè)出來后，比如發(fā)現(xiàn)哪個(gè)模塊是整個(gè)系統(tǒng)性能的瓶頸，就可以對(duì)這部分進(jìn)行代碼優(yōu)化，如果代碼優(yōu)化來不及的話，也可以選擇定向擴(kuò)容。

容量預(yù)測(cè)之后，可以進(jìn)行動(dòng)態(tài)的擴(kuò)縮容、資源預(yù)算等，比如當(dāng)業(yè)務(wù)需要達(dá)到每秒三十萬筆交易時(shí)，也許不用統(tǒng)一的全面的擴(kuò)容，只需要把瓶頸部分的容量擴(kuò)展。故障預(yù)測(cè)可以幫助進(jìn)行動(dòng)態(tài)的切流量、替換硬件等等。時(shí)間關(guān)系，不展開詳述。

 以上就是我認(rèn)為的AIOps落地的技術(shù)路線圖，是根據(jù)我十幾年的運(yùn)維科研經(jīng)驗(yàn)的基礎(chǔ)上總結(jié)歸納出來的。我們清華大學(xué)NetMan實(shí)驗(yàn)室二十左右個(gè)同學(xué)對(duì)前面提到的每個(gè)題目都正在進(jìn)行研究。

AIOps這么大的一件事還需要匯聚社區(qū)的力量。因此我提出的AIOps的戰(zhàn)略路線圖是，通過社區(qū)集合整個(gè)工業(yè)界的力量（因?yàn)樗麄兪煜み\(yùn)維場(chǎng)景、也有豐富的數(shù)據(jù)）同時(shí)集合算法界的力量（因?yàn)樗麄兪煜に惴ǎ?。以往工業(yè)界和學(xué)術(shù)界的交流就是工業(yè)界和科學(xué)家的一對(duì)一進(jìn)行交流合作。可能整個(gè)項(xiàng)目的一半時(shí)間都花在問題的定義和迭代上面，而且沒有公認(rèn)的benchmark數(shù)據(jù)和缺乏比較性。

大家看到了我們前面的技術(shù)路線圖，我們現(xiàn)在已經(jīng)把問題定義好了，而且受到ImageNet的啟發(fā)，我們也創(chuàng)建了運(yùn)維領(lǐng)域的智能挑戰(zhàn)賽。而這個(gè)智能運(yùn)維的挑戰(zhàn)賽實(shí)際上它也是一種社區(qū)合作的思路。我稱之為工業(yè)界和算法界的合作2.0。普林斯頓大學(xué)畢業(yè)的華裔女科學(xué)家李飛飛在不被看好的情況下創(chuàng)建了ImageNet的數(shù)據(jù)集和人工智能挑戰(zhàn)賽，重新定義了研究人工智能的方式，培養(yǎng)了很多人才和專家，推動(dòng)了如今如火如荼的人工智能浪潮，最終帶動(dòng)了整個(gè)人工智能領(lǐng)域的高速發(fā)展。