雙態營運分享之：業務情境驅動的服務型CMDB

標籤：自身   個數   結束   調用   軟體   bsp   解決問題   配置   單元   

最近這幾年，國內外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