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

在基于 Error Budget 的灰度发布准入体系中,SLI(Service Level Indicator,服务等级指标)和SLO(Service Level Objective,服务等级目标)是构建所有容量决策的基石。没有精确的 SLI 和合理的 SLO,Error Budget 就失去了数学锚点,灰度发布准入也将沦为凭感觉拍板的操作。

2.1 定义服务等级指标(SLI)

SLI 是对服务某个特定维度的直接测量值,通常表示为一段时间内的好事件计数 / 总事件计数。SLI 必须可量化、可采集、与用户体验强相关。

核心原则:SLI 不是监控指标的全集,而是用户能感知到的“好”与“坏”的边界。例如,99% 的请求在 200ms 内完成,比“平均延迟 150ms”更能反映真实体验。

2.1.1 常见的 SLI 类型

SLI 类型 定义公式 典型阈值(好事件) 适用场景
可用性 成功请求数 / 总请求数 HTTP 状态码 < 500 API 网关、负载均衡
延迟 快速请求数 / 总请求数 P99 < 200ms 数据库查询、RPC 调用
吞吐量 已处理请求数 / 时间窗口 不低于基线 90% 批处理、消息队列
错误率 5xx 错误数 / 总请求数 < 0.1% 核心交易链路
饱和度 资源使用量 / 容量上限 CPU < 80% 容量规划、弹性伸缩
灰度发布准入中的 SLI 选择:建议至少选择延迟(P99)和错误率(5xx)两个维度。因为新版本代码最容易引入性能退化(延迟升高)或逻辑缺陷(错误率飙升),这两个 SLI 能最快反映容量是否被击穿。

2.2 定义服务等级目标(SLO)

SLO 是为 SLI 设定的目标边界值,是服务所有者对用户做出的承诺。SLO 必须比 SLI 的测量值更严格,且通常以“时间窗口内的达标率”来表述。

2.2.1 SLO 的数学表达

一个典型的 SLO 表述为:
“在 30 天滚动窗口内,99.9% 的请求延迟低于 200ms。”

其中:

  • SLI = 延迟低于 200ms 的请求比例
  • SLO = 99.9%(目标值)
  • 时间窗口 = 30 天(滚动计算)

2.2.2 SLO 分级策略

SLO 等级 目标值 允许停机时间/月 典型服务
核心(Tier 1) 99.99% 4.32 分钟 支付、登录、商品详情
重要(Tier 2) 99.9% 43.2 分钟 搜索、推荐、评论
普通(Tier 3) 99% 7.2 小时 历史订单、用户画像
避坑指南:不要为所有服务设置统一的 99.99% SLO。过高的 SLO 会导致 Error Budget 极低,灰度发布时任何微小波动都会触发准入拒绝,反而阻碍正常迭代。SLO 应基于业务重要性和成本权衡。

2.3 SLO 与 Error Budget 的数学关系

Error Budget 是 SLO 的“允许犯错空间”,其数学关系极为简洁:

Error Budget = 1 - SLO

例如:
SLO = 99.9%  →  Error Budget = 0.1%
SLO = 99.99% →  Error Budget = 0.01%

在时间窗口内,Error Budget 可以换算为具体的可容忍失败次数:

可容忍失败次数 = 总请求数 × (1 - SLO)

示例(30 天窗口,日均 1000 万请求):
总请求数 = 1000万 × 30 = 3亿
SLO = 99.9%
可容忍失败次数 = 3亿 × 0.1% = 30万次

这意味着在 30 天内,该服务最多允许 30 万次失败(延迟超标或错误响应)。一旦消耗完,Error Budget 归零,灰度发布准入将被暂停,直到下一个窗口重置。

容量规划视角:Error Budget 不仅是“故障预算”,更是容量冗余的量化指标。当 Error Budget 充足时,说明系统有足够的容量余量来承受新版本带来的短暂波动;当 Error Budget 耗尽时,系统已处于容量临界状态,任何变更都可能引发雪崩。
SLO 与 Error Budget 数学关系及灰度准入决策流程 SLO 与 Error Budget 数学关系及灰度准入决策流程 SLO 目标值 例:99.9% Error Budget = 1 - SLO = 0.1% 实际消耗 失败次数 / 总请求 剩余 Budget = 允许 - 已消耗 剩余 > 0? ✅ 允许灰度发布 容量冗余充足 ❌ 暂停灰度发布 容量已达临界 灰度发布准入的核心逻辑:Error Budget 剩余量直接决定是否允许新版本进入生产环境

2.4 时间窗口与滚动计算

Error Budget 的计算必须基于滚动时间窗口,而非固定日历月。常见的窗口配置:

  • 7 天滚动窗口:适合快速迭代的服务,Error Budget 重置快,灰度发布节奏更灵活。
  • 30 天滚动窗口:行业标准,平衡了稳定性与迭代速度,适合大多数核心服务。
  • 90 天滚动窗口:适合低频变更的基础设施组件,如 DNS、负载均衡。
容量规划建议:在灰度发布准入场景中,建议使用7 天滚动窗口作为“快速检测”指标,配合30 天滚动窗口作为“长期健康”指标。当 7 天 Error Budget 耗尽时立即暂停灰度;当 30 天 Error Budget 低于 50% 时触发容量预警。

2.5 多 SLO 组合与准入策略

一个服务通常有多个 SLO(延迟、错误率、吞吐量)。灰度发布准入需要综合判断:

SLO 维度 权重 准入条件(示例)
延迟 P99 SLO 40% 剩余 Budget > 30%
错误率 SLO 40% 剩余 Budget > 50%
吞吐量 SLO 20% 剩余 Budget > 20%

准入决策公式:

准入分数 = Σ(各维度剩余Budget比例 × 权重)
准入条件:准入分数 > 0.4(阈值可调)

这种加权方式避免了单一维度耗尽就阻塞所有变更,同时确保关键维度(延迟、错误率)有更高的发言权。

多 SLO 组合灰度发布准入决策架构 多 SLO 组合灰度发布准入决策架构 延迟 P99 SLO 剩余 Budget: 40% 权重: 40% 错误率 SLO 剩余 Budget: 60% 权重: 40% 吞吐量 SLO 剩余 Budget: 80% 权重: 20% 加权准入分数 = 40%×0.4 + 60%×0.4 + 80%×0.2 ✅ 准入分数 = 0.56 > 0.4 允许灰度发布

2.6 关键总结

  • SLI 是测量值,SLO 是目标值,Error Budget 是允许的偏差空间。
  • Error Budget 的数学本质是 1 - SLO,在滚动窗口内按请求量换算为可容忍失败次数。
  • 灰度发布准入的核心判断依据是 Error Budget 剩余量:剩余充足则允许发布,耗尽则暂停。
  • 多 SLO 场景下使用加权准入分数,避免单一维度过度约束变更流程。
  • 时间窗口的选择直接影响灰度发布的节奏:窗口越短,对容量波动的容忍度越低,变更越保守。
下一步实践:在开始灰度发布准入配置前,请先为你的核心服务完成 SLI 定义和 SLO 设定。建议从“延迟 P99”和“错误率”两个维度起步,设置 30 天滚动窗口的 99.9% SLO,然后观察一周内的 Error Budget 消耗模式。