上周跟几个做基础架构的朋友撸串，三个人里两个刚因为线上故障熬了三个通宵，还有一个刚被拉去开了两个小时的复盘会。散场的时候他把冰可乐往桌上一顿，说这会开的，一半时间在说”这个操作谁点的”，一半时间在说”下次我们要加强意识”，半句话没提当时监控为什么没报警，流量切流的开关为什么点了三秒才响应。
先搞清楚复盘要拦的是什么
说白了，很多团队把复盘的起点放错了位置。一上来先找责任人，先把流程上的签字链路捋一遍，谁审批的，谁执行的，谁当时在值班，谁漏看了告警。等把人找齐，责任划完，两三个小时过去了。真正跟故障本质相关的细节，比如当时扩容的阈值为什么设成了80%而不是70%，跨机房同步的链路为什么没有做超时熔断，业务侧临时加的批量导出任务为什么没有走专门的限流通道，这些东西没人问。所有的复盘动作，首先要对准系统的漏洞，而不是人的过失。
我之前见过一个团队，故障发生在凌晨两点，值班同学发现之后花了12分钟把流量切回了旧版本，服务恢复。复盘的时候大家围着表数时间，说为什么发现问题花了3分钟，为什么切流花了12分钟，整整花了一个半小时算时间差，最后定的改进项是”值班同学要提高敏感度，切流操作要练熟”。结果过了两周同样的问题又来了——这次是切流开关因为版本迭代被锁了权限，值班同学点不动，又多花了8分钟申请权限。上次挖出来的问题根本不是人不熟练，是权限体系跟发布流程完全脱节，上次复盘等于白开。
这才叫亏得慌。
别把流程补全当成复盘的终点
说实话，现在很多复盘会的产物，就是一堆流程文档。比如这次故障是因为新同学没走审批就上了配置，那下次就加一道审批；这次故障是因为告警漏发了，那下次就加个告警渠道；这次故障是因为值班同学睡着了，那下次就加个每半小时的签到。这些东西有没有用？有点用。但远远不够。流程补全永远是复盘的最后一步，而不是第一步。
麻烦在于，所有的流程补全，都是在给已经发生的问题打补丁，从来没有顺着问题往上摸，看看整个系统的设计本身有没有藏着雷。比如那个配置审批的事，你加了审批，那审批的人凭什么判断这个配置改了会不会出问题？他有没有全链路的配置变更影响清单？他点审批的时候，是真的看了变更内容，还是就走个流程打个勾？很多时候答案是后者。
我之前跟一个做SRE的老大哥聊，他说他们团队做复盘，从来不在第一次开会的时候就写改进项。第一次会就拉所有在场的人，从故障发生的前24小时开始，按时间线把所有发生的事列出来——哪个时间点业务侧提了新需求，哪个时间点运维侧做了磁盘清理，哪个时间点监控系统报了个没人理的warning，哪个时间点网关侧的日志飘了几百行timeout，所有的细节，不管看起来多小，都记下来。等把时间线捋顺了，大家才会发现，哦原来那个没人理的warning，就是故障最早的信号，离真正的服务不可用，差了整整40分钟。这时候再去定改进项，说要把warning级别的告警按影响范围分级，要安排人专门盯核心链路的warning，那才是真的有用，而不是空喊口号。
那些被藏在复盘里的隐性成本
很多人觉得复盘就是花几个小时开个会，写个报告，没什么成本。不对。你要是把复盘开成了批斗会，那成本比你想的高多了。把复盘开成批斗会的代价，从来不是一次会议的时间成本，是整个团队的信任损耗。
上次有个读者给我发消息，说他们团队之前出过一次大故障，复盘的时候leader把所有责任都推给了当时值班的校招生，说他操作失误。结果那个校招生干完三个月就走了，走之前把自己手里的所有文档都整理得干干净净，没留半句话。后来大家才发现，当时那个操作，是leader之前在群里拍板让他做的，因为当时业务方催得急，没走正规流程。
没人敢担责的团队，迟早要出更大的故障。为了找个背锅的人，团队丢了一个能扛事的新人，剩下的人之后再遇到事，第一反应不是怎么快速恢复服务，而是怎么把聊天记录存好，怎么把责任撇清。这种信任成本，要花好几个季度才能补回来。
还有一种更隐蔽的成本，就是大家为了不被追责，开始做过度的防御。比如之前因为一次配置变更出了故障，之后所有的配置变更都要拉三个人审批，哪怕只是改个前端的文案参数。本来十分钟能做完的事，现在要等两天才能走完流程。业务侧怨声载道，运维侧也天天被找，大家都累，但没人敢改。说白了，这种防御性的流程，本质上就是复盘的时候没找对根因，最后全团队为一个模糊的问题买单。
上周跟那个被拉去开复盘会的朋友再约撸串，他说他们这周把之前攒的三次故障的时间线重新拉了一遍，没找责任人，就顺着时间线摸，发现有两个共同的问题——一个是监控系统的告警分级做的一塌糊涂，所有告警都堆在一个群里，大家看久了就麻木；另一个是跨团队的信息同步根本没有固定通道，业务侧加了批量任务，运维侧根本不知道，等资源打满了才发现。现在他们正在改监控的分级规则，打算这周就上线。
他说现在再开复盘会，没人一上来就问谁的错了。毕竟大家都是拿工资干活的，谁也不想系统出问题。真要出了事，先把事解决，再把根找到，比啥都强。