2. SLI 与 SLO 基础:定义服务等级指标与服务等级目标

在 SRE 实践中,SLI(Service Level Indicator,服务等级指标)与SLO(Service Level Objective,服务等级目标)是构建可靠性工程的基石。它们不仅量化了服务的“健康”程度,更是 Error Budget 策略的输入与约束条件。理解这三者的关系,是设计灰度发布准入策略的前提。

2.1 什么是 SLI(服务等级指标)?

SLI 是对服务某个特定维度的量化测量,通常是一个随时间变化的比率或数值。常见的 SLI 维度包括:

维度 典型 SLI 定义 测量方式
可用性 请求成功数 / 总请求数 HTTP 200/5xx 状态码计数
延迟 在特定时间窗口内,满足阈值(如 ≤200ms)的请求比例 P99 / P95 分位延迟
吞吐量 每秒成功处理的请求数(RPS) 服务端请求计数器
错误率 返回错误(如 HTTP 5xx、超时、业务异常)的请求比例 错误日志 / 监控指标
饱和度 资源使用量 / 资源容量上限 CPU / 内存 / 连接池使用率
实践建议:SLI 应选择用户可感知的指标。例如,对于 API 网关,核心 SLI 是“端到端请求延迟 P99 ≤ 500ms”和“可用性 ≥ 99.9%”,而非内部数据库连接池大小。

2.2 什么是 SLO(服务等级目标)?

SLO 是团队为 SLI 设定的目标阈值,代表“我们希望服务做到多好”。SLO 通常是一个百分比,并附带一个时间窗口(如过去 30 天)。

  • 格式示例:“在过去 30 天内,99.9% 的请求延迟 ≤ 200ms”。
  • 严格程度:SLO 应比用户实际期望略低,为系统留出容错空间。
  • 多层级:通常分为“严格 SLO”(如 99.99%)和“宽松 SLO”(如 99.9%),用于不同场景。
关键原则:SLO 不是 SLA(服务等级协议)。SLA 是对外的承诺,通常附带赔偿条款;SLO 是内部目标,用于指导工程决策。SLO 可以比 SLA 更严格,但绝不能更宽松。

2.3 SLI 与 SLO 的关系:一个示例

假设我们有一个用户登录服务:

  • SLI:过去 1 分钟内,登录请求的 HTTP 200 响应比例。
  • SLO:过去 30 天内,该 SLI 的月度平均值 ≥ 99.95%。

如果某次灰度发布导致登录接口错误率上升,SLI 会立即下降。当 SLI 低于 SLO 阈值时,意味着我们正在消耗 Error Budget。

2.4 Error Budget 的定义与计算

Error Budget(错误预算)是 SLO 的“反向”指标,代表服务在给定时间窗口内允许失败的总量。计算公式为:

Error Budget = (1 - SLO) × 总请求量 × 时间窗口

例如,一个 SLO 为 99.9% 的服务,在 30 天(约 2,592,000 秒)内,假设每秒 1000 个请求:

总请求量 = 2,592,000 × 1000 = 2,592,000,000
Error Budget = (1 - 0.999) × 2,592,000,000 = 2,592,000 次失败

这意味着该服务在 30 天内最多允许约 259 万次失败。一旦消耗完,团队必须停止所有非紧急变更(如灰度发布),优先恢复稳定性。

2.5 三者的核心关系:一个内联 SVG 流程图

下图展示了 SLI、SLO 与 Error Budget 之间的闭环关系:

SLI、SLO 与 Error Budget 闭环关系 SLI 测量 实际请求成功率 / 延迟 SLO 目标 期望阈值(如 99.9%) Error Budget 允许失败次数 消耗判断 SLI 是否低于 SLO? 行动决策 停止变更 / 回滚 / 修复 灰度发布准入 仅当 Budget 充足时允许 修复后重新测量 SLI

2.6 关系总结表

概念 本质 与 Error Budget 的关系 在灰度发布中的作用
SLI 实时测量值 作为 Error Budget 消耗的输入 灰度期间持续监控,判断是否触发回滚
SLO 目标阈值 定义 Error Budget 的总量 决定灰度发布是否允许准入
Error Budget 剩余容错空间 自身是决策依据 当 Budget 耗尽时,禁止灰度发布

2.7 实践中的关键考量

  • SLI 选择:避免选择“完美”但无意义的指标。例如,内部健康检查的成功率通常很高,但无法反映真实用户体验。
  • SLO 设定:不要追求 100%。100% 的 SLO 意味着零容错,会导致 Error Budget 为 0,任何变更都无法进行。
  • 时间窗口:Error Budget 通常使用滚动窗口(如 30 天),而非固定日历月,以避免月末“突击”消耗。
  • 多 SLO 场景:一个服务可以有多个 SLO(如延迟 SLO + 可用性 SLO)。灰度发布准入应检查所有 SLO 的 Error Budget 是否充足。
常见陷阱:不要将 SLI 与 SLO 混为一谈。SLI 是“实际值”,SLO 是“期望值”。在灰度发布准入脚本中,应比较的是“当前 SLI 是否在 SLO 范围内”,而非“SLI 是否等于 SLO”。

2.8 一个内联 SVG 架构图:多 SLO 下的 Error Budget 视图

当服务包含多个 SLO 时,Error Budget 的管理需要分层聚合。下图展示了一个典型微服务的多维度 Error Budget 视图:

多 SLO 下的 Error Budget 分层视图 用户服务 可用性 SLO (99.95%) Budget: 0.05% 延迟 SLO (P99 ≤ 200ms) Budget: 1% 超时 错误率 SLO (< 0.1%) Budget: 0.1% Error Budget 聚合判断:所有 SLO 的 Budget 均未耗尽? 是 → 允许灰度发布;否 → 禁止变更 说明:灰度发布准入条件 = 所有 SLO 的 Error Budget 均未耗尽(即 SLI 仍在 SLO 范围内) 任一 SLO 的 Budget 耗尽,则触发“禁止变更”策略,直至 Budget 恢复。

2.9 小结