百度雲曲顯平：AIOps時代下如何用運維數據系統性地解決運維問題？

本文是根據百度雲智能運維負責人曲顯平10月20日在msup攜手魅族、Flyme、百度雲主辦的第十三期魅族技術開放日《百度雲智能運維實踐》演講中的分享內容整理而成。

內容簡介：本文主要從百度運維技術的發展歷程、如何作智能運維、故障管理場景、服務諮詢場景和麪對的挑戰等幾個方面介紹了百度雲智能運維實踐。

百度運維技術的三個階段

第一階段：基礎運維平臺 2008年~2012年

2008年，在百度運維部創建以前，尚未一個標準而統一的運維平臺。例如，搜索、廣告、貼吧都有各自的運維平臺。

存在的問題：

技術和平臺能力沒法複用，業務之間須要交互時比較複雜。

解決方法：

①爲幫助業務解決問題，咱們把各個分散在不一樣業務的運維平臺整合起來作成一套標準化運維平臺；

②有了統一運維平臺後，運維部門內的角色就分爲了兩個，即標準的運維工程師和運維平臺研發工程師。

第二階段：開放的運維平臺 2012年~2014年

第一階段仍然存在的問題：

①個性化需求不少，統一平臺很難所有解決

②PaaS出現以後，運維平臺和PaaS的關係

解決方法：

①開放運維平臺，即所有API化。

②經過提供標準化的監控數據的採集、計算、報警能力，最基礎的程序分發、數據分發、任務調度能力，解決自身平臺的需求。

③利用PaaS方法，把一些研發的技術平臺和運維技術平臺整合在一塊兒，解決重複造輪子的問題。

第三階段：AIOps階段 2014年開始

百度從2014年就開始了智能運維的實踐。最先的時候，咱們更可能是經過完善底層的大數據平臺能力，提供一些數據分析和挖掘的算法和工具，解決運維數據沒有獲得合理運用，運維人工效率低等問題，這是偏大數據的方法。

百度對於AIOps的理解

在2015年，AI變得異常火熱，百度也是想將自身先進的機器學習算法應用到運維領域之中，因而咱們和百度的大數據實驗室、深度學習實驗室進行了合做。運維研究人員把需求和歸整好的數據提交給實驗室的人員，而後他們會根據數據訓練模型，最終提供一些庫和方法供業務使用。2016年，Gartner提出了AIOps這個詞，也就是咱們說的智能運維，這和百度的實踐是不謀而合的。

三個核心內容

隨着智能運維的發展，百度也是把數據、工程和策略三個，做爲最核心內容來系統地解決運維行業的應用。從數據角度來說，首先要構建一個完整的數據倉庫，接着要建設運維知識庫。知識庫是在數據倉庫上抽象進行的。從工程角度，一方面，分析數據和訓練算法模型須要大數據平臺和框架，另外一方面，運維業務研發人員還作了一套運維工程研發框架，用以解決標準化、可擴展和複用的問題。這個框架十月份剛剛開源，感興趣的朋友能夠看下。

在百度內部，一致的運維「語言」很是關鍵。咱們要統一不一樣的工具和平臺，造成一致的運維模式。因此無論是故障感知、故障診斷決策、彈性伸縮決策仍是運維操做和執行，只有統一塊兒來才能解決這個問題。一致不只是數據一致、工程一致，還須要策略自己的一致性。

自動駕駛分級

在構建整個百度智能運維體系的過程當中，咱們重點參考了自動駕駛裏的分級理論。百度是有這樣兩個部門的，一個叫L3，一個叫L4。L3部門重點在作相似於輔助駕駛或者高度輔助駕駛；L4部門作的是高度徹底自動駕駛。下圖是關於自動駕駛的分級。

運維能力分級

自動化運維能力分級

當時咱們團隊參照這個自動駕駛分級，構建出了一個自動化運維能力的分級標準，用以評估咱們各個方向的自動化水平，一共分爲六個能力等級，即人工、工具輔助、部分自動化、有條件的自動化、高速自動化和徹底自動化。

關鍵點：決策規劃由運維繫統作出，而不是人

人負責：制定優化目標（好比，可用性、效率、成本等）

運維繫統負責：根據其對待處理的需求、待解決的問題的理解，以及對運維對象的認知（經驗），自主作出解決方案（規劃）並在控制執行過程當中根據目標和運維對象的狀態反饋來適時調整執行規劃。

智能化運維能力分級

在自動化能力分級之中，咱們還細化出了一個智能化運維能力分級（咱們始終認爲智能運維是實現徹底自動化運維的一種手段）。實現智能化能力，重點解決的是在運維感知和決策過程當中，人工效率低和準確率不足的問題。

關鍵點：決策規劃由運維繫統作出，而不是人

人負責：制定優化目標（好比，可用性、效率、成本等）

運維繫統負責：根據其對待處理的需求、待解決的問題的理解，以及對運維對象的認知（經驗），自主作出解決方案（規劃）並在控制執行過程當中根據目標和運維對象的狀態反饋來適時調整執行規劃。

如何作運維

咱們但願每個運維工具都像一個小型的運維機器人同樣，解決運維的問題。運維工程師須要把每個運維工具抽象化，同時也要像一個標準框架同樣，能夠在代碼庫裏克隆，把框架代碼複製下來。經過三個基本核心，感知、決策和執行來進行編寫執行器，接着能夠經過配置實現一些具體任務調度的配置或者併發執行的配置；每個運維工程師要實現感知邏輯、決策邏輯、執行邏輯，利用運維核心解決可靠性的問題。在測試方面，要在線下創建看代碼的邏輯去驗證。結合這個看代碼，把比較核心的運維故障抽象出來，再把一些常見的故障模擬出來，具體的狀況能夠在這裏面運行；寫完一個運維工具或者算法，須要直接在上面運行，從而檢測出是否有效。

故障處理場景

百度內部如何解決故障處理場景

故障處理場景通常分四個主要階段：故障發現、服務止損、服務恢復、故障總結。

在服務止損方面，核心是如何讓用戶感知不到這個故障，對於運維來說，更多用的方法是隔離、降級，而非從代碼BUG入手解決的問題。

在服務恢復方面，這個通常是在服務止損或者說故障被隔離以後，很大程度上須要運維和研發共同合做，好比定位代碼的BUG，最終要決定如何把線上的問題真正解決掉。恢復，更多用的是修復來解決。在百度，大多數的故障都是能夠用隔離和降級解決的，只有那些極特殊的case，纔會經過程序回滾來恢復。回滾風險很大，並且效率很低。

在整個解決故障處理場景的階段，每個階段均可以結合智能運維的方法。從開始服務部署、監控添加、故障發現、止損決策、止損操做、根因診斷、恢復操做，最後報告自動生成。

把AIOps應用到故障處理最核心的基礎是，全面覆蓋監控。在百度，作的最全面的是雲上的監控，因此包含這四個維度的監控：系統監控、業務監控、內網監控和外網監控。

系統監控主要的監控對象是機器/容器和服務的動態內容；業務監控針對業務和用戶的訪問日誌等；內網監控則針對IDC內網設備和內網鏈路；外網監控爲了保障用戶、運營商鏈路到百度IDC中間的狀態。

有了全面的監控以後，才能開始如今業界常提到的一個智能運維技術，自動異常檢測。

典型的異常檢測場景

有關異常檢測場景，我爲你們舉三個典型的例子，第一個，週期波動的數據。

上圖中的藍、綠、黃三條線分別表明着今天、昨天、上週的時間線，藍線比較明顯，後面還有綠線和黃線。它們相對來講週期性體現得特別強。這種數據很難用傳統的計算方法設置閾值。針對這種場景，咱們會使用不一樣類的算法，專門解決這種問題。

第二個，關心突變的數據。

突變的數據也是一個比較典型的場景，週期性數據更多參考的是天級和周級的數據，而這個場景更多說的是某一個細節層面，能夠理解爲它是對一小塊數據的放大。

第三個，關心是否超出了必定波動範圍的數據。

這種場景是咱們用普通的監控方法很難覆蓋的，不少狀況下，其均值或基線不會有特別明顯的變化，但系統如今確實出現了很大的不一樣狀態，可能僅僅是波動更劇烈了，對於這類場景，咱們更多的是去看波動的狀況，就是除基線之外的一些特徵。

今年八月份，百度雲開源了一個數據標註的工具－Curve 。咱們始終以爲算法雖然很重要，但遠沒有數據自己重要。作機器學習時，數據的建設纔是最須要花時間解決的問題，百度的運維工程師也是重點在解決數據標準和數據獲取的問題。

如何應對報警風暴

當出現大規模報警時，手機可能會直接被打爆。異常檢測重點解決的是故障感知的問題。當故障被感知後，須要通知給運維工程師。首先，作逐級通告，對報警進行分級。接着作數據的整理，整理出每個數據，最後抽象化數據的特徵，按照每一個維度或特徵進行報警的歸併。

完成前兩步以後，報警會有必定改善。最後要用數據分析方法或者機器學習的方法處理。數據的特徵已經被抽象化，因此有不少方法能夠解決，第一種方法是傳統數據挖掘，好比關聯分析，頻繁項集挖掘是最被普遍使用到的方法，它能夠有效將同類報警進行合併。第二種方法是機器學習，由於前面抽象出了特徵，那作分類聚類都是比較直接的事情。從咱們的實踐狀況看，最後的效果二者相差不大，你們均可以嘗試。

報警產生後，就至關於感知階段結束，以後就到達故障處理階段。接下來，我分享幾個百度內部以爲效果最好的處理方法。

第一個方法，多維度定位。這個更多偏業務問題的定位。業務都有訪問日誌，日誌由各個不一樣維度的數據組成。一個故障的出現可能有不一樣維度，運維工程師須要經過訪問日誌的數據進行計算分析，分析出真正影響故障的維度。

在這個基礎上，能夠作可視化。這是一類結合業務特徵的可視化方法，如上圖，這是一個模塊拓撲圖，不少圈圈，不少研發，這裏有健康度、響應時間等等各類維度的展現。像模塊響應時間，又可能會分不少類、不少維度或者不少模塊，底下是每個不一樣的模塊，均可能產生對應的一些狀況。

接下來，百度如今大部分在用的是基於信息熵的維度特徵推薦。例如，一個出現故障問題的指標，大的流量降低，可能有不一樣的維度。運維工程師會對每個維度裏的子維度數據進行分析，分析降低的程度，以及對於如今整個流量整體的降低程度的不一樣佔比，而後作一個排序，就能夠獲得故障影響較高的某幾個維度，從而幫助工程師儘快定位到這個問題或者縮小問題的範圍。

第二個方法，基於服務拓撲或者服務關聯作定位。這是內部比較重要的故障判斷基礎和指導意見。百度運維傾向於把一個問題的分析分紅六個維度：

①時間維度，縮小時間範圍；

②網絡拓撲模型，縮小空間範圍，區分總體和局部故障；

③服務管理模型，推導異常集羣、實例或者機器；

④變動關聯模型，定位程序、配置、數據、運營活動上線；

⑤模塊關聯模型，上下游關聯服務的異常傳播鏈；

⑥多維度模型，維度關聯層級分析，縮小業務範圍。

上圖是一類典型的故障診斷框架。咱們可能有不少故障的分類，好比有網絡故障，細分一點是有交換機故障、鏈路故障，可能有系統故障，業務問題、操做問題等各類各樣的，都是屬於假說生成，可能都是備選故障問題。中間有一個證據評分，至關於基於前面的模型拓撲關係，對不一樣的故障作評分，把拓撲關係的線作權重，而後作置信計算和排序，最後給出最優決策判斷。

有關自愈的問題

· 故障自愈

經過自動化、智能化處理故障節省人力投入，經過預設定的處理流程和只能化判斷策略，提升故障處理可靠性，同時下降故障時間，爲業務可用性保駕護航。

· 智能自愈

①感知：經過監控系統獲取業務運行指標、智能異常檢測、網絡異常事件多種觸發方式

②決策：根據不一樣感知方式能夠配置不一樣決策模型

③執行：在單機執行基礎上，提供集羣級別、分佈式的處理方式

在執行故障自愈過程當中，並不止是一個工具的執行，而是包括了調度、伸縮、隔離預案處理甚至多個不一樣業務的聯動。自愈自己的核心並不是自動化過程，更可能是決策的過程。

舉一個典型案例叫單機房故障自愈。單機房，不只僅指機房網絡故障，更多指的是故障範圍只要限定在一個IDC內部，無論這個故障是代碼BUG，仍是外面流量接入出了問題，仍是機房整個掉電，只要故障範圍是在一個IDC內均可以解決。

基礎能力達標後，咱們要設計一個故障自愈系統，核心部分是外網流量調度止損決策器和內網流量調度止損決策器。外網比較簡單，而內網則涉及到一些負載均衡策略、彈性伸縮策略、主備切換策略等。

盲測驗收

最後講一下盲測驗收。有了故障自愈的系統後，怎麼證實你的方案好用呢？在不通知業務的狀況下，咱們會和IDC同事進行配合，拔網線或是製造網絡擁塞，這時候才能進行完整的切換，從而能夠證實基礎能力是否達標。

百度如今單機房故障自愈已經覆蓋了全部核心業務線，自愈時效控制在5分鐘內，而且對於非數據庫依賴的業務，能夠作到1-2分鐘完成機房級自愈。

諮詢服務場景

服務諮詢的場景可分爲如下三種：

①經過聊天窗口（IM軟件、瀏覽器等）實時查詢業務狀態，用戶可視化、可追查各類問題；

②經過聊天窗口（IM軟件、瀏覽器等）實時觸發運維操做，運維工程師可遠程上線、啓停任務等；

③當運維操做完成，出現狀態變化或異常等狀況時，運維工程師可主動發送相關通知，或按照策略自動進行後續操做。

在百度內部，咱們將這種場景稱爲ChatOps：

•「放心」：分級發佈和可用性干預、保障

•「貼心」：監控、部署一站式集成，信息主動推送和確認

•「省心」：高度自動化，減小人工介入和等待

•「開心」：助力業務發展，如迭代效率提高

•將運維人員從日漸瑣碎、枯燥、疲憊、低價值、高事故率的工做中解放出來

•實現運維人員的轉型和增值

AIOps的挑戰

最後說一下AIOps的挑戰。現有的AIOps技術，好比指標異常檢測、故障自愈等，更多解決的是數據自己的特徵和問題，還沒抽象到服務、程序自己的特徵這個層次上，也就是說，咱們並無真正地瞭解和解決問題自己。好比，不一樣類的服務所產生的故障和表徵是不同的，咱們但願讓數據更多、業務場景可擴展，而非針對幾個橫向的場景；在業務運營方面，咱們不只僅侷限在IDC、操做系統、機器，而是注重資源和性能優化，運維還能夠繼續拓展。對內，能夠作系統優化、成本優化；對外，幫助全部用戶作雲服務資源池優化，讓你們更好的節約成本，提高服務能力。

以上內容來自曲顯平老師的分享。

聲明：本文是由msup原創，轉載請聯繫 meixu.feng@msup.com.cn