技能提升网服务在 10:42 恢复，事故频道里却有三种“开始时间”：第一条客户反馈、第一条监控告警，以及工程师确认影响的时间。部署系统、监控和聊天工具各自记录了局部事实，如果直接按消息顺序写复盘，很容易把最早被看到的现象当成根因。
恢复之后先保护证据
保存相关时间窗内的告警、指标、日志、部署、配置、功能开关、工单和状态更新。记录每个来源采用的时区、时间精度和是否可能延迟。不要为了让时间线整齐而修改原始时间戳，必要时增加一列统一换算时间。
敏感日志应按最小范围处理，遮盖令牌、个人数据和客户内容。若日志有留存期限，先由有权限的人完成归档；AI 只使用复盘所需片段。
时间线中的每一行都要区分事实与解释
incident-response 覆盖事故分级、状态沟通、缓解记录和无责复盘，输出中包括影响、时间线、根因、五个为什么以及带负责人和截止日的行动项。
时间线建议包含发生时间、被发现时间、来源、事件、当时已知信息、采取动作和结果。10:05 发布并不自动意味着发布造成故障；它只是需要验证的相关事件。没有证据支持的推断应单列为假设。
先还原状态变化，再讨论谁做了什么
从用户影响开始倒推：什么时候错误率上升，什么时候核心功能不可用，什么时候开始缓解，什么时候恢复，什么时候确认稳定。对每个转折点寻找可观测证据，而不是只依赖参与者回忆。
工程师的操作要写清目的和结果，例如“回滚版本后五分钟错误率下降”，而不是“某人执行了错误发布”。无责不等于不追责任边界，而是把注意力放在系统为什么允许单点决定造成大范围影响。
症状、触发、根因和促成因素要分开
错误率升高是症状，某次配置变更可能是触发，缺少校验与安全默认值可能是根因，告警阈值过宽和回滚步骤不清则是促成因素。把“人为失误”写成根因通常意味着分析还没有结束。
可以使用五个为什么，但不要为了凑到第五层强行得出一个结论。复杂事故可能有多条因果链，应说明哪些已经证实、哪些仍需实验或代码分析。
行动项必须能够关闭
“加强测试”“提高意识”“完善监控”都无法验收。行动项应包含具体变更、负责人、优先级、截止日和验证方式，例如为配置增加模式校验，并在测试环境证明非法值会阻止发布。
还要区分立即缓解、永久修复和检测改进。只增加告警可能缩短发现时间，却没有减少发生概率；只修复这一行代码也可能没有处理同类变更路径。
对外说明与内部复盘使用不同信息层级
对外更新保持事实、影响、当前状态和下一次更新时间，不暴露未经确认的根因或敏感架构。内部复盘可以记录更详细证据，但仍应限制访问，并由事故负责人审核发布。
什么时候算真正结束
复盘文档完成不代表事故关闭。应确认行动项进入可跟踪系统，负责人接受，截止日期合理，修复上线后验证有效，并在一段时间后回查是否降低同类告警。
AI 可以把分散记录排序、识别矛盾和生成复盘骨架，但不能替团队决定因果关系。可执行复盘的标准是：任何重要结论都能回到证据，任何改进都能由下一次验证证明是否完成。
