事后复盘

故障发生后，目标不是 追责，而是 让同类故障更难发生。Blameless Postmortem（无责复盘） 记录时间线、根因、行动项，把个人失误变成 系统改进。

学习目标

• 掌握 postmortem 文档结构
• 会用 5 Whys 追根因（止于可改的系统层）
• 把复盘结论写回 SLO 与 runbook

复盘模板

## 摘要
- 影响：tracks API 不可用 23 分钟
- 用户：约 120 次 502

## 时间线（UTC+8）
14:02  磁盘 95%，MySQL 慢查询
14:05  连接池满，backend 5xx 上升
14:18  重启 backend + 清日志恢复

## 根因
磁盘满 → binlog 无法写入 → ...

## 行动项
- [ ] 磁盘告警阈值 80%（prom-alerts）
- [ ] 日志轮转策略（7 天）
- [ ] 连接池 + 超时 review

5 Whys 示例

为何 502？          → Tomcat 线程满
为何线程满？        → 等 MySQL 连接
为何连接等？        → 连接池耗尽
为何耗尽？          → 慢查询 + 长事务
为何慢查询？        → 缺索引 + 磁盘 I/O 饱和
为何 I/O 饱和？     → 日志未轮转，磁盘满  ← 可行动根因

停在 「某人粗心」 不够；要落到 监控、自动化、架构（rel-types）。

与可观测性的关系

复盘依赖 指标 + 日志 + 时间线（prom-intro）。没有监控的故障只能猜——事后补 scrape 与告警是常见 action item。

宝塔单机常见 action

故障	典型 action
磁盘满	logrotate、告警、备份外迁
OOM	JVM 上限、swap 策略、升配
证书过期	宝塔自动续期 + 提前 14 天告警
误删数据	备份恢复演练、权限分离

文化要点

• 无责：聚焦流程与系统，不攻击个人
• 公开：团队可读的文档，新人也能学
• 可追踪：每个 action 有 owner 与 deadline

练习

• 用模板写一次「假想磁盘满」复盘（200 字）
• 对「开发误删生产表」做 5 Whys（至少 4 层）
• 列出 3 条应写入 runbook 的 CodeRoadMap 操作

小结

复盘把一次故障变成永久免疫。 下一课：综合练习。