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