选择您的服务等级目标 (SLO)

Last reviewed 2024-03-29 UTC

Google Cloud 架构框架中的本文档定义了用户体验如何定义可靠性，以及如何选择合适的服务等级目标来达到这种可靠性级别。本文档以 SLO 的组成部分中定义的概念为基础。

站点可靠性工程 (SRE) 文化重视可靠的服务和客户满意度。如果没有定义的服务等级和收集指标的方法，则很难（如果不是不可能的话）确定在改进方面将资金投向何处以及投入多少资金。

用于衡量服务等级的重要指标是服务等级目标 (SLO)。SLO 由以下值组成：

  • 服务等级指标 (SLI)：服务的特定方面的指标，如选择 SLI 中所述。
  • 时长：衡量 SLI 的窗口。这可能是基于日历的，也可以是滚动窗口。
  • 目标：SLI 应在运行状况良好的服务中在指定时间段内满足的值（或值范围）。例如，良好事件占您希望服务满足的事件总数的百分比，例如 99.9％。

为您的服务选择合适的 SLO 是一个过程。首先，您需要定义用于确定可靠性以及最终确定 SLO 的用户体验历程。您选择的 SLO 需要衡量整个系统，同时还要平衡功能开发的需求与运营稳定性。选择 SLO 后，您需要以迭代方式对其进行改进，并使用错误预算来管理它们。

定义用户体验历程

理想情况下，您的 SLI 和 SLO 基于关键用户历程 (CUJ)。CUJ 会考虑用户目标以及您的服务如何帮助用户实现这些目标。您可以定义 CUJ，而不考虑服务边界。当满足 CUJ 时，客户很满意，这表示服务成功。

客户满意度或不满意度决定了可靠性，是任何服务最重要的特征。

因此，将您的 SLO 设置到合适的高度（不要太高），以便大多数用户对您的服务感到满意。就像 100% 可用性不是正确的目标一样，在 SLO 中增加“9”的个数会很快增加成本，而且可能对客户而言无关紧要。

对于正常运行时间和其他重要指标，请尽量将目标值控制在 100% 以下，但接近此值。评估所需的最低服务性能和可用性级别。不要根据外部合同级别设置目标。

使用 CUJ 开发 SLO

选择您的公司最重要的 CUJ，然后按照以下步骤开发 SLO：

  1. 选择 SLI 规范（例如可用性或新鲜度）。
  2. 定义如何实现 SLI 规范。
  3. 确保您的计划涵盖所有 CUJ。
  4. 根据过去的性能或业务需求设置 SLO。

CUJ 不应限制为单个服务，也不应限于单个开发团队或组织。您的服务可能依赖于数十个或更多其他服务。您可能也希望这些服务以 99.5% 的 SLO 来运行。但是，如果未跟踪端到端（整个系统）性能，则运行可靠的服务并非易事。

定义目标和持续时间

定义目标和时长（请参阅之前的 SLO 定义）可能很困难。开始此过程的一种方法是确定 SLI 并随时间绘制图表。请记住，SLO 不一定从一开始就是完美的。迭代您的 SLO，以确保它符合客户满意度并满足您的业务需求。

在部署、服务中断和每日流量模式等事件期间跟踪 SLO 合规性时，您将深入了解目标。这些数据分析可让您更清楚地了解目标和持续时间的良好、不良或可容忍度。

功能开发、代码改进、硬件升级和其他维护任务都有助于使您的服务更可靠。频繁进行这些细微更改的能力有助于更快地提供更高质量的功能。但是，服务的更改速率也会影响可靠性。可实现的可靠性目标定义了客户可以接受并从中受益的更改速度和范围（称为功能速度）。

如果您无法衡量客户体验并据此确定目标，则可以转向外部来源和进行基准分析。如果没有可比较的基准，即使您还无法确定目标，也要衡量客户体验。随着时间的推移，您可以达到合理的客户满意度阈值。此阈值就是您的 SLO。

了解整个系统

您的服务可能存在于进行上游和下游处理的许多服务中。以零散的方式（逐个服务）衡量分布式系统的性能无法准确反映客户的体验，并且可能会导致过于敏感的解释。

相反，您应该根据流程前端的 SLO 来衡量性能，以了解用户的体验。如果自动并成功地重试查询，则用户不会担心导致查询失败的组件故障。

如果有共享内部服务，则每项服务都可以根据关联的 SLO 单独衡量性能，而面向用户的服务充当其客户。请单独处理这些 SLO。

使用智能重试、缓存和排队等弹性因素，可以在可用性较差的服务（例如 99.9%）之上构建高可用性服务（例如 99.99%）。任何具有统计工作知识的人都应能够阅读和理解您的 SLO，而无需了解您的基础服务或组织布局（如 Conway 定律中所述）。

选择正确的 SLO

产品开发速度和运营稳定性之间存在着固有的矛盾。对系统的更改越多，它就越有可能崩溃。随着功能速度的提高，监控和可观测性工具对于运营稳定性至关重要。此类工具称为应用性能管理 (APM) 工具，也可用于设置 SLO。

如果定义正确，SLO 可帮助团队做出数据驱动型运营决策，从而加快开发速度，而不会影响稳定性。SLO 还可以围绕一个商定的目标使开发和运营团队保持一致。共享一个目标可以缓解前面提到的固有矛盾：开发团队的目标是创建和迭代产品，而运营团队的目标是维护系统完整性。

使用本文档和架构框架中的其他可靠性文档来了解和开发 SLO。阅读并理解这些文章后，请参阅《SRE 书籍》和《SRE 手册》中有关 SLO（和其他 SRE 实践）的更多详细信息。

使用严格的内部 SLO

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

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

反复验证以改进 SLO

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

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

错误预算会显示您的服务是高于还是低于特定时间窗口所需的可靠性。一段时间内（例如 30 天）“错误预算”的计算公式为 (100% – SLO)。

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

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

SLO 建议总结

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

后续步骤