《復雜運維場景下，如何實現分鐘級的故障根因定位》要點：
本文介紹了復雜運維場景下，如何實現分鐘級的故障根因定位，希望對您有用。如果有疑問，可以聯系我們。

作者介紹

熊亞軍

靈犀技術總監,原百度系統部高級項目經理,負責百度IT基礎設施監控團隊,其帶領的團隊經歷了百度服務器規模邁入幾十萬量級,網絡架構數次演進,對服務器尤其是網絡層的監控和運維自動化智能化有豐富的經驗.

開篇：

在超級互聯網公司,隨著服務器規模都早早邁過 10 萬臺量級,加之業務模式的多樣性和 IT 架構的云化遷移,其 IT 運維團隊面臨的挑戰與日俱增,常規的系統和經驗都需要不斷迭代更新.

本文將給大家介紹在超級互聯網公司如何基于網絡的故障根因自動定位技術,提高故障定位速度,從而提高業務可用性.

規模效應和云的效應極大提升了運維的復雜性

首先我們先來看看超級互聯網公司的業務架構示例圖：

在超級互聯網公司中,通常不同的層次都由不同的團隊來負責運維管理,同層次不同的硬件/系統/應用都由不同的小組來負責運維管理.

就基礎設施即服務這層來說,隨著IT設備規模的不斷增加,IT 設備故障的告警種類與告警數量也隨之急劇增加.

告警的多面性、冗余性、耦合性,導致某些核心層面的故障會引起大面積告警的現象,而這些告警又有可能分屬不同小組,運維人員處理故障會增加排查問題的難度以及增加小組間溝通成本.

同時因為對故障信息缺乏統一的管理,無法對告警系統進行反饋優化,致使誤報漏報頻出.同樣也無法進行全面的故障信息統計分析,不知道如何對基礎設施資源進行風險管理.

眾所周知,IT基礎設施層的運維工作,直接影響公司服務穩定性.一次服務中斷事件便會對公司造成極大的經濟損失.

但正如上述現狀描述中提到的問題：

• 運維平臺繁雜多樣,
• 運維小組之間溝通滯后,
• 告警信息共享程度低,
• 工程師水平參差不齊,故障處理自動化程度較低.

告警系統缺乏有效的反饋機制進行系統優化,同時缺少全面有效的故障信息沉淀,無法幫助預算與評估采購系統進行合理采購.

這些都極大約束了運維水平的與時俱進,新的方法論和新的運維技術有迫切的內部需求.

我們收斂匯總一下復雜運維場景下的主要痛點：

• 如何在告警風暴時壓縮告警
• 如何快速從大量告警中找到故障根源
• 如何提高不同運維小組的故障處理協作效率
• 如何實現對IT基礎設施的風險管理

如何應對?打造以故障定位為核心的運維生態體系!

基于上述背景下的痛點問題,一套以故障定位為核心的運維生態體系的建立便成為高逼格的不可或缺：

• 統一故障信息入口,使用機器學習的算法對信息進行分類整合和推理,自動定位故障生成case,設計開發統一故障處理平臺,通知工程師來平臺進行處理故障.
• 同時將所有數據進行沉淀分析,反饋給告警系統和質量管理系統,提高故障處理效率,加強基礎設施風險管理.

而在這套生態體系中,故障自動定位技術便是體系是否能夠成功建立的核心要素.

故障根因自動定位簡要科普

故障根因自動定位系統為人工智能的分支,屬于診斷性專家系統,專家系統通常包含:

• 人機交互界面
• 知識庫
• 推理機
• 解釋器
• 綜合數據庫
• 知識獲取

其中最重要的是知識庫和推理機.知識庫用于專家經驗的存儲,是一種靜態規則,推理機根據現象結合知識庫中的規則反復推理得出結論.規則集的組成形式有多種方式,本文重點介紹的是二叉決策樹.

故障根因定位系統的設計架構系統

故障根因自動定位系統主要由監控系統、接入系統、推理系統、通告系統四個部分組成,分別的功能如下：

• 監控系統：監控系統負責各類探針數據的采集,根據監控規則產生告警；
• 接入系統：接入系統負責對各類監控系統的告警信息進行匯總并格式化處理；
• 推理系統：推理系統根據專家推理樹進行故障根因定位推理,定位最終告警原因,確定故障根源；
• 通告系統：通告系統根據定位出的故障根因進行故障信息通告.

看個實際案例,看看到底能解決啥問題?

故障推理算法是整個故障定位系統的核心,這里重點闡述下故障推理算法的實現方式.

故障定位算法采用機器學習中的二叉決策樹的方式實現:

• 一方面希望將故障所產生的所有告警信息整合為一條信息,減少告警量；
• 另一方面希望能夠智能定位出故障點,減少工程師排查問題的時間,并引入自動化處理.

以某公司網絡故障根因定位為例,實現上述目標需要三步:

第一步：將問題排障過程的經驗提煉成二叉決策樹；

第二步：將告警信息按照時間分片算法進行分類分組；

第三步：將分組的告警信息輸出給決策樹進行自動推理輸出推理結果.

看看推理樹是怎么構建的呢?

根據某公司目前網絡故障時的告警特點和網絡工程師運維的特點,得出下面的一些結論,而這些結論可幫助我們構建出經驗推理樹.

A、告警信息是分層次的:

• 第一層是交換機級別,如ROUTER_ID、CPU、TM告警；
• 第二層次是板卡告警,比如板卡芯片問題,板卡故障；
• 第三層次是端口告警,LINK-NEW告警等與端口相關的告警；

B、每一層的告警又可分為原子告警,衍生性告警.

比如：

第三層告警,LINK-NEW便是衍生性的告警,而PORT DOWN的告警為原子告警,即PORT DOWN了一定會有LINK-NEW的告警,反之不然.

根據以上結論,故障定位的原則為：重要性從最高層往最低層報,每層中重要性從原子告警到衍生性告警報.

比如:

收到了ROUTER_ID,PORT DOWN, LINK-NEW的告警,那么只需報ROUTER_ID的告警；

如果只有PORT DOWN, LINK-NEW的告警,就重點報`PORT;

DOWN的告警,如果只有LINK-NEW的告警,則只能報LINK-NEW`的告警.

引入故障追蹤列表,比如第二層的【BOARD告警】引起第三層的告警【PORT、OSPF、LINK-NEW】,每個故障追蹤列表形成一個Case,即Case的生成過程不是以某交換機為單位,而是以故障追蹤列表為單位.

根據上述的分析,設計推理樹如下圖所示：

沒太看明白?看看推理樹的構建原則和實現方式

A、推理樹的構建有以下四個原則：

原則一：告警從高層向底層,在邏輯層次上面,越根源性的告警越先判斷.

例如:

A出現問題必然導致B出現問題,B出現問題必然導致C出現問題,在邏輯層次上面,A的根源性最高,當A、B、C告警同時到達,先判斷A,判定A、B、C故障的根因為A.

在告警關聯度上面,越明確關聯的告警越先判斷.

例如:

故障A對應有A1、A2、A3三種告警,關聯度依次為A1 > A2 > A3,先判斷A1,由A1直接確定A1、A2、A3的故障根因為A.

原則二：從原子到衍生告警.

原則三：推理樹的建立根據告警來定.

原則四：驗證規則,根據經驗和知識庫來定.

B、推理過程實現有以下三種方式：

方式一：

給出特征 —> 推理機 —> 結論 —> 驗證 —> 發出結果

方式二:

自主收集特征 —> 推理機 —> 結論 —> 驗證 —> 發出結果

方式三:

數據 —> 根據特征設計的推理機 —> 結論 —> 驗證 —> 發出結果

簡單來說,方式一就是半人工方式、方式二就是簡單機器學習方式、方式三就是智能機器學習方式.

來個總結吧,4步搭建你的故障根因定位系統

看完是不是有點小激動,想動手試試如何構建一套智能故障根因定位系統,需要如下幾個步驟:

第一步: 構建CMDB

CMDB是監控系統的基礎,數據部分通常分為靜態、動態兩大類.

就網絡設備而言,靜態數據通常包括：

• 機框
• 矩陣
• 板卡
• 模塊
• 端口

動態數據通常包括：

• IP地址
• 路由
• 端口狀態
• 端口流量

第二步: 告警標準化

需要統一告警信息的格式,便于故障定位系統提取關鍵特征級并進行分類分組.

第三步:梳理告警關系

理清告警之間的關聯關系,關聯關系需要是邏輯上面的,形成必要的關系,例如A是B上游模塊,A出現問題必然會導致B出現問題.

第四步: 構建推理樹

根據人工故障定位判斷邏輯,構建推理樹,設定每個推理節點的判決條件.

OK啦,做完以上幾步,您就搭建了一個簡單的故障根因自動定位系統,通過對每個推理節點判斷條件的不斷優化,您可以不斷提升故障自動定位準確率,讓您的運維效率得到大幅提升,IT運營水平逐步與BAT等超級互聯網公司運營水平對齊.

如果您需要任何幫助,也加入由靈犀linkedsee和高效運維共同建立的微信群,與本文作者和更多同行進行交流.

同時您也可以免費體驗目前靈犀linkedsee對外發布的產品.

致謝：

本文由靈犀(IT運營專家)供稿.

說明：

關于本文或靈犀,您有什么需要討論的?歡迎加入如下微信群.

請添加微信號 jia_yanni001 為好友,由她邀請您加入,接頭暗號為：IT運營交流.

轉載請注明本頁網址：
http://www.fzlkiss.com/jiaocheng/4496.html