⚠️
本文是示例模板：把时间线、原因和整改项替换为你自己的内容即可。复盘的价值不在于追责，而在于让同一个坑不绊倒两次。

事故经过

某周二下午，监控系统开始报警：核心接口的错误率在 10 分钟内从 0.1% 爬到 30%。排查后发现，当天上午一次"无关紧要"的配置改动，把缓存过期时间从 300 秒误写成了 3 秒，导致下游数据库被打爆。

时间线

  • 10:42 配置变更上线（未走评审，认为"只是改个数字"）
  • 14:15 流量高峰到来，缓存穿透，数据库 CPU 打满
  • 14:24 告警触发，开始排查
  • 14:51 定位到配置变更，回滚
  • 15:03 服务恢复

根因分析

表面原因是配置写错了一个数字。但追问下去，真正的根因是流程：

  1. "小改动"可以绕过评审 —— 而事故往往恰恰来自小改动
  2. 配置没有格式校验，单位（秒/毫秒）全靠约定俗成
  3. 缺少灰度机制，配置一次性全量生效

我们改掉的三个坏习惯

1. 取消"小改动免检"的潜规则

所有变更，哪怕只改一个数字，也必须过一遍评审。评审的成本远低于事故的成本。

2. 给配置加上 Schema 校验

关键参数带上单位和取值范围校验，不合规的配置直接拒绝加载。

3. 配置变更也要灰度

先 1% 机器生效，观察 10 分钟再全量。回滚预案写在变更单里，而不是出事后现想。

写在最后

事故是昂贵的学费，复盘是为了不让学费白交。

这次之后，团队里"这只是个小改动"成了一句需要警惕的话。