共享事故复盘如何提升客户可靠性：SRE 与 CRE 实践经验

本文将探讨如何与受影响的客户共同回顾事故分析报告，从而获得更具可操作性的洞察，并帮助客户改进其系统架构和运维实践。对于采用 SRE 体系的团队而言，事故复盘、服务等级目标（SLO）和错误预算不仅能帮助平台方改进服务，也能帮助客户提升自身系统的可靠性。文中还将提供一个基于通用 SRE 事故分析报告模板的共享复盘示例。

事故复盘不应只服务于平台方，也应真正帮助客户。

如何让一次服务中断成为所有人的经验

即使故障完全发生在平台侧，对外共享的事故复盘仍然可以帮助客户提升自身系统的可靠性。既然我们已经了解了某次特定故障的发生过程，就应进一步思考：如何将这些经验推广到更广泛的场景中，帮助客户减轻类似事件的影响，并在未来降低平均故障检测时间（MTTD）和平均故障修复时间（MTTR）？

开展事故复盘时，客户的服务等级目标（SLO）是最有价值的数据来源之一，因为它能够帮助衡量平台中断对客户业务造成的实际影响。客户可靠性工程（CRE）团队在实践中会反复讨论 SLO，原因正在于此：SLO 和错误预算并不只是用来决定是否可以发布新功能，它们同样可以帮助团队理解故障影响、评估风险，并推动后续改进。

对于已经设定 SLO、且错误预算因故障被显著消耗的客户，我们建议与其共同开展事故复盘。复盘的目的不仅是确认客户的关切已经得到回应，更重要的是共同梳理：哪些方面进展顺利，哪些地方出了问题，哪些因素只是侥幸，以及接下来应采取哪些行动，才能帮助客户在未来更好地应对类似问题。

例如，假设某平台的存储服务在某一云区域内，针对特定类型对象出现了延迟升高的问题。这并不是客户造成的故障，但客户仍然可能通过改进监控、演练和故障转移流程来降低业务影响。

平台方的内部事故复盘报告可能如下所示。

哪些方面进展顺利

与某客户共同建设的共享监控显示，单一区域的延迟出现明显上升，因此问题得以快速升级给存储服务值班团队处理。

哪些地方出了问题

存储前端的新版本在处理未缓存读取请求时出现性能下降，但该问题未能在测试或部署过程中被发现。

哪些方面比较幸运

只有读取大小在 4KB 到 32KB 之间的对象受到了实质性影响。

行动项

在测试中，针对缓存对象和非缓存对象，分别为 1KB、4KB、32KB 等不同对象大小分桶增加明确的读写延迟测试。

设置可触发值班响应的告警：当延迟超过 SLO 限制时，按云区域聚合，并区分缓存对象与非缓存对象，同时按 1KB、4KB、32KB 等对象大小分桶进行监控。

当客户基于共享事故分析报告撰写自己的复盘报告，以便更好地理解平台故障发生的原因、时间和影响时，其报告可能如下所示。

哪些方面进展顺利

我们预先考虑过通用的单区域平台故障场景，并具备从受影响区域进行故障转移的能力。

哪些地方出了问题

虽然延迟升高很快被检测到，但我们缺少可访问的全栈监控，无法直接判断延迟究竟来自平台存储服务，还是来自我们自己的后端服务。

由于我们已经一年没有进行相关演练，且操作手册也已经过时，因此我们花了将近 30 分钟，才完成从受影响区域撤离的决策。

哪些方面比较幸运

事件发生在工作时间内，因此我们的开发团队可以随时响应，协助诊断问题原因。

行动项

新增明确的仪表盘，用于监控平台存储服务的聚合读写延迟。

定期进行区域故障转移测试，至少每季度一次，以验证故障转移指引仍然有效，并增强运维团队对该流程的熟悉度和信心。

确定事故复盘行动项优先级并跟踪进展

只有根本原因被彻底解决，事故复盘才算真正完成。

然而，向客户共享事故复盘行动项的当前状态并不容易。客户很可能不会使用与平台方相同的问题跟踪系统，因此双方都无法实时查看复盘中的哪些行动项已经完成、哪些仍未解决。

在一些海外公司内部，团队会通过自动化流程跟踪这些行动项，并在事故复盘中提示哪些关键行动项仍未完成。但除非这些信息被发布到问题跟踪系统中对外可见的部分，否则客户无法看到它们；而出于流程和权限管理方面的考虑，这通常并不是常规做法。

目前，我们会与每位客户每月进行一次 SLO 评审。在评审中，我们会列出重大事件，以及每个事件对应的后续分析或事故报告；同时，我们也会利用这一机会汇报此前事件中尚未解决的关键缺陷状态，并检查客户侧行动项的推进情况。在这类场景中，团队也可以借助 PingCode 这类智能化研发管理工具，将 SLO 评审、事故行动项、需求排期、测试发布和复盘知识沉淀串联起来，让事故改进从“记录下来”真正走向“持续推进”。

共享事故复盘的其他收益

开诚布公本身就是一种机会

共享事故复盘报告不仅能带来切实的可靠性提升，还具有其他多方面的价值。对于正在向 SRE 文化转型、并开始采用无责复盘机制的客户而言，对外共享的事故复盘报告可以作为撰写内部复盘报告的参考模板。

我们首先要承认，从零开始撰写第一份事故复盘报告确实很困难。如果团队手头有一系列“已经被验证为优秀”的复盘报告可供参考，将会非常有帮助。

从更高层面来看，共享复盘报告也能让客户“一窥幕后”。当客户从本地硬件迁移到云端时，难免会感到不安，因为他们放弃了对服务运行平台的许多控制权和可见性。人们通常期望云平台能够封装其所提供服务的运行细节，但遗憾的是，这种封装有时也会隐藏客户真正想了解的信息。

一份详尽的对外复盘报告，可以把这些信息呈现在客户面前，提供完整时间线和更深入的技术细节。更重要的是，它能够帮助客户将平台侧故障与自身系统表现联系起来，从而形成更完整的事故认知。

联合事故复盘：与客户共同提升系统可靠性

如果希望开展联合行动，就需要进行联合事故复盘。

共享复盘的最后一步，是创建联合事故复盘报告。到目前为止，我们讨论的主要是如何将现有文档对外共享：例如，由平台方撰写行动项，并将其分配给平台方自己。然而，对于某些客户而言，开展联合事故复盘会更有意义。在这种模式下，平台方和客户都可以为文档的各个部分做出贡献。

这样的报告不仅会反映平台方对事件的思考，也会记录客户的观察、判断和反馈。它甚至可以包含平台方分配给客户的行动项，也可以包含客户分配给平台方的行动项。对于跨部门或非研发团队较多的联合复盘，也可以使用 Worktile 这类通用项目协作系统，把任务、文档、日历、审批和沟通协同放在同一流程中，降低复盘后续推进的沟通成本。

当然，平台方不可能与大量客户都开展联合事故复盘。但至少与其中几位关键客户进行联合复盘，可以帮助我们实现两个目标：其一，建立共同的 SRE 文化；其二，在调试、设计和规划工作中持续保留客户视角。

联合事故复盘也是说服产品团队重新调整产品路线图优先级的有效工具之一，因为它能够清晰展现最终用户可以如何预防或减轻未来故障带来的影响。