通俗淺薄的解釋一下CMDB
從上述百度百科的定義來看，還是有些苦澀難懂的。我們從應用場景切入來理解CMDB，可能更加容易一些：
場景一：應用運維工程師從業務線/產品線的角度去，去查看某個業務線/產品線有多少個應用系統、哪些是核心的應用系統，這些應用系統是不是部署那些主機上，是否存在單點問題，資源是否合理分布等等。在一般的運維過程中，每個應用系統的信息都存在，但這些關鍵信息可能都是散亂的，比如用物理機部署的可能在某一個工具上維護，用雲主機部署的卻是在雲平台上進行維護，給整體的分析帶來了不便，使得無法從更高的業務角度來判斷和分析資源情況。
場景二：在日常的運維管理中，我們需要面臨很多的IT資源，有物理形態的，比如機房、機櫃、網絡設備、安全設備、物理服務器、SAN存儲、刀箱等等；有數字形態的，比如雲平台、雲主機、IP、操作系統、中間件、數據庫、代碼等等。其中的任何一個資源出現故障，可能都會影響到業務的穩定運行，那么我們怎么來統一管理這些IT資源、怎么來理清這些資源之間的關聯關系、它們之間又是如何相互影響的。
CMDB的提出就是要解決這些問題的，以提高運維的效率、甚至以達到智能運維的目的。從管理角度看，CMDB的核心就是對這些IT資源進行管理。為了進行有效的管理，CMDB有這些IT資源必要的屬性信息（注意不是最完整、最全面的信息），及這些IT資源之間是如何相互關聯、相互影響的關聯信息。從運維角度，可以一句話來簡單描述就是：
“CMDB知道一個IT資源的必要信息，也知道這個IT資源發生變動后，會影響到哪些IT資源及業務”
在CMDB中，還有兩個比較費腦細胞的概念就是“模型”及“關聯關系”：
- 模型：我們通過模型定義各個資源對象（可以理解為：對於這些資源對象，我們需要關注哪些信息--類似數據庫中的表有哪些字段一樣）。
- 關聯關系：定義說明這些對象之間的關聯關系，比如應用和雲主機是運行關系，某某應用運行在某某雲主機上，某某雲主機運行了某某應用。
這就是CMDB的模型之說，文章的后面我們通過實際例子來正式說明。定義好了這些模型、關聯關系后就要把這些模型實例化，類似我們往表中插入一行數據一樣，這行數據有主鍵key、各個字段屬性、各個外健等等。
下面，我們將從產品理念、產品架構、資源模型、原型設計、應用場景方面進行來說明我們如果構建一個符合多雲架構、符合“雙態運維”的輕量級CMDB產品。
產品理念和目標
產品理念：以應用場景為驅動，建立高效化、輕量化的運維數據樞紐。
產品目標：構建符合多雲架構、符合“雙態運維”的輕量級CMDB，並形成運維數據中心樞紐，該數據樞紐能夠支持多種業務場景，比如資產管理、資源可視化、運維監控、自動化運維、多雲管理等等。
產品框架規划設計
CMDB產品功能規划上，我們做了一個最簡化的組成，即由模型管理、數據中心、資源管理、采集平台、資源可視化等組成，具體如下：
CMDB 在功能架構上由如下核心內容組成：
- 模型管理：
- 模型定義：通過模型把需要管理的IT資源進行定義，描述IT資源的各種信息屬性，以便用戶能快速、清楚的了解資源情況。
- 關聯關系：預先定義各種關聯關系（比如運行、歸屬、組成、屬於、默認關聯、使用等），然后通過這些關聯關系來描述各個模型之間的相互關系，比如某某應用運行在某某主機上。
- 模型拓撲：通過拓撲圖形能夠直觀、便捷的對模型之間的關聯關系進行展現和管理。
- 資源實例數據中心：
- 創建模型：根據模型定義，創建資源模型。如果數據中心建立在Mysql上，表現為創建Table；如果數據中心建立在MongoDB上，表現為創建collection。
- 存儲數據：存儲采集平台從各個地方采集過來的數據； 存儲資源管理模塊手工錄入或者模板導入的數據。
- 資源管理
- 資源實例錄入和編輯：提供一個可視化的界面，用戶可以對資源實例的屬性、關聯關系進行增加、編輯和刪除等。
- 資源可視化
- 資源查詢，提供界面可以快速查找各種IT資源。
- 常見視圖：從應用運維工程師角度（含業務系統客戶），構建了業務視角；從雲平台運維工程師角度，構建了雲平台視角；從IDC運維工程師角度，構建了IDC視角；從存儲工程師角度，構建了存儲視角。
- 視角拓撲定義：可以從其他工作角色來自定義新的視圖。
- 采集平台
- Agent ： 通過在資源端安裝Agent ，實時或者定時采集數據。
- 自動發現：通過規則自動發現模型之間的關聯關系或補齊修改資源屬性。
- 批量導入：支持數據的大批量導入。
- API同步：提供接口，讓外部系統能夠實時把資源屬性進行更新。
- 第三方同步：比如通過ETL工具，從其他數據庫同步。
當CMDB構建好后，就可以向各種應用場景提供服務，比如資源可視化、運維監控、自動化運維、技術運營、智能運維等等。
核心流程規划設計
從業務操作流程來看其實並不復雜：
- 模型管理模塊定義好模型
- 數據中心根據定義，創建模型。
- 從過手工錄入或者自動采集實例化資源。
- 通過數據中心構建各種可視化應用，包括資源查閱、資源拓撲展現、運維大屏之類的可視化應用。
- 通過數據中心提供其他應用。
模型規划設計（核心部分）
傳統CMDB模型的缺點
在傳統CMDB項目的實施過程中，大家都是看了仿佛都是各種各樣的模型、五花八門的配置項目，然后，項目工作都落入定義各種配置項中去，筆者了解到之前的CMDB項目中也s落入這個陷阱而導致項目失敗。雖然我們看到項目過於關注模型而導致失敗，但是也從側面說明了模型的重要性。開發一套CMDB系統並不是一件困難的事，但是用好一個CMDB系統卻是一件困難的事。如何用好CMDB系統，規划設計一套可用的CMDB模型是一個關鍵。那么，我們又應該如何規划CMDB模型才能滿足我們的產品目標呢？
在如何規划設計CMDB模型前，我們先先說說傳統的CMDB模型，傳統的CMDB基本都是由國外的大廠家開發的，產品圍繞數據中心以基礎資源管理為主，模型配置項也極其繁雜，比如明細到了某個插座的型號、位置之類的，似乎要窮舉所有資源的所有屬性才擺休。傳統CMDB常常需要運維人員進行各種配置項后才能使用，即沒有一個可以開箱即用的模型，這個配置的過程基本把運維人員擋在系統門外，最后，肯定是不如Excel來得方便。另外是過分依賴人工維護，缺少自動化發現及自動采集功能，數據維護工作量巨大，系統投入產出比嚴重失調，最后也是不了了之。對於敏態運維DevOps的支持，更是無從談起。
新一代CMDB模型的出發點
為此，在規划設計CMDB模型時，我們可以如下幾點出發
- 要從業務應用角度出發，不能從IDC的資源管理出發，畢竟所以的IT資源歸根到底都是為業務服務的。
- 至少要存在一套可以開箱使用的模型，不能只是提供一個工具的平台，而把難題丟給了用戶。謹記“開發一套CMDB系統並不是一件困難的事，但是用好一個CMDB系統卻是一件困難的事”
- 模型屬性盡量精簡化，只需要必要屬性信息，而不是窮舉所有屬性信息。
- 人工維護是必要的，但是能夠系統自動化就要系統自動化，手工錄入是一個迫不得已的手段。
- 要場景應用為驅動，反推和檢驗模型。
- 模型要考慮多雲架構、考慮內外部資源
- 模型是為了管理，不能為了模型而模型，不能因為各種配置項、各種配置屬性，而把精力放在庫表的設計和管理上。
一個開箱即用的CMDB模型
如下是筆者為了滿足多雲架構及“雙態運維”初步規划的CMDB模型規划：
當然，筆者只是做一個開箱即用的簡要模型，但可以滿足80%以上的運維管理要求。
常見的關聯關系
比如，應用和雲主機是運行關系，某某應用運行於某某雲主機上，某某雲主機運行了某某應用，其中應用是源、主機是目標。
如何定義模型屬性
重復一句：“盡量精簡化，只需要必要屬性信息，而不是窮舉所有屬性信息。”
如何定義模型關聯關系
建立源與目標的概念，任何一個對象在不同關聯關系中都不同的定位。下面以雲主機為例，
- 雲主機與雲平台是歸屬關系，雲主機是源，雲平台是目標。
- 雲主機與應用是運行關系，雲主機卻是目標，應用卻是源。
如下圖：
當然，我們也可以通過拓撲方式更加直觀來管理這些關聯關系：
確定好有哪些模型，如何定義這些模型及模型之間的關聯關系，那么模型工作基本就可以告一段落了。接下來就是如何根據定義實例化這些模型。
實例化模型有些需要注意的地方
實例化數據庫的選擇
傳統的CMDB是基於關系型數據庫實現的，使得整個庫表架構極其復雜，可讀性極差，對外接口更是復雜了。新一代CMDB利用MongoDB這非結構化數據庫能夠更加適合CMDB的建模，推薦的做法是：
- 利用Mysql等關系型數據庫，存儲模型的定義。
- 利用MongoDB等NOSQL文檔存儲數據庫，以json的格式存儲資源實例。
實例和視圖分開
CMDB數據中心同時事務數據庫及數據倉庫的功能，為了能夠滿足數據實時更新的同時，也要滿足各種運維的監控及分析。因此，建議分成實例庫和視圖庫：
盡量減少人工錄入
手工錄入是一個迫不得已的手段，能夠采集就自動采集，能夠自定發現的就自動發現。
常見資源可視化視角需求
實現核心模型，即業務、應用和主機Host的關系。運維人員可以
從雲主機host 為起點向拓展雲平台、宿主機、網絡設備、存儲等。
擴展模型3，以機房為起點拓展機櫃、網絡設備、安全設備、物理主機、存儲設備、雲平台。
以雲平台為起點拓展機櫃、機房、網絡設備、存儲設備、物理主機。
通過不同的視圖可以滿足不同用戶對資源整體管控。
總結
一句話：開發一套CMDB系統並不是一件困難的事，但是用好一個CMDB系統卻是一件困難的事。
作者：老格，擅長產品規划和設計，擅長解決方案，擅長PPT制作，是一個懂技術的產品PM，會設計的售前咨詢。