老计聊SRE 07故障复盘,对事不对人的 postmortem 怎么做本系列的示例应用和脚本开源在 GitHub(仓库地址见文末)。本篇的故障时间线来自对示例应用的真实压测。本篇目标前面几篇,我们把可靠性度量出来(SLI/SLO/预算),又学会了在出事时精准告警。这一篇讲告警响过、故障处理完之后,最该做但最容易被跳过的一步:复盘。学完本篇你将掌握:为什么复盘的第一原则是对事不对人一份能用的复盘模板长什么样怎么用一次真实故障的时间线走完整个复盘怎么让复盘产出的改进真正落地,而不是写完就忘一、找人背锅,是最没用的复盘先说个常见的错误做法。线上出了故障,处理完了,老板拉个会:这次谁干的?怎么搞的?下次注意啊。被点名的人低头认错,会就散了。这种复盘几乎没有任何价值。因为它得出的结论是某人不小心,而这个结论没法防止下次再出事,只会带来一个后果:大家学会了藏。下次谁出了问题,第一反应是想办法遮掩、别被发现,而不是赶紧上报、一起解决。于是你的团队慢慢变成:故障越藏越深,小问题拖成大事故,没人敢说真话。SRE 的复盘文化,第一条铁律就是反过来的:对事不对人,无指责(blameless)。二、无指责,不是不追责,是追错误的系统而不是人很多人一听无指责就误会:那出了事没人负责了?不是这个意思。无指责的核心假设是:在当时那个情境下,任何一个正常、负责的人,都可能做出同样的操作。所以问题不在这个人,而在于:为什么系统允许一个误操作造成这么大影响?为什么没有防呆设计、没有及时的告警、没有快速的回滚?为什么这个人当时掌握的信息不足以做出正确判断?你看,把矛头从人错了转向系统哪里让错误发生了,追问的方向完全不同。前者的结论是下次小心点,后者的结论是加一道校验、补一个告警、做一个自动回滚。只有后者才真正让系统变强。一句话:无指责不是放过问题,是把追责的对象从人换成系统。这样大家才敢暴露真实的问题,复盘才有真东西。复盘的矛头,从指责人转向改进系统三、一份能用的复盘模板复盘不能靠嘴聊,得落成文档。一份基本够用的复盘模板,包含这几块:故障概述:什么时间、什么服务、影响了什么、多严重(最好用 SLI 量化,比如可用性掉到多少)。影响范围:多少用户、多少请求受影响、持续多久。时间线:从故障开始到恢复,每个关键节点几点几分发生了什么(发现、定位、处理、恢复)。这是复盘的核心。根因分析:到底是什么导致的。多问几个为什么,别停在表面。做对了什么:这次响应里哪些做得好,值得保留。别只盯着问题,好的经验也要沉淀。改进行动项:具体要做什么、谁负责、什么时候做完。每一项都要可执行、有人认领、有截止时间。模板不用复杂,关键是每次都认真填,尤其是时间线和行动项这两块。一份复盘模板的六个板块四、动手:用一次真实故障走一遍复盘我们对示例应用制造了一次完整的故障,记录了真实的三段时间线。现在用它填一份迷你复盘。真实数据:t1 正常期: 可用性 99.67% 错误率 0.33% t2 故障期: 可用性 88.00% 错误率 12.00% P95 502ms t3 恢复期: 可用性 100% 错误率 0%故障概述:示例应用某端点故障率异常升高,可用性从正常的 99.67% 掉到 88.00%,错误率飙到 12%,延迟 P95 升到 502ms。对照我们 99% 的 SLO,这是一次明确的违约。时间线(复盘的核心):阶段状态可用性错误率说明t1正常99.67%0.33%服务健康,预算正常消耗t2故障88.00%12.00%故障注入,错误率飙升,燃尽率约12倍,触发高优先级告警t3恢复100%0%问题解除,错误率归零,告警自动消除一次故障的完整时间线,正常到故障再到恢复根因分析:错误率从 0.33% 跳到 12%,是某个端点的故障率被显著推高导致的(在真实生产里,这可能对应一次错误的发布、一个依赖的异常、或配置错误)。注意根因指向的是什么变化引入了故障,而不是谁按错了键。做对了什么:燃尽率告警在故障期(约12倍燃尽率)及时拉响了高优先级告警,没有被淹没;恢复后告警自动消除,不需要人工干预。这说明前几篇搭的告警体系起了作用。改进行动项(示例):给这个端点增加发布前的自动校验,防止故障配置上线(负责人、截止时间)增加针对该端点错误率的独立监控面板(负责人、截止时间)补一个自动回滚机制,错误率超阈值自动回退到上一个版本(负责人、截止时间)你看,整份复盘没有一句谁的锅,全程对着数据和系统。这才是能让系统变强的复盘。五、复盘最难的不是写,是让行动项落地现实里,大量复盘文档写完就躺在某个文件夹里吃灰,行动项一条都没做,下次同样的故障又来一遍。让行动项落地,有几个实操要点:每项都要有明确负责人和截止时间,没有 owner 的行动项等于没有。纳入正常的工作排期,像对待需求一样对待它们,而不是有空再说。定期回看,复盘不是开完会就结束,过段时间要检查行动项做完没、有没有效果。重要故障的行动项优先级要高,别让它们排在新功能后面永远轮不到。复盘的价值,不在那份写得多漂亮的文档,而在于它产出的改进有没有真的让下一次故障不再发生。写复盘只是开始,落地才是目的。六、小结找人背锅是最没用的复盘,它只会让团队学会藏问题无指责不是不追责,是把追责对象从人换成系统:追问系统为什么让错误发生一份能用的复盘模板包含概述、影响、时间线、根因、做对了什么、改进行动项用真实故障走一遍复盘:可用性 99.67% 掉到 88.00%、错误率 12%,全程对着数据和系统而非人复盘最难的是让行动项落地:明确 owner 和截止时间、纳入排期、定期回看下一篇:光靠人去响应和复盘还不够,我们要把可靠性写进代码,健康检查、超时重试、优雅降级,让系统自己扛住一部分故障。参考链接本系列开源仓库(示例应用 压测脚本):https://github.com/Jich1123/sre-aws-labGoogle SRE Book - Postmortem Culture:https://sre.google/sre-book/postmortem-culture/Google SRE - Example Postmortem:https://sre.google/sre-book/example-postmortem/Google SRE Workbook - Postmortem Culture(落地实践):https://sre.google/workbook/postmortem-culture/