SRE 实战手册（四）｜错误预算：把 SLO 变成“共识机制“-平芜编程栈

SRE 实战手册（四）｜错误预算：把 SLO 变成"共识机制"

对应课程「04｜错误预算：达成稳定性目标的共识机制」。这是 SRE 最巧妙的设计，没有之一。

一、为什么需要"错误预算"这个东西？

第 03 讲我们定了 SLO：结账成功率 ≥ 99.9%。数字有了，但马上冒出一个组织问题：

研发说"我这周要发三个大版本"；SRE 说"你这周已经快把稳定性搞挂了，别发了"。
—— 谁说了算？凭什么？

传统做法靠"拍脑袋"或"职级压人"，结果是研发和 SRE 长期对立。错误预算（Error Budget）的精妙之处在于：把"稳定性"翻译成一个双方都认同的、会动态变化的"余额"，让机制而不是人去裁决。

二、错误预算到底是什么

一句话：错误预算 = 1 − SLO 目标。它就是"我们被允许犯错的额度"。

我们 SLO 是 99.9%，所以：

错误预算率 = 1 − 0.999 = 0.001 （即允许 0.1% 的失败）

换算成"绝对次数"更容易理解。假设一个月结账 1 千万次：

允许的错误次数 = 0.001 × 10,000,000 = 10,000 次/月

这 10,000 次，就是本月"随便花"的额度。花完了，就得收紧；没花完，就可以放开手脚发版。

三、用代码算清楚预算状态

仓库里的deploy/error_budget.py提供了纯数学模式，直接看一眼余额：

python3 error_budget.py math--total1000000--errors600--slo0.999

输出（节选）：

{ "error_rate": 0.0006, # 实际错误率 0.06% "burn_rate": 0.6, # 燃烧速率 0.6×（<1，安全） "allowed_errors": 1000.0, # 本月允许 1000 次 "budget_consumed": 600, # 已花 600 次 "budget_remaining_pct": 0.4 # 还剩 40% }

解读：当前错误率 0.06%，燃烧速率 0.6×，预算还剩 40%——状态健康，研发这个月可以正常发版。

顺带一提，这个error_budget.py最初一版是用 AI 编程工具 AtomCode 以无头模式（headless）自动生成的，我再做了生产化打磨。这正是"SRE + AI 编程"的现实工作流：让 AI 出初稿，人来把关工程正确性。

四、燃烧速率（Burn Rate）：比"还剩多少"更重要

光看"还剩 40%"会漏掉一个致命信号：钱是不是正在被一把火烧掉？

燃烧速率定义：

燃烧速率 = 当前错误率 / 错误预算率

燃烧速率 = 1×：按当前速度，刚好一个月烧完全部预算（正常）。
燃烧速率 = 14.4×：1 小时烧掉 2% 的月度预算（快燃）→ 必须立刻 Page。
燃烧速率 = 6×：6 小时烧掉 5% 的月度预算（慢燃）→ 需工单跟进。

（14.4 = 2% ÷ (1h/720h)；6 = 5% ÷ (6h/720h)，来自 Google SRE Workbook 的多窗口燃烧速率法。）

deploy/slo_rules.yml里这两条告警就是这么来的（生产用 Prometheus；本实验由等价的sre_monitor.py实现同样的 14.4×/6× 判定并向 On-Call 台发 webhook）：

-alert:CheckoutBudgetBurnFastexpr:job:checkout_errors:rate1h>(14.4 * 0.001)# 1h 错误率超 1.44%for:2mlabels:{severity:critical}-alert:CheckoutBudgetBurnSlowexpr:job:checkout_errors:rate6h>(6 * 0.001)# 6h 错误率超 0.6%for:10mlabels:{severity:warning}

五、错误预算真正解决的问题：发布闸门

这才是它作为"共识机制"的落点。课程强调：错误预算是研发和 SRE 之间的"契约"，规则要提前写死：

预算状态	动作
剩余 > 0 且燃烧速率正常	正常发版，鼓励快速迭代
预算告急（如 < 10%）	冻结非必要发布，集中力量稳定性
预算已耗尽	只发修复稳定性的变更，暂停业务需求发布
预算长期用不完	说明 SLO 定得太松，可收紧目标提体验

注意：预算不是"惩罚工具"，而是"风险额度"。用完了不是研发挨骂，而是双方坐下来决定"这个月要不要为稳定性踩刹车"。这是把对抗变成协作的关键。