SLO 错误预算烧穿后，该不该自动冻结发布？「人工 override」的代价你们怎么定？

【背景】 做了 10 年运维，去年带一个 20 人团队给核心交易链路上了 SLO 错误预算（error budget）机制，跑了 5 个月，踩的坑比写代码还多。先给几个具体数字：

• 服务 P99 < 300ms，月度 SLO 99.9%，折算下来每月预算 = 30 天 × 24h × 60min × 0.1% ≈ 43 分钟；
• 上线头一个月预算就烧穿 3 次，触发「自动冻结发布」，业务方直接来找我拍桌子，因为当时正在赶一个支付 bugfix 的上线窗口；
• 复盘那 3 次烧穿，2 次根因是同一个连接池配置 bug，1 次是下游限流参数改错——也就是说，冻结发布期间「最需要发的那个 fix」被自己的机制卡住了。

这件事让我开始认真想：错误预算到底是「质量闸门」还是「管理工具」？这两者的实现方式完全不一样。

【常见的三种做法】 A. 硬闸门：预算耗尽 → 自动冻结所有发布（含 hotfix），直到 SLO 回到预算内才能解冻。逻辑是「质量不达标就没有发布资格」。 B. 分级闸门：预算耗尽 → 冻结新功能发布，但 hotfix / bugfix 走例外流程（人工审批 + 风险评估 + 事后复盘）。 C. 软指标：预算只当看板看，烧穿只在周报里标红，发不发最终由人拍板。

我见过 A 和 C 各跑过一段时间，B 是现在大多数团队实际在用的（虽然嘴上说是 A）。

【我的倾向：B，但要给 override 定一个「足够疼」的代价】 理由有三：

1. 烧穿预算时往往恰恰是最需要发 fix 的时候——预算在漏，bug 还在，冻结发布等于让预算继续漏。我们那 3 次烧穿里，2 次的 fix 本来就能把预算补回来；
2. 纯 A 方案在组织上跑不长时间：业务方一旦绕过（找别的渠道直接发、线下改配置），机制就死了。机制的存活靠的是「大多数时候自动执行 + 少数时候高代价人工例外」；
3. override 的代价设计是关键。我们的做法：override 人必须手写一份风险评估（影响面、回滚方案、预计烧穿速率），这份文档直接进下次事故复盘的必读材料，且 override 次数计入团队季度质量分。代价不是「不让过」，而是「过了也要留痕、要付认知成本」。

【想听大家】

1. 你们线上是 A / B / C 哪种？如果 C，预算烧穿后实际发生了什么？
2. 预算粒度怎么切：单服务、业务线、还是整个团队共享一个池？小团队（<10 人）值得上这套吗，还是直接靠 oncall 经验就够？
3. 业务方和 SRE 对「99.9% 是不是够了」有分歧时（业务要 99.99%，SRE 说成本高 10 倍），你们怎么谈？有没有真实拍板案例？
4. 预算烧穿冻结发布时，hotfix 的例外审批一般谁来批——SRE 负责人、业务负责人、还是双方共同？

欢迎贴你们的具体数字（SLO 目标、预算窗口、烧穿次数、override 次数），空对空的「我们也在用 SLO」我就不展开了。