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 定得太松可收紧目标提体验注意预算不是惩罚工具而是风险额度。用完了不是研发挨骂而是双方坐下来决定这个月要不要为稳定性踩刹车。这是把对抗变成协作的关键。六、常见坑坑 1把错误预算当 KPI 扣钱→ 团队开始隐瞒故障、粉饰 SLI预算机制彻底失效。坑 2只算还剩多少不看燃烧速率→ 慢火烧了三天才发现预算早空了。坑 3预算耗尽后没人有权冻结发布→ 机制没牙齿等于摆设。坑 4SLO 定太低预算永远用不完→ 失去约束意义沦为形式主义。七、小结与思考题错误预算 1 − SLO是把稳定性变成可协商余额的机制。燃烧速率比剩余多少更能预警快燃 14.4×、慢燃 6× 是业界经验值。预算是契约不是惩罚用完了由机制而非职级决定暂停发版。思考题你们团队现在能不能发版由谁决定如果引入错误预算耗尽即冻结发布这条规则你们的组织里谁有权按下那个暂停键这个权力现在在不在该在的人手里下一篇我们用真实电商案例把定 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 定得太松可收紧目标提体验注意预算不是惩罚工具而是风险额度。用完了不是研发挨骂而是双方坐下来决定这个月要不要为稳定性踩刹车。这是把对抗变成协作的关键。六、常见坑坑 1把错误预算当 KPI 扣钱→ 团队开始隐瞒故障、粉饰 SLI预算机制彻底失效。坑 2只算还剩多少不看燃烧速率→ 慢火烧了三天才发现预算早空了。坑 3预算耗尽后没人有权冻结发布→ 机制没牙齿等于摆设。坑 4SLO 定太低预算永远用不完→ 失去约束意义沦为形式主义。七、小结与思考题错误预算 1 − SLO是把稳定性变成可协商余额的机制。燃烧速率比剩余多少更能预警快燃 14.4×、慢燃 6× 是业界经验值。预算是契约不是惩罚用完了由机制而非职级决定暂停发版。思考题你们团队现在能不能发版由谁决定如果引入错误预算耗尽即冻结发布这条规则你们的组织里谁有权按下那个暂停键这个权力现在在不在该在的人手里下一篇我们用真实电商案例把定 SLO 时还要考虑哪些因素讲透。
