CMDB 为什么难做？因为它不是一张资产表

前两篇关于开源ITSM的文章发出来后，收到了很多读者的留言，其中问得最多的问题都和CMDB有关：

我们花了几百万做CMDB，换了好几个供应商，折腾了两三年，为什么还是不好用？

我见过最夸张的一个案例：某银行的CMDB系统里，光"服务器"这个配置项，就有三个不同的字段分别叫"主机名"、"机器名"、"设备名"，三个字段的值还不一样，运维人员查个信息要三个地方来回对。

90%的CMDB项目做失败，根本不是技术问题，而是认知问题：你从一开始就把CMDB当成了一张资产台账表，出发点就错了。

01

把CMDB当资产表的三大坑

1. 只记属性，不记关系

资产表的逻辑很简单：记录每个资产的属性信息，比如服务器有多少核、多大内存、在哪个机房、什么时候买的。

但CMDB的核心价值根本不是这些属性，而是关系：

- 这个服务器上跑了什么应用？

- 这个应用依赖哪些数据库和中间件？

- 这个数据库挂了会影响哪些业务服务？

- 这些业务服务对应的负责人是谁？

没有这些关系的CMDB，就是个死的花名册，故障来了你还是不知道影响范围，变更来了你还是不知道风险有多大，除了盘点的时候能数一下有多少台服务器，基本没用。

2. 追求大而全，不做场景化

很多企业做CMDB，一上来就喊口号："我们要把所有IT资产都管起来"，从服务器、网络设备、存储，到打印机、键盘鼠标甚至办公桌椅，全都要录进CMDB。

摊子铺得太大，结果就是：

- 数据录入工作量爆炸，只能靠人工补录，错误率极高

- 没有明确的使用场景，大家录完数据不知道用来干嘛，也不愿意维护

- 最后真正能用的配置项不到10%，钱花了，事没办成

CMDB不是百科全书，不需要什么都管，能解决1-2个核心业务问题的CMDB，就是好CMDB。

3. 重建设，轻运营

很多人觉得CMDB是个项目，建完就完事了。上线的时候热热闹闹，所有人都来录数据，过了半年没人维护，服务器下架了没更新，应用迁走了没同步，数据全过期了，又变成了摆设。

CMDB不是一锤子买卖，是持续运营的系统。没有自动发现机制，没有数据质量监控，没有运营激励流程，再好的技术也撑不住。

02

正确的CMDB打开方式：从"资产管理"转向"服务关系管理"

CMDB的本质不是管资产，而是管业务服务和技术资源之间的依赖关系，是IT运维的"作战地图"。

给大家四个落地建议：

1. 先找业务场景，不要先找资产

做CMDB的第一步，不是去盘点有多少台服务器，而是先回答一个问题：我们做CMDB是为了解决什么业务问题？

- 是想把故障恢复时间从4小时缩短到30分钟？

- 是想把变更故障率从20%降到5%？

- 是想把IT资产利用率提升30%？

找到1-2个最痛的核心场景，围绕场景来梳理需要的配置项和关系，不需要一开始就全覆盖。比如你要解决故障定位的问题，那你只需要先梳理"业务服务-应用-数据库-服务器"这一层关系就够了，其他的慢慢来。

2. 关系优先，属性为辅

对于每个配置项，先梳理它的上下游依赖关系，再补充必要的属性。

不需要记录服务器的所有硬件参数，只要能满足故障定位、变更评估的需求就够了，但是必须记录清楚这个服务器上跑了什么应用，依赖哪些服务，出了问题找谁。

关系对业务的价值，远大于属性的完整性。

3. 自动化优先，人工录入为辅

能自动发现的绝对不人工录，能从其他系统同步的绝对不二次录入。

- 服务器、网络设备用自动扫描发现

- 云资产直接对接云厂商API同步

- 应用、服务信息从发布系统自动同步

- 只有实在无法自动获取的信息，才考虑人工补充

从源头上把数据质量的问题解决了，后面才不会陷入"数据不准→没人用→没人维护→数据更不准"的死循环。

4. 融入现有流程，不要做独立系统

不要把CMDB做成一个孤立的系统，要把它的能力嵌入到大家日常的工作流程里：

- 变更申请时，自动分析变更影响的范围和风险

- 故障发生时，自动展示关联的服务拓扑和责任人

- 成本核算时，自动统计每个业务的资源使用情况

大家在日常工作中自然用到CMDB，也自然会去维护数据质量，形成正向循环。

03

我们的开源ITSM项目是怎么设计CMDB模块的？

正是因为看到了行业里这些痛点，我们在设计开源AI Native ITSM项目的CMDB模块时，就完全避开了传统CMDB的坑，开发完成后将具备这些核心能力：

1. 内置自动发现引擎：支持网络扫描、SSH主机发现、K8S容器发现、阿里云/腾讯云/AWS云资产同步，90%以上的配置项可以自动发现，不需要人工录入

2. 原生支持CSDM模型：按照ServiceNow通用服务数据模型设计，天然区分业务服务、技术服务、应用、基础架构等层级，关系清晰

3. 内置服务拓扑和影响分析：数据库宕机时，一键就能查到影响哪些业务服务、哪些用户、哪些关联的变更和故障历史

4. 完全开源开放：所有代码都在GitHub上，你可以根据自己的需求二次开发，也可以对接现有的IT系统

结语

CMDB难做，难的从来不是技术，而是认知。

把CMDB从资产台账变成服务关系的作战地图，它才能真正产生业务价值。

你做CMDB的时候遇到过最头疼的问题是什么？是数据质量差？还是找不到使用场景？欢迎在评论区留言.

我们的开源AI Native ITSM项目目前已经在GitHub上获得了30+ Star，已经完成了工单管理、AI智能分诊、RAG知识库、工作流引擎等核心功能开发，支持Docker一键部署体验；CMDB模块正在快速迭代中，欢迎感兴趣的朋友到GitHub了解、提Issue、一起共建。

项目地址：https://github.com/heidsoft/itsm

官网：https://cloudmesh.top

我正在做一个开源 ITSM 项目，目标是对标 ServiceNow，构建面向国内企业的 AI Native ITSM 平台。

方向包括：ITIL v3、CMDB、流程引擎、连接器市场、插件市场、Skill 市场、企业 AI 自动化。