4. 事件管理与风险缓解

第四章：事件管理与风险缓解

引言

现代技术系统错综复杂，由此引发了一系列可能影响其功能、可靠性和安全性的潜在问题。站点可靠性工程师（SRE）最重要的职责之一，就是确保事件得到快速解决，同时最大限度地减少对用户的影响。在本章中，我们将探讨 SRE 背景下事件管理与风险缓解的核心概念。

事件管理是指识别、分析和解决系统事件，以尽可能快速、高效地使系统恢复正常运行。它涉及多项任务，例如识别和分类事件、协调响应工作以及实施纠正措施。我们将探讨成功的事件管理流程的各项要素，以及结构化团队协作与沟通的重要性。

相比之下，风险缓解侧重于主动识别并解决系统中的潜在威胁和弱点，以阻止或减轻事件的影响。本章将教你如何评估风险、确定优先级、进行缓解，并建立一种促进韧性的持续改进文化。学完本章后，你将掌握管理和减少系统中事件与风险所需的知识和技能，从而确保为用户提供可靠且安全的服务。

结构

在本章中，我们将涵盖以下主题：

• 事件管理的目的
• 事件优先级划分
• 事件严重级别
• 事件响应计划
• 需要考虑的风险
• 分析风险
• 减少生产事件的最佳实践
• 风险与缓解
• 风险缓解的最佳实践

目标

在本章中，我们将讨论事件管理流程，以便在尽可能快地恢复服务正常的同时，限制对业务运营的影响，并保持约定水平的服务质量。

事件管理的目的

事件管理流程的目标是在尽可能减少对业务运营的负面影响、维持约定服务质量水平的前提下，尽快恢复正常的服务运营。

任何管理过在线服务的人都知道，生产环境中可能会出现意外问题。无论你的设计有多么容错，也无论你的发布流程有多么严谨，总会出现用户无法正常使用服务的情况。

你付出了大量努力来创建一个受欢迎的服务。你添加新功能以取悦现有客户并吸引潜在新客户。部署一项新功能（或任何变更）会增加发生事件或出现最终用户可见问题的可能性。生产中的事故可能会损害与客户的关系。在可靠性与产品速度之间找到平衡，对于业务增长和用户留存至关重要。好处是，一旦你找到了这个平衡点，就可以同时提升可靠性和功能交付速度。

更多关于软件风险

你可能期望 Google 设计出万无一失的服务。但在某个临界点之后，进一步提高服务的可靠性对其自身及其用户来说就不再是可取的。极端的可靠性会限制新功能开发的迭代速度。商品可以交付给用户，但会大大增加其成本，从而减少团队能够提供的功能数量。用户无法区分高可靠性与极端可靠性之间的差异，因为他们的体验主要受制于蜂窝网络或设备等可靠性较低的组件。智能手机用户无法分辨 99.99% 和 99.999% 可靠性之间的区别。SRE 将不可用风险与快速创新和高效服务运营结合在一起，以增强用户的功能、服务和性能。

事件优先级划分

为某个情况分配优先级，不仅有助于驱动有关响应流程的决策，还能为其他人提供有用的背景信息。在回顾某个事件时，优先级会立即给出一个明确的指标，表明之前已进行的评估。在事件首次创建时或触发后，该事件的优先级可以被更改。作为参考，我们将考虑任何 SRE 中都非常常见的几种情况，以及如何通过正确的分类来处理它们。请看下表：

事件优先级	影响：人员与服务	严重性：时间 严重性	3-低	2-中	1-高
		影响	用户无法执行部分工作	用户无法执行关键时效性功能	关键服务的大部分不可用
低-3	一两名人员	服务水平降级但仍满足 SLA	低	低	中
中-2	一个物理位置的多个人员	服务水平降级至或低于 SLA	中	中	高
		事件原因涉及多个功能领域
高-1	特定区域的所有用户	多个区域的人员受到影响。面向客户的服务不可用	高	高	高

表 4.1：事件优先级划分

现在让我们讨论前面提到的场景。作为一名 SRE，理解事件的性质及其对业务的影响至关重要。考虑一个例子：有些人无法执行某些任务。这会导致重大的业务损失吗？会影响公司形象吗？答案是否定的。我们可以轻松地将这类事件归入低类别。但是，尽快解决问题也很重要，因为到目前为止，我们还不知道出了什么问题，也不知道稍后会有多少人受到影响。考虑下一个场景：一个物理位置的多人受到影响，并且主要流程已失败。这显然是业务损失；我们将把它分类为高优先级事件，必须在服务等级协议（SLA）内修复。

事件严重级别

事件的严重级别用于衡量事件对公司的潜在影响。严重级别有助于 IT 和 DevOps 团队理解影响并确定修复的优先级。你的严重性评估值（SEV）级别定义得越清晰，团队中的每个人就越可能步调一致，并正确响应问题。有了明确定义的严重级别，就可以节省宝贵的时间——原本用来识别和解释事件紧急程度的时间，现在可以用于解决问题。

严重级别的使用

对大多数团队来说，SEV 级别的主要好处是节省时间。一个定义了严重级别并制定了每个级别处理计划的团队，可以迅速行动以实施解决方案。有了预定义的严重级别，团队可以在重大危机的头几分钟内节省宝贵时间，无需费力判断情况的严重性、分配责任和制定计划。

计划好的事件解决和沟通，以及明确定义的 SEV 和优先级，可以在处理重大事件时显著缩短响应时间。

严重性与优先级的区别

初次审视时，事件严重性和事件优先级可能看起来是同义词。似乎理所当然地认为，危及生命的紧急情况应当优先于不那么紧急的事项，对吧？

然而，对大多数公司来说，情况要复杂得多。严重性 衡量的是损害程度。事件对用户的影响有多严重？整个基础设施是否面临风险？是否阻止他们完成必要的工作？这可能会造成烦恼并增加额外工作量。

相反，优先级是一种对重要程度进行排序的方式。我们需要在多长时间内解决这个问题？哪个问题应该最先处理？

但优先级和严重性并不总是匹配。例如，假设你网站上的“关于我们”页面显示时未对齐。这不算大问题，因为它不影响网站的功能。用户可以继续做他们需要做的事情。专业人员仍然可以完成他们的工作。

但企业可能认为修复它很重要，因为它影响品牌形象、引起困惑或只是让公司看起来不专业。因此，这可能是一个低严重性但高优先级的事件。

定义事件严重级别

每个公司响应事件的方式都不同。在确定严重级别以及相关的流程和期望时，不仅应考虑事件的影响，还应当考虑以下几点：

• 你的技术团队有多少人
• 值班安排
• 你的服务一天中最繁忙和最空闲的时间
• 考虑事件发生率

让我们进一步了解可能考虑到的严重级别范围，以及它们对组织和领域专家的意义。请看下图：

图 4.1：事件严重级别

事件响应计划

不同组织的具体流程细节可能略有不同，但基本框架是相同的。图 4.2 展示了以下流程：

图 4.2：事件响应计划流程

根据 Exambeam 的解释，事件响应计划通常包括：

• 公司如何处理事件以及与其整体目标的关系。
• 事件响应角色与职责。
• 处理事件每个阶段的详细说明。
• 危机响应人员、公司其他部门以及外部各方之间共享信息的协议。
• 如何利用以往事故的经验教训来加强当前和未来的安全性。

需要考虑的风险

在讨论风险时，尝试将其映射到不同的类别非常重要，例如与你的依赖项、监控、容量、运营和发布流程相关的风险。对于每一类，要考虑如果某些事情出错会发生什么，比如第三方宕机，或者应用程序或配置中存在 Bug。因此，在考虑你的大小时，你应该问自己以下问题：

• 是否存在任何明显的漏洞？
• 你是否已为此 SLI 设置了告警？
• 即使现在，你是否仍在收集这些指标？

同时，确保映射监控和告警方面的任何依赖关系。例如，如果你使用的某个托管系统宕机了，会发生什么？

在一个关键用户旅程中，你应当尝试找出每个组件每个故障点的风险。一旦发现这些风险，你将需要衡量以下内容：

• 有多少客户受到了该问题的影响？
• 你认为出现问题有多频繁？
• 花了多长时间才弄清楚出了什么问题？

另外，了解过去一年发生的任何事件也很有帮助。使用历史数据而不是凭直觉，可以为你提供准确的估算并为实际事件提供一个良好的起点。例如，你可能想要考虑以下情况：

• 系统配置错误，导致其能处理的请求数量减少。
• 新版本发布导致少量请求失败，但问题一天后才被发现。问题被发现后，回滚很容易。
• 云服务提供商的单可用区虚拟机/网络故障。
• 云服务提供商的一个区域的虚拟机/网络故障。
• 操作员意外删除了数据库，需要从备份中恢复。

另一个需要考虑的话题是风险因素。这些是影响整体检测时间（TTD）和修复时间（TTR）的全局因素。大多数情况下，这些是运营因素，可能会延长发现故障（例如使用基于日志的指标时）或通知值班工程师的时间。缺乏手册、文档或自动化流程可能是另一个例子。除此之外，你还面临以下情况：

• 由于运营过载（例如告警噪音），预计检测时间（ETTD）增加了 +30 分钟。There is a

4. 事件管理与风险缓解

如果没有事后复盘（post-mortems）或对行动项进行跟进，发生问题的概率会高出 17%。

---

分析风险

本节概述了在事件发生期间分析风险的方法。最有效的风险缓解方法是缩小潜在的业务影响范围。

生产事故生命周期

当服务的最终用户受到不利影响时，就发生了生产事故。服务运行的环境及其所处环境总是在不断变化。例如，新用户激增或基础设施故障（坏消息）都可能危及服务的可靠性。生产事故是流程或配置演变过程中不可避免的不良结果。根据 Google 的一项调查，客户满意度会在某些节点下降甚至降低。请看下图：

图 4.3：生产事故生命周期
（此处应插入原图，描述生产事故从发生到恢复的典型阶段）

可靠性的成本

如果保持高于服务等级目标（SLO）的可靠性能够满足大多数用户，那么目标应该比 SLO 高多少？你低于 SLO 的程度越深，用户就越不满意。然而，令人吃惊的是，当你的 SLO 超过期望水平时，用户对可靠性的重视程度会逐渐降低。你仍然会遇到事件，客户也会注意到它们。但只要你的服务平均高于 SLO，事件发生的频率就足够低，用户仍会感到满意。换句话说，一旦达到 SLO，进一步提高可靠性对用户不再有益。可靠性是昂贵的。除了工程工时外，还有错失的机会成本。例如，可靠性要求可能会拖慢产品的上市时间。此外，可靠性成本通常是指数级的。这意味着运营一个可靠 10 倍的服务，成本可能高出 100 倍。你的 SLO 设定了一个低于 100% 的最低可靠性标准。但如果你高于 SLO，则意味着你在可靠性上支付了超出必要的费用。好消息是，你可以将错误预算（即超出需求的可靠性）用于比维持用户不可见的冗余可靠性更有价值的事情。例如，你可以更频繁地发布版本、针对生产基础设施运行压力测试以发现隐藏问题，或让工程师专注于功能而不是可靠性。高于 SLO 的可靠性仅作为缓冲，防止用户看到你的不稳定。稳定你的可靠性，以最大化错误预算的投资回报。

---

响应计划

事件响应团队在发生安全漏洞时应遵循以下五个步骤：

1. 识别（Identification）： 当发现事件时，团队应能够快速识别组织系统中的异常，收集更多证据，确定事件的严重程度，并记录谁（Who）、什么（What）、哪里（Where）、为什么（Why）以及如何发生（How）。
2. 分类（Categorization）： 在进行任何恢复之前，必须将故障类型归类为轻微、中等或严重。
3. 优先级（Prioritization）： 一旦发现安全漏洞，团队的首要任务是止血并恢复正常运行。临时隔离措施，例如移除受损的生产服务器或隔离网络部分。永久隔离措施包括在使用不完善的系统进行临时生产的同时，从头开发改进的解决方案。
4. 响应（Response）： 团队谨慎地恢复受损的生产系统，以防止问题再次发生。此步骤的重要决策包括确定从哪个时间点开始恢复操作，以及确定如何验证受影响的系统和活动已恢复正常。
5. 关闭（Closure）： 清除（Eradication）应是生产事件关闭的支持要素。建议在事件结束后两周内执行此步骤，此时细节在每个人脑海中仍然清晰。

记录事件、进行更多研究以确定其全部范围、找出响应团队表现出色的地方以及确定可以改进的地方，这些都是复盘阶段的目标。请看下图：

图 4.4：事件响应计划
（此处应插入原图，展示响应计划的五个步骤流程）

---

减少生产事故的最佳实践

最佳实践如下：

建立并不断更新 SLO

当 SRE 讨论可靠性时，SLO 通常被频繁提及。它们为错误预算奠定了基础，并指定了你希望服务达到的可衡量可靠性水平。SLO 会影响整个生产事故周期，因为它们决定了你在准备工作中需要投入多少精力。换句话说，SLO 影响整个周期。你的客户是否需要高于 90% 的 SLO？也许你当前使用的全量发布就足够了。你需要 99.95% 的 SLO 吗？如果是这样，可能是时候考虑投资增量发布和自动回滚了。在发生事件时，SLO 为你提供了量化影响的基础。也就是说，它们能让你知道什么时候情况很糟，更重要的是，糟糕到什么程度，用你的整个组织（从值班人员到高层管理人员）都能理解的语言表述。

撰写事后复盘报告

Google Cloud CRE 负责人 Dave Rensin 喜欢将生产事件视为意外投资，所有成本都已预先支付。这是他对生产事故的看法。你可能需要弥补收入损失，并用生产力下降为代价。你总是用用户的善意来支付。你从中学到的关于避免（或至少减轻）未来生产事件影响的教训，就是你从这项投资中获得的回报。事后复盘是从情境中汲取宝贵经验教训的方法。它们记录了发生的事情和原因，并指出需要改进的领域。可能需要一天或更长时间，但撰写详尽的事后复盘是值得的，因为你可以收回意外投资的价值，而不是让它白白流失。

确定个人责任

实现这一目标的第一步是建立问责制。首先分析数据，根据已建立的参数对事件进行分类，并为每个类别找到负责人。在组织范围内拥有一致的指标有助于减少事件数量，而处理这些事件的负责人可以通过降低数字而得到适当的奖励。

预防因变更引发的事件

最后，鼓励有效的变更管理系统。任何时候对应用程序或基础设施进行修改，都可能出现问题。例如，发布测试覆盖不足的更新可能导致严重事故。专业人员有责任预测变更的负面效应，并想出减轻这些效应的策略。应分析与变更相关的事件，识别变更管道中潜在的风险驱动因素，跟踪趋势，并将变更按适当的类别划分优先级。数据挖掘是一个好方法。访问大量数据可能是有利的，许多企业现在都在使用超越常规运营报告方法的技术。简单的实例分析可能无法揭示全部信息。通过将事件数据与相邻数据源匹配，获得所发生事件的完整画面。审计记录、故障报告和修订历史等数据可能已经大量存在。利用这些数据来了解事件减少背后的“为什么”。

另一个企业可以利用的宝贵资源是文本分析。为了理解事件数据，分析自由格式的数据（如描述、评论、工作备注等）以发现关键字是很有用的。例如，假设搜索 Webex 返回了数十个事件。然而，发现这些情况的解决时间出奇地短。

---

风险与缓解

SRE 学科致力于确保复杂系统的性能、安全性和可靠性。有效的事件管理和针对系统故障、性能降级和安全漏洞的风险缓解是 SRE 的基本组成部分。在本节中，我们将深入探讨事件管理背景下风险与缓解的细微差别，强调这两个概念的相互关联性，并提供构建弹性系统的富有洞察力的建议和方法。

为了最大限度地减少系统事件对用户的影响并迅速恢复正常运行，事件管理包括快速定位、分析和解决事件。另一方面，风险缓解涉及主动识别和解决系统中的潜在威胁和漏洞，以预防或减少事件发生的可能性和影响。事件管理与风险缓解的重叠在于它们共同的目标是维护系统安全性和可靠性，其中事件管理更侧重于反应性策略，而风险缓解更侧重于主动性策略。

SRE 必须首先识别可能影响其系统的潜在威胁和漏洞，才能有效管理风险和事件。风险评估需要彻底检查系统的架构、组件、依赖关系、周围环境以及潜在的外部因素。全面的风险分析应考虑多种因素，包括硬件故障、软件缺陷、人为错误和安全漏洞。通过主动识别风险，SRE 可以预见到潜在事件，并采取预防性措施来避免或减轻它们对系统性能和可靠性的影响。

在识别出潜在风险后，下一步是根据它们再次发生的可能性以及对系统可能产生的影响进行评估和排序。这种优先级排序使 SRE 能够更有效地分配资源，并首先集中精力解决最重要的风险。常用的风险优先级排序技术包括风险矩阵和定量风险评估，后者为每种风险的可能性和影响分配数值，从而实现客观比较。

对风险进行优先级排序后，SRE 可以制定有效的缓解计划，以降低其可能性或影响。风险缓解有几种重要方法，包括：

• 预防（Prevention）：实施策略以消除风险的根本原因或降低其可能性。修补已知的软件漏洞、实施严格的访问控制和使用冗余硬件组件是一些预防措施。
• 检测（Detection）：实施监控和告警系统，尽早检测到事件和潜在风险。早期检测可以实现更快的响应和解决，从而减少对系统可靠性和性能的影响。
• 遏制（Containment）：建立程序和控制在事件发生时减少其影响。可以使用流量限制、隔离受影响组件或使用备用系统等技术来实现这一点。
• 恢复（Recovery）：确保具备适当的策略和工具，以便在事件发生后快速有效地恢复正常操作。这包括制定明确的事件响应流程、备份计划、灾难恢复计划，并定期测试这些流程。

4. 事件管理与风险缓解

页面：110–134

风险缓解的最佳实践

作为SRE，以下是一些风险缓解的最佳实践：

• 风险评估：定期进行全面风险评估，以检测整个系统中潜在的漏洞和威胁。作为SRE，需考虑各种因素，例如硬件故障、软件缺陷、人为错误和安全漏洞。随着系统演进和新信息的出现，审查并更新风险评估至关重要。
• 风险优先级排序：根据风险发生的概率和对系统的潜在影响，评估并确定风险的优先级。优先缓解高风险因素，并相应分配资源。使用风险矩阵或定量风险评估，以便进行客观比较。
• 实施预防措施：作为SRE，主动实施预防措施以消除或降低风险发生的可能性非常重要。你的职责可能包括修补软件漏洞、实施严格的访问控制、使用冗余硬件组件以及推行安全编码实践。
• 建立监控和告警系统：作为SRE，建立强大的监控和告警系统以便及时识别事件和潜在风险至关重要。早期发现有助于更快响应和解决，减少对系统性能和可靠性的影响。
• 规划遏制与恢复：制定流程和控制措施以限制事件的影响，例如流量限制、隔离受影响组件或利用回退系统。建立清晰的事件响应流程、备份和灾难恢复策略，并定期测试以确保其有效性。
• 培养持续改进的文化：鼓励一种拥抱持续改进并从事件中学习的文化。进行事后复盘（post-mortems）以分析事件、确定根本原因并实施纠正措施。跨团队分享经验教训，防止未来发生类似事件。
• 跨职能协作：促进开发、运维、安全及其他利益相关者之间的协作，确保风险管理是一项集体责任。鼓励开放沟通和知识共享，让相关团队参与风险评估和缓解工作。
• 拥抱自动化：自动化重复且容易出错的任务，以最小化人为错误的风险。使用自动化测试、部署和监控工具，确保流程的一致性和可靠性。
• 规划容量与可扩展性：预测未来容量需求并相应扩展系统，以最小化性能下降和停机的风险。使用容量规划技术和工具来预测需求，并部署自动扩缩容解决方案以应对意外的流量高峰。
• 评估第三方依赖的风险：第三方依赖（如库、框架、服务提供商）可能构成严重威胁。作为SRE，选择可靠且维护良好的解决方案非常重要，同时避免在系统中过度依赖任何一个依赖项。
• 规划风险转移策略：在某些情况下，可能需要通过将风险转移给第三方来实施风险转移策略。这可能是一种更高效且更具成本效益的方法。作为SRE，可以考虑购买保险、将特定系统组件委托给专家供应商，或利用提供冗余和故障转移功能的云服务等选项。

将这些做法融入SRE流程中，你可以有效地管理和缓解风险，确保你的系统持续为用户提供可靠、安全且高性能的服务。

结论

总之，本章全面概述了站点可靠性工程中事件管理与风险缓解的关键方面。我们探讨了事件管理的复杂性，强调了快速识别、分析和解决系统事件以保持运维稳定性和用户满意度的重要性。此外，我们还强调了结构化团队协作和有效沟通在确保事件管理流程成功中的重要性。

此外，本章深入探讨了风险缓解的主动方法，即重点是在潜在威胁和漏洞破坏系统功能之前识别并解决它们。通过这里提供的指导，读者可以深入了解风险评估、优先缓解工作以及培养持续改进文化以增强系统弹性。

在第5章“错误预算”中，读者将学习错误预算——基于预定义SLO的系统可接受不可靠性水平。该章强调了平衡可靠性与创新的重要性，并教授如何定义、测量和管理SLO与SLI。读者还将学习有效的错误预算管理策略、SRE与开发团队之间的协作，以及将错误预算融入组织文化以推动更好决策、保持对用户满意度和系统性能的关注的重要性。

多选题

1. 以下哪项不是有效事件管理流程的关键组成部分？

   • a. 事件检测与分类
   • b. 事件响应与解决
   • c. 向第三方转移风险
   • d. 事后复盘与改进

2. SRE进行风险缓解的主要目标是什么？

   • a. 增加事件发生频率
   • b. 最小化事件发生的概率和影响
   • c. 最大化系统停机时间
   • d. 忽略潜在威胁和漏洞

3. 哪种风险缓解策略涉及实施措施以消除或降低风险发生的可能性？

   • a. 检测
   • b. 预防
   • c. 遏制
   • d. 恢复

4. 在事件管理与风险缓解的背景下，主动措施和被动措施的主要区别是什么？

   • a. 主动措施侧重于预防事件，而被动措施侧重于事件发生后的处理。
   • b. 主动措施涉及团队间协作，而被动措施由个人执行。
   • c. 主动措施由管理层实施，而被动措施由技术人员执行。
   • d. 主动措施需要使用外部工具，而被动措施可以手动执行。

5. 事件后进行事后复盘分析的主要目的是什么？

   • a. 为事件归责
   • b. 识别根本原因并实施纠正措施
   • c. 评估事件的财务影响
   • d. 评估个别团队成员的表现

6. 哪种技术通常用于根据风险发生的可能性和对系统的潜在影响来确定风险优先级？

   • a. 风险矩阵
   • b. 事件分类
   • c. 容量规划
   • d. 告警阈值设置

答案

1. c
2. b
3. b
4. a
5. b
6. a

---

来源

1. Exambeam
2. https://cloud.google.com/blog/products/devops-sre/shrinking-the-impact-of-production-incidents-using-sre-principles-cre-life-lessons

---

加入我们书籍的Discord空间
加入书籍的Discord工作区，获取最新更新、优惠、全球技术动态、新版本发布以及作者参与的会议：
https://discord.bpbonline.com

4. 事件管理与风险缓解

页码范围： 110–134
描述： 讲解事件优先级、严重级别、响应计划及减少生产事故的最佳实践

图像

• 图片1912（第117页）
• 图片1919（第118页）
• 图片1927（第121页）
• 图片1934（第123页）
• 图片600（第134页）