一次有效的复盘应该产出这5样东西，缺任何一个都容易"下次还是同样的问题"：
| 序号 | 产出物 | 作用 | 跟踪方式 |
|---|---|---|---|
| 1 | 故障时间线文档 | 还原事实，避免记忆偏差 | 归档到知识库 |
| 2 | 根因分析（5Why） | 找到真正的系统性原因 | 复盘报告附件 |
| 3 | 改进Action列表 | 把"建议"变成具体任务 | 项目管理工具跟踪 |
| 4 | 监控/告警规则更新 | 让同类问题下次能被提前发现 | 监控系统验证 |
| 5 | SOP新建或更新 | 下次碰到同类问题有标准处理流程 | 知识库入库 |
大多数团队停在了第1和第2步——"分析到位但执行没跟上"。
产出物1：故障时间线文档
模板
# 故障时间线：[故障标题]
| 时间 | 事件 | 操作人 | 备注 |
|------|------|--------|------|
| 14:32 | 运维A执行配置变更（修改DB连接池参数） | 张三 | 未走变更审批 |
| 14:35 | 数据库连接池耗尽，应用开始报错 | - | 监控未触发告警 |
| 14:38 | 用户开始投诉"系统打不开" | - | 客服群收到反馈 |
| 14:41 | 值班发现告警（HTTP 5xx率飙升） | 李四 | 告警延迟6分钟 |
| 14:45 | 定位到连接池参数异常 | 李四 | 对比前一天配置发现差异 |
| 14:48 | 回滚配置，服务恢复 | 李四 | - |
| 14:52 | 确认业务完全恢复 | 李四 | 验证多个接口 |
**故障时长**：20分钟（14:32-14:52）
**影响范围**：全站用户，预估影响用户数约2000
**发现方式**：用户投诉（非监控主动发现）
关键原则
- 只记录事实，不做评价（"张三失误了"→改成"执行了配置变更"）
- 精确到分钟
- 记录"发现方式"——是监控发现的还是用户投诉发现的，差别很大
产出物2：根因分析（5Why方法）
模板
## 5Why分析
Why 1: 为什么服务中断了？
→ 数据库连接池耗尽，应用无法获取连接
Why 2: 为什么连接池会耗尽？
→ 连接池maxActive从200被改成了20
Why 3: 为什么参数被错误修改？
→ 运维在修改另一个参数时误改了这行（配置文件相邻行）
Why 4: 为什么误改没有被发现？
→ 变更没走审批流程，没有人Review配置diff
Why 5: 为什么变更没走审批？
→ 当前变更流程没有强制门禁，全靠自觉申请
## 根本原因
变更流程缺少技术门禁——没有强制在配置修改前生成diff并经过另一人确认。
## 系统性原因（超出本次事件）
- 连接池参数没有设置合理的下限保护
- 告警规则只检查连接池使用率>90%，没有检查连接池maxActive参数变化
关键原则
- 不要停在"人为失误"——人会犯错是必然的，要找到系统层面为什么没有拦住
- 至少追问到第4个Why，通常到第5个能找到系统性原因
产出物3：改进Action列表（最关键）
这是90%的复盘缺失的环节——把"改进建议"拆解成具体的、可分配的、有deadline的任务。
模板
## 改进Action列表
| 编号 | Action | 负责人 | 截止日期 | 验证方式 | 状态 |
|------|--------|--------|---------|---------|------|
| A1 | 配置变更必须生成diff并提交审批 | 张三 | 2026-05-25 | 测试环境模拟一次变更走完整流程 | 待开始 |
| A2 | 连接池参数加下限保护（min=50） | 李四 | 2026-05-22 | 尝试设置<50时系统拒绝并告警 | 待开始 |
| A3 | 新增告警：关键参数值突变检测 | 李四 | 2026-05-25 | 模拟参数变化验证告警触发 | 待开始 |
| A4 | 更新变更管理SOP（加审批环节） | 王五 | 2026-05-28 | SOP Review通过并发布 | 待开始 |
| A5 | 复盘报告归档到知识库 | 张三 | 2026-05-20 | 知识库可搜索到 | 待开始 |
关键原则
- 每个Action有且仅有1个负责人
- 每个Action有明确的截止日期
- 每个Action有"验证方式"——怎么证明这件事做完了且有效
- 不写"加强xxx"这种虚话——必须具体到"做什么+怎么验证"
用云效跟踪
在阿里云云效（Projex）里创建一个"复盘改进项"的工作项类型：
工作项类型：复盘改进Action
字段：
- 关联故障编号（必填）
- 负责人（必填）
- 截止日期（必填）
- 验证方式（必填）
- 验证结果（完成时填写）
- 状态：待开始 → 进行中 → 待验证 → 已完成
每周站会Review一次"进行中"和"逾期"的改进项。这比"写在PPT里然后遗忘"靠谱10倍。
产出物4：监控/告警规则更新
每次故障复盘至少要回答一个问题：这次如果监控/告警更好，能不能更早发现、甚至避免？
本案例的告警更新：
# 新增告警1：连接池关键参数突变检测
- alert: DBPoolConfigChanged
expr: abs(db_pool_max_active - db_pool_max_active offset 5m) > 0
for: 0m
labels:
severity: warning
annotations:
summary: "数据库连接池maxActive参数发生变化"
description: "当前值: {
{
$value }}, 请确认是否为计划内变更"
# 新增告警2：连接池参数低于安全阈值
- alert: DBPoolConfigTooLow
expr: db_pool_max_active < 50
for: 0m
labels:
severity: critical
annotations:
summary: "数据库连接池maxActive低于安全下限(50)"
description: "当前值: {
{
$value }}, 可能导致连接不足"
这两条告警如果在这次故障前就存在，14:32配置被修改的瞬间就能收到告警，而不是等到14:41用户投诉后才发现。
产出物5：SOP新建或更新
本案例需要新建/更新两篇SOP：
新建：PR-CHG-002_数据库配置参数变更标准流程
- 操作前：生成当前配置快照
- 提交diff到审批
- 审批通过后执行
- 执行后验证：连接池连通性测试
- 异常时回退方案
更新：SC-INC-001_生产环境紧急故障响应SOP
- 增加一条判断："如果故障发生在变更操作之后30分钟内，优先检查最近的变更记录"
复盘闭环的完整流程
故障发生
↓
应急处理（优先恢复）
↓
48小时内召开复盘会
↓
产出5个标准文档：
├── 时间线文档 → 归档知识库
├── 5Why分析 → 找到系统性原因
├── 改进Action列表 → 录入云效Projex跟踪
├── 监控告警规则更新 → 部署到监控系统并验证
└── SOP新建/更新 → 入库并Review
↓
每周站会Review改进项进度
↓
所有Action完成+验证通过 → 闭环
一份复盘自检清单
每次复盘结束后，用这个清单确认是否"真的闭环了"：
- [ ] 时间线文档已归档（精确到分钟、只记事实）
- [ ] 5Why分析至少追问到第4层（不止于"人为失误"）
- [ ] 改进Action每项有负责人+截止日期+验证方式
- [ ] 改进Action已录入项目管理工具（非PPT/文档）
- [ ] 至少1条新的监控/告警规则已部署并验证
- [ ] 相关SOP已新建或更新
- [ ] 复盘报告可被后续搜索到（关键词：故障类型+系统名）
- [ ] 下次站会已安排Review改进项进度
小结
复盘不是"开会+写PPT"——是一个产出驱动的闭环过程。5个产出物中：
- 时间线和5Why解决"搞清楚发生了什么"
- Action列表解决"确保改进真的执行了"
- 监控更新解决"同类问题下次能被提前发现"
- SOP更新解决"同类问题下次有标准处理方法"
缺任何一环，复盘就会变成"分析得很透彻、改进永远在路上"。用云效Projex跟踪每个Action到验证通过，比在PPT里写"已改进"靠谱得多。
