對大部分中大型的企業來說，CMDB建設對於整個IT服務和IT運維管理的重要性不言而喻，但是目前仍然有非常多的企業無法建設好CMDB。

我最近剛好接觸了一個公安系統的朋友，他和我聊了關於身份管理系統。聊完，我恍然大悟，這套思想和我們企業CMDB建設的思想幾乎一摸一樣。

1

CMDB中管理的CI屬性不是越多越好

只有被大量系統消費的數據才需要放到CMDB中。

在生命周期內不容易變化的數據，我們可以理解為“靜態”配置數據。

對比身份管理系統：身份上不會把我們個人的所有屬性放上去，比如年齡就是一個狀態數據，而出生年月是一個靜態數據。

2

保障CMDB數據準確性的核心要依靠消費和流程

配置自動發現功能對於CMDB的確重要，能有助於我們配置數據的初始化和配置數據的審計，但是我們不能依賴自動發現保障數據的準確性，更不能期望所有的屬性、關聯關系都通過自動發現來實現。

配置數據的準確性需要靠消費場景，只有通過消費場景，我們才能夠及時發現配置數據的錯誤；發現了配置數據的錯誤，我們才能夠及時對配置數據進行修正；這樣就會形成一個正循環。

人員手工操作永遠是不可靠的，配置數據的準確性需要靠流程。只有靠流程和工具，才能保障配置數據的準確性。比如資源申請需要經過流程審批，資源完成交付後，工具可以將配置數據自動化註冊到CMDB中。

對比身份管理系統：身份管理系統目前並沒有線上自動化采集的功能，完全是依靠消費和流程保障數據的準確性。如你的身份不準確，你的駕照、社保系統都是無法使用的，甚至你入住酒店、乘坐高鐵都是不可以的；另外我們的國家制定了一套完整的身份管理流程，包括身份的創建、更新、過期等一整套生命周期管理流程，並且有公安局這個機構負責管理。

3

以資源為中心的CMDB演變為

以應用為中心的CMDB

無論是以資源為中心的CMDB，或是以應用為中心的CMDB，都是從業務需求的角度出發，對CI對象以不同的形式進行組織，對CI和CI的關聯關系進行管理，CI的本質並沒有變。

過去，企業的應用架構大多是單體應用架構和分層應用架構，資源和應用之間的關聯關系並不復雜，一臺物理服務器可能就承載了一個或多個應用。此時，我們采用以資源為中心的CMDB並不會給企業的運維管理帶來什麽影響。

但是，現在企業的應用架構發生了非常大的變化，分布式和微服務架構在企業中開始普及，應用和資源之間的關系變得復雜，目前更多的是一個應用對應多個虛擬機和容器的情形，並且應用關聯的虛擬機和容器經常是變化的。此時，以應用為中心的CMDB建設就變得比較迫切。

對比身份管理系統：在70年代，各省的身份管理系統是以省為單位構建的，而且沒有實現全國聯網，公安局在追蹤人員信息的時候經常只能獲取到人員的家庭信息，很難獲取到人員準確的公司信息。

到90年代後，身份實行全國聯網，公司通過身份為員工繳納社保和稅收。公安局通過身份就可以追蹤到人員的公司信息，實現更多的犯罪分析的場景。

因此，企業在建設CMDB的過程中，重心不是選擇什麽樣的CMDB工具，也不是規劃CMDB的模型及屬性。

重心是像我們的身份管理系統一樣，先定義清CMDB在IT運維管理和IT流程管理中的角色和作用，定義清楚CMDB數據管理的負責人和流程，設計的其他運營工具要能夠消費CMDB數據，這樣CMDB就容易建設成功，並且很容易發揮價值。

CMDB本身不具備價值，只有產生消費，CMDB才發揮價值！

從身份管理系統思考企業CMDB的建設