很多故障复盘并不是缺少数据，而是缺少统一的分析现场。监控、日志、CMDB、告警系统各自都有信息，但这些信息如果没有被放到同一条判断链里，复盘时就会变成手工拼图。
问题不在“有没有数据”，而在“能不能对齐”
一次故障发生后，监控系统能提供指标曲线，日志系统能提供错误堆栈和请求 ID，CMDB 能提供资产和依赖关系，告警系统能提供触发与恢复时间线。
这些数据单看都成立，但复盘需要回答的是组合问题：
- 异常最早在哪个时间点出现？
- 影响范围是单实例、单服务还是链路级扩散？
- 日志证据能否和资产关系对应起来？
- 处置慢，是因为判断链断了，还是责任边界没拆清？
如果每个问题都要切到不同系统里查，复盘效率就会明显下降。
临时文档不是稳定的复盘入口
常见做法是把监控截图、日志片段、架构图都贴进一个复盘文档。这个办法能解决一次汇报，却很难变成可复用能力。
截图无法保留完整查询语义，过滤条件容易丢，数据来源和访问权限也缺少统一维护。过一段时间再回看，很难确认当时的时间范围、对象范围和查询条件是否还能复现。
所以复盘要沉淀的不是“材料包”，而是可复用的分析资产。
仪表盘负责对齐时间和指标
BK Lite 运营分析把 CMDB、监控、告警、日志及业务接口等数据源纳入同一分析空间。对于复盘里的指标观察，仪表盘是比较适合的承载方式。
它支持折线图、柱状图、饼图、单值图，也支持全局时间选择器和公共过滤条件。这样多个组件可以在同一时间口径下联动刷新，避免每张图都用不同时间范围。
比如复盘接口超时时，可以把服务状态、告警趋势、资源数量、业务指标放在同一页里比较，而不是只看某台机器的 CPU 曲线。
拓扑图负责表达影响范围
故障复盘里另一个关键问题是影响范围。只看指标数值，很难说明问题是局部波动还是链路级影响。
运营分析的拓扑图支持图标节点、文本节点、单值节点、图表节点和连线，可以表达对象关系、依赖链路和节点状态。单值节点和图表节点还可以绑定数据源，让结构图不只是静态示意，而是能带上关键状态。
架构图则更适合表达静态资源结构，比如变更前后架构、跨云资源分布、系统分层说明。对于需要长期维护的复盘视角，架构图比临时画图更稳定。
数据源和目录也要纳入治理
分析页面一旦沉淀，就要考虑可维护性。运营分析通过目录树统一管理目录、仪表盘、拓扑图、架构图，支持按业务域、专题或职责范围组织内容。
数据源管理负责定义 REST API 路径、参数模板、图表类型、数据源标签和团队归属。命名空间管理负责维护连接信息，支持 TLS 开关、密码加密存储和启停管理。这样复盘页的数据来源和可见边界不会只靠口头约定。
更稳的复盘链路
更稳的做法是：先用仪表盘把关键指标按统一时间轴对齐，再用拓扑图表达影响范围，用架构图沉淀长期结构，最后通过目录和数据源治理保证页面可复用、可维护。
这不是把复盘自动化成一个结论，而是把复盘前的证据组织方式标准化。只有证据站到同一张图里，复盘才更容易从“材料整理”回到“问题分析”。
🚀 欢迎体验平台能力
🌐 官网：https://www.bklite.ai/
🧪 Demo：http://bklite.canway.net/
