配置文件被改过没人知道，故障复盘就少了一段关键证据
发布负责人小周是在复盘会上被问住的。
接口超时发生在发布后十几分钟。监控曲线有，错误日志也有，应用到数据库的依赖关系也能查到。所有材料看起来都在指向同一个方向：连接不稳定。
直到业务接口人问了一句：“故障发生前，连接池配置是不是刚调过？”
会议室安静了几秒。
有人翻发布记录，有人翻群消息，有人登录机器看当前文件。可当前文件只能证明“现在是什么样”，不能证明“当时是什么样”。真正卡住复盘的，不是没人看日志，而是没人能拿出配置文件在故障前后的版本和差异。
复盘最怕的不是线索少，而是线索到了配置层突然断掉。
病根：运行状态没有留痕
很多团队对 CMDB 的第一印象，是资产台账。
主机属于哪个组织，数据库关联哪个应用，中间件实例挂在哪条链路上。这些信息很重要，它们帮助团队回答“对象是谁”和“对象之间怎么连”。
但小周眼下缺的不是对象关系。他已经知道异常接口依赖哪套数据库，也知道请求失败发生在哪个时间窗口。
他缺的是另一种证据：这个对象在故障发生时，到底按什么配置运行。
配置文件处在一个容易被忽略的位置。它不像监控指标那样天然进入大屏，也不像错误日志那样在故障时被第一时间搜索。可连接地址、超时时间、缓存开关、启动参数这些细节，往往直接影响系统运行状态。
配置变化不一定是根因。但如果它没有版本、没有差异、没有操作上下文，复盘就只能退回口头确认。
第一层：当前文件不能代表当时状态
复盘会后，小周先登录机器看配置文件。
文件还在，内容也能打开。但这一步很快遇到第一个问题：当前文件只能说明“现在加载的内容可能是什么”，不能说明故障发生前后是否发生过变化。
如果有人在故障后为了恢复服务临时改过配置，当前文件甚至可能已经不是故障现场的状态。
这就是配置文件复盘里最常见的断点：能看到文件，不等于能看到版本。
BK Lite CMDB 把配置文件放到资产详情中查看，面向主机、中间件、数据库等受支持模型，展示配置文件路径和版本历史。这样排查顺序会更稳：
- 先定位具体资产
- 再查看该资产有哪些配置文件
- 再确认故障前后是否出现新的配置版本
这一步不负责替团队下根因结论。它先把“当时是不是这样”从记忆问题变成证据问题。
第二层：有版本还要能看差异
小周找到了两个版本，但复盘还没有结束。
配置文件经常不是大段变化，而是小到很容易被忽略的一行。连接地址改了一个域名，超时时间从一个值变成另一个值，缓存开关被关掉，启动参数少了一段，都会改变运行行为。
如果只能分别打开两个版本人工比对，复盘仍然很慢。
BK Lite CMDB 支持查看配置文件版本内容，也支持两个版本的差异对比。差异对比的价值，不是告诉你“这行就是根因”，而是把问题从一整份文件压缩到几个具体变化点。
这时复盘讨论会发生变化。
它不再是“有没有人记得昨天改没改”，而是“这个时间窗口里确实多了一个版本，差异集中在连接池参数和目标地址上，是否与接口超时对应”。
证据越具体，判断越少靠感觉。
第三层：文件差异还要接上操作上下文
看到差异以后，小周又遇到下一个问题。
谁在什么时候做了这次变化？它属于例行调整、故障恢复，还是自动采集带来的记录更新？同一时间段资产实例是否还有其他变更？
只看文件内容，回答不了这些问题。
BK Lite CMDB 的资产详情可以展示实例变更记录，支持按变更类型、变更场景、操作人、时间范围筛选。CMDB 操作日志则记录模型与资产相关操作，并保留操作类型、变更场景、操作人与前后数据快照。
这两类信息补的是上下文。
| 复盘问题 | 需要看的证据 |
|---|---|
| 故障前后有没有配置变化 | 配置文件版本历史 |
| 具体变了哪些内容 | 两个版本的差异对比 |
| 变化发生在什么时间段 | 实例变更记录 |
| 谁做过相关操作 | 操作日志中的操作人与快照 |
到这里，小周终于能把配置文件从“疑似线索”放回一条可追溯链路里。
这张链路图不是为了把配置变化直接归因到故障，而是说明复盘进入配置层以后，证据会分成两条路：有版本和差异，讨论就能继续往下追；只有当前文件，判断很容易停在回忆和口头确认。
第四层：关键变化不能只靠事后发现
复盘可以补证据，但关键配置变化最好不要每次都等到复盘时才第一次被看见。
有些主机配置本身就处在高风险位置，比如数据库连接、网关转发、采集器参数、核心中间件启动项。它们不一定每天变化，但一旦变化，就应该尽快进入相关人的视野。
BK Lite CMDB 的数据订阅支持配置文件变更触发，但这里有清晰边界：配置文件变更触发仅对主机模型生效，基于检测窗口内新采集成功的配置文件版本判定；通知按实例去重，避免同一实例后续版本反复刷屏。
这条能力适合用来盯关键主机配置，而不是把所有模型、所有配置都推成通知。
真正需要设计的是规则边界：哪些实例值得订阅，通知给谁，是否启用，是否按组织和职责范围管理。边界设计不好，配置变化感知也会变成噪声。
技术洞察：配置不是附件，而是运行证据
配置文件在复盘里的价值，可以拆成三层：
- 可回看：能回到具体资产，看到配置文件路径和版本历史
- 可比较：能对比两个版本，确认变化集中在哪里
- 可追溯：能结合实例变更记录和操作日志，还原变化上下文
这三层缺一层，复盘都会变形。
只有当前文件，没有版本，团队无法确认当时状态。
只有版本，没有差异，团队仍然要人工翻全文。
只有差异，没有操作上下文，团队很难判断变化处在哪个场景里。
把证据链放回资产视角
理想的复盘路径，不是大家在多个系统和聊天记录里来回找证据。
它应该先回到资产对象：
- 通过资产关系确认异常对象和上下游。
- 在资产详情里查看配置文件路径和版本历史。
- 对比故障前后的配置文件版本差异。
- 结合实例变更记录和操作日志确认操作上下文。
- 对关键主机配置建立订阅，让高价值变化更早进入视野。
BK Lite CMDB 的配置文件、变更记录、操作日志和数据订阅，分别接住的是这条链路里的不同断点。
它不替团队直接判断根因，也不承诺把配置变化自动解释成事故原因。它更重要的作用，是让配置文件不再散落在机器、脚本和群消息里，而是回到资产详情下，成为可查看、可比较、可追溯的运行证据。
小周后来在复盘结论里没有写“配置变化就是根因”。
他写的是另一句更稳的话：故障时间窗口内，目标资产出现过配置新版本，差异集中在连接参数；该变化已与对应变更记录和操作日志核对，后续关键主机配置纳入订阅范围。
这才是配置文件在复盘里真正该承担的角色。
它不替人下判断，但它让判断有证据。