发布负责人小周是在复盘会上被问住的。
接口超时发生在发布后十几分钟。监控曲线有，错误日志也有，应用到数据库的依赖关系也能查到。所有材料看起来都在指向同一个方向：连接不稳定。
直到业务接口人问了一句：“故障发生前，连接池配置是不是刚调过？”
会议室安静了几秒。
有人翻发布记录，有人翻群消息，有人登录机器看当前文件。可当前文件只能证明“现在是什么样”，不能证明“当时是什么样”。真正卡住复盘的，不是没人看日志，而是没人能拿出配置文件在故障前后的版本和差异。
复盘最怕的不是线索少，而是线索到了配置层突然断掉。
晨会前 20 分钟，运维负责人小周被问住了。
昨天下午发布后，支付回调服务抖动了十几分钟。故障已经恢复，业务侧也确认交易补偿完成，但复盘材料迟迟拼不成一张完整图。
监控同学给了接口延迟曲线。
研发同学贴了几段带请求 ID 的错误日志。
CMDB 里能查到支付回调、缓存、数据库和下游账务服务的关系。
告警列表里也有触发、认领和恢复时间。
材料看起来很全。可复盘主持人追问了一句：
“这次到底是哪个点先异常？影响范围是一个实例、一条服务链，还是整段支付链路？”
会议室安静了几秒。
不是没人有数据，而是每个人手里都只有一块碎片。小周能解释其中任意一张截图，却很难把这些截图串成一个连续现场。
这就是很多故障复盘最难受的地方：证据都在，现场不在。
晨会前二十分钟，运维负责人被追问一件事：昨天那次抖动，到底是应用自己有问题，还是底层资源刚改过？
群里已经有人甩出了几张截图。有人说数据库实例前一晚做过调整，有人说服务其实早就迁过节点，还有人坚持配置没变。CMDB 里并不是没有这批资产，相关实例、关系和负责人也都能查到，但没有人愿意直接拿那份数据下结论。
让人头疼的，不是 CMDB 里查不到对象，而是查到了以后，没人敢保证它还是当前状态。信息开始过期以后，CMDB 会从排障入口退回成参考资料。
先把现场拉近一点。主角是某金融客户的 SRE 值班同学小李。
2:40 核心交易接口 P99 从 200ms 飙到 8 秒，告警群开始刷屏。
2:41 监控把问题指向订单服务所在主机10.20.31.47，CPU 跑满，日志里全是异常。
2:42 小李打开 CMDB，搜到了这台机器。资产名、IP、机房、负责人，信息齐齐整整。
2:42 之后……真正的问题才开始。
很多团队对 CMDB 的失望，往往就发生在这一刻。它能告诉你“这是谁”，却回答不了“它牵动了谁”。