半夜报警响了，人得爬起来
凌晨两点，手机突然嗡嗡震动。打开一看，监控平台弹出一条红色告警：核心服务响应时间飙升，错误率突破阈值。这种场景对SRE来说太熟悉了——咖啡灌下三杯，团队围在屏幕前查日志、翻指标，花两个小时终于把服务拉回来。可问题来了：下次还这么救火？
故障复盘不是追责大会
很多人以为复盘就是开会批评谁没写好代码、谁删错了配置。其实真正在意系统稳定的团队，更关心“为什么当时那个人会那么做”。比如某次数据库被打挂，表面看是运维误删索引，深挖下去才发现：文档里根本没写这个索引的作用，新来的同事自然不知道它不能动。
所以第一件事是定基调：所有人可以讲自己干了啥，不用担心被点名扣绩效。只有这样，才能听到真实的声音。
先还原时间线，像看回放录像
别一上来就分析原因。先把整个过程按分钟级列出来：
00:00 - 监控触发延迟告警
00:07 - 值班SRE收到PagerDuty通知
00:15 - 发现缓存命中率骤降
00:23 - 回滚最近一次配置变更
00:41 - 服务逐步恢复
01:10 - 错误率回归正常水平这就像行车记录仪，帮你看到哪里开始跑偏。有时候你会发现，真正的问题出现在告警之前很久——比如那个配置变更其实在六小时前就上线了，只是流量高峰才暴露问题。
多问几个“为什么”，别停在第一层
有人改了配置 → 为什么他敢改？→ 因为权限没限制 → 为什么不限制？→ 因为觉得小改动不用审批 → 为什么觉得不用？→ 因为过去没人出过事。
看到没，一个问题能挖出流程漏洞。Google的SRE手册里提过一个经典案例：服务器宕机，原因是数据中心断电。继续问下去，发现备用发电机燃料不足。再往下，是维护清单漏掉了这项检查。一层层剥开，最终改的是排班表上的巡检任务分配逻辑。
输出具体动作，而不是口号
别说“加强测试”“提高意识”这种空话。要的是可执行项：
- 给关键配置加二次确认弹窗
- 在发布流程中插入自动化检查点
- 每周随机抽取两个历史告警做桌面推演
比如你们发现每次大促前都会忘更新CDN缓存规则，那就把它做成发布 checklist 的固定条目，不勾选就不能上线。
让复盘结果活在日常工作中
很多报告写完就被塞进文件夹吃灰。聪明的做法是把教训变成监控的一部分。例如上次因为磁盘满了导致服务崩溃，这次就在 Grafana 面板上加个“剩余空间趋势预测”图表，提前三天标黄预警。
或者把典型故障场景编成脚本，每月跑一次混沌工程实验。就像消防演习，平时练熟了，真着火时不慌。
小改进积累成高可用
没有哪个系统天生稳如老狗。Netflix 的稳定性是一次次炸出来的经验堆出来的。SRE复盘的目的不是追求零故障——那不可能。而是让同样的坑永远不会再踩第二次。每解决一个根因，等于给系统穿上了新的防弹衣。
下次再遇到半夜报警，你会发现自己处理得越来越快，甚至有些问题还没爆发就被拦住了。这才是复盘的意义：不是修电脑，是在造一台越来越聪明的机器。