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

作为 SRE站点可靠性工程师我们维护的是大规模、复杂的分布式系统。我们不断为服务添加新功能引入新系统。鉴于系统规模庞大、变化速度极快故障和中断不可避免。当故障发生时我们会修复根本问题使服务恢复正常运行。然而如果没有一套正式的事后复盘流程来从故障中吸取经验教训同样的问题就可能反复出现。若不加以控制故障的复杂性会不断累积甚至像滚雪球一样蔓延最终让系统和运维人员都不堪重负并影响用户体验。因此事后复盘对 SRE 事故管理至关重要。事后复盘的概念在科技行业早已广为人知。所谓事后复盘是指对事故本身、事故影响、为缓解或解决问题而采取的措施、根本原因以及为防止类似事故再次发生而制定的后续行动进行书面记录。本章将介绍判断何时开展事后复盘的标准、事后复盘的一些最佳实践并结合我们多年积累的经验提出如何培育事后复盘文化的建议。某海外大型科技公司的事后复盘理念撰写事后复盘报告的首要目标是确保事故得到完整记录所有根本原因都得到充分理解更重要的是要采取有效的预防措施以降低类似事故再次发生的可能性和/或影响范围。受篇幅所限本章不会详细讨论根本原因分析技术。不过在系统质量领域已有大量文章、最佳实践和工具可供参考。我们的团队会采用多种根本原因分析技术并选择最适合自身服务特点的方法。任何重大不良事件发生后都必须开展事后复盘。撰写事后复盘报告并不是惩罚而是整个公司共同学习的机会。事后复盘流程确实会消耗一定时间和精力因此我们会谨慎选择启动复盘的时机。不同团队可以根据自身情况保留一定灵活性但常见的事后复盘触发条件包括用户可见的停机或性能下降超过某一阈值发生任何形式的数据丢失需要值班工程师采取干预措施例如版本回滚、流量重新路由等问题解决时间超过某一阈值监控系统失效通常意味着事故需要由人工发现。在事故发生前就明确事后复盘标准至关重要这样才能确保所有人都清楚何时需要开展复盘。除上述客观触发条件外任何利益相关方也都可以要求对某一事件进行事后复盘。无责事后复盘是 SRE 文化的一项基本原则。真正无责的事后复盘必须专注于识别事故的根本原因而不是指责任何个人或团队的失误。无责复盘假定所有参与事故处理的人员都出于善意并基于当时掌握的信息作出了他们认为正确的判断和处理。如果组织中盛行互相指责、羞辱“做错事”的个人或团队的文化人们就会因为害怕受到惩罚而不愿揭示问题。无责文化起源于医疗和航空电子等行业。在这些行业中任何错误都可能造成致命后果。因此它们努力营造一种氛围将每一次“错误”都视为强化系统的机会。只有当事后复盘的重点从追究责任转向探究系统性原因——即为什么个人或团队会掌握不完整或错误的信息——有效的预防计划才有可能落地。你无法简单地“改变”人但可以改进系统和流程从而更好地支持人们在设计和维护复杂系统时作出正确选择。当服务中断发生时事后复盘报告并不是走形式。工程师会将其视为一次机会不仅修复服务缺陷也提升组织整体的韧性。一份客观公正的事后复盘报告不应成为宣泄不满或相互指责的场所而应指出服务可以在哪些方面、以何种方式得到改进。以下是两个示例指责式表达“我们需要重写整个复杂的后端系统过去三个季度它每周都会出问题我相信大家都已经受够了这种零零碎碎的修补。说真的如果我再被叫醒一次我就自己把它重写一遍……”无责表达“重写整个后端系统或许能够有效减少这些令人困扰的告警而且当前版本的维护手册很长很难完全掌握。我相信未来的值班人员会感谢我们做出这样的改进。”最佳实践避免指责建立无责复盘机制撰写无责的事故复盘报告并不容易因为复盘报告的格式往往会清晰呈现导致事故发生的具体行为。正因如此在报告中避免追责尤为重要。这样可以让人们更有信心、更无顾虑地向上反馈问题。此外个人或团队频繁撰写事故复盘报告不应被视为羞耻。相反如果组织中充斥着追责氛围就可能滋生掩盖事故和问题的文化从而给组织带来更大的风险。协作与知识共享让事后复盘真正产生价值我们重视协作事后复盘流程也不例外。复盘工作流的每个阶段都包含协作与知识共享。我们的事后复盘文档使用在线协作文档工具并采用内部模板。无论使用哪种工具都应关注以下关键能力实时协作能够快速收集数据和想法这在事后复盘的早期阶段尤为重要。开放式评论 / 注释系统便于众包解决方案并提升问题覆盖范围。通知能力既可以定向通知文档中的协作者也可以邀请其他人提供意见。对于研发团队而言事后复盘不应只是孤立的一份文档而应与目标、需求、开发、测试、发布和知识沉淀形成闭环。例如借助PingCode 这类智能化研发管理工具团队可以将事故复盘中的行动项、缺陷修复、版本发布和 Wiki 知识沉淀串联起来让复盘结论更容易转化为后续研发改进。撰写事后复盘报告还包括正式的审核与发布环节。在实践中团队通常会先在内部分享复盘报告初稿然后邀请一组资深工程师评估其完整性。审核标准可能包括是否收集了关键事故数据以供日后参考是否完成了影响评估根本原因分析是否足够深入行动计划是否恰当由此产生的缺陷修复是否已按合理优先级推进是否已将结果告知相关利益方初步审核完成后事后复盘报告会在更大范围内分享通常会发送给更大的工程团队或内部邮件列表。我们的目标是让尽可能多的人都能从中受益获得必要的知识或经验教训。对于任何可能识别最终用户的信息组织都应设置严格的访问权限即使是事后复盘报告这样的内部文档也不应包含此类信息。最佳实践所有事后复盘报告都应经过审核未经审核的复盘报告就像从未存在过一样。为确保每份完成的草稿都能得到审核我们鼓励定期召开复盘评审会议。在这些会议中重要的是结束所有仍在进行的讨论和评论记录相关想法并最终确定报告的正式版本。一旦相关人员对文档及其行动项感到满意事后复盘报告就会被添加到团队或组织的历史事故库中。透明的共享方式可以让其他人更容易找到这些复盘报告并从中学习。如何在组织中引入事后复盘文化在组织中引入事后复盘文化并非易事它需要持续培养和不断强化。我们通过高层管理者积极参与审核与协作流程来强化这种协作式的事后复盘文化。管理层可以推动和鼓励这种文化但理想情况下无责事后复盘应源于工程师的自我驱动。为了培育事后复盘文化SRE 会积极开展各种活动传播我们从系统基础设施中获得的经验。一些活动示例如下本月复盘报告在每月简报中与整个组织分享一篇有趣且写作质量较高的复盘报告。事后复盘交流小组该小组用于分享和讨论内部及外部的复盘报告、最佳实践以及对复盘报告的评论。事后复盘读书会团队会定期举办事后复盘阅读会。在会上大家会分享一篇有趣或影响较大的复盘报告并准备一些茶点供事故参与者、非参与者以及新入职员工共同讨论事故经过、经验教训以及事故后续影响。通常情况下被讨论的复盘报告已经是几个月甚至几年前的内容。厄运之轮新入职的 SRE 通常会参加“厄运之轮”演练相关内容可参见“灾难角色扮演”。该演练会重现以往事故复盘中的场景由一组工程师扮演复盘中设定的角色。原事故指挥官也会到场以帮助演练尽可能贴近真实情况。在组织中引入事后复盘的最大挑战之一是有些人可能会质疑其价值尤其是在考虑到准备工作所需成本时。以下策略有助于应对这一挑战将事后复盘逐步融入现有工作流。经过一段时间的试运行并完成几次完整、成功的事后复盘后不仅可以证明其价值也有助于确定启动复盘所需的必要条件。确保撰写高质量事后复盘报告成为一种受到奖励和赞扬的行为。这种认可既可以通过前文提到的社交方式公开表达也可以纳入个人和团队绩效管理。鼓励高层领导重视并参与其中。许多海外科技公司的高层管理者都曾公开强调事后复盘的重要性。在复盘文化落地过程中工具的作用并不是替代文化建设而是降低协作和跟进成本。对于需要跨部门推进复盘行动项的团队也可以借助Worktile 这样的通用项目协作系统统一管理任务、项目、文档、日历、审批等内容让事故复盘后的改进措施真正被跟踪、执行和验收。最佳实践公开表彰做正确事情的人某海外大型科技公司的创始人和高管曾主持每周一次的全员大会。该大会在公司海外总部举行并通过网络直播覆盖全球各地办公室。2014 年的一次大会以“事后复盘的艺术”为主题重点讨论了一起影响重大的安全事件。一位 SRE 讲述了他最近推送的一次版本发布。尽管进行了全面测试但一次意外的交互导致一项关键服务中断了四分钟。由于这位 SRE 反应迅速立即回滚变更避免了更长时间、更大范围的宕机因此事故只持续了四分钟。这位工程师不仅因快速、冷静的处理方式立即获得了两份同事奖金还赢得了大会现场观众的热烈掌声其中包括公司创始人以及数千名员工。除这样的公开论坛外该公司还拥有一系列内部社交网络便于同事们对写得出色的事故复盘报告和优秀的事故处理表现给予赞扬。这只是众多例子之一。在这些例子中同事、CEO 以及各级管理者都会对这些贡献给予认可。最佳实践征求对事后复盘有效性的反馈在一些海外科技公司团队致力于及时解决问题并在内部分享创新成果。他们会定期对团队进行调查了解事后复盘流程如何支持目标实现以及该流程还可以如何改进。调查问题可能包括公司文化是否支持你的工作撰写事后复盘报告是否过于繁琐你的团队会向其他团队推荐哪些最佳实践你希望开发哪些工具调查结果让一线 SRE 有机会提出改进建议从而提升事后复盘流程的有效性。除事故管理和后续行动的操作层面之外事后复盘实践已经逐渐融入组织文化。如今在重大事件之后开展全面的事后复盘已成为不少成熟技术团队的文化规范。结论通过事后复盘实现持续改进可以说持续投入资源培育事后复盘文化有助于减少服务中断并提升用户体验。一些海外大型科技公司会设立专门的事后复盘工作组负责协调公司内部的复盘工作统一复盘模板利用事故发生时所用工具中的数据自动生成复盘报告并协助自动化提取复盘报告中的数据以便进行趋势分析。这些公司已经能够在视频、宽带、邮件、云服务、广告和地图等不同产品线之间协作总结和分享最佳实践。尽管产品形态各异但它们开展事后复盘的共同目标始终一致从最艰难的时刻中吸取教训。大型技术组织每月都会生成大量事后复盘报告因此用于汇总和分析这些报告的工具变得越来越重要。这些工具能够帮助团队识别跨产品边界的共同主题和改进领域。为了便于理解和自动化分析一些团队会持续增强事后复盘模板添加更多元数据字段。未来这一领域还会有更多探索包括利用机器学习预测系统薄弱环节、促进实时事故调查以及减少重复事故的发生。