4. SLI 与 SLO 基础:定义与错误预算
在可观测性与 SRE 实践中,SLI(Service Level Indicator,服务等级指标)与SLO(Service Level Objective,服务等级目标)是定义服务可靠性的核心语言。错误预算(Error Budget)则是在 SLI 与 SLO 基础上建立的运维决策机制。本节将系统阐述这三个基础概念及其相互关系。
4.1 SLI(服务等级指标)定义
SLI 是对服务某个特定维度的量化测量,通常表示为一段时间内的比率、计数或持续时间。SLI 必须可观测、可采集、可计算,且直接反映用户体验。
| SLI 类别 | 典型指标 | 测量方式 | 示例 |
|---|---|---|---|
| 可用性 | 请求成功率 | 成功请求数 / 总请求数 | HTTP 200/5xx 比率 |
| 延迟 | 响应时间百分位 | P50/P95/P99 延迟 | P99 延迟 < 200ms |
| 吞吐量 | 每秒请求数(RPS) | 单位时间请求计数 | 峰值 RPS > 10000 |
| 错误率 | 失败请求占比 | 错误响应数 / 总响应数 | 5xx 率 < 0.1% |
| 饱和度 | 资源使用率 | 当前使用量 / 容量上限 | CPU 使用率 < 80% |
SLI 选择原则:优先选择与用户直接交互的指标(如前端延迟、API 成功率),而非基础设施指标(如 CPU 使用率)。SLI 应覆盖服务的核心用户旅程(Critical User Journey, CUJ)。
4.2 SLO(服务等级目标)定义
SLO 是为 SLI 设定的目标阈值,表示服务在特定时间窗口内应达到的可靠性水平。SLO 通常以百分比形式表达,例如“99.9% 的请求在 200ms 内完成”。
SLO 的设定需平衡用户体验与运维成本。过高的 SLO(如 99.999%)会显著增加架构复杂度和运维投入,而过低的 SLO 则可能损害用户信任。
| SLO 等级 | 可用性目标 | 年度最大不可用时间 | 典型适用场景 |
|---|---|---|---|
| 标准 | 99.9% | 8.76 小时 | 内部工具、非关键业务 |
| 高 | 99.99% | 52.56 分钟 | 面向用户的核心服务 |
| 极高 | 99.999% | 5.26 分钟 | 金融交易、实时通信 |
常见误区:SLO 不是“承诺”,而是“目标”。SLO 允许偶尔未达标,但需通过错误预算机制进行管理。不要将 SLO 与 SLA(Service Level Agreement,服务等级协议)混淆,SLA 是合同层面的法律承诺,通常比 SLO 更宽松。
4.3 错误预算(Error Budget)概念
错误预算 = 1 - SLO。例如,SLO 为 99.9% 的服务,其错误预算为 0.1%(即 1000 个请求中允许 1 个失败)。错误预算定义了服务在给定时间窗口内允许的不可靠性总量。
错误预算的核心价值在于:
- 量化风险容忍度:明确团队可以承受多少故障。
- 驱动运维决策:当错误预算充足时,可进行风险较高的变更;当错误预算耗尽时,应冻结发布并优先恢复可靠性。
- 平衡创新与稳定:避免因过度追求 100% 可用性而阻碍功能迭代。
错误预算消耗示例:某服务 SLO 为 99.9%,月度总请求数为 1000 万,则月度错误预算为 10000 次失败。若本月已发生 8000 次失败,则剩余错误预算为 2000 次。此时团队应评估是否继续发布新版本。
4.4 SLI、SLO 与错误预算的关系
下图展示了三者之间的核心逻辑链路:SLI 提供原始测量数据,SLO 设定目标阈值,错误预算则基于 SLO 计算并驱动运维行动。
4.5 错误预算的消耗与恢复机制
错误预算并非静态资源,它在时间窗口内动态消耗与恢复。常见的错误预算窗口包括:
- 滚动窗口(Sliding Window):例如过去 30 天内的错误预算,每天滚动更新。
- 固定窗口(Fixed Window):例如按自然月计算,每月重置。
错误预算的消耗速率取决于实际故障频率与持续时间。当错误预算剩余低于一定阈值(如 20%)时,团队应进入“可靠性警戒”状态。
错误预算策略示例:
# 错误预算消耗计算(伪代码)
slo = 0.999 # 99.9%
total_requests = 10_000_000
error_budget = (1 - slo) * total_requests # 10000
# 本月已发生失败请求数
failed_requests = 7500
remaining_budget = error_budget - failed_requests # 2500
# 剩余百分比
remaining_percent = (remaining_budget / error_budget) * 100 # 25%
if remaining_percent < 20:
print("进入可靠性警戒:暂停高风险发布")
else:
print("错误预算充足:可继续正常发布")
4.6 SLI 与 SLO 的典型组合模式
在实际服务画像中,一个服务通常定义多个 SLI,并为每个 SLI 设定独立的 SLO。下表展示了常见组合:
| 服务类型 | SLI | SLO | 错误预算(30天) |
|---|---|---|---|
| API 网关 | 请求成功率 | 99.95% | 0.05% 请求可失败 |
| 数据库 | 查询延迟 P99 | P99 < 100ms | 1% 查询可超时 |
| 消息队列 | 消息投递成功率 | 99.99% | 0.01% 消息可丢失 |
| CDN | 缓存命中率 | 95% | 5% 请求可回源 |
实践建议:初始阶段每个服务定义 2-3 个 SLI 即可,避免指标过多导致运维负担。优先覆盖“可用性”和“延迟”两个维度,后续再根据业务需要扩展。