百度智能運維工程架構

本文做者：AIOps智能運維

背景：爲何要作智能運維

 

百度雲智能運維團隊在運維工具和平臺研發方向歷史悠久，支撐了全百度數十萬規模的服務器上的運維服務，所提供的服務包括服務管理、資源定位、監控、部署、分佈式任務調度等等。最近幾年，團隊着力於發展智能化運維能力以及AIOps產品化建設。

 

衆所周知，百度除了搜索業務以外，還有不少其餘的業務線，有像地圖、百科、知道、網盤這樣的老牌業務，也有諸如像教育、醫療這樣的新興業務，每一個業務在規模上、服務架構上都有很大差別。業務自己對穩定性的要求很高，須要保持99.995%的高可用，同時在業務上雲的背景下，虛擬化、混合雲等都給咱們帶來了新的挑戰。

 

百度運維經歷了從腳本&工具、基礎運維平臺、開放可定製運維平臺到咱們如今的智能運維平臺，這樣四個階段的轉變。過去運維的核心目標是提高效果，好比持續交付的速度、服務穩定性、運營成本等。通過這麼多年的建設，整個運維行業已經很是成熟，而咱們所支撐業務規模仍在不斷增加，愈來愈多的運維場景和問題沒法用傳統方法來解決，而運維效率也難以繼續支撐業務規模的快速擴張，因此咱們更加關注怎麼樣解放運維自身的效率，以及解決傳統運維方法（人工、自動化）所解決不了的問題。

 

這就比如從馬車到汽車是爲了提高運輸效率，而到汽車已經接近飽和的時候，咱們又但願用自動駕駛把駕駛員從開車這項體力勞動中解放出來，不只能夠增長運行效率，同時也能夠減小交通事故率，這也是咱們對智能運維的訴求。

 

發展：AIOps，從理念到落地

 

2016年Gartner報告中提出了AIOps概念，也就是Algorithmic IT Operations；基於算法的IT運維，主要指用大數據、機器學習驅動自動化、服務檯、監控這些場景下的能力提高。

 

咱們從2014年開始作智能運維方面的探索，最開始也是集中在監控指標分析、報警分析、故障根因分析、性能和成本分析這些方面，到2016年咱們已經完成將AI應用於完整的運維平臺研發的論證。在咱們語義下的AIOps，目標是將人的知識和運維經驗與大數據、機器學習技術相結合，開發成一系列的智能策略，融入到運維繫統中。用這樣的智能運維繫統去完成運維任務，是咱們所認爲的AIOps，也就是Artificial Intelligence IT Operations。有意思的是，2017年以後的Gartner報告也將AIOps的概念改爲了Artificial Intelligence IT Operations。

 

咱們認爲AIOps中有三部分不可或缺，一個是運維開發框架，這個是咱們後續智能運維研發的骨架，第二個是運維知識庫，這是讓骨架能與咱們真實線上環境關聯起來的關鍵因素，起到了血肉的做用，讓骨架能動起來。而最後一個則是運維策略庫，這是運維的大腦，控制着運維平臺的行爲。

 

使用運維開發框架實現的運維程序，咱們稱其爲運維機器人。運維機器人能夠在多種不一樣的運維場景下提供多樣的運維能力，服務不一樣類型的業務和用戶。

 

框架：新的運維開發模式

 

運維開發框架基於這樣一個抽象，就是若是咱們把線上環境看作一個黑盒服務，那麼咱們對它的操做無非讀寫兩類，所謂的寫也就是操做控制流，是那種要對線上狀態作一些改變的操做，咱們常說的部署、執行命令，都屬於這一類；另外一類是讀，指的是數據流，也就是要從線上獲取狀態數據，並進行一些聚合統計之類的處理，咱們常說的指標匯聚、異常檢測、報警都在這個裏面。經過運維知識庫，能夠在這兩種操做的基礎上，封裝出多種不一樣的運維機器人，對業務提供高效率、高質量以及高可用方面的能力。

 

根據操做流和數據流的不一樣，咱們把框架分紅了兩部分，最基礎的是運維執行框架，在這之上，加上分佈式計算組件的支持，咱們還建設了用於運維大數據計算的計算框架。

 

1工程化

 

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

 

在過去，運維研發採用簡單的開發-使用方式，缺乏必要的測試維護。而如今，在代碼開發階段，能夠經過執行框架，用統一的操做接口庫提高研發效率。在測試階段，開發套件提供了單測和仿真系統，簡化測試環境搭建。在上線後的階段，經過狀態服務和託管系統，可知足在各災難場景下的運維機器人的自維護。

 

2組件化

 

運維開發框架經過三種不一樣的組件功能組合成運維機器人。分別是感知器、決策器和執行器。這三種組件針對各自使用場景，提供了多種架構能力。

 

感知器運維機器人的眼睛和耳朵感，就像人有兩個眼睛和兩個耳朵同樣。運維機器人也能夠掛載多個感知器來獲取不一樣事件源的消息，好比監控的指標數據或者是報警事件，變動事件這些，甚至能夠是一個定時器。這些消息能夠以推拉兩種方式被感知器獲取到。這些消息也能夠作必定的聚合，達到閾值再觸發後續處理。

 

決策器是運維機器人的大腦，因此爲了保證決策的惟一，機器人有且只能有一個決策器。決策器也是使用者主要要擴展實現的部分。除了常見的邏輯判斷規則以外，將來咱們還會加入決策樹等模型，讓運維機器人自主控制決策路徑。

 

執行器是運維機器人的手腳，因此一樣的，執行器能夠並行的執行多個不一樣的任務。執行器將運維長流程抽象成狀態機和工做流兩種模式。這樣框架就能夠記住當前的執行狀態，若是運維機器人發生了故障遷移，還能夠按照已經執行的狀態讓長流程斷點續起。

 

知識庫：運維的知識圖譜

 

知識庫是智能運維架構中很是重要的一部分：全部要處理的數據都來自知識庫，以及全部處理後的數據也都會再進入到知識庫中。知識庫由三部分組成，分別是元數據、狀態數據和事件數據。持續的數據建設，是智能運維建設的關鍵。

 

考慮到將來須要對接不一樣的內部雲平臺和公有云平臺，因此咱們的運維數據也須要從底層的多種不一樣的運維平臺中抽取，清洗和作數據的整合。並以儘量高的時效性提供給平臺用戶使用。所以咱們知識庫建設遵守這四個能力指標進行，分別是全、準、新、穩。

 

因爲知識庫涉及的存儲的內容篇幅太大，而且是相對獨立的一塊工做，因此這裏就再也不展開了。

 

實踐：運維機器人

 

單機房故障自愈是2017年咱們完成的重點項目，目標是將單機房範圍的故障自愈水平廣泛提高到L4級（整個處理過程，包括決策過程基本無人介入）。固然，另外一部分緣由是過去一兩年發生的幾回業界重大線上事故，咱們但願能夠防微杜漸，進一步提高MTTR水平。

 

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

 

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

 

2.決策方面，具有全局信息、自動決策的算法組件替代了過去「老中醫會診」的人工決策模式；

 

3.執行方面，狀態機等執行長流程組件的加入，讓執行過程可定位、可複用。

 

目前L4級的單機房故障自愈，已經覆蓋百度大多數核心業務線，止損效率可作到分鐘級，最快秒級止損，較人工止損效率提高60%-99％。

 

總結

 

隨着AIOps逐漸走向成熟和產品化，必將有愈來愈多的運維場景被AIOps所變革，而咱們，百度雲智能運維團隊，也但願秉承着這個方向，爲行業貢獻更多的創新理念、技術和產品，歡迎你們一塊兒加入探討。

 

最後，用一句話來總結下工程架構對於智能運維的意義：

 

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

 

原文連接地址：https://developer.baidu.com/topic/show/290063