雙態運維分享之：業務場景驅動的服務型CMDB

最近這幾年，國內外CMDB失敗的案例比比皆是，成功的寥寥可數，有人質疑CMDB is dead？但各類業務場景代表，當下數據中心運維，CMDB依然是不可或缺的一部分，它承載着運維的基礎，掌握運維的命脈。

分析以往失敗的案例，靜靜的想想，失敗無非兩點：

1、CMDB自身建設能力不夠，沒法適應當下數據中心和雲環境的新形勢。當下數據中心的特色是敏捷、動態、持續發展。甚至當風暴來臨時，數據中心的環境是瞬息萬變。傳統型CMDB跟不上節奏，只能望洋興嘆，頻繁應付處理各式各樣的問題。

2、非場景驅動，沒法支撐業務需求。CMDB建設目的就是爲了知足業務的須要，可以保證業務持續高效的運做，可是不少狀況下你們只是把CMDB做爲一個靜態的配置管理庫，未能和業務緊密關聯。

若想使業務系統走上敏捷運維之路，勢必對傳統型CMDB進行一次革新，實現觀念和思路的轉變。將從一個簡單的靜態配置信息庫轉變到爲業務系統提供持續運行的能力，爲資產提供精算運營的能力，爲技術架構提供敏捷自動化的能力上來。打造一個雲計算下的由業務場景驅動的服務型CMDB。

下面，咱們經過一個常見的業務場景，從業務部門提出業務系統需求，到內部IT資源協調、上線部署、監控運行，再到平常運維，來分析如何建設CMDB，才能保證業務系統的敏捷運維。

（一）系統首先內嵌一個業務系統上線的審批流程，步驟以下：

 

一、業務部門向系統架構組提出業務系統建設的SLA（服務等級協議）要求；

二、系統架構組根據SLA的要求，分析得出最基本的架構單元；

三、運維部門根據基本架構單元進行部署實施。

（二）從系統實現上分兩種形態：部署形態和運行形態

部署形態

 

一、流程結束後，將業務系統、SLA要求、部署詳情寫入CMDB；

二、根據既定的部署流程，啓動流程（系統預先內置部署流程）；

三、匹配自動化腳本（或者調用API）；

四、自動建立運行環境，部署系統；

五、更新CMDB。

運行形態

 

 

一、監控工具從CMDB獲取策略；

二、監控工具收到指令，馬上實施監控；

三、監控工具實時反饋業務系統SLA指標給CMDB；

四、CMDB將實時反饋與原有的設定進行對比及趨勢分析，判斷運行的情況；

5~八、一旦當前運行情況不知足要求，CMDB觸發自動化流程，對運行環境實時彈性擴容。

以上能夠看出，CMDB已經轉變爲自動化，由服務驅動整個過程，讓業務系統的運維更加敏捷。所以，構建持續、高效、敏捷型的運維，服務型CMDB的建設更顯重要。

服務型CMDB建設須要從2個方面入手：

 

一、服務意識

傳統型CMDB，服務的對象是運維人員，大多被動接受一些指令。然而，雲計算下CMDB的服務對象更可能是業務策略、流程、自動化工具。由被動的模式變爲主動模式，須要主動去發現問題、解決問題。

二、服務框架

提供完整的API體系，構建圍繞上層業務的服務，充分整合外部應用，爲應用的擴展提供便捷。

若想建設健壯運行的CMDB，以上兩個切入點只是開始，紮實的基礎功能必不可少：

一、建模能力

創建靈活的底層數據模型，能夠隨時擴展資源，知足不一樣應用場景的消費須要。

二、自動發現能力

採用輪詢機制、APM抓包、API調用等方式，發現數據中心和雲環境的基礎設施、虛擬應用以及它們之間錯綜複雜的關係。

三、清晰的表現能力

經過多維度、多視角，清晰明瞭地展現整個數據中心的架構。

四、管理粒度

在基礎設施同應用模型之間創建受權管理機制，根據業務須要來肯定管理的深度和粒度。

五、容量分析能力

評估數據中心，綜合度量分析，掌控運維家底和態勢，並持續推進運維能力的改進與提高。

六、影響分析

經過影響分析功能，快速分析故障影響的範圍和程度，及時找出故障根源，保障業務高效運行。

在這個理想化的場景下，CMDB爲業務系統提供SLA服務要求，爲系統架構的建設和擴展提供驅動能力。沒有一個CMDB可以作到開箱即用，每個企業都有不同的管理角度和管理粒度。咱們只有先作好CMDB自身的服務，夯實基礎，靈活擴展，上層才能依據業務按需實施。CMDB的建設不是一蹴而就，而是由業務場景驅動、慢慢磨合，CMDB建設之路任重而道遠！

做者簡介：周振中，現任優雲軟件產品汪，運維工程獅一枚，小半條腿跨入運維的浩瀚世界，目標是成爲一隻有點逼格的產品汪，就醬。