定义 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)。”

    显示 SLO 和 SLI 之间关系的图表。

  • 服务等级协议 (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 指标类型 ValueTypeMetricKind

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 毫秒。

后续步骤