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 平台只需要在上面补应用和业务关系。