Postmortem Recovery Playbook：复盘之后如何把恢复动作固化下来

为什么需要一份 postmortem recovery playbook

故障复盘（postmortem）结束后，团队通常会产出一份原因分析和改进项列表。但问题在于：列表贴在 Wiki 里，几个月后没人记得。等到下一次事故发生时，还是手忙脚乱地翻聊天记录、问同事“上次怎么恢复的”。

Postmortem recovery playbook 就是把复盘里可重复的恢复动作抽取出来，格式化为任何人（包括值班新人）都能照着执行的步骤手册。它不代替根因分析，而是解决“恢复慢”的问题——Google 的 SRE 实践表明，有 playbook 的服务，MTTR（平均恢复时间）能降低 50% 以上。

但很多人写 playbook 时掉进一个坑：把复盘报告全文抄进去，没有提取真正可执行的步骤。结果 playbook 变成另一份文档，没人读，没人用。

复盘输入：哪些内容值得沉淀为恢复动作

不是所有复盘结论都能成为 playbook。只有满足以下条件的动作才值得写入：

可验证：执行后能立即看到效果（比如重启服务、切换流量、回滚版本）。
有确定性：多人在同样条件下执行，结果一致。
有边界：明确了触发条件（比如“当 P99 延迟超过 500ms 持续 3 分钟”）。

举个例子：复盘发现“数据库连接池耗尽导致请求排队”，根因是代码中未关闭连接。这个根因本身是修复任务，留给开发迭代。但恢复动作可以是：“当连接池使用率 > 90% 持续 2 分钟，自动扩容连接池上限到 200，同时触发告警通知 DBA 介入。”这个动作就可以写进 playbook。

常见失败场景是团队把“加强代码审查”“增加单元测试覆盖率”这种长期改进项也当成恢复动作。这些很重要，但不是 playbook 的内容——它们属于改进 backlog。

笔记本上记录的事故复盘要点和恢复动作列表，箭头标注关键步骤与责任人。

恢复动作沉淀：如何从复盘报告转化为步骤

提取恢复动作时，我推荐用“操作流”方式来组织，而不是列表。比如：

笔记本上记录的事故复盘要点和恢复动作列表，箭头标注关键步骤与责任人。

步骤 1：确认影响范围
  - 登录 Grafana 查看全局错误率面板
  - 如果错误率 > 5%，转步骤 2；否则继续监控 10 分钟
步骤 2：执行回滚
  - 切换到上一次稳定版本标签（v2.3.1）
  - 确认部署后错误率下降至 < 1%
  - 如果回滚失败（如版本冲突），转步骤 3
步骤 3：切换流量到冷备集群
  - 修改 DNS 记录指向备用集群 IP
  - 等待 TTL 过期后验证可用性

重点在于：写清楚判断条件和备选路径。很多团队只写了“执行回滚”，但回滚本身可能失败，没有 fallback 计划就会卡住。

另一个容易失败的地方是：步骤中缺少“负责人”。比如“重启服务”这个动作，谁有权限操作？值班 SRE 还是开发工程师？在 playbook 里明确“由 on-call 工程师发起，需要安全审计授权”可以减少推诿。

告警与负责人：当 playbook 和监控联动

Playbook 不能孤立存在，它必须与告警体系绑定。做法是：在 playbook 头部标明触发此 playbook 的告警规则。例如：

告警名称：HighErrorRate
告警条件：服务错误率 > 2% 持续 5 分钟
负责人（Role）：On-Call SRE（主）, 后端服务负责人（备）
切换条件：On-Call SRE 10 分钟内未响应，自动升级给后端负责人

写清楚负责人和升级条件，是为了避免“等着确认”导致的延迟。一个真实案例：某团队 playbook 写了“联系 DBA”，但未注明值班 DBA 是谁，结果等了 20 分钟电话才打通。改进后，在 playbook 里直接写上“企业微信机器人 @DBA 值班组”，并且嵌入 5 分钟未回复自动拨打电话的规则。

除了人，还要写清楚工具入口。比如“执行回滚”这个动作，不能只写“使用 CI/CD 平台”，而要具体到“登录 Jenkins（地址：xxx）选择‘Rollback to Last Stable’参数化构建”。

下次演练：如何让 playbook 不变成僵尸文档

Playbook 最大的敌人是不被使用。定期演练是唯一的解决方案。

演练的频率取决于服务的重要性和变更频率。我的建议是：

核心支付服务：每月演练一次
常规 API 服务：每季度一次
内部工具：每半年一次

演练不一定是全流量压测，可以是 tabletop 演练——团队成员围着一张 playbook，口头走一遍步骤，发现遗漏或不明确的地方。

失败场景：很多团队演练只是“读一遍”，没有模拟异常条件。更有效的做法是：在演练中故意制造 playbook 里没写到的故障点（比如告警通道本身断开、回滚版本号写错），观察实践者是否知道如何绕过。

每次演练后，必须更新 playbook 版本号，并在团队群里公示改动。版本管理可以用 Git，每次提交记录写明“本次演练发现某步骤缺少判断条件，已补充”。

常见误区与边界

Playbook 越详细越好？ 不是。超过 20 步的 playbook 在执行时容易丢失注意力。建议控制在 10 步以内，必要时拆分为子 playbook（如“回滚子流程”、“扩容子流程”）。
Playbook 一旦写好就不改了？ 不可能。每次重大事故复盘后，以及每季度演练后，必须修订。
Playbook 只适用大团队？ 小团队同样需要。单人值班时，playbook 是防止遗忘的保单。

场景案例：一次支付超时恢复过程的 playbook 化

假设一次复盘结论：支付下单接口因 Redis 热 key 导致缓存雪崩，恢复动作是手动清除热 key 并限流。

提取后的 playbook 片段：

告警条件：支付下单接口 P99 延迟 > 3s
步骤：
1. 登录 Redis-cli，执行 `MEMORY USAGE payment:hot_order` 确认热 key 内存占用
2. 如果占用 > 100 MB，执行 `DEL payment:hot_order` 清除缓存（注意：会短暂增加 DB 压力）
3. 同步在网关层对 /payment/order 接口限流 50%（跳转 Nginx 限流配置页）
4. 观察 2 分钟，如果 P99 恢复 < 1s，结束；否则转步骤 5（回滚版本）
责任人：On-Call SRE

这个 playbook 避免了“先联系开发确认”的环节，值班人即可执行。