摘要：作者介紹王藝，百度云智能運維架構(gòu)研發(fā)負責(zé)人。年轉(zhuǎn)向運維方向，作為智能運維架構(gòu)方向的技術(shù)負責(zé)人，致力于為百度智能運維平臺和產(chǎn)品提供高性能高可用可擴展的系統(tǒng)架構(gòu)和基礎(chǔ)設(shè)施。持續(xù)的數(shù)據(jù)建設(shè)，是智能運維建設(shè)的關(guān)鍵。

作者介紹

王藝，百度云智能運維架構(gòu)研發(fā)負責(zé)人。2010年加入百度，先后負責(zé)百度鏈接庫、百度志愿計算、百度統(tǒng)一資源管理的研發(fā)，經(jīng)歷過千億級網(wǎng)頁鏈接的洗禮，也調(diào)度過數(shù)十萬量級的服務(wù)器，熱衷于直面架構(gòu)技術(shù)挑戰(zhàn)，在分布式計算、分布式資源和任務(wù)調(diào)度方面經(jīng)驗豐富。2015年轉(zhuǎn)向運維方向，作為智能運維架構(gòu)方向的技術(shù)負責(zé)人，致力于為百度智能運維平臺和產(chǎn)品提供高性能、高可用、可擴展的系統(tǒng)架構(gòu)和基礎(chǔ)設(shè)施。

背景：為什么要做智能運維

百度云智能運維團隊在運維工具和平臺研發(fā)方向歷史悠久，支撐了全百度數(shù)十萬規(guī)模服務(wù)器上的運維服務(wù)，所提供的服務(wù)包括服務(wù)管理、資源定位、監(jiān)控、部署、分布式任務(wù)調(diào)度等等。最近幾年，團隊著力于發(fā)展智能化運維能力以及AIOps產(chǎn)品化建設(shè)。

眾所周知，百度除了搜索業(yè)務(wù)之外，還有很多其他的業(yè)務(wù)線，有像地圖、百科、知道、網(wǎng)盤這樣的老牌業(yè)務(wù)，也有諸如像教育、醫(yī)療這樣的新興業(yè)務(wù)，每個業(yè)務(wù)在規(guī)模上、服務(wù)架構(gòu)上都有很大差異。業(yè)務(wù)本身對穩(wěn)定性的要求很高，需要保持99.995%的高可用，同時在業(yè)務(wù)上云的背景下，虛擬化、混合云等都給我們帶來了新的挑戰(zhàn)。

圖1：百度運維發(fā)展歷程

百度運維經(jīng)歷了從腳本&工具、基礎(chǔ)運維平臺、開放可定制運維平臺到我們現(xiàn)在的智能運維平臺，這樣四個階段的轉(zhuǎn)變。過去運維的核心目標(biāo)是提升效果，比如持續(xù)交付的速度、服務(wù)穩(wěn)定性、運營成本等。經(jīng)過這么多年的建設(shè)，整個運維行業(yè)已經(jīng)非常成熟，而我們所支撐業(yè)務(wù)規(guī)模仍在不斷增長，越來越多的運維場景和問題無法用傳統(tǒng)方法來解決，而運維效率也難以繼續(xù)支撐業(yè)務(wù)規(guī)模的快速擴張，所以我們更加關(guān)注怎么樣解放運維自身的效率，以及解決傳統(tǒng)運維方法（人工、自動化）所解決不了的問題。

這就好比從馬車到汽車是為了提升運輸效率，而到汽車已經(jīng)接近飽和的時候，我們又希望用自動駕駛把駕駛員從開車這項體力勞動中解放出來，不僅可以增加運行效率，同時也可以減少交通事故率，這也是我們對智能運維的訴求。

發(fā)展：AIOps，從理念到落地

2016年Gartner報告中提出了AIOps概念，也就是Algorithmic IT Operations；基于算法的IT運維，主要指用大數(shù)據(jù)、機器學(xué)習(xí)驅(qū)動自動化、服務(wù)臺、監(jiān)控這些場景下的能力提升。

我們從2014年開始做智能運維方面的探索，最開始也是集中在監(jiān)控指標(biāo)分析、報警分析、故障根因分析、性能和成本分析這些方面，到2016年我們已經(jīng)完成將AI應(yīng)用于完整的運維平臺研發(fā)的論證。在我們語義下的AIOps，目標(biāo)是將人的知識和運維經(jīng)驗與大數(shù)據(jù)、機器學(xué)習(xí)技術(shù)相結(jié)合，開發(fā)成一系列的智能策略，融入到運維系統(tǒng)中。用這樣的智能運維系統(tǒng)去完成運維任務(wù)，是我們所認為的AIOps，也就是Artificial Intelligence IT Operations。有意思的是，2017年之后的Gartner報告也將AIOps的概念改成了Artificial Intelligence IT Operations。

圖2：AIOps整體架構(gòu)

我們認為AIOps中有三部分不可或缺，一個是運維開發(fā)框架，這個是我們后續(xù)智能運維研發(fā)的骨架；第二個是運維知識庫，這是讓骨架能與我們真實線上環(huán)境關(guān)聯(lián)起來的關(guān)鍵因素，起到了血肉的作用，讓骨架能動起來；而最后一個則是運維策略庫，這是運維的大腦，控制著運維平臺的行為。

使用運維開發(fā)框架實現(xiàn)的運維程序，我們稱其為運維機器人。運維機器人可以在多種不同的運維場景下提供多樣的運維能力，服務(wù)不同類型的業(yè)務(wù)和用戶。

框架：新的運維開發(fā)模式

圖3：運維開發(fā)框架

運維開發(fā)框架基于這樣一個抽象，就是如果我們把線上環(huán)境看做一個黑盒服務(wù)，那么我們對它的操作無非讀寫兩類。所謂的寫也就是操作控制流，是那種要對線上狀態(tài)做一些改變的操作，我們常說的部署、執(zhí)行命令，都屬于這一類；另一類是讀，指的是數(shù)據(jù)流，也就是要從線上獲取狀態(tài)數(shù)據(jù)，并進行一些聚合統(tǒng)計之類的處理，我們常說的指標(biāo)匯聚、異常檢測、報警都在這個里面。通過運維知識庫，可以在這兩種操作的基礎(chǔ)上，封裝出多種不同的運維機器人，對業(yè)務(wù)提供高效率、高質(zhì)量以及高可用方面的能力。

根據(jù)操作流和數(shù)據(jù)流的不同，我們把框架分成了兩部分，最基礎(chǔ)的是運維執(zhí)行框架，在這之上，加上分布式計算組件的支持，我們還建設(shè)了用于運維大數(shù)據(jù)計算的計算框架。

1、工程化

運維開發(fā)框架給開發(fā)者提供一系列的開發(fā)套件，除了包含了一系列的基礎(chǔ)能力，還包含了一個標(biāo)準的運維工程研發(fā)流程。

在過去，運維研發(fā)采用簡單的開發(fā)-使用方式，缺少必要的測試維護。而現(xiàn)在，在代碼開發(fā)階段，可以通過執(zhí)行框架，用統(tǒng)一的操作接口庫提升研發(fā)效率。在測試階段，開發(fā)套件提供了單測和仿真系統(tǒng)，簡化測試環(huán)境搭建。在上線后的階段，通過狀態(tài)服務(wù)和托管系統(tǒng)，可滿足在各災(zāi)難場景下的運維機器人的自維護。

2、組件化

運維開發(fā)框架通過三種不同的組件功能組合成運維機器人。分別是感知器、決策器和執(zhí)行器。這三種組件針對各自使用場景，提供了多種架構(gòu)能力。

圖4：運維開發(fā)框架的組件

感知器是運維機器人的眼睛和耳朵，就像人有兩個眼睛和兩個耳朵一樣。運維機器人也可以掛載多個感知器來獲取不同事件源的消息，比如監(jiān)控的指標(biāo)數(shù)據(jù)或者是報警事件，變更事件這些，甚至可以是一個定時器。這些消息可以以推拉兩種方式被感知器獲取到。這些消息也可以做一定的聚合，達到閾值再觸發(fā)后續(xù)處理。

決策器是運維機器人的大腦，所以為了保證決策的，機器人有且只能有一個決策器。決策器也是使用者主要要擴展實現(xiàn)的部分。除了常見的邏輯判斷規(guī)則之外，未來我們還會加入決策樹等模型，讓運維機器人自主控制決策路徑。

執(zhí)行器是運維機器人的手腳，所以同樣的，執(zhí)行器可以并行的執(zhí)行多個不同的任務(wù)。執(zhí)行器將運維長流程抽象成狀態(tài)機和工作流兩種模式。這樣框架就可以記住當(dāng)前的執(zhí)行狀態(tài)，如果運維機器人發(fā)生了故障遷移，還可以按照已經(jīng)執(zhí)行的狀態(tài)讓長流程斷點續(xù)起。

知識庫：運維的知識圖譜

知識庫是智能運維架構(gòu)中非常重要的一部分：所有要處理的數(shù)據(jù)都來自知識庫，以及所有處理后的數(shù)據(jù)也都會再進入到知識庫中。知識庫由三部分組成，分別是元數(shù)據(jù)、狀態(tài)數(shù)據(jù)和事件數(shù)據(jù)。持續(xù)的數(shù)據(jù)建設(shè)，是智能運維建設(shè)的關(guān)鍵。

圖5：運維知識庫概覽

考慮到未來需要對接不同的內(nèi)部云平臺和公有云平臺，所以我們的運維數(shù)據(jù)也需要從底層的多種不同的運維平臺中抽取，清洗和做數(shù)據(jù)的整合。并以盡可能高的時效性提供給平臺用戶使用。因此我們知識庫建設(shè)遵照這四個能力指標(biāo)進行，分別是全、準、新、穩(wěn)。

由于知識庫涉及的存儲的內(nèi)容篇幅太大，并且是相對獨立的一塊工作，所以這里就不再展開了。

實踐：運維機器人

單機房故障自愈是2017年我們完成的重點項目，目標(biāo)是將單機房范圍的故障自愈水平普遍提升到L4級（整個處理過程，包括決策過程基本無人介入）。當(dāng)然，另一部分原因是過去一兩年發(fā)生的幾次業(yè)界重大線上事故，我們希望可以防微杜漸，進一步提升MTTR水平。

相比較原有的單機房故障處理方式，在感知、決策、執(zhí)行三個方面，L4級的單機房故障自愈系統(tǒng)效果顯著：

感知方面，智能異常檢測算法替代過去大量誤報漏報的閾值檢測方法；

決策方面，具備全局信息、自動決策的算法組件替代了過去“老中醫(yī)會診”的人工決策模式；

執(zhí)行方面，狀態(tài)機等執(zhí)行長流程組件的加入，讓執(zhí)行過程可定位、可復(fù)用。

目前L4級的單機房故障自愈，已經(jīng)覆蓋百度大多數(shù)核心業(yè)務(wù)線，止損效率可做到分鐘級，最快秒級止損，較人工止損效率提升60%-99％。

圖6：單機房自愈效果

圖6所示，在過去的一次case中，北京某處機房掉電，受影響業(yè)務(wù)線2min內(nèi)即完成止損，對比之前的故障處理方式，止損效率提升非常顯著。

總結(jié)

隨著AIOps逐漸走向成熟和產(chǎn)品化，必將有越來越多的運維場景被AIOps所變革，而我們百度云智能運維團隊，也希望秉承著這個方向，為行業(yè)貢獻更多的創(chuàng)新理念、技術(shù)和產(chǎn)品，歡迎大家一起加入探討。

最后，用一句話來總結(jié)下工程架構(gòu)對于智能運維的意義：

框架在手，AI我有：智能時代，框架會越來越重要，從機器學(xué)習(xí)框架TensorFlow到自動駕駛框架Apollo，概莫能外。