尋夢新聞LINE@每日推播熱門推薦文章，趣聞不漏接❤️
前言
AIOps概念火熱，但如何落地？清華大學裴丹副教授在GOPS上海站的主題演講中，通過庖丁解牛的方式給出了AIOps落地的技術路線圖；同時提出AIOps落地戰略路線圖，通過AIOps Challenge網站，匯聚社區力量，共同推進AIOps落地。 以下是裴丹副教授的演講稿。概述
這兩年隨著人工智能大潮來臨，基於人工智能的智能運維（AIOps）開始火爆起來了,得到了更廣泛的關注，並且有一小部分人一往無前的投入到AIOps中去了。
但是還存在一個無法回避的問題：AIOps到底在自己的場景下怎麼落地？所以今天不分享具體案例，而是分享AIOps落地應該遵循的路線圖。既有技術路線圖，也有戰略路線圖。這雖然不是唯一的一個路線圖，但這是我今後十年會不斷努力、專注和迭代的一個方向，希望為那些對AIOps感興趣的朋友們提供一些借鑒意義。
1.運維的目標和意義
運維在人類未來的生產生活中的作用會越來越重要。預計到2020年全球將有500億到1000億的設備，這些設備會承載無數的服務，涵蓋互聯網、金融、物聯網、智能製造、電信、電力網路、政府等等的生產生活的方方面面。這些硬件和軟件都是人造出來的，都是不完美的。運維要做的是保障業務能夠可靠高速高效安全的運轉，因為它會直接影響到業務的收益和成本。目前已有運維方法的主要難點是突發故障的發現、止損、修復和規避，也是我們要解決的關鍵問題。這些難點導致我們運維人有很多痛點。2.運維的痛點
我相信在座的各位都看到過這幅圖，我們運維人是全年365天7×24小時的救火，我們壓力山大。在過去的三個月里，我走訪了大概幾十家跟運維相關的單位，我經常聽到的描述是我們的壓力很大、我們在不停的背鍋、我們的日子是如履薄冰、幸福指數低、不知道下一秒會發生什麼、睡不了安穩覺，還有人略帶誇張的說我們做運維就是把腦袋別在褲腰帶上。但是從這些描述我們能體會到我們運維人目前的工具還不足，因此如果人工智能能幫助我們的話，運維的生產力將得到極大的提高。
最早先運維處於手工階段時，可能每天需要「祈禱」不要發生故障。在做到自動化運維後，我們做到了不少自動化腳本，把很多已知任務像流水線一樣串起來，就像特斯拉電動機車流水線一樣。但是，很多故障都是突發的。在故障突發時，我們會把所有相關的人糾集到一個作戰室，然後大家在一起拼命的想搞清楚問題的原因。我們的目標是兩分鐘就能搞定，實際上有可能需要一個半小時。在解決問題的過程中，每一分每一秒都在給業務帶來持續損失。在處理突發故障時，我們主要關心三個問題（也是主管最關心的問題）：發生了什麼，怎麼解決，多長時間能解決。由人力來回答這些問題效率低、不準確、不及時。因為我們要對付的這個系統實在是太複雜了。AIOps提高運維生產力的一種方式就是把處理突發故障時的人力分析盡可能的都替換成機器來做。3.痛點的來源
我們現在來看看複雜度的來源。下圖展示的是對一個互聯網公司來說最不可控的部分——越來越複雜接入網路。這是當時AT&T的一個網路拓撲圖，左上角的iPhone連接到互聯網的話，經歷的這個網路設備的種類有十幾種，數量幾十個。
數據中心的系統也在不斷的演進，其規模複雜度、變更頻率非常大，技術更新也非常的快。網路中心的拓撲越來越龐大，像上圖所示，微軟Azure數據中心大概半年就會更新一次拓撲結構，然後底層會逐漸融入SDN、NFV這樣的技術。
與此同時，軟件的規模、調用關係、變更頻率也在逐漸增大。上圖是前兩天騰訊視頻的朋友提供的軟件模塊之間的調用，非常複雜。同時，由於持續集成、敏捷開發、DevOps，每一個模塊隨時都可能發生變化，隨時都可能給我們帶來故障，也就是說整個雲計算也在不斷地發生變化。容器、持續交付、軟件架構、工程方法也在不斷的演進，會不斷的給我運維工作帶來挑戰。
所以說，這麼龐大、複雜、多變的軟硬件系統，它的軟硬件故障的放生是不可能避免的，但是我們運維需要保障上層的業務可靠高速高效安全的運轉。那遇到突發故障的時候我們怎麼能準確快速的決策呢？如果要靠人力去維護一些規則，那是顯然不可行的。4.解決辦法–AIOps
那怎麼辦呢？運維大數據。我們現在有非常多的監控工具，采集存儲了海量的、價值極高的各種監控數據。我們希望當遇到突發事件的時候，能夠基於這些數據快速準確做出決策。而處理海量、高速、多樣的數據並產生高價值，正是機器學習的專長。也就是說，採用機器學習技術是運維的一個必然的走向。
我們希望在將來會有一個自動決策的CPU，大大的提升我們運維的效率，要真正能做到不光是雙11的時候我們能夠喝茶來保證的運維，而是在日常365天7×24小時都能夠喝著茶，把運維工作做好。那麼將來的願景是什麼樣子呢？現有監控提供數據采集，AIOps的引擎做出決策建議，少數運維專家最終決策，執行自動化腳本進行故障止損、修復、規避等操作。
具體而言，AIOps引擎 中的「異常檢測」模塊在檢測到異常之後可以將報警第一時間報給運維人員，達到「故障發現」的效果；「異常定位」模塊達到「故障止損」的效果，它會給出一些止損的建議，運維專家看到這個定位之後也許他不知道根因，但是他知道怎麼去根據已有的預案來進行止損，然後再執行自動化的腳本。如果是軟件上線導致的問題我們回卷，如果業務不允許回卷就趕緊發布更新版本；如果是容量不夠了，那我們動態擴容；如果部分軟硬件出問題了，我們切換一下流量等等。AIOps引擎中的「根因分析」模塊會找出故障的根因，從而對其進行修復。 如果根因是硬件出了問題，像慢性病一樣的問題，那我們可以讓我們的運維人員去修復。同時，AIOps 引擎中的「異常預測模塊」能夠提前預測性能瓶頸、容量不足、故障等，從而做到「故障規避」。比如，如果我們預測出來了設備故障的話，那麼可以更新設備；如果說我們發現性能上的瓶頸是代碼導致的，那就交給研發人員去修改。
核心的AIOps的引擎會積累一個知識庫，從里邊不斷的學習。也就是說監控數據會給AIOps提供訓練數據的基礎，然後專家會反饋一部分專家知識，上圖是我展望的AIOps大概的體系結構，這里面關鍵的一點是，我們還是離不開運維專家的。最終的止損、規避的決策、軟件的代碼修復以及設備的更換還是要靠人來做的，但是機器把絕大部分工作都做了，包括異常檢測、異常定位、根因分析、異常預測。5.AIOps的落地情況
核心思路–庖丁解牛
那麼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擅長解決的問題。當我們擁有了故障傳播關係，並它比較全而且準的話，根因分析就變得可行了。當發生故障時，依據準確的報警， 順著故障傳播樹就能找到根因，從而進行故障修復。
故障規避
性能瓶頸預測、容量預測、故障預測等異常預測是故障規避的經典場景，如上圖所示。 性能瓶頸被預測出來後，比如發現哪個模塊是整個系統性能的瓶頸，就可以對這部分進行代碼優化，如果代碼優化來不及的話，也可以選擇定向擴容。容量預測之後，可以進行動態的擴縮容、資源預算等，比如當業務需要達到每秒三十萬筆交易時，也許不用統一的全面的擴容，只需要把瓶頸部分的容量擴展。故障預測可以幫助進行動態的切流量、替換硬件等等。時間關係，不展開詳述。6.總結
以上就是AIOps落地的技術路線圖，通過社區集合整個工業界的力量（因為他們熟悉運維場景、也有豐富的數據）同時集合算法界的力量（因為他們熟悉算法）。以往工業界和學術界的交流就是工業界和科學家的一對一進行交流合作。可能整個項目的一半時間都花在問題的定義和迭代上面，而且沒有公認的benchmark數據和缺乏比較性。
後面會分享AIOPS更多這方面的內容，感興趣的朋友可以關注下~
