跳到主要内容

CMDB 5 万条资产只记得一个 IP，怎么跨模型找

· 阅读需 8 分钟

现场：小赵排障卡在 20 分钟，只因一个 IP​

凌晨 1 点，小赵被叫起来处理一个 P2 告警。

告警说“10.0.1.5 节点上的服务响应超时”。他打开 CMDB，准备找一下这个 IP 是哪台机器、跑什么业务、归谁管。

CMDB 里的资产有几万条。他凭直觉选了“主机”模型，在搜索框里输入 IP，没命中。

小赵在 CMDB 搜索界面反复切换模型

他改选“数据库”模型，搜索，还是没命中。

又改选“中间件”模型，这次命中了，但他心里没底：这个 IP 是不是同时也是某台主机？是不是同时也是某个数据库的部署目标？

他又回到“主机”模型，切换到精确匹配模式，再搜一次，这次命中了。

整个过程花了 20 分钟，中间切换了 3 个模型，还调整了一次匹配方式。

最后他发现，这个 IP 同时挂在 3 个模型下：主机模型 1 条、数据库模型 1 条、中间件模型 1 条。而他第一次搜的“主机”模型下其实是有命中的，只是因为大小写不敏感没匹配上。

病根：分类被放到了搜索前面​

小赵的卡点，不是他不会用 CMDB。也不是 CMDB 录得不够。

病根在于：大多数 CMDB 的搜索设计，把“按模型分类”放到了“按关键词搜索”前面。

这种设计假设：你已经知道“这个 IP 属于哪个模型”。

在资产规模小、模型分类清晰的早期，这个假设大致成立。一个 IP 多数情况下确实只属于一个模型，凭直觉选模型就能搜到。

但当资产规模到几万条、跨服务依赖开始复杂时，这个假设经常不成立。同一个 IP 经常同时挂在多个模型上：既是一台主机（主机模型），又是某个数据库的部署目标（数据库模型），还是某个中间件的配置项所在节点（中间件模型）。

把分类当前提，会带来两个具体问题：

第一个问题：搜不到时无法判断是“真没有”还是“在别处”。 一线经常反复试多个模型浪费时间，要么干脆放弃 CMDB，重新走“问人 + 翻聊天记录”的老路。

第二个问题：跨模型的同名资产无法一次性看到。 每次只在一个模型里查，会反复漏掉另一半信息，复盘时也容易出现“为什么没查到”的口径不一致。

三层连续断点​

把这条治理链拆开看，搜索入口的顺序问题具体会卡在三层。

第一层：跨模型命中没法一次性看到​

小赵面对的问题，核心是“分类”应该属于搜索结果，而不是搜索前提。

在 5 万条资产规模的 CMDB 里，一线排障时“只记得一个 IP”是常态。先要求选模型再搜，等于让一线先完成一个判断题（“这是主机还是数据库还是中间件？”），然后才能做检索题（“这条 IP 到底存不存在？”）。

但实际情况是，这个判断题往往没有标准答案。一个 IP 可能同时是主机和数据库，这种“既是又是”在生产环境里很常见。先选模型，就直接漏掉一半。

跨模型全文检索的解决思路，是把“选模型”这一步从搜索入口里拿走，改在搜索结果里呈现。

第二层：大小写与精确匹配，默认值要照顾“记得大概拼写”的人​

真实录入数据里，大小写经常不一致，同一台机器可能被录成 WebServer、webserver、WEBSERVER 三种形式。

如果搜索默认按大小写敏感，那“记得大概拼写”的人就搜不到。系统应该默认按大小写不敏感检索，让模糊记忆也能命中。同时提供精确匹配开关，允许在确实需要严格区分的场景下切换。

小赵第一次搜“主机”模型下没命中，根本原因就是：他记的是小写 IP，而录入的资产字段是按大写形式存的。默认不区分大小写，这本来是个一行配置的事。

第三层：权限过滤与检索历史，决定“搜得到但点不开”的体验​

命中数大时，分页能力决定响应速度。但比速度更重要的是，检索结果必须严格限定在用户组织权限和实例级权限范围内。

一线看到的命中，必须是自己有权限看到的那些，而不是“看着很多但点进去全没权限”。

还有检索历史。同一个 IP、一串错误码、一个节点名，经常被不同人反复搜。保留最近检索词、一键复用，可以省掉大家反复输入的成本。历史的保存位置应该在用户本地，不进后端持久化，既给了一线便利，也不污染检索库本身。

技术洞察：把分类从判断条件变成信息呈现​

把上面三层重新归拢，CMDB 搜索入口顺序问题的核心，是一个判断条件 vs 信息呈现的设计选择。

把“按模型分类”放在搜索前面，意味着把分类当成判断条件，先做判断再检索。这种设计在一线有把握时省事，但在没把握时反而成了卡点。

把“按模型分类”放在搜索结果里，意味着把分类当成信息呈现，先检索再判断。这种设计在一线有把握时也省事（直接点开结果里的对应模型），在一线没把握时也省事（直接看分布决定深入哪里）。

搜索这件事的本质是“找到”而不是“分类”。“找到”的入口应该越简单越好；“分类”的判断应该让数据自己来呈现，而不是让一线先承担。

把几层重新串起来：理想中的 1 分钟搜索​

回到开头小赵那个场景，如果 CMDB 已经按“先查再选”的方式设计，他那一晚的 20 分钟会变成什么？

他打开 CMDB，在搜索框里输入 IP，不需要选模型。

先选模型 vs 先查再看分布：搜索入口的范式转换

系统直接返回：这个 IP 一共在 3 个模型里有命中，主机 1 条、数据库 1 条、中间件 1 条。

他先点开“主机”模型标签，看到 1 条匹配，匹配字段高亮显示。点开详情，确认这是某台生产服务器。

再看“数据库”模型标签，看到 1 条匹配，确认是某个 MySQL 的部署目标。

再看“中间件”模型标签，看到 1 条匹配，确认是某个 Kafka 节点的连接地址。

整个过程 1 分钟，不用切换模型，不用调整匹配方式，不用反复确认“是不是漏了”。

BK Lite 补的是“先查再选”这条治理链​

在 BK Lite CMDB 中，搜索功能承担的正是把“按模型分类”从搜索前提转化为搜索结果的能力。

CMDB 搜索明确支持按关键词跨模型检索资产，先返回总命中数与各模型命中数（以模型标签的形式呈现）；选择某个模型标签后，分页查看该模型的命中结果；支持精确匹配开关，默认不区分大小写，需要时切换；检索结果在左侧以列表呈现，匹配字段高亮；右侧查看选中资产详情，并可直接跳转到资产详情页；检索结果受用户组织权限与实例级权限过滤，严格按用户可见范围返回；检索历史保存在用户本地，支持一键复用或清除。

CMDB 搜索能力架构：从输入到结果呈现

这套能力补的不是“让搜索更快”，而是让“不知道资产在哪个模型下”的人也能先查再选。

已有的 CMDB 不是不能用，只是搜索的入口顺序需要从“先选模型”调整成“先查再看分布”。对几万条资产的 CMDB 来说，这个调整能让“只记得一个 IP 的人”在第一次查询里就拿到完整答案，而不是被反复要求猜测。

上手前先问几句​

如果你的 CMDB 还在“先选模型再搜”的设计，可以用下面这几条做一次自检：

  • 搜索入口是否要求先选模型？ 如果是，优先把跨模型全文检索作为默认入口
  • 大小写是否默认不敏感？ 真实录入数据里大小写经常不一致，默认值不区分才能让“记得大概拼写”的人也能搜到
  • 分页是否稳？ 命中一多就卡，会让一线直接放弃用 CMDB
  • 检索结果是否严格按用户权限过滤？ 一线不能看到自己点不开的命中
  • 检索历史是否保留？ 同一个人和不同人经常会搜同样的关键词

对几万条资产的 CMDB 来说，这几点调整能让“只记得一个 IP 的人”在第一次查询里就拿到完整答案，而不是被反复要求猜测。

这条治理链一旦补上，CMDB 就不再是“事后录入的台账”，而是排障现场真正愿意用的入口。