事故复盘方法论

本文目录导读：

1. 核心理念：三个“不”
2. 事故复盘五步法
3. 常见误区与最佳实践
4. 总结一句话

事故复盘（也称为事后剖析，Postmortem）是运维、SRE（站点可靠性工程）和软件开发中非常重要的一环，它不是为了追责，而是为了从失败中学习，改进系统和流程。

以下是一套系统化、可落地的事故复盘方法论，涵盖了从“响应”到“改进”的全流程。

核心理念：三个“不”

1. 不追责：复盘的首要目标是找出系统和流程的缺陷，而不是惩罚个人，一旦追责，人就会隐瞒或扭曲信息，导致无法找到根因。
2. 不假设：不要预设是某个人的错，通过事实和数据说话，还原时间线。
3. 不停止：改进不是一次性的，需要持续跟踪改进措施的有效性，形成闭环。

事故复盘五步法

第一步：快速响应与止血 (Blameless Action)

在开始深入复盘之前,必须确保事故已经彻底解决，业务恢复正常。

• 立即止损：回滚、限流、降级、重启、切流。
• 保留现场：保存所有日志、监控数据、进程状态、配置快照。
• 初步通报：通过邮件或即时通讯工具通知相关团队，告知事故已处理。

第二步：收集数据与还原时间线 (Data Collection & Timeline)

这个阶段的目标是客观、完整地记录发生了什么。

• 主要数据源：
  • 监控系统：CPU、内存、磁盘IO、网络流量、请求延迟、错误率、SLA指标。
  • 日志系统：应用日志、系统日志、审计日志、DB慢查询日志。
  • 变更记录：最近一周/24小时内的代码发布、配置更改、数据库变更、基础设施变更。
  • 告警记录：谁收到了告警？何时收到？告警是否被正确处理？
  • 事件时间线：

    创建一张表格,每一行代表一个关键事件：时间（精确到秒）、事件描述、操作人、影响范围。

第三步：根因分析 (Root Cause Analysis)

这是最核心的一步,使用“五问法” 或 鱼骨图，层层递进，找到问题的真正根源。

• 技术根因：某行代码的bug、数据库连接池耗尽、Kubernetes HPA配置错误、第三方依赖服务宕机。
• 流程根因：代码评审漏过了风险、灰度发布策略缺失、变更审批流过于简单、监控告警阈值设置不当。
• 认知根因：架构师对流量预估不足、运维人员对配置项理解错误、沟通不畅导致信息不对称。

示例： 为什么服务A挂掉了？

1. (直接原因) 数据库连接数打满。
2. (为什么？) 服务A代码中有一条SQL未加索引，导致全表扫描。
3. (为什么未加索引？) 该SQL是新版本功能引入，代码评审未发现。
4. (为什么代码评审没发现？) 评审清单中没有检查SQL性能的步骤。
5. (根本原因) 缺少SQL性能评审流程。

第四步：制定改进措施 (Action Items)

根因找到了,需要转化为具体、可执行、可验证的行动计划，改进项要分类：

• 立即止损类：需要马上修复，防止同类事故再次发生。（如：加索引、回滚代码）
• 系统加固类：提升系统韧性和容错能力。（如：实现熔断降级、增加自动扩缩容、添加缓存）
• 流程优化类：改进开发、测试、运维流程。（如：完善代码评审清单、增加变更审批节点、建立灰度发布规范）
• 监控告警类：增强可观测性。（如：增加关键指标的告警、创建仪表盘、细化告警级别）
• 文档与培训类：沉淀知识，提升团队能力。（如：编写事故复盘报告、组织相关技术分享）

第五步：复盘会议与报告 (Postmortem Meeting & Report)

• 会议原则：基于时间线，描述事实，讨论改进，不指责个人。
• 参与人：所有相关团队（开发、测试、运维、产品经理），以及更高层级的管理者（如CTO）。
• 复盘报告模板：一份优秀的报告通常包含以下内容：
  • 事故概要：一句话描述事故影响、根因和解决方案。
  • 影响范围：影响了多少用户、多少业务、持续时间多长？是否导致数据丢失？
  • 时间线：从触发到恢复的详细时间轴。
  • 根因分析：清晰说明技术、流程、认知上的根本原因。
  • 经验教训：这次事故带来了哪些启示？
  • 改进措施清单：每一项措施的Owner、DDL（截止日期）、优先级。
  • 后续行动：如何验证改进效果？（如：进行混沌工程、压力测试）

常见误区与最佳实践

总结一句话

事故复盘不是为了惩罚做错事的人，而是为了让系统变得更好，让团队变得更聪明。

下一次当你的团队遇到事故时,试着按这个流程走一遍，你会发现，团队不仅没有变弱，反而比以前更强大、更值得信赖。