一次事故，全员熬一阵子，写完复盘文档，好像一切解决了。
结果过了几周，同类型事故换个接口、换个脚本、换个同事，又重演一遍。
你会发现复盘开会很频繁，真正被消灭的事故模式却不多。
表面上在“找根因”，实际上只是在记录这次发生了什么，而没有追问：
当时团队是站在怎样的前提和约束下做那几个决定的。
这篇就讲清三件事
一是只盯结果的复盘为什么基本挡不住下一次
二是真正有用的复盘应该多看哪些前提条件
三是怎么把这些前提沉淀成团队防线，而不是一篇篇孤立的事故报告
==============================
一、只写“根因”为什么挡不住下一次
很多复盘文档长得很像流程模板
- 直接原因：配置写错、字段没校验、边界没处理
- 间接原因：测试覆盖不足、监控不完善
- 改进措施：补用例、加告警、加强培训
看起来有板有眼，现实效果却往往是
- 字段名换一个，同类问题再来一遍
- 接口换一个，同类逻辑再翻车一次
- 人员一换，新同事再走一遍老路
根本原因在于
这些复盘只在回答“这次为什么挂”，没有回答“为什么大家会在类似情景下做出同样选择”
真正推动事故发生的，往往不是那一行条件判断，而是背后的默认前提
- 赶上线比补测试更重要
- 临时配置随时可以改，没人记得回收
- 多系统联动没有人负责整体视角，只管自己这一块
只改那一行代码，不碰这些前提
下次只要环境还一样，团队自然会重复同一条决策路径
结果就是同一类事故换个壳子再发生一次
==============================
二、不看“当时的世界”复盘只能怪人
一场事故真正有价值的信息，大致有三层
1、表层是“发生了什么”
这一层通常写得最详细
- 哪个服务出错
- 哪条配置有问题
- 哪个脚本漏了校验
这层记录很重要，但如果只停在这里，复盘很容易变成“追责谁写错了”
2、中层是“当时大家看见了什么”
需要补充的是当时的认知环境
- 指标是否足够清晰，能否支持判断风险高低
- 有没有统一视图让人看到全链路状态
- 文档和实际是否对得上，新人是否知道哪些部分已经很脆弱
很多决策看起来是“判断失误”，本质是信息不全
如果复盘不把这一层摊开，下次大家在同样信息缺失的情况下，还会做同样判断
3、深层是“当时默认的游戏规则是什么”
还有一层更隐蔽的东西，是团队日常已经习惯的规则
- 需求有硬日期，上线挡不住，测试可以缩
- 配置可以直接改线上，只要有人拍板
- 出了问题先修再说，根因以后慢慢找
这些规则哪怕没写在制度里，也在每天影响每一个决定
如果复盘只谈“技术问题”，不碰这些规则，那同样的坑还会在那里等下一次
==============================
三、复盘时必须补上的几块前提信息
要让复盘真正有用，除了写“直接根因”，至少要多回答几类问题
1、当时有哪些约束被默认接受了
可以直接问团队
- 这次迭代的时间压力有多大
- 代码评审和测试是否被主动削减
- 哪些风险当时已经看见，只是觉得“先上了再说”
把这些约束写清楚，是在提醒大家
问题不是“谁不够谨慎”，而是那种时间和资源分配方式，本身在推着人走捷径
2、当时缺了哪些关键信息
例如
- 有没有任何监控能提前提示这条链路风险上升
- 是否存在一键化脚本可以在上线前跑一轮全链路检查
- 文档里有没有醒目标注“这一块已经老旧，动之前要特别小心”
如果每次事故现场都是一句“我们当时以为没问题”
那就该追问：当时是基于什么信息得出的这个判断
3、有哪些信号其实已经出现却被忽略
常见情况包括
- 早期零星告警被当作偶发现象
- 测试环境里出现过类似问题，但没人认为线上会放大
- 评审中有人提过风险，但被一句“时间来不及”压过去
这些内容如果不好意思写在复盘里，就说明团队只敢谈“代码错了”，不敢谈“决策错了”和“组织方式有问题”
那同一类坑肯定还会反复踩
==============================
四、怎么让团队不再重复同一种掉坑模式
光写一份深刻复盘还不够，更重要的是把“踩坑模式”变成团队公共防线。
1、先给常见的翻车模式起名字
比如：
- 无上限重试模式：错误一出现就疯狂重试，最后把系统自己打爆；
- 配置组合爆炸模式：配置项越加越多，随便一改就造出新路径；
- 无优先级抢资源模式：关键业务和低价值任务抢同一拨资源。
一旦有名字，大家在讨论设计时就能迅速对号入座。一看到类似味道，就有人会说“这很像某某模式，要小心”。
2、把坑写成检查清单嵌进日常流程
可以为每一种常见模式写一张简短卡片：
- 典型表现：线上大概会出现什么现象；
- 触发条件：什么组合最容易触发这种事故；
- 检查问题：设计和评审时至少要问哪几句。
然后让这几张卡片进入日常流程：
- 需求评审时，对照看有没有碰上这些模式；
- 架构评审时，用来检查是否在重复老路；
- 上线前自查一遍，确认没有踩到已知雷区。
3、让复盘文档按“模式”串起来
如果每一份复盘都是孤立文档，很难形成团队记忆。更好的做法是：
- 按模式而不是按时间整理历史事故；
- 把同一类问题归到同一个目录里；
- 每次新事故发生时，先去翻一下这类模式之前出现时的决策经过和修复经验。
新人加入团队时，只要读完几类典型模式的合集，大致就能知道：
- 这个系统最危险的地方在哪里；
- 团队曾经被哪些假设和习惯坑过。
4、配合易路，把“踩坑模式”变成可观测、可控制的出口层结构
如果你的系统里大量流量都要经过代理出口，那这些“踩坑模式”最后往往会在出口层放大：重试风暴、配置漂移、优先级混乱，全都体现在某几批 IP 上。这个时候，用一个能分组、可观测的代理平台，会比单纯“换线”更有意义。
以易路代理为例，你可以：
- 按业务模式建线路组：把“无优先级抢资源模式”拆成高优业务出口组、采集出口组、测试出口组，在面板上实时看到各组的 QPS、成功率和错误分布；
- 用标签固化“安全组合”：把已经踩过坑的配置（国家、线路类型、并发上限）固化成一套出口标签，后续新脚本只能选标签，而不是随手拼接新组合；
- 利用可视化统计，给“无上限重试模式”加硬约束：看到某一组线路错误率和重试数异常，就可以直接从面板层限流、下线，避免问题扩散。
简单说，你在团队层面给“翻车模式”起名字、写清单，帮助大家识别坑；在代理层面用易路把这些规则托住，让“少踩坑”不只靠自觉，而是靠结构和工具一起兜底。
==============================
团队为什么会在同一个坑里反复跌倒
往往不是因为大家不够聪明，也不是因为复盘不够认真，而是因为
- 复盘只盯“发生了什么”，不问“当时为什么这么做”
- 只改那一行代码，不改背后默认的游戏规则
- 把每次事故写成一次性故事，而没有提炼出可复用的模式和检查点
更有用的做法是
- 在复盘里把约束、信息缺失和被忽略的信号写出来
- 把翻车模式命名、归档，做成简短检查清单
- 让这些东西进入日常设计评审和上线流程
这样，当类似场景再出现时，团队里至少会有人说一句
“等等，这看起来很像我们以前那次事故的前奏，要不要先停一下”
从这一刻开始，你就不再只是记录事故，而是在一点点收回系统和团队的复杂度