本文是根據百度雲智能運維負責人曲顯平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原創，轉載請聯繫 [email protected]