复盘是让系统更健壮的过程，需还原事实、定位根因、推动改进；包含事故信息、时间线、根因分析、改进措施四步，强调结构化、证据支撑与闭环行动。
复盘不是追责，是让系统更健壮的过程。一次有效的生产事故复盘，核心在于还原事实、定位根因、推动改进，而非归咎个人。关键是要有结构、有证据、有闭环——模板只是骨架，真正起作用的是团队对问题的诚实面对和持续行动力。
一、事故基本信息：用数据锚定事件边界
快速锁定“谁、在什么时间、影响了什么”，避免后续讨论失焦：
- 事故编号：如 PROD-20240521-001（环境-日期-序号），便于追踪和归档
- 发生时间：精确到分钟（UTC+8），注明是否跨班次；恢复时间同样记录
- 影响范围：明确服务名、接口路径、用户群体（如“订单创建接口超时，影响全部C端用户”）
- 关键指标恶化值：错误率从 0.02% → 37%，P99 延迟从 210ms → 4.8s，CPU 持续 98% 超 12 分钟
- 初步定级：按 SLA 影响时长/用户量/资损定义为 P0/P1/P2（例：P0 —— 核心支付链路中断 >5 分钟）
二、时间线还原：用日志和监控拼出真相
拒绝模糊描述（如“大概三点左右出的问题”），以可观测性数据为唯一依据：
- 按分钟粒度列出关键节点：告警触发时间、第一个 5xx 日志时间、运维介入时间、回滚执行时间、监控指标拐点时间
- 每条时间点标注来源：Prometheus 查询截图、ELK 日志截图、Zabbix 截图、Git 提交哈希（如“14:22:17，/api/v2/order/create 返回 500，trace_id=abc123，对应应用日志 ERROR 行”）
- 标出信息断点：哪一环缺乏日志？哪个组件无埋点？哪类请求未被链路追踪覆盖？——这些本身就是待改进项
三、根因分析：穿透表象，问到“为什么”第五层
用 5 Whys 或鱼骨图法深挖，直到触及可行动的底层原因：
- 现象：订单创建失败率飙升 → Why1：下游库存服务返回 503 → Why2：库存服务 Pod 全部 OOMKill → Why3：新上线的缓存预热脚本内存泄漏 → Why4：该脚本未经过压测且未配置内存 limit → Why5：CI 流水线未强制校验容器资源声明，SRE 也未在发布清单中设卡点
- 区分直接原因（缓存脚本泄漏）与系统原因（缺乏资源约束机制、缺少发布前内存验证环节）
- 避免出现“人为失误”“粗心”等无效归因，要指向流程、工具或权限设计缺陷
四、改进措施：必须可验证、有时限、有Owner
每条 Action 都要回答三个问题：做什么？谁负责？什么时候闭环？怎么证明做完？
- 短期止血（24 小时内）：回滚脚本、临时扩容内存 limit、增加库存服务熔断降级开关
- 中期加固（7 个工作日内）：在 CI 流水线中加入容器资源检查插件（Owner：DevOps 张工）；为所有预热类脚本补充内存 profile 和超时控制（Owner：后端 李组）
- 长期机制（Q3 内落地）：建立“高危操作白名单+双人确认”发布流程；将内存泄漏检测纳入安全扫描基线（Owner：SRE 团队 + InfoSec）
一次认真走完这四步的复盘，比十次口头总结更有价值。模板不重要，重要的是团队愿意暴露问题、共同担责、把教训变成下次不踩坑的护栏。
