SRE-架构框架-可靠性

Google-架构框架-可靠性

可靠性概览

Google Cloud 架构框架中的此类别介绍如何在云平台上构建和运营可靠的服务。此外，您还将了解一些支持可靠性的 Google Cloud 产品和功能。

该架构框架介绍了最佳实践，提供了实现建议，并说明了一些可用的产品和服务。该框架旨在帮助您设计 Google Cloud 部署，以便它能够完全满足您的业务需求。

如需运行可靠的服务，您的架构必须包含以下内容：

可衡量的可靠性目标，如有偏差可以及时纠正。
具备可扩缩性、高可用性、灾难恢复和自动变更管理的设计模式。
尽可能自行修复的组件，以及包含可监测性的插桩的代码。
运行服务的操作过程必须将运营人员的手动工作量和认知负担降到最低，同时可让您快速检测并缓解故障。

可靠性是所有工程人员（例如开发、产品管理、运营和站点可靠性工程 (SRE) 团队）的责任。每个人都必须负起责任，了解其应用的可靠性目标、风险和错误预算。团队应该能够适当地确定工作的优先级，并上报可靠性和产品功能开发之间的优先级冲突。

在架构框架的可靠性类别中，您将了解如何执行以下操作：

了解核心可靠性原则
确定您的可靠性目标
定义 SLO
采用 SLO
将可观测性内置到您的基础架构和应用中
在设计时确保可扩缩性和高可用性
创建可靠的操作流程和工具
构建高效的提醒
构建突发事件管理协作流程

可靠性原则

Google Cloud 架构框架中的本文档介绍了在云平台上运行可靠服务的一些核心原则。这些原则有助于在您阅读架构框架的其他部分时，建立共识，了解某些 Google Cloud 产品和功能如何支持可靠的服务。

在架构框架可靠性类别中，使用了以下术语。这些术语对如何运行可靠的服务至关重要。

服务等级指标 (SLI)

“服务等级指标”(SLI) 是对所提供服务的等级的某些方面进行精心定义的定量衡量的指标。它是一个指标，而非目标。

服务等级目标 (SLO)

“服务等级目标”(SLO) 指定服务可靠性的目标等级。SLO 是 SLI 的目标值。当 SLI 等于或高于此值时，该服务被视为“足够可靠”。由于 SLO 是做出有关可靠性的数据驱动型决策的关键，因此它们是站点可靠性工程 (SRE) 做法的焦点。

错误预算

一段时间内“错误预算”的计算方式为 100% – SLO。错误预算可说明您的系统在某个时间窗口内是高于还是低于所需的可靠性，以及该时间段内允许多少分钟的停机时间。

例如，如果您的可用性 SLO 为 99.9%，则 30 天期限的错误预算为 (1 - 0.999) ✕ 30 天 ✕ 24 小时 ✕ 60 分钟 = 43.2 分钟。每当系统不可用时，系统都会使用或消耗系统的错误预算。在上一个示例中，如果系统在过去 30 天内有 10 分钟的停机时间，并且 30 天期限在开始时有 43.2 分钟的未使用总预算，则剩余的错误预算会减少到 33.2 分钟。

我们建议您在计算总错误预算和错误预算消耗率时使用 30 天的滚动窗口。

服务等级协议 (SLA)

服务等级协议 (SLA) 是与您的用户签订的显式或隐式合同，其内容涵盖达成（或未达成）合同中引用的 SLO 而造成的影响。

核心原则

Google 的可靠性理念源于以下核心原则。

可靠性是您的首要任务

从短期来看，新产品功能有时会是您的首要任务。但从长远来看，可靠性是您的首要产品功能，因为如果产品速度太慢或长时间不可用，就可能会被用户放弃，从而使其他产品功能无关紧要。

可靠性由用户定义

对于面向用户的工作负载，请衡量用户体验。用户必须对您的服务的表现满意。例如，衡量用户请求的成功率，而不仅仅是查询 CPU 使用率等服务器指标。

对于批量和流式工作负载，您可能需要衡量数据吞吐量的关键性能指标 (KPI)，例如每个时间窗口扫描的行数，而不需要衡量服务器指标，如磁盘使用率。吞吐量 KPI 有助于确保用户需要的每日报告或季度报告按时完成。

100% 可靠性是错误的目标

您的系统应足够可靠以确保用户满意，但不能过于可靠以至投资不合理。确定 SLO 以设置所需的可靠性阈值，然后使用错误预算将变化速率控制在适当的范围内。

只有当该产品或应用的 SLO 与费用相符时，才将此框架中的设计和操作原则应用于产品。

可靠性和快速创新相辅相成

使用错误预算在系统稳定性和开发者敏捷性之间取得平衡。以下指导可帮助您确定何时应该加快或放慢速度：

如果错误预算充足，您可以快速创新、改进产品或添加产品功能。
当错误预算减少时，请放慢速度并专注于可靠性功能。

设计和操作原则

为了最大限度地提高系统可靠性，需要遵循以下设计和操作原则。架构框架可靠性类别的其余部分中详细讨论了其中每个原则。

确定您的可靠性目标

架构框架的这一部分中介绍的最佳做法包括以下内容：

选择适当的 SLI。
根据用户体验设置 SLO。
反复验证以改进 SLO。
使用严格的内部 SLO。
使用错误预算来管理开发速度。

如需了解详情，请参阅架构框架可靠性类别中确定您的可靠性目标。

将可观测性内置到您的基础架构和应用中

架构框架的这一部分介绍了以下设计原则：

对代码进行插桩以最大限度地提高可观测性。

如需了解详情，请参阅架构框架可靠性类别中的将可观测性内置到您的基础架构和应用中。

在设计时确保可扩缩性和高可用性

架构框架的这一部分介绍了以下设计原则：

创建冗余以实现更高的可用性。
跨区域复制数据以进行灾难恢复。
设计多地区架构以应对地区级服务中断。
消除可扩缩性瓶颈。
过载时平缓降低服务水平。
预防和缓解流量峰值。
清理并验证输入。
以可以保留系统功能的方式进入故障安全模式。
将 API 调用和操作命令设计为可重试。
识别和管理系统依赖项。
最大限度地减少关键依赖项。
确保可以回滚所有更改。

如需了解详情，请参阅架构架构可靠性类别中的在设计时确保可扩缩性和高可用性。

创建可靠的操作流程和工具

架构框架的这一部分介绍了以下操作原则：

为应用和服务选择良好的名称。
借助 Canary 测试过程实现渐进式发布
为限时促销和发布活动分散流量。
自动执行构建、测试和部署流程。
防范运维人员的错误。
测试故障恢复过程。
执行灾难恢复测试。
试验混沌工程。

如需了解详情，请参阅架构框架可靠性类别中创建可靠的操作流程和工具。

构建高效提醒

架构框架的这一部分介绍了以下操作原则：

优化提醒延迟时间。
针对表现（而非原因）触发提醒。
针对离群值（而不是平均值）触发提醒。

如需了解详情，请参阅架构框架可靠性类别中构建高效的提醒。

构建突发事件管理协作流程

架构框架的这一部分介绍了以下操作原则：

指定明确的服务所有权。
利用经过微调的提醒来缩短检测时间 (TTD)。
通过突发事件管理计划和培训，缩短缓解时间 (TTM)。
设计信息中心布局和内容以最大限度地缩短 TTM。
针对已知的中断情况记录诊断过程和缓解措施。
利用无责备事后分析来了解服务中断情况并防止再次发生。

如需了解详情，请参阅架构框架可靠性类别中的构建突发事件管理协作流程。

可靠性目标

Google Cloud 架构框架中的本文档提供的最佳实践用于定义衡量服务的客户体验的适当方法，以便您可以运行可靠的服务。您将学习如何反复验证您确定的服务等级目标 (SLO)，并使用错误预算来了解发布其他更新时可靠性可能受到影响的时间。

选择适当的 SLI

请务必选择适当的服务等级指标 (SLI) 来全面了解您的服务表现如何。例如，如果应用采用多租户架构（多个独立客户使用的典型 SaaS 应用），请务必按租户级层捕获 SLI。如果您仅在全球汇总级层衡量 SLI，您可能会错过应用中会影响单个重要客户或少数客户的关键问题。改为设计应用以在每个用户请求中包含租户标识符，然后将该标识符传播到应用栈的每一层。此标识符可让您的监控系统在请求路径中的每一层或微服务中汇总租户级层的统计信息。

您运行的服务类型还决定了要监控的 SLI，如以下示例所示。

投放系统

以下 SLI 通常是提供数据的系统的 SLI：

可用性反映服务可用时间所占的比例。它通常根据格式正确的成功请求来定义，例如 99%。
延迟时间反映特定百分比的请求可以完成的速度。它通常用除第 50 百分位以外的百分位来定义，例如，“第 99 百分位为 300 ms”。
质量反映特定响应的好坏程度。质量的定义通常是特定于服务的，用于指明对请求的响应内容与理想响应内容的差异程度。响应质量可以用二进制数表示（好或差），也可以用 0% 到 100% 来表示。

数据处理系统

以下 SLI 通常是处理数据的系统的 SLI：

覆盖率反映已处理的数据比例，例如 99.9%。
正确率反映被视为正确的输出数据所占的比例，例如 99.99%。
新鲜度反映源数据或汇总输出数据的新鲜程度。通常更新越新越好，例如 20 分钟。
吞吐量反映正在处理的数据量，例如 500 MiB/秒甚至 1000 个请求/秒 (RPS)。

存储系统

以下 SLI 通常是存储数据的系统的 SLI：

耐用性反映写入系统的数据将来被检索的可能性，例如 99.9999%。任何数据永久丢失事件都会降低耐用性指标。
吞吐量和延迟时间也是存储系统的常见 SLI。

选择 SLI 并根据用户体验设置 SLO

本架构框架部分的核心原则之一是可靠性由用户定义。尽可能靠近用户来衡量可靠性指标，例如以下选项：

如果可能，请对移动或 Web 客户端进行插桩。
- 例如，使用 Firebase Performance Monitoring 来深入了解 iOS、Android 和 Web 应用的性能特征。
如果不可行，请对负载均衡器进行插桩。
- 例如，使用 Cloud Monitoring 进行外部应用负载均衡器日志记录和监控。
在服务器上衡量可靠性应作为最后的选择。
- 例如，使用 Cloud Monitoring 监控 Compute Engine 实例。

将您的 SLO 设置到合适的高度（不要太高），以便几乎所有用户都对您的服务感到满意。由于网络连接或其他暂时性客户端问题，您的客户可能不会注意到应用中短暂的可靠性问题，从而让您能够降低 SLO。

对于正常运行时间和其他重要指标，请尽量将目标值控制在 100% 以下，但接近此值。服务所有者应该客观地评估可让大多数用户满意的最低服务性能和可用性级别，而不仅仅是基于外部合同级别设置目标。

进行更改的速率会影响系统的可靠性。但是，频繁进行细微更改的能力有助于更快地提供更高质量的功能。根据客户体验调整要实现的可靠性目标往往有助于确定客户可以接受的最大更改速度和范围（即功能速度）。

如果您无法衡量客户体验并据此确定目标，则可以运行竞争性基准分析。如果没有可比较的竞争关系，即使您还无法确定目标，也要衡量客户体验。例如，衡量系统可用性或有意义且成功的客户交易率。您可以将此数据与业务指标或 KPI 相关联，例如零售订单的量或客户服务电话和工单量及其严重程度。在一段时间内，您可以使用这样的关联来达到合理的客户满意度阈值。此阈值就是您的 SLO。

反复验证以改进 SLO

SLO 不应一成不变。每季度一次或至少每年一次重新审视 SLO，并确认它们能够准确地反映用户满意度并与服务中断密切相关。确保它们涵盖当前的业务需求和新的关键用户历程。请在定期审核 SLO 之后，视需要对其进行增订。

使用严格的内部 SLO

建议将内部 SLO 设置得比外部 SLA 更严格。由于违反服务等级协议 (SLA) 往往要求您发放财务补偿或客户退款，而您希望在问题产生财务影响之前解决掉。

我们建议您将这些更严格的内部 SLO 与无责备的事后分析流程和突发事件审核搭配使用。如需了解详情，请参阅 Architecture Center 可靠性类别中的构建突发事件管理协作流程。

使用错误预算来管理开发速度

错误预算可说明您的系统在某个时间窗口内是高于还是低于所需的可靠性。一段时间内（例如 30 天）“错误预算”的计算公式为 (100% – SLO)。

当错误预算中有剩余容量时，您可以继续快速发布改进或新功能。当错误预算接近零时，请冻结或减慢服务更改，并投入工程资源以提高可靠性特性。

Google Cloud 的运维套件包含 SLO 监控，可最大限度减少设置 SLO 和错误预算的工作量。运维套件包含一个图形界面（可帮助您手动配置 SLO）、一个 API（用于以编程方式设置 SLO）和一个内置信息中心（用于跟踪错误预算使用率）。如需了解详情，请参阅如何创建 SLO。

建议

如需将架构框架中的指导运用到您自己的环境，请遵循以下建议：

确定和衡量以客户为中心的 SLI，例如服务的可用性或延迟时间。
定义比外部 SLA 更严格、以客户为中心的错误预算。包含违规后果，例如生产冻结。
设置延迟时间 SLI 以捕获离群值（例如第 90 或第 99 百分位），以检测最慢响应。
每年至少审核一次 SLO，并确认它们与用户满意度和服务中断情况密切相关。

后续步骤

详细了解如何使用以下资源定义可靠性目标：

将可观测性内置到您的基础架构和应用中（本系列的下一个文档）
Coursera - SRE：衡量和管理可靠性
SRE 图书 SLO 章节和用于实现 SLO 的 SRE 工作簿
调整您的 SLI 指标

探索架构框架中的其他类别，例如系统设计、卓越运营以及安全性、隐私权和合规性。

定义SLO

本文档是由两部分组成的系列中的第 1 部分，其中介绍了运营在线服务的团队如何使用服务等级目标 (SLO) 开始构建和采用站点可靠性工程 (SRE) 文化。SLO 是服务的目标可靠性等级。

在软件即服务 (SaaS) 中，产品开发的速度和运营稳定性之间存在着自然压力。对系统的更改越多，它就越有可能崩溃。监控和可观测性工具可帮助您在提高开发速度时保持对运营稳定性的信心。不过，虽然此类工具（也称为_应用性能管理_ (APM) 工具）很重要，但这些工具最重要的一个应用是设置 SLO。

如果定义正确，SLO 可以帮助团队做出数据驱动型运营决策，从而加快开发速度，而不会影响稳定性。SLO 还可让开发和运营团队围绕单个商定目标开展工作，从而缓解其目标（创建和迭代产品（开发）和维护系统完整性（运营））之间存在的自然压力。

SLO 以及其他 SRE 做法在 SRE 书籍和 SRE 手册中详细介绍。本系列文章介绍了如何简化理解和开发 SLO 的过程，以帮助您更轻松地采用它们。阅读并理解这些文章后，您可以在书籍中找到更多信息。

本系列文章向您介绍有关在组织中实施 SLO 的清晰路径：

本文档介绍什么是 SLO 以及如何为您的服务定义 SLO。
采用 SLO 介绍介于工作负载类型的不同 SLO 类型，如何衡量这些 SLO，以及如何根据这些 SLO 开发提醒。

本系列文章面向 SRE、运营团队、DevOps、系统管理员以及负责在线服务稳定性和可靠性的其他人员。其中假定您了解互联网服务与网络浏览器和移动设备的通信方式，并且您对网络服务的监控、部署和问题排查方式有基本了解。

DevOps 现状报告确定了可提高软件交付方面表现的功能。本系列文章将帮助您使用以下功能：

监控和可观测性
监控系统以做出明智的业务决策
主动式故障通知

术语

本系列文档使用以下术语和定义：

服务等级：用于衡量给定服务为用户完成其预期工作的指标。您可以基于“用户满意度”来描述此衡量指标，并根据各种方法进行衡量，具体取决于服务的用途以及用户希望执行的操作或告诉它可执行的操作。

示例：“用户希望我们的服务可用且快捷。”

关键用户旅程 (CUJ)：用户为实现一个目标与服务进行的一组互动，例如单次点击或多步骤流水线。

示例：“用户点击‘结算’按钮，等待购物车处理完成，系统返回收据。”

服务等级指标 (SLI)：可针对某个服务等级定量衡量的用户满意度指标。换句话说，要衡量服务等级，您必须衡量表示用户对该服务等级（例如，服务可用性）的满意度的指标。可以将 SLI 视为图上的一条线，随着服务改善或降级，该条线会随时间变化。

示例：“衡量过去 10 分钟内的成功请求数量，除以过去 10 分钟内所有有效请求的数量。”

服务等级目标 (SLO)：您希望服务在多数情况下达到并据以衡量 SLI 的等级。

示例：“在 14 天衡量的所有有效请求中，95% 的服务响应应快于 400 毫秒 (ms)。”

服务等级协议 (SLA)：有关未满足 SLO 时将会发生什么情况的描述。一般而言，服务等级协议 (SLA) 是提供商与客户之间的法律协议，甚至可能包含补偿条款。在与 SRE 相关的技术讨论中，我们通常会避免使用该术语。

示例：“如果服务在一个日历月内未达到 99.95％可用性，则该服务提供商每分钟都会因不合规而补偿客户。”

错误预算：在您在违反 SLO 之前可承受的时间量或负面事件数量。此衡量指标可告诉您贵企业期望或可容忍的错误数。错误预算对于帮助您做出有潜在风险的决策至关重要。

示例：“如果我们的 SLO 达到 99.9％可用性，我们允许 0.1％的请求通过突发事件、事故或实验处理错误。”

为什么选择 SLO？

构建 SRE 文化时，为什么从 SLO 开始？简而言之，如果您不定义服务等级，则很难衡量您的客户是否对您的服务感到满意。即使您知道您可以改进服务，但只要缺乏定义的服务等级，就很难确定改善之处和投入力度。

您可能倾向于为每项服务开发单独的 SLO，而不考虑是否面向用户。例如，一种常见的错误是分来衡量两个或多个服务，例如前端服务和后端数据存储区，其中用户依赖两个服务但不知道两者的区别。更好的方法是开发基于产品（服务集合）的 SLO，并专注于您的用户与其进行的最重要互动。

因此，要开发有效的 SLO，最好了解您的用户与您的服务的互动，这称为关键用户旅程 (CUJ)。CUJ 会考虑用户的目标，以及用户如何使用您的服务来实现这些目标。CUJ 可从客户的角度定义，而不考虑服务边界。满足 CUJ 后，客户很满意，而客户满意是服务成功的关键衡量指标。

服务的可靠性是客户服务满意度的一个关键方面。如果服务不可靠，则服务的用途并不重要。因此，可靠性是任何服务最重要的特征。可靠性的一个常见指标是正常运行时间，这通常指系统已启动的时间量。但是，我们更倾向于更实用、更精确的指标：可用性。与衡量系统停机时间相比，可用性仍回答系统是否已启动的难问题，但更为精确。在当今的分布式系统中，服务可能会部分停机，而正常运行时间无法很好地捕获此因素。

可用性通常按_多个九_来描述，例如 99.9% 可用（三个九）或 99.99% 可用（四个九）。衡量可用性 SLO 是衡量系统可靠性的最佳方法之一。

除了帮助定义运营成功之外，SLO 还可以帮助您选择资源投入领域。例如，SRE 书籍通常会指出，您为之设计的每个九都会产生增量费用和边际效用。人们通常认为，实现可用性中下一个九的费用是前一个九的十倍。

选择 SLI

要确定是否满足 SLO（即成功），需要衡量指标。此衡量指标称为_服务等级指标_ (SLI)。SLI 衡量您提供给客户的特定服务的等级。理想情况下，SLI 与接受的 CUJ 关联。

选择最佳指标

开发 SLI 的第一步是选择要衡量的指标，例如每秒请求数、每秒错误数、队列长度、响应代码在指定时间段的分布或传输的字节数。

此类指标通常属于以下类型：

**计数器。**例如，在给定衡量点发生的错误数。此类指标会增加，但不会减少。
**分布。**例如，在给定时间段内填充特定衡量指标细分的事件数。您可以衡量 0-10 毫秒内完成的请求数、11-30 毫秒内完成的请求数，以及 31-100 毫秒内完成的请求数。结果是每个存储分区的计数，例如 [0-10: 50]、[11-30: 220]、[31-100: 1103]。
**采用平均值。**例如，系统的可衡量部分的实际值（例如队列长度）。此类指标会增加也会减少。

如需详细了解这些类型，请参阅 Prometheus 项目文档和 Cloud Monitoring 指标类型 ValueType 和 MetricKind。

SLI 的一个重要区别是_并非所有指标都是 SLI_。实际上，SRE 手册会声明以下内容（已添加实证）：

“…我们通常将 SLI 视为_两个数字的比率__：良好事件数除以事件总数…”_

“SLI 的范围为 0% 到 100%，其中 0% 表示全都是无用功，100% 表示一切完好。我们发现这种扩缩非常直观，这种风格很容易引起错误预算的概念。”

许多软件公司都会跟踪数百或数千个指标；只有少数指标符合 SLI 的要求。除了衡量良好事件与事件总数的比率之外，哪个指标可用作良好 SLI？理想的 SLI 指标具有以下特征：

**指标与用户满意度直接相关。**通常，如果服务的行为与期望不符、失败或缓慢，用户会不满意。任何基于这些指标的 SLO 都可以通过将 SLI 与其他用户满意度指标（例如客户投诉工单数量、支持电话数量、社交媒体情感或上报情况）进行比较来验证。如果您的指标与用户满意度的其他指标不对应，则可能不是用作 SLI 的良好指标。
指标恶化与中断相关。 在中断期间看起来良好的指标是 SLI 的错误指标。正常运营期间表现不佳的指标也是 SLI 的错误指标。
**指标提供良好的信噪比。**导致大量假负例或假正例的任何指标都不是良好 SLI。
**指标随客户满意度单调扩缩，且近似线性扩缩。**随着指标改善，客户满意度会提高。

考虑下图中的图表。随着时间的推移绘制了两个可用作服务 SLI 的指标。服务降级的时间段以红色突出显示，而服务良好的时间段以蓝色突出显示。

在发生不良 SLI 的情况下，用户不满意未直接对应于负面事件（例如服务降级、缓慢或中断）。此外，SLI 独立于用户满意度波动。在良好 SLI 中，SLI 和用户满意度相关联，不同的满意度等级清晰，且不相关波动要少得多。

选择适当数量的指标

通常，单个服务具有多个 SLI，特别是在服务执行不同类型的工作或向不同类型的用户提供服务时。例如，最好将读取请求与写入请求分开，因为这些请求会以不同的方式运作。在这种情况下，最好选择适用于每个服务的指标。

相比之下，许多服务在整个服务中执行类型相似的工作，可以直接进行比较。例如，如果您拥有网店，用户可能会查看首页、查看子类别或热门 10 清单，查看详细信息页面，或者搜索商品。您可以将这些操作组合成一个 SLI 类别，例如浏览服务，而不是为其中每项操作开发和衡量单独 SLI。

实际上，用户的期望不会在类似类别的操作之间发生大幅变化。用户满意度不取决于他们所浏览的数据的结构，无论数据是派生自宣传商品的静态列表，还是利用跨大型数据集的机器学习辅助搜索动态生成的结果。通过回答以下问题，可以量化用户满意度：“我是否很快看到整页的商品？”

理想情况下，您希望使用尽可能少的 SLI 来准确表示给定服务的容忍度。通常，一个服务应该具有 2 到 6 个 SLI。如果 SLI 太少，可能会错过有价值的信号。如果 SLI 过多，您的电话接听团队就要跟踪太多东西，但边际附加效用有限。请记住，SLI 应简化您对生产运行状况的理解，并提供覆盖率。

选择 SLO

SLO 由以下值组成：

**SLI。**例如，包含 HTTP 代码 200 的响应数与响应总数的比率。
**持续时间。**指标的衡量时间段。此时间段可以基于日历（例如，从一个月的第一天到第二个月的第一天），也可以是滚动窗口（例如，过去 30 天）。
**目标。**例如，您希望在给定持续时间内满足的良好事件占事件总数的目标百分比（例如 99.9％）。

开发 SLO 时，定义持续时间和目标可能会很困难。开始此过程的一种方法是确定 SLI 并随时间绘制图表。如果您无法确定要使用的持续时间和目标，请记住您的 SLO 不一定完美。您很可能会迭代您的 SLO，以确保它符合客户满意度并满足您的业务需求。您可以尝试从一个月两个_九_ (99.0%) 开始。

在部署、中断和每日流量模式等事件期间跟踪 SLO 合规性时，您可以深入了解哪些目标良好，哪些较差，或者哪些可容忍。例如，在后台进程中，您可以将 75％的成功率定义为足够。但对于任务关键型、面向用户的请求，您可能会设定更积极的目标，例如 99.95%。

当然，没有单个 SLO 适用于每种用例。SLO 依赖于以下几个因素：

客户期望
工作负载类型
用于传送、执行和监控的基础架构
问题领域

本系列文章中的第 2 部分采用 SLO 侧重于与领域无关的 SLO。与领域无关的 SLO（例如服务可用性）不会替换简要指标（例如每分钟销售的微件）。但是，无论企业用例如何，它们都可以帮助衡量服务是否正常工作。

与领域无关的指标通常可以减少到一个问题；例如，“服务是否可用？”或“服务是否足够快？”在考虑两个因素的 SLO 中最常找到答案：可用性和延迟时间。您可以采用以下措辞描述 SLO，其中 X = 99.9% 且 Y = 800 毫秒：

X％的有效请求成功，且成功快于 Y 毫秒。

采用SLO

本文档定义了几个服务等级目标 (SLO)，它们适用于不同类型的常见服务工作负载。本文档为两部分文章中的第 2 部分。第 1 部分定义 SLO 中介绍了 SLO，展示了 SLO 是如何从服务等级指标 (SLI) 派生的，并描述了什么是良好的 SLO。

DevOps 现状报告确定了可提高软件交付方面表现的功能。这两个文档可以帮助您实现以下功能：

监控和可观测性
监控系统以做出明智的业务决策
主动式故障通知

衡量的指标

无论您的网域如何，许多服务都具有相同的功能，可以使用通用 SLO。以下关于通用 SLO 的讨论按服务类型组织，并详细介绍了适用于每个 SLO 的 SLI。

请求驱动的服务

_请求驱动的服务_会接收来自客户端（其他服务或用户）的请求，执行一些计算，可能将网络请求发送到后端，然后向客户端返回一个响应。请求驱动的服务通常通过可用性和延迟时间 SLI 来衡量。

可用性作为 SLI

可用性 SLI 表示服务是否正常运行。可用性 SLI 的定义如下：

成功处理的有效请求所占的比例。

首先，您需要定义“有效”。一些基本定义可能是“长度非零”或“遵循客户端-服务器协议”，但服务所有者负责定义“有效”的含义。衡量有效性的一种常用方法是使用 HTTP（或 RPC）响应代码。例如，我们通常认为 HTTP 500 错误是要计入 SLO 的服务器错误，而 400 错误则是不用计入的客户端错误。

在确定要衡量的指标后，您需要检查系统返回的每个响应代码，以确保应用正确、一致地使用这些代码。为 SLO 使用错误代码时，务必询问代码是否是用户服务体验的准确指标。例如，如果用户尝试订购缺货的商品，网站是否会中断并返回错误消息，或者网站是否会建议类似产品？为了与 SLO 配合使用，错误代码需要与_用户的期望_相关联。

开发人员可能会误用错误。如果用户询问商品暂时缺货的产品，开发人员可能会错误地编写要返回的错误。不过，系统实际上正常运行，没有出现错误。即使用户无法购买所需商品，代码也需要作为成功返回。当然，此服务的所有者需要知道某个产品缺货，但从客户的角度来看，无法进行销售不是错误，不应计入 SLO。但是，如果服务无法连接到数据库以确定商品是否有库存，则这是一个错误，应计入错误预算。

您的服务可能会更复杂。例如，您的服务可能处理异步请求或为客户提供长时间运行的过程。在这些情况下，您可以通过其他方式公开可用性。但是，我们建议您仍将可用性表示为成功的有效请求的比例。您可以将可用性定义为客户的工作负载按请求运行的分钟数。（此方法有时称为衡量可用性的“良好时间”方法。）对于虚拟机，您可以根据初始请求后可通过 SSH 访问虚拟机的分钟比例来衡量可用性。

延迟时间作为 SLI

延迟时间 SLI（有时称为“速度”）指示服务是否足够快。“延迟时间”SLI 的定义与“可用性”类似：

处理速度超过阈值的有效请求所占的百分比。

如需测量延迟时间，可以计算计时器启动时间与给定请求类型的停止时间之间的差异。关键是用户对延迟的感知。常见的隐患是衡量延迟时间时过于精确。实际上，用户无法区分 100 毫秒 (ms) 和 300 毫秒的刷新时间，可能会接受 300 毫秒到 1000 毫秒之间的任意值。

相反，最好是开发以活动为中心的指标，可以让用户集中注意力，例如，在以下流程中：

交互式：用户在点击元素后等待结果的时间，1000 毫秒。
写入：1500 毫秒，用于更改底层分布式系统。虽然对于系统而言，此时间长度会被视为缓慢，但用户往往倾向于接受该时间。我们建议您在指标中明确区分写入和读取。
后台：5000 毫秒，针对用户不可见的操作，例如定期刷新数据或其他异步请求。

延迟时间通常以分布的形式进行衡量（参见本系列第 1 部分中的选择 SLI）。在给定分布的情况下，您可以测量各种百分位数。例如，您可以测量比历史第 99 个百分位慢的请求数。在本例中，我们认为好的事件是比这个阈值快的事件，而这个阈值是通过检查历史分布设置的。您还可以根据产品要求设置此阈值。您甚至可以设置多个延迟时间 SLO，例如典型延迟时间与尾延迟时间。

我们建议您不要仅使用平均（或中位数）延迟时间作为 SLI。发现中位数延迟时间太慢意味着一半的用户已经感到不满意。换句话说，在发现对长期错误预算的真正威胁之前，可能会有好几天的延迟。因此，我们建议您为_尾延迟时间_（第 95 百分位）和_延迟时间中位数_（第 50 百分位）定义 SLO。

在 ACM 文章重要指标中，Benjamin Treynor Sloss 写下以下内容：

“一个很好的实际经验法则…第 99 百分位延迟不应超过延迟时间中位数的三到五倍。”

Treynor Sloss 继续写道：

“我们发现服务的第 50、95 和 99 百分位延迟时间度量值都是单独有价值的，理想情况下，我们将围绕这些值设置 SLO。”

可以遵循的一个好模型是根据历史百分位数确定延迟时间阈值，然后测量每个存储桶中有多少请求。如需了解更多详情，请参阅本文档后面有关延迟时间提醒的部分。

质量作为 SLI

对于复杂的服务而言，质量是很有帮助的 SLI，这些服务 (SLI) 设计为在依赖项变慢或不可用时通过降级来正常失败。质量 SLI 的定义如下：

已处理且服务没有降级的有效请求所占的比例。

例如，网页可以从一个数据存储区加载其主要内容，并从其他 100 个服务和数据存储区加载辅助性的可选资源。如果一项可选服务已停止服务或运行速度过慢，该网页仍可以在没有辅助元素的情况下呈现。通过测量已传递降级响应的请求数（即，缺少至少一个后端服务响应的响应），可以报告不良请求的比例。您甚至可以跟踪有多少对用户的响应缺少来自单个后端的响应，或者缺少来自多个后端的响应。

数据处理服务

有些服务不是为了响应用户请求而构建的，而是使用来自输入的数据、处理该数据并生成输出。这些服务在中间步骤中如何表现并没有最终结果那么重要。对于此类服务，最强大的 SLI 是“新鲜度”“覆盖率”“正确性”和“吞吐量”，而不是“延迟时间”和“可用性”。

新鲜度作为 SLI

“新鲜度”SLI 的定义如下：

更新时间超过阈值的有效数据的比例。

例如，在批处理系统中，新鲜度可以是为给定输出成功运行一项处理后所经过的时间。在更复杂的或实时处理系统中，您可以跟踪在流水线中处理的最新记录的存在时间。

例如，假设一款实时生成地图块的在线游戏。用户可能不会注意到创建地图块的速度有多快，但他们可能会注意到地图数据丢失或不是最新。

或者，假设某个系统会读取库存跟踪系统的记录，从而为电子商务网站生成消息“X 件商品有货”。您可以按以下方式定义“新鲜度”SLI：

使用了在最后一分钟内刷新的库存信息的视图的百分比。

您还可以使用传递非刷新数据的指标来通知质量 SLI。

覆盖率作为 SLI

“覆盖率”SLI 的定义如下：

已成功处理的有效数据的比例。

如需定义覆盖率，请先确定是将输入作为有效项接受还是跳过该输入。例如，如果输入记录损坏或长度为零，无法处理，您可以考虑将该记录视为无效，用于测量您的系统。

接下来，您计算有效记录的数量。您可以使用简单的 count() 方法或其他方法来执行此步骤。此数字是您的总记录数。

最后，要生成覆盖率 SLI，您需要计算已成功处理的记录数，并将该数量与有效记录记录总数进行比较。

正确性作为 SLI

“正确性”SLI 的定义如下：

生成正确输出的有效数据所占的比例。

在某些情况下，您可以通过多种方法确定输出的正确性，以验证输出的处理情况。例如，旋转图片或为之着色的系统绝不应产生零字节图片，或长度或宽度为零的图片。请务必将此验证逻辑与处理逻辑本身区分开来。

测量正确性 SLI 的一种方法是使用已知良好的测试输入数据，即具有已知正确输出的数据。输入数据需要代表用户数据。在其他情况下，可能会对输出进行数学或逻辑检查，如前面旋转图片的示例所示。另一个示例可能是结算系统，它通过检查交易前的余额与交易后的余额之间的差值是否与交易本身的值相符来确定交易是否有效。

吞吐量作为 SLI

“吞吐量”SLI 的定义如下：

数据处理速率快于阈值的时间比例。

在数据处理系统中，吞吐量通常比对给定工作的单一延迟度量等更能代表用户的满意度。例如，如果每个输入的大小变化很大，那么如果作业以可接受的速度进行，比较每个元素完成的时间可能就没有意义了。

“每秒字节数”是测量处理数据所需工作量（无论数据集的大小如何）的常用方法。但是，任何与处理成本大致成线性关系的指标都是可行的。

根据预期吞吐率对数据处理系统进行分区，或实现服务质量系统以确保处理高优先级输入和对低优先级输入进行排队，这可能是值得的。无论哪种方式，按照本节所定义的方式测量吞吐量都可以帮助您确定系统是否按预期工作。

计划执行服务

对于需要按固定间隔执行操作的服务（例如 Kubernetes cron 作业），您可以测量“偏差”和“执行时长”。以下是计划的 Kubernetes cron 作业示例：

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "0 * * * *"

偏差作为 SLI

作为 SLI，“偏差”的定义如下：

在预计开始时间的可接受时段中开始的执行比例。

“偏差”衡量作业的计划开始时间与实际开始时间之间的差异。例如，如果前面的 Kubernetes cron 作业设置为每小时零分钟开始，而实际在每个小时的第三分钟开始，则偏差为三分钟。如果作业提前运行，则偏差为负。

您可以用一段时间的分布情况来衡量偏差，并使用相应的可接受范围来定义良好的偏差。要确定 SLI，您需要比较良好范围内的运行次数。

执行时长作为 SLI

作为 SLI，“执行时长”的定义如下：

在可接受的时段内完成的执行所占的比例。

“执行时长”是指完成作业所需的时间。对于给定执行，常见的故障模式是实际时长超过计划时长。

一个有趣的案例是，如何使用此 SLI 来衡量永无止境的作业。由于这些作业没有完成，因此您需要记录给定作业花费的时间，而不是等待作业完成。此方法提供了工作完成时间（即使在最坏情况下）的准确分布。

与偏差一样，您可以将执行时长作为分布情况来跟踪，并为良好事件定义可接受的上限和下限。

其他系统的指标类型

许多其他工作负载都有自己的指标，可用于生成 SLI 和 SLO。请参考以下示例：

存储系统：耐用性、吞吐量、首字节时间、blob 可用性
媒体/视频：客户端播放连续性、开始播放的时间、转码图执行完整性
游戏：匹配活跃玩家的时间、生成地图的时间

如何衡量

在了解要衡量的内容之后，您可以决定如何进行测量。您可以通过多种方式收集您的 SLI。

服务器端日志记录

生成 SLI 的方法

处理请求或已处理数据的服务器端日志。

注意事项

优点：

可以重新处理现有日志以回填历史 SLI 记录。
跨服务会话标识符可以跨多个服务重建复杂的用户历程。

缺点：

系统不会记录未到达服务器的请求。
导致服务器崩溃的请求可能无法被记录。
处理日志的时间长度可能会导致过时的 SLI，这可能是因为操作响应的数据不足。
写入代码以处理日志可能是一项容易出错、耗时的任务。

实现方法和工具：

BigQuery
Dataflow、Apache Spark
Splunk

应用服务器指标

生成 SLI 的方法

从处理用户请求或处理其数据的代码导出 SLI 指标。

注意事项

优势：

向代码中添加新指标通常既快捷又费用不高。

缺点：

系统不会记录未到达应用服务器的请求。
多服务请求可能难以跟踪。

实现方法和工具：

Cloud Monitoring
Prometheus
第三方 APM 产品

前端基础架构指标

生成 SLI 的方法

利用负载均衡基础架构中的指标（例如，Google Cloud 的全球第 7 层负载均衡器）。

注意事项

优点：

指标和历史数据通常都已存在，因此减少了工程的入门工作量。
测量是在最靠近客户的位置进行，但仍在服务基础架构内。

缺点：

不适用于数据处理 SLI。
只能大致估算多请求用户历程。

实现方法和工具：

Cloud Monitoring
CDN/LB 指标或报告 API（Cloudflare、Akamai、Fastly）

合成客户端或数据

生成 SLI 的方法

构建定期发送虚构请求并验证响应的客户端。对于数据处理流水线，创建合成的、已知良好的输入数据并验证输出。

注意事项

优点：

衡量多请求用户历程的所有步骤。
从基础架构外部发送请求会捕获 SLI 中更多的整体请求路径。

缺点：

借助合成请求大致估算用户体验，可能会有误导性（误报或漏报）。
覆盖所有极端情况是困难的，可以转移到集成测试中。
可靠性高的目标需要频繁探测才能进行准确测量。
探测流量会消除真实流量。

实现方法和工具：

Cloud Monitoring 正常运行时间检查
开源解决方案：
- Cloudprober
- blackbox_exporter
供应商解决方案：
- 捕获点合成监控
- New Relic 合成
- Datadog 合成监控

客户端插桩

生成 SLI 的方法

向用户与之交互的客户端添加可观察性功能，并将事件记录回跟踪 SLI 的服务基础结构。

注意事项

优点：

提供最准确的用户体验衡量。
可以量化第三方（例如 CDN 或付款服务机构）的可靠性。

缺点：

客户端日志提取和处理延迟使这些 SLI 不适合触发操作响应。
SLI 衡量指标将包含许多可能不受直接控制的高度可变的因素。
将插桩构建到客户端中可能涉及大量的工程工作。

实现方法和工具：

Google Analytics、Firebase
用户分析：Armitude 及类似工具
移动/前端监控：New Relic Browser、Raygun Real User Monitoring、Sentry
用于记录和跟踪的自定义客户端和自定义服务器

选择测量方法

理想情况下，您需要选择与客户的服务体验密切相关的测量方法，并且需要投入一定的精力。为了实现此理想情况，您可能需要组合使用上表中的方法。下面是一个建议的方法，按工作量增加的顺序列出，您可以慢慢实现：

**使用应用服务器导出和基础架构指标。**通常，您可以立即访问这些指标，并且它们会快速提供值。一些 APM 工具包含内置 SLO 工具。
**使用客户端插桩。**由于旧式系统通常缺少内置的最终用户客户端插桩，因此设置插桩可能需要大量投入。但是，如果您使用能提供客户端插桩的 APM 套件或前端框架，则可以快速了解客户的满意度。
**使用日志处理。**如果您无法实现服务器导出或客户端插桩，但存在日志，则可能会发现日志处理是最有价值的。另一种方法是合并导出和日志处理，将导出用作某些 SLI（例如即时可用性）的直接源，并将日志处理用于长期信号（例如提醒部分后面讨论的慢速消耗提醒）。
**实现合成测试。**在基本了解客户如何使用您的服务后，可以测试服务等级。例如，您可以用已知的良好数据为测试账号播种，并对其进行查询。此测试可以帮助突出显示不容易观察到的故障模式，例如低流量服务。

设定目标

设置目标的最佳方式之一就是创建一个描述 SLO 以及如何开发它们的共享文档。当文档随着时间的推移在 SLO 上实现和迭代时，您的团队可以对其进行迭代。

我们建议企业所有者、产品所有者和高管查看本文档。这些利益相关方可以提供关于服务预期以及产品可靠性权衡的见解。

对于贵公司最重要的关键用户历程 (CUJ)，以下是开发 SLO 的模板：

选择 SLI 规范（例如可用性或新鲜度）。
定义如何实现 SLI 规范。
仔细阅读您的计划，确保涵盖您的 CUJ。
根据过去的性能或业务需求设置 SLO。

CUJ 不应限制为单个服务，也不应限于单个开发团队或组织。如果您的用户依赖于数百种以 99.5% 的可用性运行的微服务，但没有人跟踪端到端的可用性，则您的客户可能不满意。

假设您有一个查询依赖于按顺序工作的五个服务：负载均衡器、前端、Mixer、后端和数据库。

如果每个组件的可用性均为 99.5%，则最坏情况下面向用户的可用性如下：

99.5% * 99.5% * 99.5% * 99.5% * 99.5% = 97.52%

这是最坏情况下面向用户的可用性，因为如果五个服务中的任何一个发生故障，整个系统将失败。只有在栈的所有层都必须立即可用来处理每个用户请求，而没有任何弹性因素（如中间重试、缓存或队列）的情况下，才会出现这种情况。在服务之间具有如此紧密耦合的系统是一种不合理的设计，并且与微服务模型不一致。

以零散的方式（逐个服务）根据分布式系统的 SLO 来衡量性能并不能准确地反映客户的体验，而且可能会导致过于敏感的解释。

相反，您应该根据前端的 SLO 来衡量性能，以了解用户的体验。如果用户的查询仍然成功，则用户不会关心组件服务是否失败，并导致系统自动成功重试查询。如果您共享了内部服务，则这些服务可以根据它们的 SLO 单独衡量性能，而面向用户的服务充当其客户。您应该单独处理这些 SLO。

使用智能重试、缓存和排队等弹性因素，可以在可用性较差的服务（例如 99.9%）之上构建高可用性服务（例如 99.99%）。

通常，任何具有统计工作知识的人都应能够阅读和理解您的 SLO，而无需了解您的基础服务或组织布局。

SLO 工作表示例

开发 SLO 时，请记住执行以下操作：

请确保您的 SLI 指定了一个事件、一个成功标准，以及您在哪里如何记录了成功或失败。
根据良好事件的比例定义 SLI 规范。
请确保您的 SLO 同时指定目标等级和测量时段。
描述您方法的优点和缺点，以便相关方了解所涉及的权衡和微妙之处。

例如，请考虑以下 SLO 工作表。

CUJ：首页加载
SLI 类型：延迟时间 SLI 规范：在 100 毫秒内处理的首页请求的比例 SLI 实现： * 从服务器日志的“延迟时间”列衡量的，100 毫秒内处理的首页请求所占的比例。（缺点：此衡量方法会遗漏无法到达后端的请求。） * 通过在运行在虚拟机上的浏览器中执行 JavaScript 的探测器测量，在不到 100 毫秒内处理的首页请求的比例。（优点和缺点：当请求无法到达网络时，这种测量方法会捕获错误，但可能错过只影响一部分用户的问题。） SLO：过去 28 天内 99% 的首页请求在不到 100 毫秒内送达

CUJ：首页加载

SLI 类型：延迟时间 SLI 规范：在 100 毫秒内处理的首页请求的比例 SLI 实现： * 从服务器日志的“延迟时间”列衡量的，100 毫秒内处理的首页请求所占的比例。（缺点：此衡量方法会遗漏无法到达后端的请求。） * 通过在运行在虚拟机上的浏览器中执行 JavaScript 的探测器测量，在不到 100 毫秒内处理的首页请求的比例。（优点和缺点：当请求无法到达网络时，这种测量方法会捕获错误，但可能错过只影响一部分用户的问题。） SLO：过去 28 天内 99% 的首页请求在不到 100 毫秒内送达

注意：如果无法作为一个团队就目标等级达成一致，请选择某个等级并同意在 6 个月后重新讨论它。选择错误的数字比不选择任何数字要好。

SLO 和提醒

引入 SLO 等新可观察性系统的错误方法是使用该系统完全替换旧系统。相反，您应该将 SLO 视为一个补充系统。例如，我们建议您不要删除现有的提醒，而是将它们与这里介绍的 SLO 提醒并行运行。这种方法允许您发现哪些就有提醒是可预测的 SLO 提醒，哪些提醒与您的 SLO 提醒并行触发，以及哪些提醒永远不会触发。

SRE 的一个原则是根据症状而不是原因来提醒。SLO 本质上是对症状的测量。在用 SLO 提醒时，您可能会发现症状提醒与其他提醒一起触发。如果您发现旧有的基于原因的提醒触发时没有 SLO 或症状，则不妨完全关闭这些提醒、将它们转换为工单提醒或简单地登录以供以后参考。

如需详细了解此主题，请参阅 SRE 手册，第 5 章。

SLO 消耗率

SLO 的消耗率衡量的是故障向用户暴露错误和消耗错误预算的速度。通过测量消耗率，您可以确定服务违反其 SLO 的时间。基于 SLO 消耗率的提醒是一种很有价值的方法。请记住，您的 SLO 基于时长，而后者可能会很长（数周甚至数月）。但是，目标是快速检测在违规实际发生之前，导致 SLO 违规的条件。

下表显示了在给定的时间间隔内，如果 100% 的请求都失败（假设每秒查询数 (QPS) 是恒定的），则超过目标所需的时间。例如，如果您在 30 天内测量了 99.9% 的SLO，那么您可以在这 30 天内承受 43.2 分钟的完全停机时间。例如，所有停机时间可能会一次性发生，也可以分散到多个事件。

目标	90 天	30 天	7 天	1 天
90%	9 天	3 天	16.8 小时	2.4 小时
99%	21.6 小时	7.2 小时	1.7 小时	14.4 分钟
99.9%	2.2 小时	43.2 分钟	10.1 分钟	1.4 分钟
99.99%	13 分钟	4.3 分钟	1 分钟	8.6 秒
99.999%	1.3 分钟	25.9 秒	6 秒	0.9 秒

在实践中，如果您想获得较高的成功率，就不能承受任何 100% 中断的突发事件。但是，许多分布式系统可以部分失败或平缓降级。即使在这种情况下，您仍想知道是否需要人工介入（即使发生的是部分故障也是如此），而 SLO 提醒为您提供了确定这一点的方法。

何时提醒

一个重要问题是，何时根据 SLO 消耗率采取行动。通常情况下，如果将在 24 小时内耗尽错误预算，那么“现在”就是找人解决问题的时候了。

衡量故障率并不总是简单的。一系列小错误可能在当时看起来很可怕，但结果是短暂的，并且对 SLO 产生的影响无关紧要。同样，如果系统长时间轻微损坏，这些错误会累积为 SLO 违规。

理想情况下，您的团队会对这些信号做出反应，以便您在给定时间段内用完几乎所有的错误预算（而不是超出）。如果用得太多，则表示您违反了 SLO。如果用得太少，则承担的风险不够，或者让待命团队疲于应付。

您需要一种方法来确定系统何时崩溃到需要人工干预的程度。以下部分讨论了解决这个问题的一些方法。

快速消耗

SLO 消耗的一种类型是“快速 SLO 消耗”，因为它会快速消耗您的错误预算，并且需要您干预以避免 SLO 违规。

假设您的服务以每秒 1000 个查询 (QPS) 的速度正常运行，并且希望在一周七天的时间内保持 99% 的可用性。您的错误预算约为 600 万个允许错误（总请求数为 6 亿个）。例如，如果在错误预算耗尽之前还有 24 小时，则每秒的错误数限制为 70 个，或者是一小时内 252,000 个错误。这些参数基于一般规则：可呼叫事件至少占季度错误预算的 1%。

您可以选择在这一个小时过去之前检测这个错误率。例如，在观察 15 分钟每秒 70 个错误的速率后，您可能会决定呼叫待命工程师，如下图所示。

理想情况下，这个问题在您用掉 24 小时预算中的一个小时之前就解决了。选择较短的时段（例如，一分钟）来检测此速率可能太容易出错。如果目标平均检测时间 (MTTD) 短于 15 分钟，则可以调整此数字。

慢速消耗

另一种消耗率是“慢速消耗”。假设您引入了一个错误，在第 5 天或第 6 天消耗掉了周错误预算，或者在第 2 周消耗掉了月预算？最佳应对方法是什么？

在这种情况下，您可能会引入一个“慢速 SLO 消耗”提醒，让您知道在提醒时段结束之前，您将消耗掉整个错误预算。当然，该提醒可能会返回很多误报。例如，可能经常存在这样一种情况，即错误发生的时间很短，但速度很快就会消耗掉您的错误预算。在这些情况下，该条件是误报，因为它只持续很短的时间，不会长期威胁您的错误预算。请记住，目标不是消除所有的错误来源；而是要“保持在可接受的范围内，不超出您的错误预算”。对于不会对错误预算构成合理威胁的事件，您希望避免提醒人工干预。

对于慢速消耗事件，我们建议您通知一个工单队列（而不是呼叫或发送电子邮件）。慢速消耗事件不是紧急事件，但是在预算到期之前需要人工干预。这些提醒不应以电子邮件的形式发送给团队列表，否则很快会被忽略。工单应该可跟踪、可分配和可转移。团队应该针对工单负载、完结率、可操作性和重复项创建报告。过多的、无法操作的工单是手动操作的好例子。

熟练地使用 SLO 提醒需要时间，并取决于团队的文化和期望值。记住，您可以随着时间的推移对 SLO 提醒进行微调。根据需要，您还可以有多种提醒方法和不同的提醒时段。

延迟提醒

除了可用性提醒之外，您还可以设置延迟提醒。借助延迟时间 SLO，您可以测量未达到延迟时间目标的请求的百分比。通过使用此模型，您可以使用与用于检测错误预算是快速还是慢速消耗的相同提醒模型。

正如前面提到的延迟时间中位数 SLO，有一半的请求可以不符合 SLO。换句话说，在您检测到对长期错误预算的影响之前，您的用户会面临数天的延迟。相反，服务应定义“尾延迟时间目标”和“典型延迟时间”目标。我们建议使用历史第 90 百分位数来定义典型延迟时间，并使用第 99 百分位数定义尾延迟时间。设置这些目标后，您可以根据希望计入每个延迟时间类别的请求数量，以及速度太慢的数量，来定义 SLO。此方法的概念与错误预算相同，应同等对待。因此，您可能会得到这样的结论：“90% 的请求将在典型延迟时间内处理，99.9% 的请求将在尾延迟时间目标范围内处理”。这些目标可确保大多数用户体验到您的典型延迟时间，并且仍允许您跟踪有多少请求比您的尾延迟时间目标慢。

一些服务可能有高度不同的预期运行时。例如，在数据存储区中读写数据可能会有显著不同的性能预期。您可以引入运行时性能存储桶，而不是枚举所有可能的期望，如下表所示。这种方法假定这些类型的请求是可识别的，并预先分类到各个存储桶中。不要期望动态地对请求进行分类。

面向用户的网站
存储桶	预期最大运行时
读取	1 秒
写入/更新	3 秒

数据处理系统
存储桶	预期最大运行时
小	10 秒
中	1 分钟
大	5 分钟
巨大	1 小时
特大	8 小时

通过测量当前的系统，您可以了解这些请求通常需要多长时间才能运行。以处理视频上传的系统为例。如果视频很长，处理时间应该会更长。我们可以使用视频长度（以秒为单位）来将这个工作分类到一个存储桶中，如下表所示。该表记录了一周内每个存储桶的请求数以及不同的运行时分布百分比。

视频时长	一周内测量的请求数	10%	90%	99.95%
小	0	-	-	-
中	190 万	864 毫秒	17 秒	86 秒
大	2500 万	1.8 秒	52 秒	9.6 分钟
巨大	430 万	2 秒	43 秒	23.8 分钟
特大	81000	36 秒	1.2 分钟	41 分钟

从这样的分析，您可以得出提醒的几个参数：

fast_typical：最多有 10% 的请求比这个时间快。如果有太多请求的速度超过了这个时间，那么您的目标可能是错误的，或者您的系统可能发生了变化。
slow_typical：至少 90% 的请求都比这个时间快。这个限制得出您的主延迟 SLO。这个参数指示大多数请求是否足够快。
slow_tail：最少 99.95% 的请求比这个时间快。此限制可确保不会有太多慢速请求。
deadline：用户 RPC 或后台处理超时并失败的点（通常已经硬编码到系统中的限制）。这些请求实际上不会很慢，但实际上会失败并报错，然后计入可用性 SLO。

定义存储桶的一项准则是将存储桶的 fast_typical、slow_typical 和 slow_tail 放在一个数量级内。这条准则可确保存储桶的宽度不会太大。我们建议您不要尝试防止存储桶之间的重叠或间隙。

存储桶	fast_typical	slow_typical	slow_tail	deadline
小	100 毫秒	1 秒	10 秒	30 秒
中	600 毫秒	6 秒	60 秒（1 分钟）	300 秒
大	3 秒	30 秒	300 秒（5 分钟）	10 分钟
巨大	30 秒	6 分钟	60 分钟（1 小时）	3 小时
特大	5 分钟	50 分钟	500 分钟（8 小时）	12 小时

这会产生类似于 api.method: SMALL => \[``1s, 10s``\] 的规则。在这种情况下，SLO 跟踪系统将看到一个请求，确定其存储桶（可能通过分析其方法名称或 URI，并将名称与对照表进行比较），然后根据该请求的运行时更新统计信息。如果这个过程花了 700 毫秒，则在 slow_typical 目标范围内。如果花了 3 秒，则在 slow_tail 范围内。如果是 22 秒，则超出 slow_tail，但仍不是错误。

在用户满意度方面，您可以将缺少尾延迟时间视为等同于不可用。（即响应速度很慢，应被视为失败）。因此，我们建议您使用与可用性相同的百分比，例如：

所有请求的 99.95% 在 10 秒内得到满足。

典型延迟时间由您自己决定。Google 的一些团队认为 90% 是不错的目标。这与您的分析以及您为 slow_typical 选择时长的方式相关。例如：

所有请求的 90% 在 1 秒内得到处理。

建议的提醒

根据这些准则，下表包含一组 SLO 提醒基准。

SLO	测量时段	消耗率	操作
可用性，快速消耗典型延迟时间尾延迟时间	1 小时时段	不到 24 小时会违反 SLO	呼叫某人
可用性，慢速消耗典型延迟时间，慢速消耗尾延迟时间，慢速消耗	7 天时段	超过 24 小时才会违反 SLO	创建工单

SLO 提醒是需要时间来培养的技能。本部分中的时长是建议时长；您可以根据自身需求和精确程度来调整这些值。将提醒与测量时段或错误预算支出进行绑定可能会有所帮助，或者您可以在快速消耗和慢速消耗之间添加另一层提醒。

可观察的基础架构和应用

Google Cloud 架构框架中的本文档提供了在服务中添加可观测性的最佳实践，以便您可以更好地了解服务性能并快速识别问题。可观测性包括监控、日志记录、跟踪、性能剖析、调试和类似系统。

监控是 Google SRE 手册中的服务可靠性层次结构的基础。如果没有适当的监控，您无法判断应用是否正常运行。

对代码进行插桩以最大限度地提高可观测性

精心设计的系统的目标是从开发阶段开始就具有适当的可观测性。不要等到应用进入生产阶段才开始观测。对代码进行插桩并考虑以下指导：

为了高效地进行调试和问题排查，请考虑要写入哪些日志和跟踪记录条目，以及要监控和导出哪些指标。对系统中最可能或最频繁出现的故障模式进行排序。
定期审核和删减监控。删除未使用或无用的信息中心、图形、提醒、跟踪和日志记录，以免杂乱无章。

Google Cloud 的运维套件提供实时监控、混合多云监控和日志记录（例如 AWS 和 Azure 服务）以及跟踪、性能剖析和调试。Google Cloud 的运维套件还可以自动发现和监控在 App Engine 上或 Istio 等服务网格中运行的微服务。

如果您要生成大量应用数据，可以使用 BigQuery 优化大规模提取分析事件日志。BigQuery 还适用于保存和分析来自监控框架的高基数时序数据。这种方法非常有用，因为它可让您以较低的费用运行任意查询，而无需尝试从头开始设计完美的监控，并将报告与监控分离开来。您可以使用 Looker 数据洞察或 Looker 根据数据创建报告。

可扩缩性和高可用性设计

本文档在 Google Cloud 架构框架中，提供了在设计服务架构时需要遵循的设计原则，使这些服务能够容忍故障并根据客户需求进行缩容。当服务需求较高或发生维护事件时，可靠的服务将能够继续响应客户请求。以下可靠性设计原则和最佳实践应该是系统架构和部署计划的一部分。

创建冗余以实现更高的可用性

具有高可靠性需求的系统必须避免单点故障，并且必须在多个故障网域之间复制其资源。故障网域是可以单独出现故障的资源池，例如虚拟机实例、可用区或地区。跨故障网域进行复制时，您可以获得高于单个实例可以达到的总体可用性水平。如需了解详情，请参阅地区和可用区。

作为可能属于系统架构的一个具体冗余示例，为了将 DNS 注册过程中的故障隔离到个别可用区，请为同一网络中的实例使用区域级 DNS 名称以互相访问。

设计具有故障切换功能的多可用区架构以实现高可用性

您可以将应用的架构设计为使用分布在多个可用区中的资源池，并在可用区之间复制数据、进行负载均衡和自动执行故障切换，从而使应用灵活应对区域级故障。运行应用堆栈每一层的区域级副本，并消除架构中的所有跨可用区依赖项。

跨区域复制数据以进行灾难恢复

将数据复制或归档到远程地区，以便在发生地区级服务中断或数据丢失时进行灾难恢复。在使用复制功能时，除了因复制延迟而可能丢失少量数据之外，远程区域中的存储系统已经具有几乎最新的数据，因此恢复速度会更快。使用定期归档而非持续复制时，灾难恢复涉及从新区域的备份或归档中恢复数据。此过程通常会导致服务停机时间比激活持续更新的数据库副本更长，并且可能因连续备份操作之间的时间间隔而造成数据丢失。无论使用何种方法，整个应用堆栈都必须重新部署并在新区域中启动，并且在发生这种情况时服务将不可用。

如需详细了解灾难恢复概念和技术，请参阅针对云基础架构服务中断设计灾难恢复架构。

设计多区域架构以灵活应对区域级服务中断

如果您的服务需要在整个区域出现故障的罕见情况下持续运行，请将其设计为使用分布在不同区域的计算资源池。运行应用栈每一层的地区级副本。

跨地区使用数据复制，并在地区发生故障时进行自动故障切换。某些 Google Cloud 服务具有多区域变体，例如 Cloud Spanner。为应对区域级故障，请在设计中尽可能使用这些多区域服务。如需详细了解地区和服务可用性，请参阅 Google Cloud 位置。

确保不存在跨地区的依赖项，使得将地区级故障的影响范围限制在该地区。

消除地区级单点故障，例如在无法访问时可能导致全球服务中断的单个地区主数据库。请注意，多地区架构的费用通常较高，因此在采用此方法之前，请综合考虑业务需求与费用。

如需进一步了解如何跨故障域实现冗余，请参阅云应用的部署原型 (PDF) 调查问卷。

消除可扩缩性瓶颈

识别无法超越单个虚拟机或单个区域资源限制的系统组件。某些应用会垂直扩缩，在其中，您可以在单个虚拟机实例上添加更多 CPU 核心、内存或网络带宽以处理负载增加的情况。这些应用对可扩缩性有严格的限制，并且您必须经常手动对其进行配置以处理增长。

如果可能，请将这些组件重新设计为横向扩缩，例如使用分片或分区，跨虚拟机或可用区扩缩。如需处理流量或使用量增长，添加更多分片即可。使用标准虚拟机类型，可自动添加以处理每个分片的负载增长。如需了解详情，请参阅构建可扩缩且弹性佳的应用时应遵循的模式。

如果您无法重新设计应用，则可以将自行管理的组件替换为无需用户操作即可横向扩缩的全代管式云服务。

过载时逐步降低服务级别

设计您的服务以承受过载。服务应该检测过载，并向用户返回降低质量的响应或减少部分流量，而不是在遇到过载时完全不能工作。

例如，服务可以使用静态网页响应用户请求，并暂时停用处理费用较昂贵的动态效果。从 Compute Engine 到 Cloud Storage 的热故障切换模式中详细介绍了此行为。或者，服务可以允许执行只读操作并暂时停用数据更新。

当服务降级时，应通知操作员以纠正错误情况。

预防和缓解流量峰值

请不要跨客户端同步请求。太多客户端在同一时刻发送流量会导致流量高峰，从而会导致级联故障。

在服务器端实施高峰缓解策略，例如限制、排队、减载或熔断、优雅降级和确定关键请求的优先级。

客户端上的缓解策略包括客户端限制和使用抖动的指数退避算法。

清理并验证输入

为了防止会导致服务中断或安全漏洞的错误、随机或恶意输入，请清理并验证 API 和操作工具的输入参数。例如，Apigee 和 Google Cloud Armor 有助于防范注入攻击。

定期使用模糊测试，其中自动化测试框架会有意使用随机、空的或过大的输入调用 API。在隔离的测试环境中进行这些测试。

操作工具应在更改发布之前自动验证配置更改，如果验证失败，则应拒绝更改。

以可以保留功能的方式进入故障安全模式

如果问题导致发生故障，系统组件应以可让整个系统继续运行的方式发生故障。这些问题可能为软件错误、输入或配置有误、计划外实例中断或人为错误。您的服务流程有助于确定您应该是过于宽松或过于简单，而不是过于限制。

请考虑以下示例场景以及应对故障的方法：

一般而言，最好是让配置错误或为空的防火墙组件故障打开，并允许未经授权的网络流量在操作员修复错误期间短时间通过。此行为可让服务保持可用，而不是故障关闭并阻止所有流量。该服务必须依靠应用栈中更深层次的身份验证和授权检查，在所有流量都通过时保护敏感区域。
但是，最好让控制用户数据访问的权限服务器组件故障关闭并阻止所有访问。当配置损坏时，此行为会导致服务中断，但可在故障打开时避免机密用户数据泄露的风险。

在这两种情况下，故障都应引发高优先级提醒，以便操作员可以解决错误情况。服务组件应偏于故障打开，除非这会对业务造成极大的风险。

将 API 调用和操作命令设计为可重试

API 和操作工具必须尽可能确保重试安全。处理许多错误情况的自然方法是重试以前的操作，但您可能不知道第一次尝试是否成功。

您的系统架构应使操作具有幂等性 - 如果您对一个对象连续执行两次或多次相同的操作，则应该会产生与单次调用相同的结果。非幂等性操作需要更复杂的代码，以避免系统状态损坏。

识别和管理服务依赖项

服务设计人员和所有者必须维护对其他系统组件的依赖项的完整列表。服务设计还必须包括从依赖项故障中恢复，或者如果完全恢复不可行，则正常降级。考虑系统和外部依赖项（如第三方服务 API）使用的云服务的依赖项，识别具有非零故障率的每个系统依赖项。

设置可靠性目标时，请注意服务的 SLO 受其所有关键依赖项的 SLO 的数学约束。您的可靠性不会高于其中一个依赖项的最低 SLO。如需了解详情，请参阅服务可用性计算。

启动依赖项

与稳定状态行为相比，服务在启动时的行为会有所不同。启动依赖项可能与稳定状态运行时依赖项大不相同。

例如，启动时，服务可能需要从它很少再次调用的用户元数据服务加载用户或账号信息。如果许多服务副本在发生崩溃或例行维护后重启，则副本会严重增加启动依赖项的负载，尤其是在缓存为空且需要重新填充时。

测试服务在负载下启动，并相应地预配启动依赖项。考虑这样的设计：通过保存从重要启动依赖项中检索的数据的副本逐步将设计降级。此行为使您的服务可以使用可能过时的数据重启，而不是在关键依赖项中断时无法启动。在可行的情况下，您的服务稍后可以加载最新数据，以恢复正常运行。

在新环境中引导服务时，启动依赖项也很重要。设计应用堆栈并采用分层架构，各个层之间没有循环依赖关系。循环依赖关系可能看似可容忍，因为它们不会阻止对单个应用的增量更改。但是，循环依赖关系可能会使得在灾难使整个服务堆栈崩溃后难以或无法重启。

最大限度地减少关键依赖项

最大限度地减少服务的关键依赖项数量，即其故障不可避免地导致服务中断的其他组件。为了使您的服务能够更灵活地应对其依赖的其他组件中的故障或运行缓慢的问题，请考虑以下示例设计技术和原则，将关键依赖项转换为非关键依赖项：

提高关键依赖项的冗余级别。添加更多副本，从而降低整个组件变得不可用的可能性。
使用对其他服务的异步请求，而不是阻止响应，或使用发布/订阅消息功能将请求与响应分离。
缓存其他服务的响应，以从依赖项的短期不可用状态中恢复。

为使服务中故障或运行缓慢现象对依赖它的其他组件的影响较小，请考虑以下示例设计技术和原则：

使用具有优先次序的请求队列，并优先处理用户正在等待响应的请求。
从缓存中提供响应，以减少延迟时间和负载。
以可以保留功能的方式进入故障安全模式。
在流量过载时逐步降级。

确保可以回滚所有更改

如果没有明确定义的方法来撤消对服务进行的某些类型的更改，请更改服务的设计以支持回滚。应定期测试回滚流程。必须对每个组件或微服务的 API 进行版本控制，并且它们必须具有向后兼容性，使得上一代客户端继续随着 API 的发展而正常运行。此设计原则对于允许逐步发布 API 更改至关重要，可在必要时快速回滚。

对于移动应用而言，实现回滚的成本可能很高。Firebase Remote Config 是一项 Google Cloud 服务，可简化功能回滚。

您无法轻松回滚数据库架构更改，因此请分多个阶段执行。设计每个阶段，以允许按最新版本的应用和先前版本进行安全架构读取和更新请求。这种设计方法让您可以在最新版本出现问题时安全地回滚。

建议

如需将架构框架中的指导运用到您自己的环境，请遵循以下建议：

在客户端应用的错误重试逻辑中实现随机化指数退避算法。
实现具有自动故障切换功能的多地区架构，以实现高可用性。
使用负载均衡功能在分片和地区之间分布用户请求。
将应用设计为在过载时逐步降级。提供部分响应或提供有限功能，避免完全停止工作。
建立容量规划的以数据为依据的流程，并使用负载测试和流量预测来确定何时预配资源。
制定灾难恢复程序并定期进行测试。

操作流程和工具

Google Cloud 架构框架中的本文档提供了以可靠方式运行服务的操作原则，例如如何部署更新、在生产环境中运行服务以及测试故障。可靠性架构设计应涵盖服务的整个生命周期，而不仅仅是软件设计。

为应用和服务选择好的名称

避免在生产配置文件中使用内部代号，因为它们可能会造成混淆（尤其是对于较新的员工），从而增加服务中断的缓解时间 (TTM)。请尽可能为您的所有应用、服务和关键系统资源（例如虚拟机、集群和数据库实例）选择良好的名称，并遵守其各自的名称长度限制。良好的名称应描述实体的用途；应该是准确、具体且独特的，并且读起来应该是有意义的。良好的名称应避免首字母缩略词、代号、缩写以及可能具有冒犯性的用语，并且即使对外发布，也不会引发负面的公众反应。

借助 Canary 测试实现渐进式发布

对服务二进制文件或配置进行的即时全局更改本身就存在风险。逐步发布新版本可执行文件和配置更改。从一个小范围（例如一个可用区中的几个虚拟机）开始，逐步扩大范围。如果更改没有达到预期效果，或者在部署过程中的任何阶段对用户产生负面影响，则快速回滚。您的目标是在只影响一小部分用户流量时识别并解决错误，然后再在全球范围内发布更改。

设置一个 Canary 测试系统，该系统会注意到服务更改，并对更改后的服务器与其余服务器的指标进行 A/B 比较。系统应标记意外行为或异常行为。如果更改没有达到预期效果，则 Canary 测试系统应该会自动停止发布。问题可能很明显（如用户错误）或很细微（如 CPU 使用率增加或内存膨胀）。

最好在出现问题的第一个提示时停止并回滚，然后在没有服务中断时间压力的情况下诊断问题。更改通过 Canary 测试后，请逐步将其传播到更大的范围，例如先传播到一个完整的可用区，然后再传播到第二个可用区。让更改后的系统有时间逐步处理更多用户流量，以发现潜在的 bug。

如需了解详情，请参阅应用部署和测试策略。

为限时促销和发布活动分散流量

您可能有一些促销活动（例如在某个精确时间开始的促销），并鼓励许多用户同时连接到服务。如果是这样，请设计客户端代码以将流量分散到几秒内。在发出请求前添加随机延迟。

您还可以预热系统。预热系统时，您需要提前将预期的用户流量发送到系统，以确保系统按预期运行。此方法可以防止在规划的开始时间出现的即时流量高峰导致您的服务器崩溃。

自动构建、测试和部署

通过使用持续集成和持续交付 (CI/CD) 流水线，消除发布流程中的手动工作。执行自动集成测试和部署。例如，使用 GKE 创建现代化 CI/CD 流程。

如需了解详情，请参阅持续集成、持续交付、测试自动化和部署自动化。

防范运维人员的错误

设计您的操作工具以拒绝可能无效的配置。当配置版本为空、部分或截断、损坏、逻辑不正确或不符合预期或者未在预期时间内收到时，检测并发出提醒。工具还应拒绝与先前版本存在很大差异的配置版本。

禁止范围宽泛导致可能具有破坏性的更改或命令。这些宽泛的命令可能是“撤消所有用户的权限”“重启此地区中的所有虚拟机”或“重新格式化此地区中的所有磁盘”。只有当操作员在部署配置时添加紧急替换命令行标志或选项设置时，才应该应用此类更改。

工具必须显示有风险的命令的影响范围（例如，更改影响的虚拟机数量），并且要求在工具继续操作之前需要明确的操作员确认。您还可以使用功能来锁定关键资源并防止意外或未经授权删除它们，例如 Cloud Storage 保留政策锁定。

测试故障恢复

定期测试从服务故障中恢复的操作过程。如果不进行定期测试，则当发生实际故障而需要这些过程时，它们可能不起作用。定期测试的内容包括地区性故障切换、如何回滚版本以及如何从备份恢复数据。

执行灾难恢复测试

与故障恢复测试一样，不要等到灾难来袭再行动。请定期测试和验证您的灾难恢复程序和流程。

您可以创建一个系统架构来提供高可用性 (HA)。此架构与灾难恢复 (DR) 并不完全重叠，但在考虑恢复时间目标 (RTO) 和恢复点目标 (RPO) 值时，通常需要考虑 HA。

HA 可帮助您达到或超出商定的操作性能级别，例如正常运行时间。当您在 Google Cloud 上运行生产工作负载时，您可以在第二个地区中部署被动或主动备用实例。在此架构中，如果主要地区发生灾难，应用会从不受影响的地区继续提供服务。如需了解详情，请参阅针对云服务中断设计灾难恢复架构。

试验混沌工程

考虑在测试做法中使用混沌工程。将实际故障引入到安全环境中的负载下生产系统的不同组件中。这种方法有助于确保对系统整体没有影响，因为您的服务会在每个级别正确处理故障。

注入到系统中故障可能包括 RPC 的崩溃任务、错误和超时，或者资源可用性的降低。使用随机故障注入功能来测试服务依赖项中的间歇性故障（波动）。这些行为在生产环境中难以检测和缓解。

混沌工程可确保将此类实验的影响降至最低并加以控制。您可以将此类测试视为实际服务中断的演习，并利用收集的所有信息来改善服务中断响应。

构建高效提醒

Google Cloud 架构框架中的本文档提供了用来创建提醒以帮助您运行可靠服务的操作原则。您拥有有关服务性能的信息越多，问题出现时您做出的决策就越明智。设计提醒以及早并准确检测到所有会影响用户的系统问题，并最大限度地减少假正例。

优化提醒延迟时间

在以下两点之间会保持平衡：太早发送的提醒会给运营团队带来压力，太晚发送的提醒会导致长时间服务中断。在监控系统通知用户问题之前调整提醒延迟时间，以最大限度地减少检测时间，同时最大化信号与噪声。使用错误预算使用率来获得最佳提醒配置。

针对表现（而非原因）触发提醒

根据对用户体验的直接影响触发提醒。不符合全局或每个客户的 SLO 则会产生直接影响。不针对故障的每个可能的根本原因发出提醒，尤其是当影响仅限于单个副本时。设计良好的分布式系统可以从单副本故障中顺利恢复。

针对离群值（而不是平均值）触发提醒

监控延迟时间时，请定义 SLO，并为第 90、95 或 99 百分位延迟时间（而不是平均或第 50 百分位延迟时间）设置提醒（三选二）。良好的平均值或延迟时间中位数值可以在第 90 百分位或更高级别隐藏不可接受的高值，以免导致非常糟糕的用户体验。因此，在监控任何关键操作（例如，与网络服务器的请求-响应交互、数据处理流水线中的批量完成或者对存储服务的读取或写入操作）的延迟时间时，您都应该应用此离群值提醒原则。

事件流程管理

Google Cloud 架构框架中的本文档提供了管理服务和定义响应突发事件流程的最佳实践。所有服务都会出现突发事件，因此您需要一个有详尽文档记录的流程来高效响应这些问题并缓解这些问题。

突发事件管理概览

精心设计的系统最终会有无法达到 SLO 的时候，这是不可避免的。在缺少 SLO 的情况下，根据他们以往的经验来确定可接受的服务等级。无论 SLA 包含什么内容，客户都会上报给您的技术支持团队或类似团队。

为了给客户提供合适的服务，请制定并定期测试突发事件管理方案。该方案可以只有短短一页，是包含 10 项内容的一个核对清单。此过程可帮助您的团队缩短检测时间 (TTD) 和缓解时间 (TTM)。

TTM 优于 TTR，其中的 R 是英语 Repair（修复）或 Recovery（恢复）的首字母，它通常用于表示完全修复（而不是缓解）。TTM 强调快速缓解措施，以快速结束服务中断对客户的影响，然后再启动通常需要时间更长的流程来完全解决问题。

如果系统设计良好、运营出色，则其故障间隔时间 (TBF) 也会增加。换句话说，可靠性（包括良好的突发事件管理）的运营原则旨在降低故障频率。

如需运行可靠的服务，请在突发事件管理过程中运用以下最佳做法。

指定明确的服务所有权

所有服务及其关键依赖项都必须有明确的所有者，负责遵守其 SLO。如果存在重组或团队调优，则工程主管必须确保将所有权明确移交给新团队，一并移交所需的文档和进行适当的培训。服务的所有者必须很容易被其他团队发现。

利用经过微调的提醒来缩短检测时间 (TTD)

在缩短 TTD 之前，请查看并实施架构框架可靠性类别中的将可观测性内置到您的基础架构和应用中和确定您的可靠性目标部分中的建议。例如，区分应用问题和底层云问题。

一组完善的 SLI 会在适当的时间向您的团队发出提醒，而不会触发过多提醒。如需了解详情，请参阅架构框架可靠性类别的构建高效的提醒部分或“优化您的 SLI 指标：CRE 经验谈”。

通过突发事件管理计划和培训，缩短缓解时间 (TTM)

如需降低 TTM，请制定一个经过实践检验的突发事件管理方案。轻松获取环境变化数据。确保团队知道他们可以快速应用通用缓解措施以最大限度地缩短 TTM。这些缓解技术包括排空、回滚更改、增加资源容量以及降低服务质量。

如另一份架构框架可靠性类别文档中所述，创建可靠的操作流程和工具以支持安全、快速回滚更改。

设计信息中心布局和内容以最大限度地缩短 TTM

整理服务信息中心布局和导航，以便操作员可在一两分钟内确定服务及其所有关键依赖项是否正在运行。为了快速查明问题的潜在原因，操作员必须能够扫描信息中心上的所有图表，以快速查找在触发提醒时变化显著的图表。

您的信息中心上提供了以下示例图表列表，以帮助排查问题。突发事件响应者应该能够在单个视图中对它们一目了然：

服务等级指标，例如成功请求数除以有效请求总数
配置和二进制文件发布
每秒向系统发出的请求数
每秒从系统返回的错误响应数
每秒从系统到其依赖项的请求数
每秒从系统依赖项到系统的错误响应次数

其他有助于排查问题的图表包括延迟时间、饱和度、请求大小、响应大小、查询费用、线程池利用率和 Java 虚拟机 (JVM) 指标（如果适用）。饱和度是指一些限制（例如配额或系统内存大小）导致变满。线程池利用率会查找由于池耗尽而导致的回归。

针对少数中断场景测试这些图表的位置，确保最重要的图表靠近顶部，并且图表的顺序与标准诊断工作流相匹配。您还可以使用机器学习和统计异常值检测功能来显示这些图表的子集。

针对已知的中断情况记录诊断过程和缓解措施

编写策略方案并从提醒通知链接到它们。如果这些文档可以从提醒通知中访问，那么运营商可以快速获得排查和缓解问题所需的信息。

利用无责备事后分析来了解服务中断情况并防止再次发生

构建无责备的事后分析文化和突发事件审核流程。无责备表示您的团队会客观地评估和记录问题，而不会加以责备。

错误是学习的机会，而不是批评的原因。始终以提高系统弹性为目标，使其能够从人为错误中快速恢复，甚至更好地检测和防止人为错误。从每个事后分析提取尽可能多的学习信息，并严格关注每个事后分析待办项，以降低中断频率，从而增加 TBF。

突发事件管理方案示例

已检测到生产问题（例如通过提醒或页面）或上报给我。

我应该委托给其他人吗？
- 是的。如果您和您的团队无法解决问题。
此问题是否侵犯隐私权或违反安全规定？
- 如果是，请委托给隐私权或安全团队。
此问题是紧急事件还是存在风险的 SLO？
- 如果不确定，请将其视为紧急事件。
我是否应该让更多人参与？
- 是的，如果受影响的客户超过 X%，或者解决时间超过 Y 分钟。如果不确定，请务必让更多人参与，尤其是在工作时间。
定义主要沟通渠道，例如 IRC、Hangouts Chat 或 Slack。
委托以前定义的角色，例如：
- 突发事件指挥官：负责整体协调工作。
- 沟通主管，负责处理内部和外部沟通。
- 运营主管：负责缓解问题。
定义突发事件的结束时间。此决策可能需要支持代表或其他类似团队确认。
协作完成无责备的事后分析。
参加突发事件事后分析审核会议，讨论相关事宜并采取行动。

建议

如需将架构框架中的指导运用到您自己的环境，请遵循以下建议：

制定突发事件管理方案，并培训您的团队使用该方案。
如需缩短 TTD，请实施建议以将可观测性内置到您的基础架构和应用中。
构建一个“变化内容”信息中心，以便在发生突发事件时轻松查看变化。
记录查询代码段，或构建包含频繁日志查询的 Looker 数据洞察信息中心。
评估 Firebase 远程配置以缓解移动应用的发布问题。
测试失败恢复（包括从备份恢复数据），以降低部分突发事件的 TTM。
设计并测试配置和二进制文件回滚。
跨区域复制数据以进行灾难恢复，并使用灾难恢复测试，以在发生区域服务中断后缩短 TTM。
如果企业需要高可用性来证明费用合理，则可以设计多区域架构以应对区域服务中断，从而增加 TBF。