事后复盘文化：SRE 如何通过无责复盘从失败中学习

作为 SRE（站点可靠性工程师），我们维护的是大规模、复杂的分布式系统。我们不断为服务添加新功能，引入新系统。鉴于系统规模庞大、变化速度极快，故障和中断不可避免。当故障发生时，我们会修复根本问题，使服务恢复正常运行。然而，如果没有一套正式的事后复盘流程来从故障中吸取经验教训，同样的问题就可能反复出现。若不加以控制，故障的复杂性会不断累积，甚至像滚雪球一样蔓延，最终让系统和运维人员都不堪重负，并影响用户体验。因此，事后复盘对 SRE 事故管理至关重要。

事后复盘的概念在科技行业早已广为人知。所谓事后复盘，是指对事故本身、事故影响、为缓解或解决问题而采取的措施、根本原因，以及为防止类似事故再次发生而制定的后续行动进行书面记录。本章将介绍判断何时开展事后复盘的标准、事后复盘的一些最佳实践，并结合我们多年积累的经验，提出如何培育事后复盘文化的建议。

某海外大型科技公司的事后复盘理念

撰写事后复盘报告的首要目标，是确保事故得到完整记录，所有根本原因都得到充分理解；更重要的是，要采取有效的预防措施，以降低类似事故再次发生的可能性和/或影响范围。受篇幅所限，本章不会详细讨论根本原因分析技术。不过，在系统质量领域，已有大量文章、最佳实践和工具可供参考。我们的团队会采用多种根本原因分析技术，并选择最适合自身服务特点的方法。

任何重大不良事件发生后，都必须开展事后复盘。撰写事后复盘报告并不是惩罚，而是整个公司共同学习的机会。事后复盘流程确实会消耗一定时间和精力，因此我们会谨慎选择启动复盘的时机。不同团队可以根据自身情况保留一定灵活性，但常见的事后复盘触发条件包括：

• 用户可见的停机或性能下降超过某一阈值；
• 发生任何形式的数据丢失；
• 需要值班工程师采取干预措施，例如版本回滚、流量重新路由等；
• 问题解决时间超过某一阈值；
• 监控系统失效，通常意味着事故需要由人工发现。

在事故发生前就明确事后复盘标准至关重要，这样才能确保所有人都清楚何时需要开展复盘。除上述客观触发条件外，任何利益相关方也都可以要求对某一事件进行事后复盘。

无责事后复盘是 SRE 文化的一项基本原则。真正无责的事后复盘，必须专注于识别事故的根本原因，而不是指责任何个人或团队的失误。无责复盘假定所有参与事故处理的人员都出于善意，并基于当时掌握的信息作出了他们认为正确的判断和处理。如果组织中盛行互相指责、羞辱“做错事”的个人或团队的文化，人们就会因为害怕受到惩罚而不愿揭示问题。

无责文化起源于医疗和航空电子等行业。在这些行业中，任何错误都可能造成致命后果。因此，它们努力营造一种氛围：将每一次“错误”都视为强化系统的机会。只有当事后复盘的重点从追究责任转向探究系统性原因——即为什么个人或团队会掌握不完整或错误的信息——有效的预防计划才有可能落地。你无法简单地“改变”人，但可以改进系统和流程，从而更好地支持人们在设计和维护复杂系统时作出正确选择。

当服务中断发生时，事后复盘报告并不是走形式。工程师会将其视为一次机会：不仅修复服务缺陷，也提升组织整体的韧性。一份客观公正的事后复盘报告，不应成为宣泄不满或相互指责的场所，而应指出服务可以在哪些方面、以何种方式得到改进。以下是两个示例：

指责式表达

“我们需要重写整个复杂的后端系统！过去三个季度它每周都会出问题，我相信大家都已经受够了这种零零碎碎的修补。说真的，如果我再被叫醒一次，我就自己把它重写一遍……”

无责表达

“重写整个后端系统或许能够有效减少这些令人困扰的告警，而且当前版本的维护手册很长，很难完全掌握。我相信未来的值班人员会感谢我们做出这样的改进。”

最佳实践：避免指责，建立无责复盘机制

撰写无责的事故复盘报告并不容易，因为复盘报告的格式往往会清晰呈现导致事故发生的具体行为。正因如此，在报告中避免追责尤为重要。这样可以让人们更有信心、更无顾虑地向上反馈问题。

此外，个人或团队频繁撰写事故复盘报告，不应被视为羞耻。相反，如果组织中充斥着追责氛围，就可能滋生掩盖事故和问题的文化，从而给组织带来更大的风险。

协作与知识共享：让事后复盘真正产生价值

我们重视协作，事后复盘流程也不例外。复盘工作流的每个阶段都包含协作与知识共享。

我们的事后复盘文档使用在线协作文档工具，并采用内部模板。无论使用哪种工具，都应关注以下关键能力：

实时协作
能够快速收集数据和想法，这在事后复盘的早期阶段尤为重要。

开放式评论 / 注释系统
便于众包解决方案，并提升问题覆盖范围。

通知能力
既可以定向通知文档中的协作者，也可以邀请其他人提供意见。

对于研发团队而言，事后复盘不应只是孤立的一份文档，而应与目标、需求、开发、测试、发布和知识沉淀形成闭环。例如，借助 PingCode 这类智能化研发管理工具，团队可以将事故复盘中的行动项、缺陷修复、版本发布和 Wiki 知识沉淀串联起来，让复盘结论更容易转化为后续研发改进。

撰写事后复盘报告还包括正式的审核与发布环节。在实践中，团队通常会先在内部分享复盘报告初稿，然后邀请一组资深工程师评估其完整性。审核标准可能包括：

• 是否收集了关键事故数据，以供日后参考？
• 是否完成了影响评估？
• 根本原因分析是否足够深入？
• 行动计划是否恰当？由此产生的缺陷修复是否已按合理优先级推进？
• 是否已将结果告知相关利益方？

初步审核完成后，事后复盘报告会在更大范围内分享，通常会发送给更大的工程团队或内部邮件列表。我们的目标是让尽可能多的人都能从中受益，获得必要的知识或经验教训。对于任何可能识别最终用户的信息，组织都应设置严格的访问权限；即使是事后复盘报告这样的内部文档，也不应包含此类信息。

最佳实践：所有事后复盘报告都应经过审核

未经审核的复盘报告，就像从未存在过一样。为确保每份完成的草稿都能得到审核，我们鼓励定期召开复盘评审会议。在这些会议中，重要的是结束所有仍在进行的讨论和评论，记录相关想法，并最终确定报告的正式版本。

一旦相关人员对文档及其行动项感到满意，事后复盘报告就会被添加到团队或组织的历史事故库中。透明的共享方式可以让其他人更容易找到这些复盘报告，并从中学习。

如何在组织中引入事后复盘文化

在组织中引入事后复盘文化并非易事；它需要持续培养和不断强化。我们通过高层管理者积极参与审核与协作流程，来强化这种协作式的事后复盘文化。管理层可以推动和鼓励这种文化，但理想情况下，无责事后复盘应源于工程师的自我驱动。

为了培育事后复盘文化，SRE 会积极开展各种活动，传播我们从系统基础设施中获得的经验。一些活动示例如下：

本月复盘报告
在每月简报中，与整个组织分享一篇有趣且写作质量较高的复盘报告。

事后复盘交流小组
该小组用于分享和讨论内部及外部的复盘报告、最佳实践，以及对复盘报告的评论。

事后复盘读书会
团队会定期举办事后复盘阅读会。在会上，大家会分享一篇有趣或影响较大的复盘报告，并准备一些茶点，供事故参与者、非参与者以及新入职员工共同讨论事故经过、经验教训以及事故后续影响。通常情况下，被讨论的复盘报告已经是几个月甚至几年前的内容。

厄运之轮
新入职的 SRE 通常会参加“厄运之轮”演练，相关内容可参见“灾难角色扮演”。该演练会重现以往事故复盘中的场景，由一组工程师扮演复盘中设定的角色。原事故指挥官也会到场，以帮助演练尽可能贴近真实情况。

在组织中引入事后复盘的最大挑战之一，是有些人可能会质疑其价值，尤其是在考虑到准备工作所需成本时。以下策略有助于应对这一挑战：

• 将事后复盘逐步融入现有工作流。经过一段时间的试运行，并完成几次完整、成功的事后复盘后，不仅可以证明其价值，也有助于确定启动复盘所需的必要条件。
• 确保撰写高质量事后复盘报告成为一种受到奖励和赞扬的行为。这种认可既可以通过前文提到的社交方式公开表达，也可以纳入个人和团队绩效管理。
• 鼓励高层领导重视并参与其中。许多海外科技公司的高层管理者都曾公开强调事后复盘的重要性。

在复盘文化落地过程中，工具的作用并不是替代文化建设，而是降低协作和跟进成本。对于需要跨部门推进复盘行动项的团队，也可以借助 Worktile 这样的通用项目协作系统，统一管理任务、项目、文档、日历、审批等内容，让事故复盘后的改进措施真正被跟踪、执行和验收。

最佳实践：公开表彰做正确事情的人

某海外大型科技公司的创始人和高管曾主持每周一次的全员大会。该大会在公司海外总部举行，并通过网络直播覆盖全球各地办公室。2014 年的一次大会以“事后复盘的艺术”为主题，重点讨论了一起影响重大的安全事件。

一位 SRE 讲述了他最近推送的一次版本发布。尽管进行了全面测试，但一次意外的交互导致一项关键服务中断了四分钟。由于这位 SRE 反应迅速，立即回滚变更，避免了更长时间、更大范围的宕机，因此事故只持续了四分钟。

这位工程师不仅因快速、冷静的处理方式立即获得了两份同事奖金，还赢得了大会现场观众的热烈掌声，其中包括公司创始人以及数千名员工。除这样的公开论坛外，该公司还拥有一系列内部社交网络，便于同事们对写得出色的事故复盘报告和优秀的事故处理表现给予赞扬。这只是众多例子之一。在这些例子中，同事、CEO 以及各级管理者都会对这些贡献给予认可。

最佳实践：征求对事后复盘有效性的反馈

在一些海外科技公司，团队致力于及时解决问题，并在内部分享创新成果。他们会定期对团队进行调查，了解事后复盘流程如何支持目标实现，以及该流程还可以如何改进。调查问题可能包括：

公司文化是否支持你的工作？撰写事后复盘报告是否过于繁琐？你的团队会向其他团队推荐哪些最佳实践？你希望开发哪些工具？

调查结果让一线 SRE 有机会提出改进建议，从而提升事后复盘流程的有效性。

除事故管理和后续行动的操作层面之外，事后复盘实践已经逐渐融入组织文化。如今，在重大事件之后开展全面的事后复盘，已成为不少成熟技术团队的文化规范。

结论：通过事后复盘实现持续改进

可以说，持续投入资源培育事后复盘文化，有助于减少服务中断，并提升用户体验。一些海外大型科技公司会设立专门的事后复盘工作组，负责协调公司内部的复盘工作：统一复盘模板，利用事故发生时所用工具中的数据自动生成复盘报告，并协助自动化提取复盘报告中的数据，以便进行趋势分析。

这些公司已经能够在视频、宽带、邮件、云服务、广告和地图等不同产品线之间协作，总结和分享最佳实践。尽管产品形态各异，但它们开展事后复盘的共同目标始终一致：从最艰难的时刻中吸取教训。

大型技术组织每月都会生成大量事后复盘报告，因此，用于汇总和分析这些报告的工具变得越来越重要。这些工具能够帮助团队识别跨产品边界的共同主题和改进领域。为了便于理解和自动化分析，一些团队会持续增强事后复盘模板，添加更多元数据字段。未来，这一领域还会有更多探索，包括利用机器学习预测系统薄弱环节、促进实时事故调查，以及减少重复事故的发生。