CMDB是運維的基礎核心系統，所有的元數據和共享數據管理源,類似於業務中的賬號平台的作用。本篇文章，我將從概念篇、模型篇、到實現與實施篇具體的進行闡述。
CMDB也稱配置管理，配置管理一直被認為是 ITIL 服務管理的核心，因為其他所有流程均需要使用配置管理數據庫 (CMDB)。在上篇的平台體系中，CMDB位於最底層的支持系統位置上，可見其作用。配置管理為什么起到核心的作用，這個地方不做逐一介紹，簡單舉個例子，比如說變更系統發起了一個部署請求，要部署某個版本到現網，部署完成之后，上層的變更系統會把變更的結果寫到CMDB中，對配置進行歸檔；在某個機器down機，此時可以快速的知道該機器的具體用途，確定影響的業務；當機器需要重新恢復的時候，可以快速的根據CMDB中的信息進行恢復。
一、概念篇
1、配置管理和配置文件管理。
ITIL所講的配置管理是從軟件工程管理角度出發的，把一切對象都當做配置，比如說源代碼、文檔、人員、服務器甚至硬盤和內存等等。所以說他和業務程序的配置管理有着本質的不同，為了有效區分，我們又習慣說業務程序的配置管理叫配置文件管理。但又有着一定的聯系，在ITIL中，業務程序的配置可能會以一個配置項存在，附屬在應用程序上，具體什么是配置項后面再解釋。
2、配置管理和資產管理
既然把一切資源對象都當做配置來看待，特別是服務器、機房、機櫃等等，那他和我們的資產管理又有着什么樣的不同呢？其實這兩個系統的區別在很多時候大家都不是很清楚，會混為一談。具體的區別我之前做過一個總結，如下：
在上圖中，你把握核心的區別點就是導向，配置管理是面向業務管理，而非成本，這個會決定配置管理的粒度。當前如果業務非常簡單，不需要對服務器端口進行管理，此時則不需要考慮納入端口的管理，否則增加管理的代價。
3、配置項
配置項是指要在配置管理控制下的資產、人力、服務組件或者其他邏輯資源。從整個服務或系統來說，包括硬件、軟件、文檔、支持人員到單獨軟件模塊或硬件組件（CPU、內存、SSD、硬盤等等）。配置項需要有整個生命周期（狀態）的管理和追溯（日志）。對配置項的分類，我一般從邏輯資源和物理資源兩個角度來分解，然后層次化分解，這個思路會讓你特別清晰，不會混亂。
4、屬性
一個配置項就是一個對象，有對象便有屬性，屬性是一個配置項的具體描述。比如說服務器這個配置項，他的具體描述有在哪個機房、哪個機櫃的哪個位置、現在是否有業務運行、具體誰負責等等。在后面的模型篇里會對屬性做全面的梳理，完成現實世界到模型世界的轉換。另外配置項和屬性可以轉換，比如說IP地址，他肯定是一個資源對象存在。但是從服務器的角度來說，它作為一個屬性存在，更准確的說是網卡的屬性。
二、模型篇
我為什么把模型單獨提取出來，因為它是CMDB建設的核心，缺少對業務的准確理解，則沒法准確的提取配置項及其屬性。在這個環節中，模型的核心職責，就是把配置項和屬性逐條的梳理出來。本人在模型整理的時候，重點做了四個方面工作，然后形成規范手冊。
1、配置管理系統的角色
可以簡單分成幾類角色，第一、應用運維，負責服務器上的業務信息維護；第二、基礎運維，負責機房、機櫃及其服務器物理信息的准確性；第三、配置管理員，負責基礎信息的維護，比如說業務分類，人員信息；第四、查詢類角色，比如研發。CMDB是核心的資源信息管理系統，一般不輕易開放權限。
2、配置項識別與定義
這是重點工作，沒有簡單的方法可循，細致活，基於上圖的【配置項】的物理資源和邏輯資源的不斷分解，根據業務需要最終識別出要管理的配置項。然后對每一個配置項進行整理，確定要管理的屬性。形成類似的下表：
就拿最核心的服務器資源來說，會形成如下表的信息整理：
逐個進行整理，在上表中有幾個方面需要注意：
第一、每個配置項目確定了維護角色，他在后續的過程中，需要對這個准確性負責，確定維護的職責邊界。
第二、要整理出配置項的關聯，比如說上表中的所屬機房、所屬機櫃。
第三、這個表不是數據庫的設計表，具體數據庫的設計表是開發人員根據這個模型參考實現。
3、基於場景的配置管理規范
配置管理的核心目的是為了確保配置信息集中管理，並且是准確的管理。在這個里面需要做兩個核心的工作。
第一、配置項的規范化管理；
第二、面向配置項的流程規范化管理，沒有一套與之匹配的配置流程，最后配置管理都會混亂不堪，這個系統也就形同虛設。
此時沒有捷徑，識別配置管理的場景，把每個流程清晰的畫出來，比如說服務器管理，它就涉及到服務器上架、服務器搬遷、服務器下線、服務器申請、服務器回收等流程。比如拿服務器回收流程來說，流程圖如下：
注意上圖中，在服務器回收的過程中，行是角色，列是階段，在每個階段，服務器的狀態可能發生變化，此時也需要做備注。方便后續開發人員在做相應的流程實現的時候，控制這類狀態。狀態的轉換對監控也有影響。
4、狀態變遷圖
用一張圖來說明資源狀態的變化，便於更好的基於場景和變更來控制配置項狀態的變更，其實也就是它的生命周期管理。舉例如下：
這些方法都是以前面向對象設計里面的內容，我覺得在CMDB配置管理工作中，有很大的作用，在一張紙上，你就可以看到狀態如何變化，然后是哪個場景促使變化，這些場景最終就會轉換成CMDB的某個功能或者某個流程。
三、實現篇
系統實現非常簡單，簡單理解就是一個配置的信息管理+流程管理，一個開發熟手，一個月就可以開發完成。難點還是在配置項識別，一定要做足功夫，把配置項的屬性、流程、狀態都整理清楚，最后按照這個來系統實現就OK了。不過在系統建設中，有一個經驗大家可以參考：CMDB一定要變成運維和運維研發的共同項目，並且具體的配置項管理人要全程參與，比如說需求討論、測試、上線驗收等等（運維研發項目都可以遵循該模式）。像上面的配置項最好能找一個對全局了解的人來做，不一定是研發。
四、實施篇
其實CMDB真的是非常簡單的系統，至少在兩家公司做的CMDB都是非常短的時間完成，最多兩個月。但是其實施的過程很多經驗可以分享。
1、導致CMDB失敗的因素
A、缺少管理層承諾----沒有管理層的承諾，CMDB不可能成功。
B、在復雜流程上消耗太多的時間---我們是創建一個CMDB庫，不是一個流程系統。
C、沒有創建相應的工作指導文檔---指導如何管理和維護CMDB。
D、沒有指定配置項負責人----確保配置項有人專職維護。
E、目標過大，涵蓋太多的功能----比如說IT采購和預算管理等等。
F、顆粒度不合適----配置合理的CMDB的配置項層次和粒度非常重要。
G、存在組織隔閡----CMDB是一個集成體系，靠流程中的每一個人通力協作，而不是某個人。
2、導致CMDB成功的因素
A、業務導向。比如說我們在CMDB的新的系統中實時加入QR碼技術，為了降低資產盤點的工作量。
B、能自動發現就自動發現，降低配置管理的成本，但自動發現的信息不能用來做告警。
C、配置項的管理員必須全程參與，需求定型、測試及驗收等等。
D、CMDB系統建設完成之后，其他系統必須和他聯動。比如說監控、質量、容量等等，用場景驅動配置項的管理。
E、流程一定要平台化，不要讓流程脫離CMDB存在，比如說搞一個OA流程，這個是很致命的。
F、CMDB要持續演進，特別是雲端資源的管理。
G、配置項和流程必須要文檔化，后期要進行CMDB培訓。