無人運維遙不可及？讓我們從AIOps建立運維大腦說起
摘要：
本文根據
裴丹老師
在〖2018 Gdevops全球敏捷運維峰會北京站〗現場演講內容整理而成。
裴丹， 清華大學計算機系長聘副教授、特別研究員、青年千人。目前主要研究AIOps，與多家大型網際網路公司在AIOps領域均有合作。在美國UCLA獲得了博士學位，之...
本文根據
裴丹老師
在〖2018 Gdevops全球敏捷運維峰會北京站〗現場演講內容整理而成。
裴丹， 清華大學計算機系長聘副教授、特別研究員、青年千人。目前主要研究AIOps，與多家大型網際網路公司在AIOps領域均有合作。在美國UCLA獲得了博士學位，之後加入美國AT&T研究院擔任資深研究員、主任研究員，在智慧運維領域發表了100餘篇學術論文和20多項美國專利授權，是ACM和IEEE的Senior Member。
大家好，我是清華大學的裴丹。我分享的主題是“基於AIOps的無人運維”。
我們生活在一個數字化的社會中，而運維則是這個數字社會的一個基礎設施級別的技術。運維做得不好，各行各業，無論是金融、電信、能源、工業製造、網際網路、物聯網，都不能高效、穩定、可靠地運轉。既然運維這麼重要，為什麼還常出現各種各樣的、甚至影響非常大的故障呢？
本質原因是我們現在遇到了一個非常大的矛盾。這個矛盾就是當前運維所大量依賴的人力決策已經無法應對當前運維所面臨的挑戰。
隨著網際網路、移動網際網路迅猛發展，使用者越來越挑剔、對應用軟體的使用者體驗要求越來越高。而我們知道，應用軟體都是建立在一個龐大、複雜、跨協議層的大型分散式系統之上的。
這個分散式系統的技術、軟體、配置通常會不斷快速地演變；其軟硬體難以避免會發生故障、Bug、變更；使用者流量會發生不可預知的變化，甚至會發生安全攻擊事件，而上述趨勢有愈演愈烈之勢。
儘管各類運維監控工具使系統執行狀態的可見度有較大提升，但是當遇到運維故障時，面對海量監控資料和龐大負責分散式系統，仍依賴運維人員在高壓下人力做出迅速、準確的運維決策，這顯然是不現實的。
也即是說人力運維決策已經無法應對當前的運維挑戰。這導致運維人員的工作生活可以說是處於水深火熱之中，“人少、事多，救火、背鍋”，7*24小時時刻準備救火。有運維人員自己做的打油詩為證：
我們解決上述核心矛盾的思路，就是逐漸減少人力在運維決策中所佔的比例，逐漸增加人工智慧在運維決策中的比例，最終實現無人運維：
這就像交通工具所經歷的變革一樣：
起初交通工具要靠人力驅動，之後能夠做到自動驅動，但還需要大量的人力決策（每公里駕駛需要人力決策100次以上），最終我們希望能夠做到無人駕駛——你坐在車上面，車自動帶你去目的地。
運維已經從最早的人力運維發展到了一定程度上的自動化運維（但還是需要大量人力盯屏決策），最終我們希望基於人工智慧的運維工具能夠更多自主決策，只需很少人力、甚至不再需要人力參與決策。
這就是我們運維行業的長遠目標：基於AIOps的無人運維。
無人運維是目標，AIOps（AI for IT Operations）是工具、是手段。 目標不可能一蹴而就，需要我們一步步腳踏實地、不斷探索去實現。因此我們必須有一種客觀的、量化的手段能夠對無人運維（或智慧運維）水平進行度量。
下面提出的無人運維量化評級方法，不包含主觀因素、不需要人主觀打分。按照這種方法，每個單位都可以與其它單位及自己以往進行客觀地比較，有效衡量本單位無人運維（或智慧運維）在行業內的相對水平及自身進展。
一、 無人運維評級
如前所述，我們希望能夠量化、綜合評估運維的生產力。因此，在設計具體指標的時候，我們考慮瞭如下因素：
直觀來講，為了達到同等的穩定性、可靠性SLA，依賴人力決策越多，其無人運維評級水平就相對低一些。
-
運維人力應計入負責運維伺服器、儲存、網路、中介軟體、資料庫、應用的所有人力。
-
例1
某網際網路公司A有X86架構的伺服器100萬臺，其中12核的50萬臺、24核的50萬臺；人力共有400人、每人每週工作60小時，其中200人50%的時間用在人力運維，另200人80%的時間用在人力運維。
按照上述方法核算下來是390 Op，再用總核數（1300萬）除以390OP，是3.3萬核每OP，對應Level 2。
-
右邊是基於確定邏輯的自動化工具，相當於“手”，負責一些比如重啟、回滾、流量排程、擴縮容、跨機房遷移等操作；
-
-
動態決策利用實時監控資料和已經挖掘好的運維知識圖譜進行實時決策。“動態決策” 包括故障發現、故障定位、故障處置、故障規避等大場景。每一個大場景還包含若干個小場景，比如故障發現包含單指標異常檢測、多指標異常檢測、文字日誌異常檢測、交易鏈條日常檢測等等。每一個場景都是運維行業幾十年發展積累下來的難題，都需要投入大量AIOps演算法人力和精力去攻克。比如我在清華的實驗室，去年投入了10個博士生分工合作研究單指標異常檢測，才把這個難題攻克了。
此外， AIOps要解決的是“系統+演算法”問題，而不是簡單的演算法問題。
這是因為我們的運維物件是個龐大、複雜、跨協議層的系統，它裡面的大量邏輯是程式員寫的程式碼和各種網路協議和應用協議。因此，AIOps運維大腦中的每一個模組都相當複雜，所以我們不要期望把運維資料灌進一個通用AI演算法就能完成該模組的功能。
解決任何一個AIOps中的模組或場景，都需要有“AIOps架構師”把複雜的場景和需求拆解成具體的功能模組： “眼”、“手”、“腦”。
“眼”解決那些通過採集資料全面感知系統執行狀態就能解決的問題；
-
-
“腦”又細分為兩類模組：1）通過挖掘歷史資料總結出來各種畫像和知識；2）通過動態決策演算法來處理各種具體運維場景。“腦”裡面的兩個模組必須能被當前AI技術所解決（要求資料豐富、資訊完整、清楚定義、單領域）。
運維領域有很多問題當前AI技術沒有辦法直接整體解決，在這種情況下我們就繼續把該問題拆解成更細的模組，以期能夠被當前AI技術解決。
為了更好地支援上述觀點，下圖展示了我在清華的實驗室中在AIOps運維大腦的各個模組中使用過的並行之有效的通用AI演算法。
可以看到不同的模組採用的通用AI演算法差異非常大，有些模組還需要若干通用AI演算法的組合才能良好解決。這張圖充分說明了AIOps的架構挑戰。
三、 智慧故障發現
接下來會介紹一下我們實驗室在“智慧故障發現”方向的進展。
智慧故障發現包括故障發現和故障定位。首先介紹我們在單指標異常檢測的最新進展。我們實驗室在這一領域的科研成果在世界範圍內處於領先的地位：
我們IMC2015工作是有監督的異常檢測，解決了之前樸素異常檢測演算法無法普適的問題；
-
-
隨著在實踐中對該WWW2018演算法的使用，發現它也存在一些不足。比如，當存在違反週期性的異常時，使用該演算法效果不好，因此我們加入了時間資訊解決了這個問題；
-
此外，我們通過聚類演算法和遷移學習，實現了對於百萬級指標進行異常檢測；
-
通過引數自動遷移，在指標模式漂移後自動適配異常檢測演算法。最後這些演算法整合成了我們非常智慧的單指標異常檢測演算法。
這個單指標異常檢測的例子很好地說明了我們實驗室的研究思路：“從實踐中來” （從實踐中總結提煉出科研問題，從根兒上解決問題，而不是通過簡單工程方法治標不治本）、“到實踐中去”（不斷實踐、不斷迭代認知、不斷完善，而不是發表一篇論文就做別的去了）。
在單指標異常檢測的基礎上，我們還實現了多指標異常檢測、面向文字日誌的異常檢測、對交易鏈條的異常檢測、異常機器定位、異常多維定位、變更故障定位、交易鏈條定位等：
這些AIOps最終被整合在一起，形成我們的“智慧故障發現”系統。
一線運維人員無需關注背後的種種演算法：當有故障發生時，系統直接告訴運維人員哪裡出了什麼樣的故障，以及該故障的原因是什麼。系統不是將海量的監控都推給運維人員讓他自己搞清楚問題是什麼，而是已經彙總好，直接給出問題所在。
例如，下圖中5臺機器4項指標出了問題：
採用人力排查的話需要看上萬臺機器、每臺各100多個指標，而我們的系統則可以把這個結果快速呈現出來：某一個具體日誌時間，發生故障時第三個引數取值的分佈在故障之前和故障之後有顯著變化，這樣就給運維人員提供了非常清晰的提示和參考，指導人員下一步該怎麼做。
同時系統還會提示本次故障和歷史上某次故障症狀上非常相似或有某種關係，進而建議運維人員現在可採取什麼樣的處置方案應對當前故障。
以上“智慧故障發現”AIOps演算法朝著無人運維的終極目標邁進了一大步。
四、運維知識圖譜
這部分將會簡要介紹運維知識圖譜的構建和使用。
構建運維知識圖譜是指從運維資料中自動挖掘：
各類運維主體；
-
運維主體之間的關係。
運維主體包括系統軟、硬體及其執行狀態：軟體是指服務、微服務、中介軟體、儲存服務、資料庫等等；硬體是指機房、機群、機架、伺服器、虛擬機器、容器、硬碟、路由器、交換機等等；各類監控資料，包括指標、日誌事件、Trace、變更、流程等等。
那麼運維知識圖譜與CMDB的區別是什麼呢？運維知識圖譜包含基於人工智慧的、模糊的、自動化挖掘的知識，而CMDB是確定的、手工配置的知識或基於確定邏輯自動配置的知識：
運維知識圖譜與傳統的運維專家知識又有什麼區別呢？
知識圖譜是中心化的，而傳統專家的知識是分佈在運維專家頭腦中的，是去中心化的。
-
知識圖譜可被快速查詢，專家知識需要人力關聯，所以緩慢易錯。
-
可以自動生成知識圖譜的變化報表，而利用專家知識要靠手動撰寫報告。
因此，建立運維知識圖譜的優勢是非常明顯的。下面我們通過兩個例子來詳細說明一下：
首先給出了各類硬體主體之間的關係：
容器1屬於容器型別1， 而容器型別1的配置細節（CPU、記憶體、儲存型別、儲存空間）都是能夠由配置資訊基於固定邏輯自動構建出來的，屬於靜態屬性。
同時，通過挖掘學習出一些動態屬性（白底紅字），比如容器型別1的資源使用限制（記憶體使用率最多能到多少），這些資訊很難靠人力準確總結或推測，得靠挖掘歷史資料獲得。
我們再看軟體主體和硬體主體之間關係，以及軟體主體之間的關係：
服務1呼叫微服務1、微服務1部署在容器1上面。這樣，軟硬體主體在圖中就通過邊連線起來了。這種關係也是通過確定邏輯基於配置資訊自動構建的（橙色的邊屬性）。
那麼，容器型別1可以支援微服務1每秒鐘多少次的交易呢（容器型別1與微服務1之間的邊的紅色屬性）？這個屬性需要通過歷史資料、壓測資料構建動態的畫像。
我們再看一下軟體主體與監控指標主體之間的關係，以及監控指標之間的關係：
服務1的一個監控指標是總流量，而這個總流量又可以按照省份屬性細分，監控指標“服務1.流量”與監控指標“服務1.流量.北京市”是包含的關係，而“服務1.流量.北京市”與“服務1.流量.北京市.聯通”又是包含關係。
當今的監控資料中雖然可能有幾百萬監控指標，但是它們之間往往有類似上述“包含”關係的某種關係。而此類關係遵循固定邏輯，是可以通過配置資訊自動構建出來的，最終可以作為邊新增在這幅圖譜中。
因此我們可以想象，這個圖譜就形成了一個無所不包的大型資料結構，供我們在其上為各類運維場景開發動態決策演算法。
上圖中還展示了“服務1.流量”的動態畫像（白底紅字）：增長趨勢、季節性、高峰時段、特殊日、最佳的變更時段等等。這些資訊在運維人員腦子裡面或多或少有一些，但是並不能被隨時隨地準確快速地查詢。我們的方法是，在專家的指導下，通過機器學習方法自動把這些知識挖掘出來，可以被自動更新和隨時查詢。
“微服務1.響應時間” 的影響因素有n個, 而它們之間的關係是通過一個函式f(x1,x2,…,xn)來刻畫的，而這個函式可能是通過一個神經網路來擬合的。這個例子清晰的說明運維知識圖譜與傳統基於確定邏輯的CMDB的區別：
在這個例子裡，我們用有限的一頁PPT，展示了一個很大的知識圖譜中很小的一個切面。可以想象上萬臺機器，上百萬指標，全都串在一起會形成如何的一幅大圖！
幸運的是，現在有不少相對成熟的圖計算系統和演算法可以處理如此規模的圖。
上述例子的一個應用場景是：以往為了應對每個月的大促，需要拍腦袋人工預測所需計算資源；有了運維知識圖譜，通過查詢圖譜以及演算法計算就可以給出準確的預測結果。
下面介紹最後一個例子，運維知識圖譜的另一個切面——故障傳播圖。有了這個故障傳播圖，就可以快速回答如下問題：
當前服務故障的根因是什麼？
-
當前底層的故障對上層服務有何具體影響？
故障傳播圖可以長成什麼樣子，又是如何構建的呢？我們通過舉例來說明：
服務1呼叫了微服務1.1和微服務1.2，而微服務1.2部署在容器1.2.1上。它們有共同的KPI A。因此，KPI A報警在這三個主體之前就自然形成了故障傳播關係，而這種故障傳播關係是可以通過配置資訊通過固定邏輯自動生成的（見上圖中藍色的邊屬性）。
有些故障傳播關係是要靠機器學習演算法自動挖掘的（見上圖中橙色的邊屬性）：
比如系統儲存日誌事件Y導致資料庫日誌事件X；資料庫日誌事件X導致微服務1.1 的KPI A 報警。同時，交換機日誌事件U也會導致微服務1.1.的KPI A 報警；而微服務1.2 KPI A 與微服務1.3的KPI C故障傳播關係體現為具有波動相關性。上圖中邊的屬性為橙色的都是自動挖掘出的故障傳播關係。
有些故障傳播關係（比如那些由網路協議導致的）很難被自動挖掘出來，也不在靜態配置中體現，而是存在於行業標準中（如網路協議），因此我們可以根據網路協議中固定的規則人工指定故障傳播關係（下圖中綠色的邊屬性），如物理層故障導致鏈路層故障：
最後，另外還有一些自動挖掘出來的畫像資訊（上圖中紅色六邊形），比如廠商手冊中關於交換機日誌事件V有一些相關知識，事件V為什麼發生、該如何處置。我們可以自動把手冊裡面的規則挖掘出來變成知識。
綜上，由演算法專家和運維專家配合，採用合適的演算法，我們可以把所有運維相關的經驗知識轉化故障傳播關係，進而形成故障傳播圖。這樣，運維最大的痛點故障根因分析也就不難解決了。
五、總結和展望
我們非常看好“基於AIOps的無人運維”，但這條路並不輕鬆，需要付出大量的努力，需要廣大運維屆的同仁們一道、一步一個腳印地去實現並完善。
無人運維的研究任重道遠，期待我們一起不斷地努力、不斷地探索、不斷提升認知，最終能給我們所在的各行各業的運維逐漸帶來革命性的影響。
