1. 程式人生 > >複雜運維場景下,如何實現分鐘級的故障根因定位

複雜運維場景下,如何實現分鐘級的故障根因定位

作者介紹

熊亞軍

靈犀技術總監,原百度系統部高階專案經理,負責百度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的生成過程不是以某交換機為單位,而是以故障追蹤列表為單位。

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

5

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

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運營交流。