2. SLO 基础概念:服务等级目标定义、SLI 与 SLO 的区别、错误预算概念

在平台工程中,SLO(Service Level Objective,服务等级目标)是连接用户期望与系统行为的核心契约。理解 SLO 之前,必须先厘清 SLI(Service Level Indicator,服务等级指标)与 SLO 的关系,并掌握错误预算(Error Budget)这一关键管理工具。本节将逐一拆解这三个概念,并展示它们如何在变更失败率归因中发挥作用。

2.1 服务等级指标(SLI)

SLI 是对服务某个特定维度的直接量化测量。它回答的是“服务现在表现如何”的问题。常见的 SLI 包括:

  • 延迟(Latency):请求响应时间,如 p99 延迟 < 200ms。
  • 可用性(Availability):成功请求占总请求的比例,如 99.9%。
  • 吞吐量(Throughput):单位时间处理的请求数,如 1000 req/s。
  • 错误率(Error Rate):返回错误状态码的请求比例,如 < 0.1%。
  • 饱和度(Saturation):资源使用程度,如 CPU 使用率 < 80%。
选择 SLI 的原则: 优先选择与用户体验直接相关的指标。对于平台工程中的变更失败率,核心 SLI 通常是“变更导致的错误率”或“变更后的可用性下降幅度”。

2.2 服务等级目标(SLO)

SLO 是为 SLI 设定的目标阈值,它回答的是“服务应该表现到什么程度”。SLO 是一个明确的、可量化的承诺,通常以时间窗口内的达标率表示。

SLO 的典型表达形式:

  • “在 30 天滚动窗口内,99.9% 的请求延迟低于 200ms。”
  • “在 28 天内,可用性不低于 99.95%。”
  • “在 7 天内,变更导致的错误率不超过 0.5%。”
关键区别: SLI 是实际测量值,SLO 是目标值。SLI 告诉你现在是多少,SLO 告诉你应该达到多少。

2.3 SLI 与 SLO 的对比

维度 SLI(服务等级指标) SLO(服务等级目标)
定义 对服务质量的直接测量 为 SLI 设定的目标阈值
回答的问题 服务现在表现如何? 服务应该表现到什么程度?
数值类型 原始测量值(如 150ms、99.92%) 带时间窗口的阈值(如 99.9% / 30d)
变更频率 实时或近实时变化 相对稳定,按季度或版本调整
在变更归因中的作用 提供变更前后的数据对比 定义变更是否“违规”的基准线

2.4 错误预算(Error Budget)

错误预算 = 100% - SLO。它代表在 SLO 允许的范围内,服务可以“犯错”的总时间或总请求量。错误预算将可靠性从目标转化为可消耗的资源。

错误预算的计算示例:

  • 如果 SLO 是 99.9%(30 天窗口),则错误预算 = 0.1%。
  • 30 天总分钟数 = 43200 分钟。
  • 允许的不可用时间 = 43200 × 0.1% = 43.2 分钟。
  • 如果本月已发生 30 分钟故障,则剩余错误预算 = 13.2 分钟。
错误预算耗尽意味着什么? 当错误预算接近 0 时,应冻结所有非紧急变更,优先恢复可靠性。这是 SLO 驱动变更管理的关键控制点。

2.5 三者的关系与流程

下图展示了 SLI、SLO 与错误预算在变更失败率归因中的协作关系:

SLI、SLO 与错误预算关系图 SLI、SLO 与错误预算在变更归因中的协作 SLI 测量 实际延迟 / 错误率 / 可用性 SLO 目标 99.9% 延迟 < 200ms 错误预算 100% - SLO = 0.1% 对比 计算 变更失败率归因:SLI 偏离 → 触发 SLO 告警 → 消耗错误预算 触发 输入 变更失败率归因决策逻辑 1. 变更后 SLI 是否超出 SLO 阈值? 2. 超出部分消耗了多少错误预算? 3. 错误预算是否接近耗尽?→ 冻结变更 / 回滚

2.6 错误预算在变更管理中的实际应用

错误预算不仅是可靠性指标,更是变更节奏的调节器。下表展示了不同错误预算状态下的变更策略:

错误预算状态 剩余比例 变更策略 风险等级
充足 > 50% 正常发布,可进行高风险变更 低
中等 20% - 50% 仅允许低风险变更,加强监控 中
紧张 5% - 20% 仅允许紧急修复,启动变更审批 高
耗尽 < 5% 冻结所有非必要变更,全力恢复 严重

2.7 变更失败率归因中的 SLO 应用示例

假设一个平台服务的 SLO 为“99.9% 可用性(30 天窗口)”,错误预算为 43.2 分钟。某次变更后,可用性下降至 99.5%,持续 10 分钟:

  1. SLI 测量:可用性从 99.95% 降至 99.5%。
  2. SLO 对比:99.5% < 99.9%,超出 SLO 阈值。
  3. 错误预算消耗:10 分钟不可用时间,消耗了 10 / 43.2 ≈ 23% 的错误预算。
  4. 归因结论:该变更为“失败变更”,消耗了显著的错误预算,需要回滚并分析根因。
核心要点: SLO 驱动的变更失败率归因,本质上是将变更对用户体验的影响量化为错误预算的消耗。消耗越多,变更的“失败”程度越高,归因优先级也越高。