摘要：從那個時候開始，我就開始用一些機器學習人工智能的技術來解決的運維問題了，有不少智能運維的嘗試，并發表了不少先關論文和專利。而處理海量高速多樣的數據并產生高價值，正是機器學習的專長。也就是說，采用機器學習技術是運維的一個必然的走向。

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

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

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

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

運維在人類未來的生產生活中的作用會越來越重要。預計到2020年全球將有500億到1000億的設備，這些設備會承載無數的服務，涵蓋互聯網、金融、物聯網、智能制造、電信、電力網絡、政府等等的生產生活的方方面面。

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

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

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

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

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

我們現在來看看復雜度的來源。下圖展示的是對一個互聯網公司來說最不可控的部分——越來越復雜接入網絡。這是當時AT&T的一個網絡拓撲圖，左上角的iPhone連接到互聯網的話，經歷的這個網絡設備的種類有十幾種，數量幾十個。

?

數據中心的系統也在不斷的演進，其規模復雜度、變更頻率非常大，技術更新也非常的快。網絡中心的拓撲越來越龐大，像上圖所示，微軟Azure數據中心大概半年就會更新一次拓撲結構，然后底層會逐漸融入SDN、NFV這樣的技術。

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

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

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

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

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

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

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

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

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

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

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

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

還有，以往有算法解決了算法上述普適性問題，但是基于監督學習的。可是，在實踐中，異常標注難以批量獲得，只有一些零星的case。如果讓業務人員去進行標注的話，會非常麻煩，因為他們只有一些歷史的case。而標注一條KPI曲線，往往需要反反復復調整矯正，耗時耗力。

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

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

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

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

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

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

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

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

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

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

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

我們面對的不再是運維應用場景與標準機器學習算法之間巨大的鴻溝，而是在中間加入了AIOps基礎算法層，和AIOps關鍵技術層。

其中關鍵技術層解決的是前一幅圖中的挑戰，而基礎算法層為關鍵技術層和最終的運維場景提供基礎的算法支撐。

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

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

?

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

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

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

?

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

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

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

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

一種思路是構建一個故障樹的超集，通過模塊調用鏈獲得模塊之間的邏輯調用關系，通過配置信息獲得物理模塊之間的物理關聯，比如共享機器資源、網絡資源等。這兩部分一起構成一個可能的故障樹，這棵樹是真正故障樹的一個超集。

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

?

性能瓶頸預測、容量預測、故障預測等異常預測是故障規避的經典場景，如上圖所示。 性能瓶頸被預測出來后，比如發現哪個模塊是整個系統性能的瓶頸，就可以對這部分進行代碼優化，如果代碼優化來不及的話，也可以選擇定向擴容。

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

?

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

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

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