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

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

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

二、非場景驅動，無法支撐業務需求。CMDB建設目的就是為了滿足業務的需要，能夠保證業務持續高效的運作，但是很多情況下大家只是把CMDB作為一個靜態的配置管理庫，未能和業務緊密關聯。

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

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

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

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

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

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

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

部署形態

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

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

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

4、自動創建運行環境，部署系統；

5、更新CMDB。

運行形態

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

2、監控工具收到指令，立刻實施監控；

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

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

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

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

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

1、服務意識

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

2、服務框架

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

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

1、建模能力

建立靈活的底層數據模型，可以隨時擴展資源，滿足不同應用場景的消費需要。

2、自動發現能力

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

3、清晰的表現能力

通過多維度、多視角，清晰明了地展示整個數據中心的架構。

4、管理粒度

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

5、容量分析能力

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

6、影響分析

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

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

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

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