背景：為什麼要做智能運維
這就好比從馬車到汽車是為了提升運輸效率，而到汽車已經接近飽和的時候，我們又希望用自動駕駛把駕駛員從開車這項體力勞動中解放出來，不僅可以增加運行效率，同時也可以減少交通事故率，這也是我們對智能運維的訴求。
發展：AIOps，從理念到落地
2016年Gartner報告中提出了AIOps概念，也就是Algorithmic IT Operations；基於算法的IT運維，主要指用大數據、機器學習驅動自動化、服務檯、監控這些場景下的能力提升。
我們從2014年開始做智能運維方面的探索，最開始也是集中在監控指標分析、報警分析、故障根因分析、性能和成本分析這些方面，到2016年我們已經完成將AI應用於完整的運維平臺研發的論證。在我們語義下的AIOps，目標是將人的知識和運維經驗與大數據、機器學習技術相結合，開發成一系列的智能策略，融入到運維繫統中。用這樣的智能運維繫統去完成運維任務，是我們所認為的AIOps，也就是Artificial Intelligence IT Operations。有意思的是，2017年之後的Gartner報告也將AIOps的概念改成了Artificial Intelligence IT Operations。
圖2：AIOps整體架構
我們認為AIOps中有三部分不可或缺，一個是運維開發框架，這個是我們後續智能運維研發的骨架；第二個是運維知識庫，這是讓骨架能與我們真實線上環境關聯起來的關鍵因素，起到了血肉的作用，讓骨架能動起來；而最後一個則是運維策略庫，這是運維的大腦，控制著運維平臺的行為。
使用運維開發框架實現的運維程序，我們稱其為運維機器人。運維機器人可以在多種不同的運維場景下提供多樣的運維能力，服務不同類型的業務和用戶。
框架：新的運維開發模式
圖3：運維開發框架
運維開發框架基於這樣一個抽象，就是如果我們把線上環境看做一個黑盒服務，那麼我們對它的操作無非讀寫兩類。所謂的寫也就是操作控制流，是那種要對線上狀態做一些改變的操作，我們常說的部署、執行命令，都屬於這一類；另一類是讀，指的是數據流，也就是要從線上獲取狀態數據，並進行一些聚合統計之類的處理，我們常說的指標匯聚、異常檢測、報警都在這個裡面。通過運維知識庫，可以在這兩種操作的基礎上，封裝出多種不同的運維機器人，對業務提供高效率、高質量以及高可用方面的能力。
根據操作流和數據流的不同，我們把框架分成了兩部分，最基礎的是運維執行框架，在這之上，加上分佈式計算組件的支持，我們還建設了用於運維大數據計算的計算框架。
1
工程化
運維開發框架給開發者提供一系列的開發套件，除了包含了一系列的基礎能力，還包含了一個標準的運維工程研發流程。
在過去，運維研發採用簡單的開發-使用方式，缺少必要的測試維護。而現在，在代碼開發階段，可以通過執行框架，用統一的操作接口庫提升研發效率。在測試階段，開發套件提供了單測和仿真系統，簡化測試環境搭建。在上線後的階段，通過狀態服務和託管系統，可滿足在各災難場景下的運維機器人的自維護。
2
組件化
運維開發框架通過三種不同的組件功能組合成運維機器人。分別是感知器、決策器和執行器。這三種組件針對各自使用場景，提供了多種架構能力。
圖4：運維開發框架的組件
感知器是運維機器人的眼睛和耳朵，就像人有兩個眼睛和兩個耳朵一樣。運維機器人也可以掛載多個感知器來獲取不同事件源的消息，比如監控的指標數據或者是報警事件，變更事件這些，甚至可以是一個定時器。這些消息可以以推拉兩種方式被感知器獲取到。這些消息也可以做一定的聚合，達到閾值再觸發後續處理。
決策器是運維機器人的大腦，所以為了保證決策的唯一，機器人有且只能有一個決策器。決策器也是使用者主要要擴展實現的部分。除了常見的邏輯判斷規則之外，未來我們還會加入決策樹等模型，讓運維機器人自主控制決策路徑。
執行器是運維機器人的手腳，所以同樣的，執行器可以並行的執行多個不同的任務。執行器將運維長流程抽象成狀態機和工作流兩種模式。這樣框架就可以記住當前的執行狀態，如果運維機器人發生了故障遷移，還可以按照已經執行的狀態讓長流程斷點續起。
知識庫：運維的知識圖譜
知識庫是智能運維架構中非常重要的一部分：所有要處理的數據都來自知識庫，以及所有處理後的數據也都會再進入到知識庫中。知識庫由三部分組成，分別是元數據、狀態數據和事件數據。持續的數據建設，是智能運維建設的關鍵。
圖5：運維知識庫概覽
考慮到未來需要對接不同的內部雲平臺和公有云平臺，所以我們的運維數據也需要從底層的多種不同的運維平臺中抽取，清洗和做數據的整合。並以儘可能高的時效性提供給平臺用戶使用。因此我們知識庫建設遵照這四個能力指標進行，分別是全、準、新、穩。
由於知識庫涉及的存儲的內容篇幅太大，並且是相對獨立的一塊工作，所以這裡就不再展開了。
實踐：運維機器人
單機房故障自愈是2017年我們完成的重點項目，目標是將單機房範圍的故障自愈水平普遍提升到L4級（整個處理過程，包括決策過程基本無人介入）。當然，另一部分原因是過去一兩年發生的幾次業界重大線上事故，我們希望可以防微杜漸，進一步提升MTTR水平。
相比較原有的單機房故障處理方式，在感知、決策、執行三個方面，L4級的單機房故障自愈系統效果顯著：
感知方面，智能異常檢測算法替代過去大量誤報漏報的閾值檢測方法；
決策方面，具備全局信息、自動決策的算法組件替代了過去“老中醫會診”的人工決策模式；
執行方面，狀態機等執行長流程組件的加入，讓執行過程可定位、可複用。
圖6：單機房自愈效果
圖6所示，在過去的一次case中，北京某處機房掉電，受影響業務線2min內即完成止損，對比之前的故障處理方式，止損效率提升非常顯著。
總結
最後，用一句話來總結下工程架構對於智能運維的意義：
框架在手，AI我有：智能時代，框架會越來越重要，從機器學習框架TensorFlow到自動駕駛框架Apollo，概莫能外。
近期熱文
近期活動
閱讀更多 DBAplus社群 的文章
