资产数据准了之后能干什么：聊聊它和 CMDB 的关系
前面几篇一直在讲怎么把资产数据做准：标签、盘点、调拨、差异管理。但有个问题没展开——数据做准之后，除了财务报表好看、审计顺利通过，还能干什么？对 IT 占大头的企业来说，答案里最有价值的一条是：反哺运维体系。这篇就聊聊资产管理系统和 CMDB 的关系，以及为什么很多企业的 CMDB 建了又废、废了又建。
一、CMDB 为什么常年建不好
先说现象。不少企业的运维团队都有过类似经历：立项建 CMDB，花几个月把配置项录入进去，上线之初数据还算准，半年后就已经不敢信了——服务器早换了、虚拟机早就销毁了、配置项还是老样子。最后 CMDB 变成一个"只在审计时才打开"的库，或者干脆荒废，运维还是靠老员工的记忆和一个 Excel 文件撑着。
问题出在数据生产方式上。CMDB 的数据传统上靠人工录入和人工维护：装机时录一条，变更时改一条，报废时删一条。每一环都依赖"有人记得去做这件事"。而 IT 环境的特点恰恰是变化频繁——虚拟机按需创建按需销毁、服务器滚动升级、应用迁移部署。人工维护的节奏根本跟不上变化的速度，数据的时效性从上线第一天起就在持续衰减。
一句话总结：靠人工录入的 CMDB，数据质量取决于人的纪律；而纪律恰恰是最不可靠的东西。要打破这个循环，得换数据的生产方式——让数据在业务流程中自动产生，而不是靠事后补录。
二、资产系统手里有 CMDB 缺的东西
资产管理系统为什么能帮上忙？因为 CMDB 需要的那部分"物理世界的事实"，恰好是资产系统的主业。
CMDB 的配置项里，有一大类是硬件实体：服务器、交换机、防火墙、存储设备、笔记本。这类配置项的关键属性是"存在性"和"位置"——这台设备在不在、在哪个机房哪个机柜、归谁管。而这正是资产管理系统通过 RFID 标签和盘点流程日复一日确认的东西。资产系统里每台服务器有唯一的资产编号，绑定使用人、部门、位置、状态；每次调拨、维修、报废都有单据流转。这些数据对 CMDB 来说，就是现成的、可信的硬件配置项来源。
反过来看，很多企业 CMDB 里硬件数据不准，根源正是缺少这套流程：设备搬走了没人告诉 CMDB、设备报废了 CMDB 还留着记录、新设备上线了 CMDB 没登记。资产系统用调拨单、处置单、盘点差异管理把这些环节都管住了——上一篇讲的差异跟踪闭环，对 CMDB 同样适用。
所以两者的合理分工是：资产系统管硬件实体的全生命周期（采购、领用、调拨、维修、报废），CMDB 管逻辑视角（部署了什么应用、依赖什么组件、提供什么服务）。物理层的数据从资产系统同步过来，逻辑层的数据从部署流程里自动采集。CMDB 自己不生产物理数据，只消费。
三、同步的具体做法
资产系统到 CMDB 的数据同步，不是简单地把表倒过去，有几个工程要点。
第一个是确立唯一标识的映射。资产系统用资产编号，CMDB 用配置项编号，两边要建一张稳定的映射关系，映射一旦建立就不要轻易变更。RFID 标签的 TID 或者资产编码印在设备铭牌上，机房巡检时扫码就能确认"这个配置项对应这台物理机"，物理和逻辑从此对得上号。
第二个是同步方向要单向。硬件属性（型号、序列号、位置、责任人、状态）从资产系统单向流入 CMDB，CMDB 侧不允许反向修改这些字段——一改两边就不一致了。CMDB 里特有的字段（应用部署关系、服务依赖）由运维侧自己维护。边界清楚，责任才清楚。
第三个是同步触发时机。资产状态变化时实时推送，是最理想的方式：资产报废单走完，CMDB 里对应配置项自动标记下线；调拨单入账，配置项的位置属性自动更新。做不到实时的，至少要做到每日增量同步加状态对账——两边状态不一致的配置项生成对账差异清单，交给运维处理。对账机制比同步本身更重要，它是数据质量的兜底。
第四个是处置流程的联动。IT 设备报废时，正确的顺序是：先在 CMDB 里摘除应用部署关系（应用下线或迁移），再走资产系统的处置单（设备物理下架报废）。顺序颠倒了会出现"CMDB 里设备还在线、实际机房里已经找不到"的幽灵配置项。这个顺序要写进运维流程，不能靠个人记性。
四、盘点对 CMDB 的额外价值
资产盘点定期确认"物理世界里有什么"，这件事对 CMDB 有一个容易被低估的价值：它能发现 CMDB 的"账外配置项"。
运维侧经常有脱离 CMDB 管理的设备：测试用的临时机器、某次应急采购没走流程的服务器、上上届运维留下的说不清用途的机器。这些设备在 CMDB 里没有记录，在资产系统里也没有——因为它们往往连采购入账都不规范。资产盘点拿着读写器把机房扫一遍，扫出来的每一台设备都要么能对上资产编号，要么进入盘盈流程。盘盈的 IT 设备信息同步给运维，CMDB 就有机会把这批账外设备纳管进来。
反过来，盘点也能发现"账内但消失"的配置项——资产系统里在册、机房里扫不到的设备，如果最近没有调拨和处置记录，那要么是被搬走了没走流程，要么是真的丢了。两种情况都值得运维和资产两边一起查。这个交叉核验的机制，单靠任何一边都做不起来。
五、从数据同步到场景联动
数据同步跑稳之后，可以再往前一步，做场景联动。
比如变更管理的联动。服务器要做滚动升级，运维在 CMDB 里圈定影响范围时，如果能直接看到资产系统里的设备状态（在保、过保、即将报废），排期决策会更靠谱——没人想把升级排在马上要报废的机器上。再比如容量规划的联动：资产系统里同型号设备的采购批次和折旧到期时间，配合 CMDB 里的部署关系，能提前推算出"这批设备折旧到期前需要多少替代容量"，给预算留出提前量。
这些联动场景没有多高的技术含量，前提只有一个：两边的数据都足够准、足够新。而这正是前面十来篇一直在讲的事情——标签、盘点、调拨闭环、差异管理，一层层做扎实，最后才有资格谈联动。数据不准的时候做什么联动都是灾难：按错误的设备状态排变更计划，比没有计划还糟。
工具层面，做 IT 资产管理的系统大多提供对 CMDB 或运维平台的开放接口，首码是其中之一，各家接口形态大同小异，差别在数据模型的完整程度——硬件全生命周期的状态够不够细，决定了同步过去之后 CMDB 能直接用多少。这个环节值得在选型时重点验证。
写在最后：CMDB 建不好的病根不在工具，在数据生产方式。资产管理系统把物理层的数据生产变成了流程驱动、盘点兜底的机制，CMDB 消费这部分数据，专注管好逻辑层，两边各干各的擅长事，比让运维手工维护一切靠谱得多。下一篇我们回到盘点这个主题的最后一公里，聊聊离线盘点——仓库没信号、地下室没网络时，手持机的数据怎么同步才不出错。
