我第一次感受到“复盘写完了，但方法没留下来”，是在一次缓存批量过期事故之后。

那份复盘其实写得很完整：

• 时间线清楚
• 影响范围清楚
• 根因清楚
• 回滚动作清楚
• 改进项也列了十几条

可两周后碰到另一场不一样的慢链事故，值班群里还是回到了原点：

• 先看哪一层？
• 先查缓存还是先查数据库？
• 什么时候该先止血？
• 最近变更值不值得立刻拉出来看？

也就是说，那份复盘很像一篇“这次发生了什么”的说明文，却没有真正留下“下次第一轮该怎么判断”的骨架。

后来我才慢慢意识到，复盘从来不是天然会长出方法论的。

事故经过写清，不等于判断顺序被留下来了。

这篇不想再讲一套空泛的复盘模板。我只想讲清楚：一份复盘要从记录升级成方法，必须从一次具体现场里把那条被验证过、也被修正过的判断链抽出来。

那次缓存事故里，最值钱的部分不是根因，而是“为什么先查这里”

那场事故最开始冒头的，其实是订单接口 timeout 和网关 504。

如果只看现象，很容易把方向压在网关、线程池或者数据库上。可当时值班同学先去看的，是缓存 miss、回源量和连接池 pending 的先后顺序。

后来复盘时，我们一开始只写了“根因是批量 key 同时过期，导致回源放大”。这句话当然没错，但它只能解释这次事故是什么，不够解释下次该怎么更快认出来。

真正让方法慢慢成形的，是把当时那些判断重新摊开：

• 为什么没有先从 504 开始追
• 为什么看到数据库 RT 抬头，也没有立刻把数据库判成起点
• 为什么在重试量上升后，先做的是关重试而不是扩线程
• 为什么动作生效后，又能确认自己不是误打误撞

这些东西一旦补进去，复盘才开始从“事故说明书”变成“判断路径样本”。

所以后来我看一份复盘，最先找的不是改进项，而是这四层东西

第一层：故障链到底是怎么长出来的

不是只写“缓存过期了”，而是把链条完整拉出来：

• 热 key 批量失效
• 回源量上升
• 连接池等待变长
• 工作线程占用拉长
• 外层 timeout 和 504 暴露

复盘一旦只停在具体对象，比如“某次 Redis 故障”，可复用性就会很差。因为下次出事的未必还是 Redis，但“吸收层失效 -> 回源放大 -> 等待链变长 -> 外层超时”这条故障链可能会再次出现。

第二层：当时第一轮为什么先看 A，不先看 B

这是最容易漏掉，也最值钱的一层。

比如那次事故里，真正值得留下来的不是“最后看了缓存”，而是：

• 先看的是最早分叉的时间顺序
• 先对比的是起点层和结果层谁先动
• 先收的是影响面，而不是最亮的红点

只有把这层写出来，下次值班的人才知道该借哪种判断，而不是只记住一个“以后缓存也要查”。

第三层：哪些动作是在保护，哪些动作是在验证

很多复盘会写“20:18 关闭重试、20:23 回撤灰度、20:31 恢复”。

但如果不说明这些动作各自想验证什么，后面的人很容易学成一套机械动作。

像那次缓存事故里，关重试不是因为所有事故都该先关重试，而是因为：

• 重试已经把调用量放大
• queue 和 pending 的增长速度快于真正处理时间
• 先减掉放大器，能让后续定位空间回来

动作一旦脱离当时的现场条件，就很容易被误学成口号。

第四层：这套经验的边界到底在哪

这一步非常关键。

如果没有边界，方法论很快就会退化成新模板。

例如那次从缓存事故里提炼出来的经验，适用的是：

• 有明显吸收层失效
• 回源放大清晰可见
• 等待链和外层 timeout 有连续传导

但如果下一次事故是发布后局部实例状态漂移，或者是网络抖动导致的单段超时，这套路径就不能原样硬套。

复盘能不能变成方法论，最后往往就看有没有把这句边界写出来。

我后来越来越少写“通用改进项”，而是更想写“下次第一轮先做什么”

很多复盘最后都会列一串正确但不够有抓手的话：

• 加强监控
• 完善预案
• 优化协作
• 提升治理能力

这些当然都对，但它们对下次值班的帮助通常很弱。

真正能让同类事故处理更快的，往往是更具体的沉淀：

• 下次先比对最早分叉的三组曲线
• 下次先确认放大器有没有起来
• 下次第一轮先抓哪几个证据快照
• 下次做到什么条件时必须先止血

这些东西不是从空中写出来的，而是从一次事故里被现场逼出来、被动作验证过、又被后续修正过的。

这就是为什么复盘不能只追根因，还得追判断链

根因会告诉你这次为什么坏。

判断链会告诉你下次怎样更快看出它正在坏。

前者当然重要，但如果只留下前者，团队学到的更多是案例知识；

后者留下来，团队学到的才是现场能力。

我后来越来越相信，真正好的复盘，不是让人看完觉得“原来这次是 Redis 批量过期”，而是让人看完以后知道：

• 类似现场里，第一轮不要先追最外层结果
• 看到回源放大和等待链接上时，要优先怀疑吸收层失效
• 放大器一旦起来，先保护系统比继续抠细节更重要

这篇的边界要卡住

如果你现在还在现场记录时间线，先去把“证据、判断、动作、结果”记清，而不是急着抽象。更前一步适合看故障时间线怎么记，才能在 30 分钟后还原判断过程？。

如果你现在卡的是值班现场怎么先收范围、先看哪条链，也更该回到前面的分诊文章，而不是直接跳进复盘抽象。

这篇只回答事故结束后的一个问题：怎么把这次现场真正值钱的判断顺序留下来。

我建议最后留下来的，不是一份更长的复盘，而是一段“下次还能借用的开场”

那次缓存事故之后，我们最后补进文档里、后来最常被反复引用的，不是根因段，也不是改进项表格，而是一段很短的话：

• 如果外层 timeout 和数据库 RT 同时出现，先比对谁先分叉
• 如果回源量、pending 和 queue 连成一条线，优先按吸收层失效看
• 如果重试已经把调用量放大，先减放大器再继续深挖

这几句看起来不像标准复盘格式，却最像真正可复用的方法。

因为它们不是事后编出来的统一原则，而是从一次具体事故里，被现场逼出来、被动作验证过、最后才留下来的。