事故复盘/事后分析文档写作：在故障…

当故障已解决或到达稳定节点，需要把事件频道、告警日志或战情室讨论整理成一份面向未来读者的无责复盘文档时使用。

适用场景

解决思路

1. 先满足前置要求：遵循 technical-writing 技能的硬性规则、真实性规则与风格规范。
2. 明确受众是「一年后遇到类似问题的工程师」，而非当时在场的人；核心原则是：事实来自证据，原因来自机制，教训来自两者，且不出现人名。
3. 把文档归类为历史记录：一旦评审通过即不可变，后续更正以带日期的附录形式追加。
4. 在事故已解决、或长时间事故到达稳定里程碑时启动；用户可见缺陷与险兆事件（评审漏掉但被某道防线拦住的）同样值得写复盘。
5. 不要在事故仍在进行时写复盘——那时由 runbook 主导；不要用它追责；也不要把它当作给干系人的状态汇报（那是 report）。
6. 按骨架撰写：标题为「[系统]：[以症状表述的故障，一行]」，并附元信息表：Incident date（YYYY-MM-DD）、Duration（从检测到解决）、Severity（按组织分类法，并在使用处定义）、Status（Draft / Reviewed）。
7. 写 Summary：包含带数字的用户可见影响、一句话根因、当前状态；让只读到这里的人也能知道发生了什么。
8. 写 Impact：量化的受影响对象与范围（失败请求数、受影响记录、金钱或时间损失）；估算要标注为估算；只有在确实核查过时才能写「无数据丢失证据」，并说明核查了什么。
9. 写 Timeline：带时间戳的条目，只写事实，每条都能追溯到证据（告警、日志行、提交、消息）；时间戳取自系统而非记忆，若只能靠记忆则明确说明；解读一律放在后续章节，绝不放在时间线里。
10. 写 Root cause and contributing factors：机制要基于代码与提交；贡献因素以列表呈现；「每个组件都正确、缺陷存在于它们之间」是合法的根因；指明哪一层检查漏掉了、哪一层抓住了。
11. 写 Wrong turns during the response：记录错误的第一版修复、被误导的信号、浪费了一小时的假设。
12. 写 Action items：每条都有负责人和验收检查，作为 tracker issue 提交并链接；禁止出现没有负责人的「调查 X」。
13. 写 Sign-off：每个评审事件一行，格式为「- YYYY-MM-DD <reviewer>: approved <scope>」。
14. 无责意味着结构性：点名角色、关卡、依赖、缺失的防线，绝不点名个人；归咎个人只能得出「更小心点」，归咎结构才能产出行动项；此原则约束叙述部分（时间线、原因、响应），而行动项负责人是任务分配而非追责——文档里是角色，链接的 tracker issue 里是个人。
15. 时间线是证据而非叙事：每条都追溯到可核查之物，时间戳来自系统而非记忆；若记忆是唯一来源，要说明。
16. 错误的修复也是内容：把当时看似合理却没奏效的修复连同其看似合理的推理一并写入；尴尬不是保留策略。
17. 严重级别取自组织分类法并在使用处定义，不得臆测；若不存在分类法，就把该字段明确留空，而不是自创一个。
18. 行动项遵循 writing-issues：结果、负责人、验收检查，提交并链接，绝不作为散文式意图留在复盘里；若你所在位置无法提交，把每条标为 `[to file: <who files it>]`，在链接存在之前复盘保持 Draft 状态。
19. 评审通过后不可变：新发现以带日期的附录追加；重写复盘等于伪造记录；评审本身写入 sign-off 行（参见核心技能的 references/truth.md）。
20. 险兆事件使用同一骨架，Impact 描述「本会发生什么」，并标注为反事实假设。
21. 复盘之后常随之而来的决策（新不变量、策略变更）通过 recording-decisions 记录并链接，而不是内嵌在复盘里；事故暴露出的 runbook 更新通过 writing-runbooks 与修复同批完成——文档是「完成」的一部分，不是后续工单。

适用边界 · 注意事项

• 事故仍在进行中时不要写复盘，此时由 runbook 主导。
• 不要用于追责或问责：需要靠人名才能讲通的复盘，说明它描述的是流程漏洞。
• 不要用于给干系人的状态更新，那是 report 而非复盘。