SLO 与错误预算：把服务稳不稳定变成可以算的数

为什么“99.9% 可用性”没人当回事

“我们的 SLA 是 99.9%。”这句话写在合同里，却几乎没人盯着它看。原因很简单：99.9% 是月度目标，等月底一算发现没达标，事故已经过去二十天了，追责没有意义，改进更无从谈起。

SLO 换了个思路：把可用性拆成能实时观察的指标，让团队每天、每小时都知道自己离红线还有多远。它不是给老板看的报表，是给值班人用的仪表盘。

SLI、SLO、错误预算：先分清三个词

• SLI（Service Level Indicator）：服务质量的度量值，比如“5 分钟内 P99 延迟小于 300ms 的请求占比”。它必须能算出来，不能是形容词。
• SLO（Service Level Objective）：SLI 的目标值，比如“该占比一个月内不低于 99.5%”。SLO 一旦定下来，团队就有了一条明确的底线。
• 错误预算（Error Budget）：100% 减去 SLO 剩下的那部分，比如 0.5%。它代表“这个月允许出错的额度”。预算没花完，可以放心发版、做实验；预算见底，就冻结变更、全力修稳定性。

把这三个词串起来，可靠性就从口号变成了可以记账的东西。

在 OBSERVE 里定义一个 SLO

在 OBSERVE 里创建 SLO 不用手搓 PromQL，选定指标、窗口和目标即可。下面是一个基于请求延迟定义的 SLO 配置示例：

slo:
  name: checkout-api-availability
  sli:
    source: prometheus
    query: >
      sum(rate(http_request_duration_seconds_bucket{le='0.3',service='checkout'}[5m]))
      /
      sum(rate(http_request_duration_seconds_count{service='checkout'}[5m]))
  objective: 99.5
  window: 30d
  budget:
    fastBurnThreshold: 14.4   # 1 小时耗尽月预算
    slowBurnThreshold: 3.0    # 6 小时耗尽月预算
  labels:
    team: checkout
    severity: page

定义好之后，OBSERVE 会自动计算当前窗口的 SLI 达标率、剩余错误预算，并在仪表盘上画出预算消耗曲线。值班人一眼就能看出“这个月还剩多少犯错额度”。

燃烧率告警：别等预算耗尽才报警

只看剩余预算有个问题：预算是月底才见底的，中途消耗速度过快的信号容易被忽略。OBSERVE 用燃烧率（burn rate）解决这个问题——燃烧率等于实际消耗速度除以允许的平均消耗速度。

比如一个月预算 0.5%，平均每天只能消耗约 0.017%。如果某天消耗了 0.17%，燃烧率就是 10 倍。燃烧率告警分两档：

• 快速燃烧（fast burn）：预算将在 1 小时内耗尽，触发 P1 告警，直接呼叫值班人。
• 慢速燃烧（slow burn）：预算将在 6 小时内耗尽，触发工单，安排白天处理。

这样，故障刚发生几分钟内就能触发告警，而不是等月底报表。

落地建议

给刚开始做 SLO 的团队三条建议：

1. 先做一两个，别贪多。挑最核心的两三个服务，把 SLO 跑顺了再铺开。
2. SLO 要跟业务对齐。用户无感的指标做得再漂亮也没用，优先选直接影响体验的 SLI。
3. 把错误预算用起来。预算没花完时，允许团队主动发版、做灰度实验，这才是 SLO 的价值——它给的是“可以失败”的空间，而不是一张追责清单。