Categories
程式開發

智能運維繫列(十三)| 面向智能化運維的CMDB系統構建


經過兩年多的努力,在2020年微眾銀行智能化運維建設終於取得了明顯成效,在智能監控領域的異常識別及根因定位方面發揮了巨大作用,甚至可以做到了秒級異常發現與定位。 CMDB系統(配置管理平台Configuration Management Datebase)作為智能化運維體系的基石與保障,除了承擔存儲和元數據支撐以外,也為智能化運維體系的正常運作、敏捷擴展提供了有力保障。 本文將結合具體實踐,介紹微眾銀行面向智能化運維的CMDB系統構建歷程以及實施效果。

前文回顧

專題| 智能時代下的運維

構建CMBD系統的三個階段

1.CMDB1.0所面臨的痛點

在2015年微眾銀行成立之初,微眾銀行構建了CMDB1.0。 CMDB1.0吸取了開源項目oneCmdb的經驗, CI模型配置結合key-value形式存儲CI數據,靈活的支持了當時的銀行基礎架構建設​​的初級階段。 但隨著不斷擴大的銀行業務規模,配置項越來越多樣,科技類的工具系統如雨後春筍般建立起來。 在此過程中,CMDB1.0的架構在系統間對接方面,配置項多樣性模型建設方面,以及數據量急速增加方面的可擴展性表現得越來越差, 同時用戶體驗方面也暴露出很多問題。 在這個階段,痛點和不足主要表現為:

  • 模型定義不完整:CMDB中管理的配置範圍、配置數據覆蓋不全,配置關係及屬性定義不完整,無法有效支撐日常運維的基礎訴求。

  • 數據維護成本高:未建立配置信息的生命週期管理流程,無法達到自動更新維護數據的目的。 當時,CMDB中數據的採集和變更嚴重依賴人員維護,維護成本高,數據滯後於真實運行情況,甚至部分配置信息在系統外維護,CMDB未能發揮應有的作用。

  • 數據質量無法保證:缺乏數據之間邏輯規則校驗機制以及數據同步校驗機制,數據準確性和數據質量無法保證,運維人員不信任CMDB。

2.面向智能化運維的CMDB2.0系統構建

從2016年開始,為構建自動化智能化運維體系,同時滿足微眾銀行分佈式架構的運維管理要求,我們重新規劃搭建起了為支撐各運維場景,提供準確靈活基礎數據能力的新一代CMDB系統,並徹底解決了CMDB1.0階段所面臨痛點。

我們以應用為中心,通過自研提供完整的、準確的,能全網管理運維對象和關係存儲的模型,實現了與運維繫統的靈活銜接。 CMDB2.0的優勢主要體現在如下三個方面:

以應用為中心。建立自動化、智能化運維體系,從應用的角度規劃管理各種運維場景。 因此,在CMDB2.0的模型設計上,我們堅持以應用為中心,全面梳理和分析行內的運維對象及關係,從物理層、邏輯層和應用層幾方面分層構建模型。 通過該模型中所定義的配置項及關係,可幫助應用運維在日常工作中快速查詢和了解整體應用資源對象和拓撲關係,提升變更發布、故障分析等運維工作效能。

智能運維繫列(十三)| 面向智能化運維的CMDB系統構建 1

圖1微眾銀行配置模型框架

重視系統的靈活性和可擴展能力性。CMDB2.0一方面需要提升配置模型的管理能力,即快速靈活的實現模型隨著業務變化而調整、修正和擴展,滿足各個運維團隊對於配置數據的深度和廣度的需求;另一方面,也需要提高配置數據的易用性,幫助用戶或其他運維繫統便捷、高效地查詢和引用CMDB數據。 在這個思路下, CMDB2.0管理平台具備如下6個方面功能特性:

  • 配置模型動態擴展:在線動態定義配置項,以及配置項的屬性、關係、數據類型、唯一性、組合關鍵字等;
  • 定義多維度查詢:支持在線自定義多項配置數據聯合查詢,以及全站檢索;
  • API接口動態生成:支持在線定義API接口,支持在線測試、驗證接口準確性;
  • 細粒度權限管控:實現行級列級的數據權限控制;
  • 多維度日誌查詢:全站數據變遷的歷史追溯;
  • 版本基線比對及回退:支持配置模型版和配置數據的版本基線比對及回溯。

智能運維繫列(十三)| 面向智能化運維的CMDB系統構建 2

圖2 CMDB系統API接口在線調試功能

3。微服務架構下的CMDB 3.0

隨著外圍系統對CMDB2.0的依賴越來越大,系統間調用關係越來越複雜, CMDB2.0各模塊耦合高,一個服務節點同時支持規則、審計,報表、接口等功能,如果一個功能點異常可能會影響整個平台服務。 於是,CMDB3.0進行了微服務架構升級,把系統接口調用、web用戶訪問,規則處理、數據處理等按功能模塊抽離成單個微服務應用,使用Dubbo框架進行微服務治理,另外3.0WEB前端是基於VUE自研的框架,改善了用戶體驗,提高了團隊開發協作能力,降低了開發風險。

智能運維繫列(十三)| 面向智能化運維的CMDB系統構建 3

圖3 CMDB演進過程

CMDB的系統設計思路:多維度確保數據的準確性

數據準確性是CMDB的生命,我們通過數據維護流程自動化、促進數據消費、數據審計等多維度保證數據的準確性,並提升使用價值,主要包括以下幾個方面:

1。建立數據生命週期管理,自動化流程驅動數據更新

CMDB2.0在建設之初,就定義了每個配置項從生產、運營、消亡的整個生命週期,並通過設計與之匹配的ITSM流程自動化驅動生命週期狀態流轉,實現了數據閉環管理。 同時,識別每個階段會影響的屬性及關係,保證配置模型的完整性。

智能運維繫列(十三)| 面向智能化運維的CMDB系統構建 4

圖4 服務器生命週期狀態變更流程

2。與多個運維工具對接,促進數據消費,提高數據流動性

結合實際運維場景,與其他運維平台聯動,數據被積極消費,在其他工具中體現CMDB信息的最大價值。 數據被廣泛應用才能保持鮮活的生命力。 如同池塘里的水,只有水不斷流動和交替,水質才能清澈。 基於靈活API服務,微眾銀行CMDB2.0已實現與ITSM、監控平台、容量平台、應用發布平台、基礎科技工具平台以及智能化運維平台等系統對接。 用一個子系統從設計態到運形態的整個生命週期為例,展示數據聯動的消費及流動過程如下。

智能運維繫列(十三)| 面向智能化運維的CMDB系統構建 5

圖5 CMDB和各運維繫統交互實現數據消費及流動

3。通過規則校驗以及人工審計確保及時發現和修復異常數據

為了保證數據準確性,通過規則校驗、系統之間的信息同步比對以及人工抽樣審核的方式的定期審計。 持續檢視和優化生命週期管理,不斷改善數據質量。 微眾銀行關鍵配置項準確率達到99%以上。

表1:CMDB自動審計規則示例

配置項 自動審計規則
服務器
  • 主機下關聯應用實例,主機狀態不是“已分配”,服務器狀態不是“已投產”
  • 主機類別是容器母機,對應服務器類別不是容器;
  • 已分配狀態主機沒有部署應用;
業務應用
  • 業務應用狀態“已上線”所屬子系統狀態不是“已上線”;
  • 子系統狀態為“已下線”,仍部署業務應用;

實施效果及未來展望

自2017年起,CMDB得到全面推廣和運作。 從這三年的運營效果來看,CMDB有效支撐了上層業務運維, 其健壯性、靈活度及準確性得到了廣泛認可,已成為運維同事信任的好夥伴。

在應用規模上看,CMDB已發展為運維同事管理和獲取配置數據的首選系統,平台對接需求應接不暇。 目前管理配置項總計226個,其中關鍵配置項通過流程維護和接口同步更新佔比72%。 同時服務行內其他運維繫統50個,提供系統接口超300個。

在服務數據化運營以及支持智能化運維方面,CMDB已成為微眾銀行自智能化運維體系體系中不可缺少的成員。

  • 驅動業務流程:CMDB為各業務流程提供高質量的配置數據,所有業務系統架構設計、資源申請、上線部署和運行維護等流程,均是通過CMDB與多個系統的協同運作來驅動落地。 當前僅ITSM系統中對接CMDB更新或查詢數據的流程已超過200個。

  • 服務數據化運營:支持服務容量規劃、成本核算、業務運營分析等場景,例如容量管理系統基於CMDB數據可提供業務整體資源利用率數據和各業務使用量數據分析報告。

  • 支持智能化運維:基於CMDB數據關係,通過監控系統端到端視圖輔助故障診斷定位、根因分析,使故障快速恢復和及時發現,已成功實現了對我行智能化監控系統這種複雜需求場景的有效支持。

智能運維繫列(十三)| 面向智能化運維的CMDB系統構建 6

圖6 CMDB數據輔助智能監控系統故障定位、根因分析

CMDB的構建仍是一個持續迭代優化過程,2020年我們基於微服務構建CMDB3.0,期望CMDB能夠通過開源平台的方式提供服務,同時實現配置項自動發現,圖像化元數據關係展示以及數據異常自動化修復等方面進一步提升。 未來CMDB的運行效果我們會繼續分享給大家,希望大家持續關注我們的演進腳步。 如果希望了解我們在智能運維中使用的機器學習算法以及支持根因分析的具體方法,請參閱該系列其他文章。

作者簡介

本文作者為微眾銀行智能運維繫統高級產品經理楊芳