Google SRE： SLI、SLO、SLA 、Error Budget 详解

0、总结

SLI是随时间变化的度量值，比如请求的延迟，每秒请求的吞吐量，或者每种请求的失败次数。这些值通常会随时间累积，然后被转换为一个比率，平均值或者相对某个阈值的百分比。

SLO是相关方一致同意的贯穿一个时间窗口（比如过去30天或者这个季度）内SLI累积成功数的目标

1、 SRE 服务质量

SLI 是我们选择的衡量系统稳定性的指标，SLO 是每个指标对应的目标，而我们又经常把 SLO 转化为错误预算，因为错误预算的形式更加直观。

转化后，我们要做的稳定性提升和保障工作，其实就是想办法不要把错误预算消耗完，或者不能把错误预算快速大量地消耗掉。

1.1 服务质量指标 SLI （Service Level Indicator）

该服务的某项服务质量的一个具体量化指标，用于测量性能。

性能指标的示例包括：

• 请求计数：例如，每分钟产生 2xx 或 5xx 响应的 HTTP 请求数。
• 响应延迟时间：例如，HTTP 2xx 响应的延迟时间。

SLI 通常分为两类：

• 基于请求的 SLI，通过计算服务的原子单位（例如成功的 HTTP 请求的数量）来测量服务性能。
• 基于窗口的 SLI，通过计算性能满足良好标准（例如低于给定阈值的响应延迟时间）的时间段（也称为窗口）来测量服务性能。

1.2 服务质量目标 SLO（Service Level Objective）

该服务的某个SLI的目标值、或目标范围，用于说明预期性能。

SLO的两种定义为：

1. SLI ≤ 目标值
2. 范围下限 ≤ SLI ≤ 范围上限

SLO 由以下值组成：

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

示例：

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

SLO 和 SLI 之间关系的图表：

1.2.1 SLO 的两种类型

SLO 有两种类型：

• 基于请求的 SLO
• 基于窗口的 SLO

1.2.2 基于请求的 SLO

基于请求的 SLO 基于一个 SLI，该 SLI 定义为良好请求数与请求总数的比率。当该比率达到或超出合规期的目标时，则基于请求的 SLO 得到满足。

例如，考虑以下基于请求的 SLO：“至少 95% 的请求延迟时间低于 100 毫秒。”良好请求是响应时间短于 100 毫秒的请求，因此合规性的测量标准是响应时间不超过 100 毫秒的请求的比例。如果此比例至少为 0.95，则表示该服务合规。

通过基于请求的 SLO，您可以了解服务在整个合规期间正常工作量的百分比（无论负载在整个合规性期间如何分布）。

1.2.3 基于窗口的 SLO

基于窗口的 SLO 基于一个 SLI，该 SLI 定义为满足一定良好标准的测量间隔数与总间隔数的比率。当该比率达到或超过合规期的目标时，基于窗口的 SLO 得到满足。

例如，考虑这样一个 SLO：“在一个 10 分钟窗口至少 99% 的时间内，第 95 百分位的延迟时间指标小于 100 毫秒”。一个良好的测量周期为 10 分钟，其中 95% 的请求的延迟时间小于 100 毫秒。合规性的衡量标准是这种良好周期的比例。如果此比例至少为 0.99，则该服务合规。

1.3 服务质量协议 SLA（Service Level Agreement）

该服务与用户之间的一个明确的、或不明确的协议，描述了在达到或没有达到SLO的后果。

如果SLO没有达到时，会有什么后果？如果没有定义明确的后果，那么我们就肯定在讨论一个SLO而不是SLA。

示例：

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

1.4 错误预算（Error Budget）

错误预算：用于测量实际性能与预期性能之间的差异，用于期望或可容忍的错误数。错误预算对于帮助做出有潜在风险的决策至关重要。

Error Budget = 100% — SLO

• 红色为错误预算
  

示例：

• “如果我们的 SLO 达到 99.9％ 可用性，我们允许 0.1％ 的请求通过突发事件、事故或实验处理错误。”
• 如果我们的服务在4周内收到的请求数为1,000,000个，则99.9%的可用性意味着，我们在这段时间里的预算是1000个错误请求。

错误预算（Error Budget）最大的作用就是“提示你还有多少次犯错的机会”
错误预算是怎么得出的呢？其实计算方式一点都不复杂，简单讲就是通过SLO 反向推导出来的。

假设一个应用在4周的时间内，所有的请求次数为4,653,680，按照给出的 SLO 反向推导，就可以得到容许的错误次数，这就是错误预算。

SLO 指定了服务在合规期间内的性能水平。在合规期间未完成的部分将成为 错误预算。错误预算量化了服务在合规性期间在满足 SLO 的前提下无法执行的部分。

通过错误预算，可以跟踪在合规期内违反 SLO 之前允许发生的独立不良事件（例如请求）的数量。您可以使用错误预算来管理维护任务，例如部署新版本。在错误预算接近耗尽时采取有风险的操作（例如推送新的更新）可能会导致违反 SLO。

合规期的错误预算为（1− SLO 目标）×（合规期中符合条件的事件）。例如，如果 SLO 是在 7 天的滚动期内 85% 的请求是良好的，则错误预算允许 15% 的这些请求是错误的。如果您在过去一周收到了 60480 个请求，则错误预算允许该总数的 15%（即 9072 个请求）是错误请求。如果提供的错误数超过此上限，则表明的服务在 7 天合规期内未达到 SLO。

1.5 关键用户旅程 (CUJ) critical user journeys

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

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