编写生产事故响应手册：在服务中断…

当需要为服务故障、数据库异常等场景编写结构化事故响应手册（runbook），或让值班工程师在凌晨3点也能按步骤恢复时使用。

适用场景

解决思路

1. 按严重级别分级：SEV1（完全宕机、数据丢失，15分钟响应）、SEV2（重大降级，30分钟）、SEV3（轻微影响，2小时）、SEV4（极小影响，下一工作日）。
2. 按固定结构组织手册：1. 概述与影响 2. 检测与告警 3. 初步分诊 4. 缓解步骤 5. 根因调查 6. 解决流程 7. 验证与回滚 8. 沟通模板 9. 升级矩阵。
3. 保持手册更新：每次事故后复盘并更新。
4. 定期测试手册：通过 game days、混沌工程演练验证。
5. 始终包含回滚步骤，保留逃生通道。
6. 记录前提假设：说明步骤生效所需满足的条件。
7. 链接到仪表盘，便于高压下快速访问。
8. 不要假设读者有背景知识，按凌晨3点的大脑状态来写。
9. 不要跳过验证，每步都要确认已生效。
10. 不要忘记沟通，持续通知相关方。
11. 不要独自处理，尽早升级。
12. 不要跳过事后复盘，从每次事故中学习。
13. 为每条命令添加前置检查与失败应对说明，例如 kubectl get pods -n payments 需注明 kubectl 已配置、kubeconfig 指向正确集群，失败时执行 aws eks update-kubeconfig --name prod-cluster --region us-east-1，并说明预期输出为 Running 状态。
14. 在手册顶部添加编号清单，与章节号对应，便于值班工程师在压力下按序勾选进度（如：声明严重级别并开战情室、检查服务健康、检查近期部署、可疑则回滚、在 #payments-incidents 发布初始通知、超过15分钟未解决则升级）。
15. 在手册顶部标注 Last Verified 日期与 Owner，并添加 CI 检查验证所有 curl 端点和 kubectl context 名称仍有效。
16. 指定专职事故沟通人（与事故指挥官分离），只负责发布状态更新。
17. 在沟通模板中加入固定议程：每15分钟更新一次（即使无新信息），包含当前状态（Investigating/Mitigating/Monitoring）、影响（什么坏了、谁受影响、流量百分比）、当前正在做什么、下次更新时间。
18. 对破坏性 SQL 命令添加显式警告，并要求先执行 dry-run 检查输出，例如先 SELECT count(*) FROM pg_stat_activity WHERE state = 'idle' AND query_start < now() - interval '10 minutes' 确认数量合理（< 50）后再执行 pg_terminate_backend。
19. 事故解决后使用 postmortem-writing 模板记录根因与预防措施。
20. 使用 on-call-handoff-patterns 结构化交接班，让接班者掌握活跃事故的完整上下文。

适用边界 · 注意事项

• 尚未发生或未规划事故响应流程的团队无需使用。
• 没有明确服务边界和告警系统的场景下，手册难以落地。
• 仅需一次性临时排查、不打算长期维护文档时不必套用完整模板。