直接上答案也是一種美德

CMDB 的建設應該以**“ 市場經濟”**為主導，先讓數據野蠻生長，各自管理，組織機構在中間再通過弱監管的方式對數據進行穿針引線，再逐步抽象出配置模型，再不斷參考行業標準，持續推動不斷完善模型標準，不僅能提升數據生產率還能提生數據生產質量。

人治強壓數治

哪里有壓迫哪里就有反抗，在過往的CMDB 建設過程中大多采用一個自上而下的**“ 計劃經濟”**建設模式，經常會出現三個現象：

01

組織上的要求，把CMDB 的建設納入正常工作中，后續又增加一系列的流程進行管控，把原本應當成為標準數據輸出型CMDB 搞成了增加工作量的數據輸入型CMDB。

02

由于是統一搭建CMDB ，在建設之初必然需要調研各團隊維護數據現狀，然后參照行業標準抽象出來一個看起來能滿足短期企業發展需求的一個標準化配置模型，然后才開始收集核驗配置數據，實際上很難接地氣。

03

各專業最開始迫于組織壓力和對美好新事物的憧憬義無反顧獻出自己手中長短不一、規格不整的EXCEL希望至少能夠滿足現有數據的維護，但在一次次投入產出未達預期和缺失明確數據消費場景下，漸漸又回歸到維護原有EXCEL工作模式

我們在CMDB 建設過程中可以找到很多原因來闡述為何CMDB 沒有能被適當的使用起來，可能有組織上的壓力、現階段需求上的差異、廠商不夠專業、工具不夠友好等等，但我覺得也許我們一開始就把力使錯了地方。

在很多客戶建設中，不難發現各專業在對自身管理范圍的數據質量都存在一定的誤差，更何況我們在建設CMDB 過程中需要匯聚應用、系統、主機、網絡等各專業配置數據，這樣就導致我們在CMDB 建設之初已經失去的數據的準確性。

數治引人治

過往CMDB 建設拋除組織壓力、流程管控等維度，只從建設思路來看，也許本質就是錯的，本身CMDB 的建設應該是一個數據治理的過程，一上來就拿各種條條框框來限定人的使用習慣和數據格式，是不人道的，而真正靠譜的CMDB 建設也許應該是以數據為導向，滿足各專業眼前對數據管理渴望的需求，比如可以直接將手中EXCEL導入進行維護，那至少要滿足以下要求：

1

至少要比EXCEL更好用

如果你都不能讓各專業自給自足，憑什么讓他們為社會主義建設添磚添瓦。

2

可滿足各專業需求，有重疊數據也不會沖突

數據本身是多維度的，在應用、主機、資產管理各維度來看一臺X86 服務器的維度完全不一樣，應用看到一臺X86 服務器只關注IP 、配置，而主機的就要關注廠商型號、內存磁盤空間、物理位置等信息，而資產管理則更側重維保、合同、金額等信息，而這些數據本身也應該是分離的，但是他們卻在從不同維度描述同一個對象。

3

可以提供各專業數據自定規則關聯調和能力

不同維度數據間相互描述的標識可以是一個IP 、也可以是多個字段共同組合而成，而這個標識是數據調和能力銜接的紐帶，通過數據間的調和從而將多維數據關聯起來真正實現從業務、應用、系統、基礎設施的端到端IT 架構可視。

4

各自維護的數據可以單獨對接外圍系統的能力

在每個專業不僅能夠通過直接導入導出EXCEL對數據進行管理，還應當具備對接外部數據源的能力，讓CMDB 適配現有或未來準備建設的系統。

小結

一個開放的CMDB 工具也許能給迷霧的人們點亮一盞燈塔。今天算是開個場，很多細節只有在實踐過程中才能發現錯誤所在。