别再说 99.9% 了：错误预算怎么从 SLO 推导、怎么花、怎么和产品谈，一次完整演算

作者：沈望舒-936｜技术 PM 5 年｜习惯把原理拆成能算、能抄的步骤 关键词：SLO、错误预算（Error Budget）、burn rate、变更冻结

一、现象与背景：目标喊得越狠，团队越不诚实

先给一组我经手的真实数字。我们一条核心交易链路，对外承诺可用性「99.99%」。听起来很唬人，但换算成时间：一个月只有 4.38 分钟的故障额度，一年 52.6 分钟。

问题出在哪？团队为了「守住 99.99%」，每次发布都要走一轮人工灰度、人工盯盘、人工回滚演练，一次发布从 30 分钟被拖到 3 小时。一年下来，发布次数从早期的每周 4 次降到每周 1 次，交付速度掉了 75%，而可用性实际只到 99.97%——离目标还差着，却把最值钱的「迭代速度」烧光了。

更反直觉的是：我们事后复盘发现，全年 52 分钟的预算里，真正「花掉」的只有 6 分钟（一次机房抖动 + 一次发布回滚）。也就是说，我们花了 75% 的交付速度，去保护一个几乎没被用到的 4.38 分钟。目标定错，比目标没达成更贵。

这件事的本质是：「99.99%」是一个愿望，不是一个可以管理的东西。它能管理的前提，是把愿望换算成一笔「可以用、可以花、可以冻结」的预算——这就是错误预算。

二、原理与根因：SLO 到底是怎么变成一笔钱的

先讲清楚三个概念的关系，我用「工资」打比方：

• SLI（Service Level Indicator）：客观量出来的指标，比如「30 天里成功请求 / 总请求」。它是工资单上的数字。
• SLO（Service Level Objective）：对内定的目标，比如「30 天成功率 ≥ 99.9%」。它是约定的工资标准。
• 错误预算（Error Budget）：1 − SLO，即允许失败的额度。它是这个月你能花、能省的弹性空间。

推导就是纯算术。以 30 天窗口、SLO = 99.9% 为例：

总时长 = 30 × 24 × 60 = 43,200 分钟
错误预算 = 43,200 × (1 − 0.999) = 43,200 × 0.001 = 43.2 分钟

也就是说，30 天里允许累计不可用 43.2 分钟，超出就要触发「预算耗尽」流程。

再对比几个常见目标的「月度额度」，差距是指数级的，不是线性的：

| 目标 | 月度可用额度 | 年度额度 | 一句话感受 | |---|---|---|---| | 99.9% | 43.2 分钟 | 8.76 小时 | 够一次计划内维护 | | 99.95% | 21.6 分钟 | 4.38 小时 | 一次回滚就吃掉一半 | | 99.99% | 4.38 分钟 | 52.6 分钟 | 一次发布事故就可能击穿 | | 99.999% | 0.26 分钟（15.6 秒） | 5.26 分钟 | 几乎不允许任何故障 |

从 99.9% 提到 99.99%，月度额度从 43 分钟砍到 4 分钟，成本（架构冗余、发布流程、人力）却通常是翻倍的。这就是为什么「多一个 9」的边际成本极高——根因在于可靠性靠冗余（多副本、多机房、降级）堆出来，而冗余是乘法级投入。

三、具体做法：三步把预算变成可执行流程

第 1 步：用「多窗口」同时盯，别只看一个 30 天数

单一 30 天窗口太钝——它会把「今天正在烧穿」平均掉。建议同时维护三个窗口（这也是 Google SRE 的做法）：

• 30 天：定目标、算预算、做变更冻结决策（慢变量）。
• 7 天：周度复盘、排优先级（中变量）。
• 1 小时 / 24 小时：实时告警（快变量）。

第 2 步：定义什么是「bad request」，写进指标

用 Prometheus 举例，把 5xx 和超时算作 bad：

# 错误率（近 5 分钟）
sum(rate(http_requests_total{status=~"5..|status="timeout"}[5m]))
/
sum(rate(http_requests_total[5m]))

SLO = 1 − 上式的 30 天滚动值。注意分母要包含所有请求，否则成功率会被高估；「超时」是否算 bad 要和产品对齐口径（这是最容易扯皮的地方）。

第 3 步：把「预算消耗速率（burn rate）」做成两级告警

核心思想：你烧预算的速度，是它正常可用速度的几倍？

burn rate = (当前窗口错误率) / (SLO 允许的错误率)

给一套可直接抄的阈值（Google SRE 推荐值）：

• 快烧（fast burn）：14.4×，窗口 1 小时 → 触发 Paging（电话/IM 强提醒）。含义：按这个速度，30 天预算会在 1 天内烧光。
• 慢烧（slow burn）：6×，窗口 6 小时 → 触发 Ticket（工单，非即时）。含义：预算会在约 5 天内耗尽，需要排期修。

用上面 99.9% 的例子验证：正常错误率 0.1%，1 小时内若实际错误率 ≥ 0.1% × 14.4 = 1.44%，就 page。

第 4 步：预算耗尽 → 变更冻结（这是和产品谈的锚点）

把这条写进发布制度：

30 天错误预算剩余 < 50%  → 只允许 bugfix 类发布，新功能冻结
30 天错误预算剩余 < 20%  → 全部非紧急变更冻结，进 incident review
预算彻底耗尽（=0）       → 停发 48 小时，做根因复盘后再解禁

注意：冻结的是「变更」，不是「迭代」。 团队把省下来的精力投到稳定性（补监控、加降级、修慢查询），而不是「不敢动」。

四、踩过的坑与反直觉之处

1. 「可用性」和「用户成功率」不是一回事。 我们一度用「进程没挂」当 SLI，结果服务活着但 30% 请求超时，用户早跑了。SLI 要站在用户视角定义（请求成功 + 时延达标），否则预算是假账。

2. 预算耗尽 ≠ 该报警，快烧才该报警。 只看 30 天累计值，一个正在发生的严重故障会被「月初还健康」平均掉，等你看到 30 天数超标，事故已经结束了。快烧告警才是救命的那个。

3. 多一个 9 不是「更稳一点」，是「成本翻倍 + 交付腰斩」。 我们 99.99% 那次就是反例。正确做法不是「一刀切 99.99%」，而是分链路分级：核心交易链路 99.95%，内部工具 99% 就够。把预算花在刀刃上，而不是全链路拉满。

4. 别把 SLO 当 KPI 考核个人。 一旦预算和绩效挂钩，团队会开始「藏故障、压成功率」（把坏请求从分母里挪走）。SLO 是团队资源分配工具，不是考核尺子。

五、结论与可复用清单

一句话结论：把「99.99%」这种愿望，翻译成「30 天 43.2 分钟」这种可以花、可以冻、可以复盘的预算，目标才从口号变成管理对象。

可直接抄的清单：

• [ ] 为每条核心链路定一个 30 天 SLO，并写清 SLI 口径（成功 = 2xx 且 p99 ≤ Xms）。
• [ ] 用 1 − SLO 算出月度预算，换算成分钟数贴到团队看板。
• [ ] 配 14.4×/1h（page）+ 6×/6h（ticket） 两级 burn rate 告警。
• [ ] 写三条变更冻结阈值（<50% / <20% / =0）进发布制度。
• [ ] 分链路分级定 SLO，别全链路 99.99%。
• [ ] 把 SLO 当资源分配工具，不当个人 KPI。
• [ ] 每次预算耗尽，做一次 incident review，问「这 6 分钟花得值不值」。

参考：Google SRE Book 中 Service Levels 与 Alerting on SLOs 章节的 burn rate 方法；本文数字均为可复算的算术推导，非引用实测。