2. 错误预算机制：定义、计算与运维决策

聊完 SLO 和 SLI，接下来这个机制才是真正让 SRE 团队「硬起来」的东西——错误预算。

说实话，我刚接触这个概念时，觉得它就是个数学游戏。直到有一次线上事故，业务方追着问「你们凭什么降级？」我拿出错误预算一看，嗯，预算已经烧光了，降级是合规操作。那一刻我才真正理解：错误预算不是束缚，是保护伞。

2.1 错误预算到底是个啥？

简单粗暴地讲：错误预算 = 1 - SLO。

你定了一个 99.9% 的 SLO，意味着服务在统计窗口内最多只能有 0.1% 的时间或请求出问题。这 0.1% 就是你的「犯错额度」。用完了，就得老实点，别再搞风险操作了。

举个例子：

• SLO = 99.9%，窗口 = 30 天
• 30 天总请求数 = 10,000,000
• 允许的错误请求数 = 10,000,000 × (1 - 0.999) = 10,000 次
• 如果这 30 天已经发生了 6,000 次错误，剩余预算 = 4,000 次

你看，这就是个「额度管理」游戏。跟信用卡额度一样，刷爆了就得还，还不上就得接受惩罚。

2.2 错误预算的计算方式

计算本身不复杂，但有几个细节容易踩坑。我一个个说。

2.2.1 基于请求量的计算（最常见）

适用于 HTTP API、RPC 调用这类场景。

# 伪代码示例
total_requests = 10_000_000
slo = 0.999
error_budget_total = total_requests * (1 - slo)  # 10,000

# 实时消耗
errors_so_far = count_errors_in_window()  # 6,000
remaining_budget = error_budget_total - errors_so_far  # 4,000

# 预算消耗率
burn_rate = errors_so_far / error_budget_total  # 60%

2.2.2 基于时间的计算

适用于数据库、消息队列这类「持续运行」的服务。比如 SLO 定义的是「99.9% 的时间可用」，那 30 天里最多只能宕机 43.2 分钟。

SLO	30 天允许宕机时间	7 天允许宕机时间	1 天允许宕机时间
99.9%	43.2 分钟	10.08 分钟	1.44 分钟
99.99%	4.32 分钟	1.01 分钟	8.64 秒
99.999%	25.9 秒	6.05 秒	0.86 秒

看到没？99.999% 的 SLO，一天只能宕不到 1 秒。这种服务你敢随便上线？

2.2.3 滑动窗口与重置

这里有个关键点：错误预算不是月底清零的。

我见过不少团队用「自然月」做窗口，结果月底最后一天疯狂上线，月初第一天又小心翼翼。这完全违背了错误预算的初衷。

正确的做法是滑动窗口。比如 30 天滑动窗口，每天往前滚一天。这样预算的消耗是连续的，不会出现「月初满血复活」的错觉。

2.3 错误预算在运维决策中的应用

这才是重头戏。错误预算不是算出来好看的，是用来做决策的。

2.3.1 上线门禁

最直接的应用：预算不足，禁止上线。

我在上一家公司定过一个规则：

• 剩余预算 > 50%：正常上线流程
• 剩余预算 20% ~ 50%：需要技术经理审批
• 剩余预算 < 20%：冻结所有非紧急变更
• 剩余预算 < 10%：进入「红色警戒」，全员聚焦稳定性

刚开始业务方很不爽，觉得我们「拿数字卡脖子」。后来有一次预算只剩 15%，我们硬是拦了一个有风险的大版本。结果第二天友商出了类似事故，宕机 2 小时。从那以后，业务方再也没质疑过这个机制。

2.3.2 事故定级与复盘

错误预算还能帮你客观地判断事故严重程度。

举个例子：

• 一次事故消耗了 5% 的预算，但总预算还剩 80% → 影响不大，正常复盘
• 一次事故消耗了 30% 的预算，总预算只剩 10% → 严重事故，需要全组复盘

我曾经用这个逻辑说服老板：别只看事故时长，要看预算消耗率。一个 5 分钟的事故，如果发生在预算快见底的时候，比发生在月初的 30 分钟事故更危险。

2.3.3 容量规划与架构升级

预算消耗的速度也能反映系统健康度。如果预算每天都在快速消耗，说明系统本身有问题，不是靠「少上线」能解决的。

我一般会设两个阈值：

指标	阈值	行动
日均预算消耗率	> 5%	排查慢路径、优化代码
峰值预算消耗率	> 20%/小时	立即扩容、限流

2.4 错误预算的常见误区

说几个我亲眼见过的翻车案例。

1. 预算永远用不完：说明 SLO 定得太松，团队没有改进动力。建议收紧 SLO。
2. 预算总是不够用：要么 SLO 定得太严，要么系统确实不稳定。先排查系统，再考虑放宽 SLO。
3. 把错误预算当 KPI：有人为了「省预算」，故意少报故障。这是自欺欺人。错误预算应该是决策工具，不是考核指标。
4. 窗口设置不合理：用自然月、自然周，导致预算「周期性重置」。一定要用滑动窗口。

2.5 错误预算的核心逻辑图

下面这张图是我自己总结的，每次给团队培训都会拿出来讲。它把错误预算的整个生命周期串起来了。

这张图的核心逻辑很简单：定 SLO → 算预算 → 盯消耗 → 做决策。每一步都环环相扣，缺一不可。

2.6 落地建议

最后给几个实操建议，都是我踩过坑之后总结的：

• 先跑通一个服务：别一上来全量推广。选一个核心服务跑一个月，验证流程。
• 自动化告警：预算消耗到 50%、30%、10% 时自动告警，别等人肉盯。
• 跟业务方对齐：错误预算不是 SRE 团队的自嗨工具。要让业务方理解「预算用完了就不能上线」这个逻辑。
• 定期复盘：每周花 15 分钟看预算消耗趋势，提前发现问题。

嗯，错误预算这部分就讲到这里。记住一句话：错误预算不是限制你，是保护你。有了它，你拒绝不合理需求时，腰杆子能硬三分。