SRE 事件管理实践：一次故障响应、回滚与事后复盘的真实案例

你有没有想过，当一家大型海外互联网公司的核心服务出现问题时，内部会如何进行 SRE 事件管理和故障响应？在技术行业里，我们常用“救火”来形容处理线上故障的过程。

当然，和真正的消防员不同，工程师面对的大多数事件通常不会直接危及生命安全。尽管这个比喻并不完全贴切，但 SRE（站点可靠性工程师）与其他领域的应急响应人员确实有许多相通之处。

和其他应急响应人员一样，SRE 也需要定期进行应急演练，持续打磨在问题发生时快速、有效应对所需的技能、工具、方法和心态。

在应急服务领域，以及一些成熟的海外技术团队内部，当系统出现问题时，通常会将其称为“事件”。事件管理的目标，就是在影响扩大之前快速识别问题、协调资源、恢复服务，并在事后总结经验，降低类似问题再次发生的概率。

这是我作为一名 SRE 经历的第一个“事件”的故事。

序章：SRE 值班前的准备

过去几个月里，我一直在某海外云计算服务的 SRE 团队轮岗。我参加了一周的 SRE 综合培训；通过每周的同伴培训和项目实践，学习这项云计算服务的相关知识；每周参加“厄运之轮”演练，面对典型的值班问题并尝试解决；跟随值班工程师工作，协助他们处理问题；还担任过副值班，协助主值班处理紧急事项，并独立处理一些不那么紧急的问题。

经过这一系列准备，迟早有一天，你需要走到最前线：成为第一响应人，承担主要职责。

编者注：《站点可靠性工程》第 28 章“加速 SRE 进入随叫随到及更高阶段”详细介绍了成熟技术团队如何培养新的 SRE，使其逐步具备随时担任第一响应人的能力。

SRE 值班：从告警到第一响应

作为一名 SRE，工作远不止值班。按设计，值班只占 SRE 工作量的一小部分，但它至关重要。这不仅是因为系统出故障时必须有人响应，更因为值班经验能帮助我们更好地理解并开展 SRE 的其他工作。

我第一次值班时，告警系统两次将我作为一级值班人呼叫；另外还有两个问题由其他同事转交给我。每次收到呼叫，我都会感到肾上腺素飙升。我心想：“我能应付吗？万一处理不了怎么办？”

但随后，我开始像培训时那样处理眼前的问题，并逐渐意识到：我不需要知道所有答案。我可以向别人求助，而他们也会回答我的问题。我也许能够胜任，但我并不是孤军奋战。

编者注：《站点可靠性工程》第 11 章“值班”提供了许多关于如何组织值班职责的建议，帮助团队长期、有效地承担值班工作。

宣布事件：一次真实的故障响应开始了

我收到的四次传呼中，有三次并不严重。第四次则要“有意思”得多。

一位工程师在使用某海外云计算服务运行自己的服务时，遇到了自动化测试失败的问题。进一步调查后，他发现部分实例存在异常。于是他通知了开发团队的主值班工程师，主值班工程师又把情况转给了我。我联系了一位更有经验的副值班工程师。随后，我们几个人和开发团队的其他成员一起展开调查。

很快，我们确认这是一个真实存在的问题。由于没有理由认为问题影响仅限于最初报告此事的内部客户，我们宣布了一起事件。

那么，宣布事件意味着什么？

原则上，这意味着某个问题具有足够高的潜在影响、影响范围或复杂性，需要多方协调、明确分工，才能得到有效管理。你在某些海外云服务状态页上看到的事件摘要，背后通常都曾由内部员工正式宣布为事件。实际操作中，在这类大型技术团队内部，宣布事件通常意味着在内部事件管理工具中创建一条新的事件记录。

作为值班培训的一部分，我学习过事件管理协议的基本原则，也接受过内部事件响应工具的使用培训。事件管理协议会明确规定相关人员的角色与职责。前面提到，SRE 与其他应急响应人员有许多相似之处。因此并不令人意外的是，成熟技术团队的事件管理流程往往会借鉴其他应急响应领域中已经验证过的事件指挥体系，并与之保持相似的思路。

在这次事件中，我担任事件指挥官。宣布事件后不到七分钟，支持团队的一名成员就接手了对外沟通的角色。虽然这次事件中我们没有正式指定其他角色，但事后回看，开发团队的主值班工程师实际上承担了行动负责人的职责：她主导了根因调查，并在需要时召集更多人参与。那位更有经验的副值班工程师则相当于助理事件指挥官。我会向他确认一系列判断，例如：“我认为我们应该做 X、Y 和 Z。你觉得合理吗？”

有效事件响应的关键之一，是事件响应人员与可能受到影响的其他人员之间保持清晰沟通。事件管理工具本身就是实现这一目标的重要组成部分。它是一个集中平台，员工可以通过它了解服务中正在发生的任何事件。该工具还会引导员工访问其他相关资源，例如问题跟踪系统中包含更多细节的问题单，或用于协调事件响应的沟通渠道。对于研发团队来说，如果希望把事件记录、问题跟踪、发布变更、测试反馈和知识沉淀串联起来，也可以借助 PingCode 这类智能化研发管理工具，让故障响应过程中的信息在不同研发环节之间更顺畅地流转。

编者注：《站点可靠性工程》第 12、13 和 14 章分别讨论了有效的故障排查、应急响应和事件管理。

回滚机制：SRE 故障恢复的关键手段

我们中的一部分人开始评估问题范围，另一部分人则寻找直接原因和根本原因，以便尽快采取措施缓解事件影响。最终，我们确认问题范围相对有限，而原因可以追溯到一次正在逐步发布的版本变更。

这种情况非常常见。生产系统中的大多数问题都由变更引起，例如新的配置、新的二进制文件，或者你依赖的某个服务进行了变更。面对这种常见情形，有两项最佳实践尤其重要。

首先，所有非紧急变更都应分阶段发布。也就是说，不要一次性改动所有内容。这样一来，你就有机会在问题扩大、影响大量客户之前发现它们，就像这次事件一样。

其次，所有部署都应该配备完善且经过充分测试的回滚机制。这意味着，一旦确认是哪项变更导致了问题，你就可以按下“撤销”按钮，使服务恢复到正常状态。

在追求服务级别目标（SLO）的过程中，通过渐进式发布控制问题规模，再借助可信赖的回滚机制快速缓解问题，是两项非常有力的工程手段。

这次事件也遵循了同样的模式：我们在问题规模还很小时发现了它，并通过回滚迅速解决了问题。

编者注：《站点可靠性工程》第 36 章“生产服务最佳实践集锦”更详细地讨论了这些以及其他最佳实践。

事后复盘：从一次事件中沉淀可靠性经验

回滚完成后，问题得到缓解，我宣布事件“结束”。此时，事件管理工具贴心地生成了一份事后复盘文档，供事件响应人员协作完善。如果继续沿用消防的比喻，这就像消防队长在火灾结束后分析火情和处置过程，以找出未来如何预防类似火灾，或如何更高效地应对类似火灾。

成熟的工程团队通常会强调“不追责”的事后复盘文化。也就是说，当问题发生时，不应该急于寻找替罪羊或惩罚对象。很可能，事件中的相关人员都怀有良好意图，具备足够能力，并且已经基于当时掌握的信息尽力做出了最佳判断。

如果你想带来持久改变，避免未来再次出现类似问题，就需要关注人员所处的系统、工具和流程如何改进。只有这样，才能从根本上降低类似问题再次发生的可能性。

尽管这次事件影响相对较小，相关缺陷本身也比较隐蔽，事后复盘仍然确定了九项具体后续行动。这些行动有望帮助我们在未来避免类似问题再次发生，或者在类似问题出现时更快发现并解决。九项行动都已记录在问题跟踪系统中，并指定了负责人，便于后续评估、研究和推进。

后续行动并不是事后复盘的唯一成果。由于团队会对每一起事件进行事后复盘，并且使用统一的复盘文档模板，因此可以进一步分析整体趋势。例如，正是通过这种方式，一些海外技术团队发现，相当一部分事件都由配置变更引起。下次有人试图说服你，在长周末前的周五晚上发布配置变更是个好主意时，不妨想起这一点。

事后复盘报告也会在相关团队内部共享。例如，在某个云计算服务团队中，团队每周都会召开一次事件回顾会议。事件响应人员会在会上向更广泛的 SRE 和开发人员群体汇报他们的复盘结果。这有助于发现可能被遗漏的后续事项，也能将经验教训分享给整个团队，让每个人都能从这些案例中更深入地思考可靠性问题。对于国内研发团队而言，这类复盘内容也可以沉淀到 PingCode 的 Wiki 中，并与需求、缺陷、测试、发布等研发流程关联起来，让经验不只停留在一次会议里，而是持续转化为团队的可靠性资产。

这也是强化“不追责”事后复盘文化的一种非常有效的方式。我记得有一次，在事后复盘会议上，汇报人试图把问题归咎于自己。会议主持人说：“我很欣赏你愿意承担责任的态度，但我们这里不这样做。”

下次当你在某些海外云服务状态页上看到“我们将对此问题进行内部调查，并对系统做出适当改进，以防止或尽可能减少此类问题未来再次发生”这类表述时，希望你能想起这个故事。

我亲身经历过成熟技术团队处理事件的方式，也可以向你保证：这绝不是一句例行公事的空话。