SRE与可靠性工程：事后复盘(Postmortem)文化

可视化演示

展示事后复盘(Postmortem)文化：复盘循环、根因分析与改进行动、无责备复盘流程，通过交互理解SRE可靠性工程复盘实践。

复盘的起源与价值

主厨的“打烊复盘”并非他自创。这个习惯最早可以追溯到美国的航空业——每一次飞行事故后，调查员不会急着开除飞行员，而是把黑匣子里的数据全部导出来，一行一行地分析“飞机为什么失控”，再把结论写进安全手册，让全世界所有飞行员都受益。医疗行业同样如此：手术并发症后的“死亡与发病率讨论会”（M&M Conference），是每一位外科医生成长的必修课。这两个行业的共同点是什么？失败是高代价的，所以必须从失败中系统性地学习。

SRE（站点可靠性工程）的创始人 Ben Treynor Sloss 在 Google 建立团队时，把这种“航空级复盘”引入了软件世界。他发现，Google 的搜索引擎如果宕机十分钟，损失的收入和信任都是天文数字，而工程师们却习惯于“修完就忘”。于是他规定：每一次达到一定严重程度的事故，都必须产出一份 Postmortem 文档，像航空报告一样严谨、公开、可检索。

那么，复盘的核心价值到底是什么？打个比方，如果你的厨房今晚烧焦了一道菜，你只把菜扔掉，那明天还会烧焦；但如果你把“为什么烧焦”写下来——是火候没调对？还是计时器坏了？——并且把计时器修好、把火候标准贴在不锈钢台面上，那么这道菜的错误就从“今晚的损失”变成了“未来所有客人的收益”。事故复盘的本质，就是把一次性的故障成本，转化为永久性的系统改进收益。 这正是 SRE 圈广为流传的那句话：“故障不可怕，可怕的是同一个故障反复发生。”

事故等级划分

主厨在打烊复盘时，并不是对每个小问题都兴师动众。盘子摔碎了一个，服务员顺手扫掉就行；但如果是烤箱起火，那必须停下所有工作、全店总动员。同样的逻辑，SRE 用“事故等级”来决定复盘的深度和紧急度——这就是 Sev1 到 Sev4 的分级体系。

Sev1（严重事故）是最高级别，对应“厨房着火了”：整个服务不可用、用户完全无法访问、资损正在以分钟级扩大。这类事故需要立即拉起应急响应群，甚至可能动用“电话树”叫醒所有相关工程师，一边抢修一边开始记录时间线。Sev2（高影响事故）对应“招牌菜做错了，客人全部退菜”：核心功能受损，但系统没有完全瘫痪，比如支付功能挂了但浏览还能用。Sev2 也需要快速响应，但修复窗口相对宽松。Sev3（一般事故）对应“某道配菜味道不对，只有几桌客人在意”：局部功能受影响，没有用户数据丢失，通常在正常工作时间内处理即可。Sev4（轻微问题）对应“酱油瓶瓶盖松了”：不影响用户体验，但值得记录在案，攒够了一批再改进。

不同公司的分级标准细节各异，但核心原则一致：等级越高，响应越快，复盘的规格也越高。 Sev1 事故必须在 24 小时内产出复盘文档，Sev2 放宽到一周，Sev3 和 Sev4 则只需在季度总结中合并复盘。这就像主厨不会为了一只摔碎的盘子熬夜开全体大会——把复盘资源集中在高杠杆事故上，才是聪明的管理。

复盘五步法

主厨的打烊复盘有一套固定流程：先让大家把今晚发生的事一桩桩摆出来，再分析每件事背后的原因，最后定下“明天谁负责改什么”。SRE 的 Postmortem 流程，本质上是同一套仪式，被规范化成了五个步骤。

第一步：记录时间线。 事故发生的每一分钟都值得被还原：几点几分收到告警、几点几分开始排查、几点几分做了第一次变更、几点几分服务恢复。在餐厅场景里，这相当于让服务员、厨师、传菜员各自说出“我当时在做什么”——把这些记忆碎片拼成一幅完整的事故地图。第二步：收集证据。 就像厨房里的监控录像和点单小票，软件世界的证据是监控系统的指标曲线、日志片段、告警记录和发布记录。没有证据的分析等于瞎猜。第三步：分析根因。 这是整场复盘的灵魂环节，我们将在下一节专门展开。第四步：制定行动项。 光找到原因不够，还必须回答“谁来改、改什么、什么时候改完”——否则复盘就只是空谈。第五步：评审发布。 复盘文档写完后，需要经过团队甚至跨团队的评审，确认结论经得起推敲、行动项没有遗漏，然后公开给全公司。

五步法最精妙的地方在于它的强制顺序：先还原事实，再探索原因，最后才谈改进。很多缺乏经验的团队一上来就急着“想办法”，结果连事故的时间线都还没对齐，就开始了互相指责——五步法用流程上的纪律，从结构上保证了复盘的客观性。

5 Whys 根因分析法

“为什么牛排会烤焦？”——“因为煎锅的温度太高了。”“为什么温度会太高？”——“因为温度旋钮卡住了。”“为什么旋钮会卡住？”——“因为三个月没保养，油垢堆积。”“为什么没保养？”——“因为没人负责定期检查厨房设备。”“为什么没有人负责？”——“因为后厨的岗位职责清单里压根没写这一项。”

这就是 5 Whys 分析法：用连续五次追问，从具体的技术故障，一层层挖到管理流程和系统设计层面的缺陷。 注意，每一次回答都必须基于事实，而不是主观猜测。这个方法由丰田生产系统的大野耐一提出，后来被 SRE 领域广泛采纳。

在写复盘文档时，5 Whys 通常被画成一根“问题树”：顶端是事故现象，向下每层是一个“为什么-因为”的因果链。大多数情况下，挖到第 3-5 层时，你会惊讶地发现根因根本不是“某个工程师手滑了”，而是“告警配置缺失”“容量预估不足”“变更审批流程形同虚设”——这些才是值得写入行动项的系统性缺陷。有一类值得警惕的情况是“多线程 5 Whys”：事故往往不止一条因果链，比如线上故障同时由代码逻辑错误和监控缺失导致，此时应该分叉出多条追问线，而不是强行塞进一条单链里。5 Whys 的产出不仅是根因结论，更是行动项清单的直接来源。

复盘文档撰写

主厨打完烊，会把今晚的教训写进一本《后厨手记》：日期、发生了什么、原因、明天的改进计划。SRE 的 Postmortem 文档结构，便是这本手记的工程化版本。一份合格的事后复盘文档，通常包含以下几个部分。

首先是标题与摘要。严谨的标题不应是“昨晚又挂了”这种情绪化表达，而应是“2025-04-12 支付服务超时事故复盘”这样的事实陈述。摘要在 3-5 句话内讲清“发生了什么、影响多大、根因是什么、做了什么修复”。其次是时间线。以分钟为粒度列出所有关键事件，包含事实、来源（哪条告警、哪个日志）和操作人。时间线是复盘文档最重要的客观基础，写得好不好直接决定后续分析的可靠性。再次是根因分析。用 5 Whys 列出因果链，区分直接原因和根本原因，并说明为什么这个根因能解释全部现象。接着是行动项。每一项必须包含负责人和截止日期，通常分为“立即修复类”和“长期改进类”。最后是经验教训和附录——这次事故给团队带来了哪些新的认知，以及相关的监控截图、日志片段等支撑材料。

文档的受众不只是亲历者，更是未来可能遇到同类问题的同事，甚至可能是几个月后重新翻阅的你自己。所以写作时要把“背景知识”也写清楚，就像主厨会在手记里画一张简单的灶台布局图，防止新人看不懂。此外，复盘文档的项目名、链接和标签要规范统一，方便检索——当团队积累了上千份复盘文档，它们就变成了一部“系统避坑百科全书”。

无指责文化

如果说复盘五步法是骨架，那么无指责文化（Blameless Culture）就是流淌在骨架里的血液。Google SRE 从实践中学到一个深刻的道理：一旦复盘变成“追责大会”，所有人都会本能地开始防御和隐瞒——“那个告警我确实看到了，但当时太忙了”“这个代码不是我写的，是某某三个月前提交的”。一旦大家开始互相甩锅，真相就永远不可能浮出水面了。

“无指责”并不意味着“无责任”。它精确的含义是：复盘追问的是系统和流程为什么允许了这个错误发生，而不是谁犯了这个错误。 想象一下，餐厅的传菜员不小心把汤洒在了客人身上。主厨如果怒吼“你怎么这么不小心”，那么从此没人敢在打烊复盘时承认自己犯了错；但如果主厨问“我们的托盘为什么没有防滑垫？传菜通道为什么这么拥挤？”，大家下次就会主动举手说“我差点又洒了，建议改进托盘”。犯错的人从“被审判者”变成了“提供关键信息的贡献者”——这才是复盘的真正姿态。

无指责文化的落地，需要管理层的示范。如果 CTO 在一次事故复盘中公开承认“是我拍板加速了这个变更”，那么全公司的工程师都会感受到安全。反之，如果管理层嘴上说“没事没事”却私下给负责人打了低绩效，那么复盘文化就会瞬间崩塌，从此所有文档都只会写“网络波动”“上游抖动”这类无可指摘的抽象原因。记住一句话：如果你想得到真相，就请用系统来承载分析；如果你想得到推诿，就请用人来承载指责。

行动项追踪

复盘文档写得再漂亮，如果行动项没人跟进，那就只是一纸空文——这好比主厨在手记里写了“要买防滑垫”，结果三个月后汤又洒了一次。SRE 的实践经验表明，行动项追踪是复盘闭环中最容易断裂但也最关键的环节。

首先，每个行动项必须指定唯一的负责人，而不是“运维组”或“后端团队”这种模糊主语——如果人人有责，那么人人无责。其次，要设定明确的截止日期，建议遵循“SLA 分级”：紧急修复类行动项在一周内完成，长期改进类项目在一个迭代周期内完成。第三，团队需要定期回顾行动项进度，通常的节奏是每周站会上花五分钟扫一遍所有未关闭的复盘行动项，就像主厨每天开工前检查“防滑垫在不在、计时器修好没”。第四，如果某个行动项在截止日期内未能完成，不能悄悄销掉，而是要重新评估优先级、重新排期，甚至在季度复盘上说明延期原因。

好的行动项还有一个特征：它是可以验收的。 “加强监控”不是好的行动项，“为支付接口添加成功率告警，阈值低于 99.9% 时触发 Sev2 告警”才是。在 Google 的实践中，行动项通常还要关联到具体的监控规则和应急流程，确保下次类似风险出现时，系统能在第一时间报警而不是等用户投诉。行动项的最终目标，是让从这次事故中提炼出的改进，真正沉积到系统的日常防护机制中——就像防滑垫被装上了托盘，而不是停留在手记上。

复盘闭环与持续改进

主厨的打烊复盘坚持了一年之后，厨房发生了肉眼可见的变化：汤洒得少了，牛排烤糊率直线下降，上菜速度也快了。因为每一次复盘的教训都变成了新的标准作业流程和工具改进，而这些改进又避免了新的问题。这就是复盘的闭环——事故 → 复盘 → 行动项 → 改进 → 新的事故（更少）→ 再复盘，形成一个持续下降的故障飞轮。

在 SRE 实践中，让这个飞轮转起来需要三个层面的投入。文化层面：定期组织复盘文化培训，让每个新人都理解“复盘不是批斗会”，同时建立“错误公开分享”的传统，比如月度可靠性分享会。工具层面：用平台化的复盘工具来沉淀文档、追踪行动项、自动关联监控数据。Google 甚至开发了内部工具来自动生成事故时间线，把工程师从繁琐的记录工作中解放出来。度量层面：团队应该追踪一些持续改进的指标，例如“每千次发布的 Sev1 事故数”“行动项按期关闭率”“事故平均恢复时间（MTTR）”。这些指标不是用来考核个人，而是用来观察整个系统的可靠性趋势。

需要特别强调的是，复盘的闭环不会自动发生。很多团队试过一次复盘觉得“太浪费时间”就放弃了，或者流于形式地写了一堆文档却从不投入资源落实行动项。真正的复盘文化需要管理者持续投入耐心与信任——就像主厨坚持了三百六十五天才把厨房打磨成米其林标准。每一个故障其实都是系统发出的珍贵信号，而复盘文化，就是让这些信号真正被听见、被转化为进化动力的机制。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""postmortem_tracker.py - 一个极简的事后复盘(Postmortem)追踪工具""" from datetime import datetime, timedelta  class Incident:    """单个事故记录"""     def __init__(self, title, sev, summary):        self.title = title        self.sev = sev        self.summary = summary        self.created_at = datetime.now()        self.action_items = []     def add_action(self, desc, owner, due_days=7):        """添加一项行动项"""        item = {            "desc": desc,            "owner": owner,            "due": datetime.now() + timedelta(days=due_days),            "done": False        }        self.action_items.append(item)        return item  class PostmortemTracker:    """记录和统计事故与复盘数据的追踪器"""     def __init__(self):        self.incidents = []     def add_incident(self, title, sev, summary):        """新增一条事故记录"""        inc = Incident(title, sev, summary)        self.incidents.append(inc)        return inc     def open_actions(self):        """列出所有未关闭的行动项"""        result = []        for inc in self.incidents:            for item in inc.action_items:                if not item["done"]:                    result.append((inc.title, item))        return result     def reliability_score(self):        """根据未关闭行动项估算可靠性分数"""        total = sum(len(i.action_items) for i in self.incidents)        done = sum(1 for i in self.incidents                   for a in i.action_items if a["done"])        if total == 0:            return 100.0        return round(done / total * 100, 1)  def demo():    """演示一次完整的事故复盘周期"""    tracker = PostmortemTracker()     # Sev1 事故: 支付服务超时    inc1 = tracker.add_incident("支付服务超时", 1,                                "2025-04-12 20:13-21:45 支付API P95延迟超10秒")    inc1.add_action("为支付接口添加成功率告警", "张三", 3)    inc1.add_action("修复Redis连接池泄漏", "李四", 5)     # Sev2 事故: 搜索功能返回缓慢    inc2 = tracker.add_incident("搜索功能缓慢", 2,                                "2025-04-18 10:00-10:50 搜索P99延迟5秒")    inc2.add_action("升级ES集群节点规格", "王五", 7)     # 模拟一周后, 第一项已完成    inc1.action_items[0]["done"] = True     print("======== 待关闭行动项 ========")    for inc_title, item in tracker.open_actions():        print(f"[{inc_title}] {item['desc']} -> 负责人:{item['owner']} "              f"截止:{item['due'].strftime('%m-%d')}")     print("\n======== 可靠性评分 ========")    print(f"行动项关闭率: {tracker.reliability_score()}%")    print("复盘闭环运转中: 每次故障都在转化为系统改进")  if __name__ == "__main__":    demo()

1. self.incidents.append(inc)每起事故都作为一条记录存入追踪器，就像主厨把每晚的问题写进《后厨手记》。
2. inc.add_action("为支付接口添加成功率告警", "张三", 3)每个行动项必须绑定唯一负责人和截止期限，防止“人人有责=人人无责”。
3. if not item["done"]:定期扫描所有未关闭的行动项，这是复盘闭环中最关键但最常被忽略的一环。
4. done / total * 100用行动项关闭率量化团队的复盘执行力，作为持续改进的度量指标。

常见误区

面试题