after-action-report

事后复盘报告

针对发布、事故或已完成的项目开展结构化复盘。产出可执行的经验教训，而不只是一份文档。

此技能用于事后分析。若要处理正在发生的事故，请使用 incident-response。若要规划发布，请使用 launch-runbook。

---

适用场景

• 任何事故发生后（不论严重程度）
• 每次重大发布后
• 项目结束时（迭代复盘、季度复盘、项目收尾）
• 某个反复出现的问题已多次发生，需要深入调查时
• 某项决策未奏效，团队希望从中吸取经验时

不适用场景

• 事故仍在处理中（请使用 incident-response）
• 发布前规划（请使用 launch-runbook）
• 不值得进行全面分析的一次性错误修复

---

所需输入

• 要分析的事件（事故、发布、项目）
• 根据日志、聊天记录和工单还原的时间线
• 参与者对所见所做的描述
• 结果和影响（用户和业务实际受到的影响）

---

框架：无责分析

最重要的原则是无责。缺少这一原则，复盘就会导致信息被隐瞒，产出流于形式的教训，而非真正有用的经验。

无责的含义

• 关注系统，而非个人
• 假设每个人在当时掌握的信息下都做出了合理的决定
• 问题应是“为什么做出这个决定是合理的？”，而不是“谁搞砸了？”
• 修复系统，意味着让下一个处于相同情境的人能够成功，而不是重蹈覆辙

无责不代表

• 不问责（行动项仍需明确负责人）
• 不讲真话（有时系统的问题显而易见）
• 不设标准（有些失败模式是个人问题，而非系统性问题）
• 不感到不适（真正的反思会让人不舒服）

---

框架：6 个部分

完整的 AAR 涵盖六个部分。

1. 总结

用 2 到 3 段概述，说明：

• 发生了什么
• 造成了什么影响（用户、业务、时间）
• 根本原因（用通俗语言说明）
• 主要行动项

管理层会阅读这一部分。只读这一部分的人也应能了解最重要的信息。

2. 时间线

还原事件时间线。

对于事故：

• T-0：发现
• T+X：确认
• T+Y：评估严重程度，指派 IC
• T+Z：开始调查
• ……缓解、沟通和解决等事件
• T+N：宣布解决

对于发布：

• 发布前的决策和里程碑
• 发布当天的事件
• 发布后的监控观察结果

对于项目：

• 重要里程碑、决策和方向调整
• 包括计划内和临时出现的事项

时间线是事实依据。对于事件经过的分歧，应以时间线为准。

3. 根本原因分析

用通俗语言说明原因。

使用以下一种或两种方法：

五个为什么。 从表面症状入手，问“为什么？”，重复 5 次（或直到找到真正的根本原因）。每个“为什么”都应得出实质性答案，而非同义反复。

示例：

• 为什么网站宕机了？数据库连接池耗尽。
• 为什么连接池耗尽？后台任务打开了过多连接。
• 为什么后台任务打开了过多连接？发生错误时，连接清理代码没有运行。
• 为什么发生错误时清理代码没有运行？最初的代码评审没有涵盖错误处理路径。
• 为什么评审没有涵盖错误处理路径？我们的评审流程没有错误处理检查清单。

第五个为什么通常能揭示系统层面的改进措施。在此例中，应改进评审流程。

因果链。 多个促成因素共同作用。

• 因素 1：后台任务打开了过多连接（技术）
• 因素 2：连接数上限设得过低，无法满足实际流量（配置）
• 因素 3：连接池饱和时没有告警（监控）
• 因素 4：近期流量翻倍，但未进行基础设施容量评估（流程）

单一修复措施无法解决这起事故。需要关注多个缺口。

4. 促成因素

这些因素并未导致事件发生，但加剧了事件影响，或移除了本可及时发现问题的安全网。

• 监控缺口
• 文档缺口
• 流程缺口
• 工具缺口
• 知识缺口

这类因素可以用“如果……就能更早发现”来描述。

5. 做得好的地方

真正的经验教训不仅要记录失败，也要记录成功。

• 哪些检测机制发挥了作用？
• 哪些响应措施发挥了作用？
• 哪些决策是正确的？
• 哪些工具或流程表现符合预期？

这不是安慰，而是校准。应当巩固并复制在此次事件中发挥作用的做法。

6. 行动项

具体明确，指定负责人，并设定日期。

行动	负责人	截止日期	类型
在连接池饱和时添加告警	[name]	[date]	监控
在 PR 模板中添加错误处理检查清单	[name]	[date]	流程
审查其他后台任务是否存在类似问题	[name]	[date]	代码

行动项标准：

• 具体。“改进监控”不具备可执行性。“在连接池饱和时添加告警，阈值设为 80%，并通知值班人员”才具备可执行性。
• **指定负责人。**写明姓名，而不是“团队”。
• **设定日期。**填写具体日期，而不是“尽快”。
• **明确工作量。**大致估算所需的小时、天或周。
• **可以完成并关闭。**明确完成标准。

未能在承诺期限内完成的行动项，应在下一次 AAR 中重新提出。行动项反复未能关闭，说明存在更深层的组织问题。

---

工作流

1. 安排 AAR

在事件发生后的 1 到 2 周内进行。留出足够时间，让情绪平复、事实收集完整；同时也要及时，趁记忆还清晰时进行。

对于事故：在响应流程中预先安排。 对于发布：在运行手册中安排。 对于项目：在项目收尾时安排。

2. 收集资料

会议前准备：

• 重建的时间线（如果有人做了记录，通常可使用记录员的笔记）
• 日志、聊天记录、工单、事故更新
• 每位参与者的个人陈述（会前以书面形式提交）
• 影响数据（受影响的用户、持续时间、收入影响等）

3. 召开会议

典型议程（60 到 90 分钟）：

• 阅读拟定的摘要（5 分钟）
• 一起梳理时间线。补充更正内容，解决分歧。（20 到 30 分钟）
• 讨论根本原因。使用五个为什么或因果链分析。（15 到 20 分钟）
• 讨论促成因素。（10 分钟）
• 讨论做得好的地方。（10 分钟）
• 确定行动项及其负责人和日期。（10 分钟）

由一名主持人负责会议。事故复盘通常由 IC 主持，项目复盘通常由项目负责人主持。主持人不能兼任记录员。

4. 撰写文档

在会议后的几天内完成。完整的 AAR 应包含全部 6 个部分。

5. 分发

内部：发布到指定位置，确保可以搜索，并在入职培训中引用。

对于高严重级别事故：可以发布对外摘要（状态页、客户邮件、公开博客）。

6. 跟踪行动项

每个行动项都应跟踪至关闭。下一次 AAR 应重新提出尚未关闭的行动项。

---

失败模式

• **跳过“小型”事故的 AAR。**容易错过问题模式。
• **指名批评、羞辱他人。**人们担心被指责时，真正的经验教训就会被掩盖。
• **行动项过于笼统。**写“改进测试”，而不是明确具体的测试改动。
• **行动项始终未关闭。**记录在案后便被遗忘，同样的事故再次发生。
• **走过场式复盘。**按部就班地进行，却没有真正反思。
• **跳过“做得好的地方”。**无法校准哪些做法正在奏效。
• 把责任推给外部。“我们的供应商出了问题。”好，那么我们针对供应商风险采取了什么系统性措施？
• **由单人完成 AAR。**一个人写完整份文档，遗漏其他视角。
• **只有失败时才做 AAR。**成功的发布也值得复盘，成功经验同样有价值。
• **拖延太久。**记忆会淡去，对话热度也会降低。应在 2 周内完成。

---

输出格式

Markdown 文档，文件名为 aar-[date]-[event-name].md。

结构：

# AAR: [Event name]

**Date of event:** [YYYY-MM-DD]
**AAR date:** [YYYY-MM-DD]
**Severity / scope:** [SEV-1 / Major launch / Project closeout]
**Facilitator:** [Name]
**Participants:** [Names]

## Summary
[2 to 3 paragraphs]

## Impact
- Users affected: [number, segment]
- Duration: [time]
- Revenue / business impact: [if applicable]

## Timeline
[Timestamped events]

## Root cause analysis
[Five whys or causal chain]

## Contributing factors
[List]

## What went well
[List]

## Action items
| Action | Owner | Due | Type | Status |
|---|---|---|---|---|
| | | | | |

## Lessons
[Reflections that don't fit elsewhere. Often the most quotable section.]

---

如果所需数据不可用

此技能的输出依赖于它无法自行生成的数据、测量结果或工具结果。当所需输入、工具或数据源不可用或无法核实时，合规的输出应是交付内容，并说明缺口：需要什么、实际获取或核实了什么，以及输出中哪些部分受到影响。为完成交付内容而捏造、估算或插值所需数值，绝不合规。说明缺口本身就是完整的答复。

---

参考文件

• references/aar-template.md - 可填写的 AAR 模板，涵盖事故、发布和项目。