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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

同時，如果遇到右下子圖的那個KPI曲線的模式的突變的話，我們首先判斷新模式是否跟老模式屬于同一類型，然后自動通過遷移學(xué)習(xí)自動調(diào)整算法參數(shù)。最后，如左下子圖所示，為了對大量的KPI自動地分配檢測算法， 我們先把海量的KPI進行分類。即使有幾百萬條曲線，其類別也不會太多。我們在每一類里面找到典型的算法，然后對同一類里的每根曲線進行微調(diào)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

AIOps這么大的一件事還需要匯聚社區(qū)的力量。因此我提出的AIOps的戰(zhàn)略路線圖是，通過社區(qū)集合整個工業(yè)界的力量（因為他們熟悉運維場景、也有豐富的數(shù)據(jù)）同時集合算法界的力量（因為他們熟悉算法）。以往工業(yè)界和學(xué)術(shù)界的交流就是工業(yè)界和科學(xué)家的一對一進行交流合作?？赡苷麄€項目的一半時間都花在問題的定義和迭代上面，而且沒有公認的benchmark數(shù)據(jù)和缺乏比較性。

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