如果你在运维行业待得够久，一定见过这样的场景：企业花大价钱上了 CMDB 项目，两年后却沦为无人维护的“数据坟墓”；故障发生时，团队宁愿直接查监控、翻服务器，也不敢相信 CMDB 里的数据。
问题出在哪？我们观察了二十年，发现四个常见的原因。
痛点一：模型太死，跟不上业务变化
传统 CMDB 的模型设计往往是“一次性工程”——上线时花几个月建好模型，然后业务一变化，模型就跟不上了。物理机、虚拟机、容器、微服务……基础设施形态不断演进，僵化的模型根本无法描述真实世界的复杂度。
要让模型真正有用，它必须足够灵活。配置项类型应该支持继承和扩展，让运维团队像搭乐高一样，随业务变化随时调整，而不是每次都要等一个漫长的建模项目。无论是物理机、容器，还是复杂的微服务调用关系，都应该能在统一的模型中被精准描述，而不是散落在不同的 Excel 表里。
痛点二：拓扑靠手画，关系靠猜
很多团队在梳理应用依赖关系时，最常用的工具是白板和 Visio。画的时候看似清晰，但画完就过期——因为基础设施每天都在变。更麻烦的是，这些手工维护的拓扑图通常只有架构师能看懂，业务方完全被排除在外。
拓扑不该是少数人的特权。一个理想的设计器应该通过拖放就能完成，让技术、业务等相关方都能参与。同时，从几百个企业级实践中沉淀出的参考模型可以直接复用——应用服务映射、基础设施依赖追踪等常见场景开箱即用。即时的视觉反馈能在循环依赖、关系缺失这些问题进入生产环境之前就发现它们。
痛点三：多源数据打架，没人敢信
监控系统说有一百台主机，云管平台说有一百二十台，Excel 里又登记了九十几台。到底信哪个？多源数据录入的“脏数据”问题，是 CMDB 失信于人的头号杀手。
要让数据可信，系统必须在入库环节就解决问题。当多个来源的数据同时汇入时，应该有一套自动识别与合并规则，智能判定哪些是同一对象并自动融合属性。只有这样，数据才能保持唯一性和纯度——这也是为后续任何自动化或智能分析铺路的基础。
痛点四：查关系像查族谱，SQL 写到怀疑人生
查找“某台交换机故障影响了哪些核心服务”这种问题，在传统关系型数据库里往往要写出几十行的递归 SQL，执行一次可能要跑几分钟。关系一跳再跳，查询复杂度指数级上升。
这类查询天然应该用图查询算法来解决,专门针对多跳关系表达做优化——在遍历路径的任意节点上按属性筛选，对跨关系链的结果进行聚合。无论是找上游依赖、追踪下游影响，还是分析服务路径，性能不会随深度增加而衰减。CMDB 的查询能力，应该从简单检索进化到真正的动态分析。
那么在这个 AI 席卷一切的时代，这些问题还存在么？
上面说的这些问题——灵活建模、可视化拓扑、自动识别、图查询——本质上都在做一件事：为基础设施建立一份可靠、可理解、可查询的“数字世界模型”。
然而 AI 大模型虽然强大，但它没法凭空理解你的基础设施。它不知道你的数据库实例跑在哪台虚拟机上，不知道哪个微服务调用了哪个中间件，更不知道昨晚那次配置变更影响了什么。这些复杂的依赖关系、多维度的属性约束、动态变化的拓扑结构，如果没有准确的数据，再强大的模型也无能为力——而对真正懂运维场景的 AI 来说，这正是它应该发力的地方。
一个能理解你基础设施拓扑的 AI，可以在故障发生时直接告诉你根因在哪个节点，而不是给你一堆泛泛的排查建议。一个记住了每一次变更上下文和影响的 AI，可以在你准备再次变更时提前预警风险范围。一个能操作系统的 AI，可以从“查问题”直接到“修问题”——因为这些复杂的模型为它提供了精确的行动地图。
我们正在做的，不是给你一个聊天的窗口，而是一个能自主协同的智能运维平台：有的诊断根因，有的评估变更风险，有的自动执行修复——你要做的，只是说清楚目标。
这条路我们已经走了二十年，但真正的改变，才刚刚开始。
