CMDB 維運平台怎麼建：模型、採集與資料準確性

CMDB 維運平台怎麼建，順序比工具重要：先列出誰要用 CMDB 的資料、用來做什麼，按這些場景圈定首期範圍；再設計模型，給每個欄位指定權威來源和維護人；能自動發現的資料全部自動採集，人工只補錄機器讀不到的資訊；然後把監控和工單接上，讓每一次變更都必須經過 CMDB；最後按月考核資料的完整率、準確率和及時率。CMDB 專案失敗，很少是因為軟體選錯了，更常見的情況是上線時資料很準，半年後與現場越來越偏離，大家不再信它，也就沒人維護了。CMDB 的基本概念（配置項、關係模型）這裡不再展開，下面按建設順序講每一步的具體做法。

先定消費場景：CMDB 2.0 和 1.0 差在哪

CMDB 裡每一個欄位都應該有人用。動手建模前，先把“誰從 CMDB 拿什麼”列成表：

誰用	從 CMDB 拿什麼	依賴的配置項和欄位	資料錯了會怎樣
監控告警	監控物件清單、負責人、機櫃和連接埠、客戶	伺服器、IP、交換器連接埠、客戶	漏監控，告警發錯人
變更評審	影響範圍	上聯、連線、依賴關係	影響漏評，誤斷業務
工單派單	位置、負責人、維保狀態	機櫃、U 位、維保到期日	工程師跑錯機櫃
自動化裝機與配置	BMC 位址、MAC、IP、VLAN、交換器連接埠	伺服器、網路卡、連接埠、IP 段	裝錯機器、配錯連接埠
計費與對帳	客戶名下的伺服器、IP、連接埠	客戶、伺服器、IP、連接埠	漏收或多收
審計與盤點	序列號、位置、狀態	伺服器、部件	帳實不符

首期挑兩三個最痛的場景，只建這些場景需要的配置項和欄位。沒有消費方的欄位，即使“以後可能有用”，也先不建，因為沒人用的欄位一定沒人維護。

社群裡常說的“CMDB 2.0”，指的就是這種以消費為導向的建法。它不是某個標準，只是一種和傳統做法相對的說法：

對比	常說的 CMDB 1.0	常說的 CMDB 2.0
定位	資產台帳，記錄有什麼	維運資料底座，給監控、自動化、工單提供資料
模型	固定欄位，改模型要改程式碼	模型可配置，配置項型別、欄位、關係按需增加
資料來源	人工錄入、表格匯入	自動發現為主，人工補錄，變更流程驅動更新
視角	以裝置為中心	能從業務、服務一路追到裝置
對外方式	頁面查詢	API 和變更事件，其他系統按需讀取或訂閱

模型設計：每個欄位都要有來源和維護人

模型可以按四層組織：物理層（機房、機櫃、裝置、部件）、網路層（連接埠、VLAN、IP）、資源層（虛擬機器、容器、儲存卷）、業務層（應用、服務、客戶）。首期一般只做前兩層。

模型設計裡最容易被忽略的，是給每個欄位定下“從哪來、誰負責、何時更新、怎麼校驗”。以伺服器為例：

欄位	來源	權威源	維護人	更新時機	校驗規則
整機序列號（唯一鍵）	自動	帶外採集	系統	每次採集	非空；排除“To be filled by O.E.M.”、全 0 這類佔位值
CPU、記憶體、硬碟	自動	帶內採集	系統	裝機、回收、換件後	與上次採集比對，變化時生成核實單
機櫃與 U 位	人工	現場	機房組	上下架工單	U 位不重疊，不超出機櫃高度
交換器連接埠	自動	LLDP 或 MAC 位址表	系統	每天	一個伺服器網口只對應一個交換器連接埠
業務 IP	自動加人工	IP 位址管理	網路組	開通、回收	位址必須落在已登記的 IP 段內
客戶與到期時間	同步	訂單或財務系統	系統	訂單變化時	不允許在 CMDB 裡手改
狀態	流程	工單	系統	工單流轉	只能按狀態機流轉，不能隨意改
負責人	人工	部門負責人	各組組長	人員變動	必須是在職帳號

建模時還要定三件事：

1. 唯一鍵怎麼取：物理裝置用整機序列號；白牌機常見序列號為空或是佔位值，改用資產編號加 BMC 的 MAC；虛擬機器用平台分配的 UUID；IP 用“位址 + 所屬網路”，因為不同內網的私有位址會重複；連接埠用“裝置 + 連接埠名”。
2. 關係的數量約束：伺服器網口與交換器連接埠是一對一，伺服器與機櫃是多對一，應用與伺服器是多對多。約束寫進模型，錄錯時系統能直接攔下。
3. 控制欄位數量：首期每類配置項的必填欄位控制在十個左右，新增欄位要說明消費方和維護人，經評審再加。

自動發現和人工錄入怎麼分工

原則是：機器能讀到的，一律自動採集；人工只補錄機器讀不到的業務資訊。各類資料的分工：

資料	自動發現手段	需要人工的部分
伺服器硬體配置	帶內採集指令碼；BMC 的 IPMI FRU 或 Redfish	無
伺服器接在哪個交換器連接埠	LLDP 鄰居；交換器 MAC 位址表	裝置不發 LLDP、MAC 表又無法區分時
IP 與 MAC 的對應	閘道器的 ARP 表；IP 位址管理系統	無
交換器型號、序列號、連接埠	SNMP 讀 ENTITY-MIB、IF-MIB	無
虛擬機器	虛擬化平台 API	業務歸屬
機櫃與 U 位	無法可靠地自動獲取	上下架時錄入，掃碼確認
客戶、合同、業務歸屬	從訂單或財務系統同步	內部系統的負責人

網路連線關係是自動發現裡最有價值、也最常被漏掉的一塊。伺服器側裝上 lldpd，就能看到每塊網路卡接在哪台交換器的哪個連接埠：

# 伺服器上安裝並啟動 lldpd 後，檢視每塊網路卡對端的交換器名和連接埠
lldpcli show neighbors summary

部分網路卡（例如 Intel X710 系列）的韌體會自己處理 LLDP 報文，系統裡的 lldpd 收不到，需要按網路卡文件關閉韌體 LLDP，例如 i40e 驅動的 ethtool --set-priv-flags <網路卡名> disable-fw-lldp on。

從交換器側批次採集，用 SNMP 讀 LLDP-MIB 和 ENTITY-MIB（團體名不要寫在指令碼明文裡）：

COMM=$(cat /etc/cmdb/snmp_community)   # 許可權設為 600 的檔案
SW=10.0.0.11
# 本端連接埠（lldpLocPortId）；索引是本端連接埠號，值多為連接埠名，也可能是 MAC，取決於廠商
snmpwalk -v2c -c "$COMM" -On "$SW" 1.0.8802.1.1.2.1.3.7.1.3
# 對端裝置名（lldpRemSysName）；索引的中間一段是本端連接埠號
snmpwalk -v2c -c "$COMM" -On "$SW" 1.0.8802.1.1.2.1.4.1.1.9
# 對端連接埠（lldpRemPortId）
snmpwalk -v2c -c "$COMM" -On "$SW" 1.0.8802.1.1.2.1.4.1.1.7
# 交換器及板卡序列號（entPhysicalSerialNum）
snmpwalk -v2c -c "$COMM" -On "$SW" 1.3.6.1.2.1.47.1.1.1.1.11

自動採集的結果和已有資料對不上時，按規則處理，而不是直接覆蓋：

情況	判定	處理
採集到了，CMDB 裡沒有	未登記裝置	生成待入庫單，查清是哪張工單、誰上的架
CMDB 裡有，連續多天採集不到（例如 7 天）	疑似下架或失聯	生成核實單；確認下架的走下架流程，不直接刪除
採集類欄位不一致	以採集為準	自動更新並保留歷史；記憶體減少、硬碟變少這類變化同時通知負責人
人工欄位與採集推斷衝突	例如登記在 A03 機櫃，LLDP 顯示接在 B05 的交換器上	生成核實單，現場確認後再改
唯一鍵衝突	兩台機器同一序列號，或序列號是佔位值	人工處理，改用資產編號作唯一鍵

核實單要有人清。積壓的核實單越多，說明資料和現場的偏差越大。

和監控、工單聯動：讓資料被用起來

監控從 CMDB 取物件

監控物件清單從 CMDB 生成，而不是在監控系統裡另外維護一份。以 Prometheus 為例，定時從 CMDB 匯出檔案服務發現所需的 JSON，CMDB 裡的機櫃、客戶、負責組直接變成指標標籤：

[
  {
    "targets": ["10.1.20.31:9100"],
    "labels": {"ci_id": "SRV-0231", "rack": "A03", "customer": "C1024", "team": "ops-a"}
  }
]

Prometheus 側在 file_sd_configs 裡指向這些檔案即可，檔案內容變化後 Prometheus 會自動重新載入目標列表，不需要重啟。匯出任務先寫臨時檔案、再改名替換正式檔案，避免 Prometheus 讀到寫了一半的檔案。

這樣告警裡自帶機櫃和客戶，Alertmanager 可以按 team 標籤把告警發給對應的小組。用 Zabbix 的，可以透過 API 按 CMDB 批次建立主機、主機組並填寫資產欄位。反過來，監控裡能看到、CMDB 裡卻沒有的主機，就是一條“未登記裝置”線索。

工單驅動 CMDB 變化

工單型別	CMDB 動作	關單前校驗
上架	新建或更新伺服器，填機櫃、U 位，狀態改為已上架	採集到的序列號與工單一致
下架、回收	狀態改為空閒或待報廢，釋放 IP 和連接埠	IP 已回收，連接埠已關閉
換件	更新部件關係，記錄舊件去向	重新採集後的配置與工單一致
網路變更	更新連接埠、VLAN、IP	LLDP 或 MAC 表的採集結果與變更後一致
故障	不改資料，自動帶出位置、上聯、客戶、負責人	—

關鍵在最後一列：工單必須關聯配置項，關單時系統用採集結果自動校驗，CMDB 沒更新或與現場不符，工單關不掉。這一條比任何考核都管用。

資料準確率怎麼考核

指標	演算法	取數方式	目標（例子）
完整率	必填欄位非空數 ÷ 必填欄位總數	系統自動統計	例如 ≥ 99%
準確率	抽樣核對一致的配置項數 ÷ 抽樣數	每月現場抽查	例如 ≥ 98%
及時率	規定時間內完成更新的變更工單數 ÷ 變更工單總數	工單與 CMDB 修改時間對比	例如 24 小時內 ≥ 95%
自動化率	由自動採集維護的欄位數 ÷ 全部欄位數	模型統計	逐季提高
核實單積壓	超過 7 天未處理的核實單數	核實佇列	例如為 0
消費方報錯	告警、工單中反饋“資料有誤”的次數	報錯入口	逐月下降

準確率不能只靠系統自己算。自動採集和人工資料互相一致，不代表與現場一致，比如 U 位登記錯了，系統裡沒有任何資料能發現。做法是每月按機櫃隨機抽樣到現場核對，每台核五項：序列號、機櫃與 U 位、交換器連接埠、IP、負責人。假設抽 60 台、3 台有誤，準確率 95%，再逐條追原因：是哪個欄位、漏在哪個流程環節、誰負責。

指標要落到人。每類配置項指定一個維護組，組的準確率和核實單積壓納入考核；月度資料品質報告發給各組負責人，連續不達標的，先查流程漏洞，而不是隻要求補錄。

CMDB 失敗的常見原因

原因	表現	對策
沒有消費方	建完只有審計時才開啟	先接監控或工單，讓資料每天被用到
模型一次求全	每類配置項幾十個欄位，大半空著	首期只建必填欄位，按需擴充套件
靠人工錄入	上線時準確，半年後大量過期	能採集的欄位全部自動化
變更繞過系統	現場先改，事後補錄或者不補	工單關單校驗，未更新不能關單
沒有維護人	錯了沒人改，核實單越積越多	每類配置項指定維護組並納入考核
多個資料來源打架	資產系統、IP 表、監控各有一份	每個欄位只認一個權威源，其他系統唯讀
專案制交付	驗收後團隊解散，無人運營	設專人運營，按月出資料品質報告

歸結起來是同一件事：CMDB 是一個需要持續運營的資料產品，不是一次性交付的軟體專案。

自建、開源還是用現成系統

路線	例子	適合	要投入的工作
自研	基於自有維運平台開發	有研發團隊、流程特殊	模型、採集、介面、許可權都要自己做和維護
開源	藍鯨配置平台、iTop、CMDBuild；偏網路和機房的 NetBox	想快速起步、願意二次開發	部署維運、採集指令碼和流程整合要自己補
商業 ITSM 套件	套件內建的 CMDB 模組	已經在用該套件做工單和變更	許可費用，採集能力視產品而定
用 DCIM 承擔物理層	機房管理系統	IDC、以物理機和機櫃為主的環境	應用層和業務關係按需另建

對 IDC 來說，物理層和網路層的資料量最大、變化最頻繁，也最適合交給專門的系統。Toplink DCIM 按“資料中心 → 機櫃 → U 位 → 裝置”組織資源，向伺服器下發採集指令碼自動獲取 CPU、記憶體、硬碟並保留歷史，人工錄入值與實測值同時保留、差異一眼可見（見機櫃與資產管理）；IP 位址管理登記每個位址分給了哪台伺服器、每個段屬於哪個 VLAN；伺服器列表裡能直接看到每台機器接在哪台交換器的哪個連接埠；系統還自帶工單管理。這一層用 DCIM 維護，CMDB 平台只需要在上面補應用和業務關係。