背景
做了 3 年 SRE，接手过两套业务，SLO 都定过：订单服务 99.95%、支付链路 99.99%、对账批处理 99.5%。看着挺完整，但真到月底复盘，错误预算（Error Budget）基本没人用——它只是季度 OKR 里的一行字，发布节奏、加功能、上灰度，全凭 PM 和研发自己拍。
去年一次真实翻车：支付网关一次小变更把 P99 从 220ms 推到 680ms，错误预算当月已经烧掉 70%，但没有任何机制拦住后续 3 次发布。直到第 4 次变更引发熔断级联，才临时拉会。复盘会上大家共识是「错误预算应该硬卡发布」，但散会之后没落地，因为「卡谁？谁授权？谁背锅？」没人说清。
所以想抛个开放问题：SLO 错误预算到底是「管理指标」还是「工程约束」？团队里到底怎么把它用起来，才算真的在用？
常见分歧 / 几种做法
我观察到的大致 4 种流派：
- 挂墙派：SLO 写进文档，错误预算算出来贴墙，但发布流程完全不看。优点是没人被「卡」，缺点是它等于不存在。
- 月度 KPI 派：错误预算烧超 → 季度绩效扣一档。问题是：绩效周期太长，且把 SRE / 研发 / 产品绑在一起算分，反而让谁都不敢主动暴露问题。
- 发布门禁派：错误预算低于阈值（比如剩 50%）→ 自动冻结非 P0 发布。听起来很「工程化」，但落地就卡在：谁有权解冻？解冻后是否留痕？研发会不会绕？
- 动态预算派：把预算拆到周 / 拆到服务，预算烧得越快，允许的变更类型越保守（比如只允许配置变更、不允许代码发布）。最贴近 SRE 直觉，但需要一套完整的变更分级 + 审批流，工程成本不低。
我的倾向与理由
我倾向 流派 3 的硬卡 + 流派 4 的分级 组合，理由有三：
- SLO 的意义在于「用稳定性换速度」。如果错误预算不影响发布节奏，它只是仪表盘上的一个数字，工程师没有理由对它负责。
- 卡发布不是目的，是让「稳定性风险显性化」的目的。硬卡会逼着大家去想：这次变更值不值得烧预算？烧多少？烧超了谁去兜？这些问题平时没人问，一卡就问出来了。
- 分级比一刀切更现实。全部冻结会让业务崩溃，按变更类型分级（配置 < 灰度 < 全量）至少保留了业务弹性，也给 SRE 留了「我判断这次可以放」的裁量空间——裁量空间 + 留痕，比纯自动规则更适合中小团队。
但我也很清楚这个倾向的软肋：「谁有权解冻」和「解冻后出事故谁背」是死结。我目前的解法是让发布门禁的阈值和审批人写进变更平台的配置里，SRE 团队持有解冻权，但每次解冻都留审计日志，季度复盘时把「解冻次数 × 后续故障数」作为 SRE 自己的 KPI 反向约束——用「SRE 的信用」来兜底这个死结。
落地后的第一个月：我们踩了三个坑
上面是「设计时」的倾向，下面是「落地后第一个月」的真实翻车记录，补上这些才完整：
坑 1：阈值 50% 一刀切 → 误杀了 3 次合法发布
第一版门禁：预算剩余 < 50% 就冻结所有非 P0 发布。结果第一周就误杀了 3 次——其中 2 次是「预算烧掉 51% 但全是已知的低频超时（P99.9 抖动），当前 P99 其实很健康」的场景。修复：把单一阈值改成双指标门禁——预算剩余 < 50% AND 当前 P99 偏离 SLO 目标 > 20% 才冻结。单看预算会误杀「烧得慢但没在恶化」的场景，单看 P99 会漏掉「烧得快但还没爆」的场景，两个条件 AND 才合理。
坑 2：解冻审批流没有 SLA → 研发绕过 第一版：解冻需要 SRE 架构师审批，但没有「审批 SLA」——我们架构师当时在休假，研发等了 4 小时没审批通过，直接走了一条「临时豁免」的旁路（变更平台里本来就有，用于紧急发布）。结果那次旁路发布后来引发了一次 P2 故障。修复：给解冻审批加了 2h SLA（超时自动升级到我 + 1），同时把「临时豁免」的旁路入口从「自助」改成「需要 SRE 值班审批」——不是封死，是加一道闸。
坑 3：多服务共享预算时「谁贡献最多错误」的归因算不清
一个公共网关服务同时服务 10 条业务线，预算烧超了，按「贡献最多错误」冻结对应业务线——但 10 条业务线共享同一个网关，错误归因到具体业务线需要 service_name + endpoint 维度的错误率拆分，我们当时的监控只有 service_name 维度，拆不出来。结果只能冻结全部 10 条业务线，引发了一次业务投诉。修复：先在网关 access log 里加了 business_line 字段（上游服务通过 header 透传），两周后有了归因数据，才能做「只冻结贡献最多错误的业务线」的精细化门禁。
想听大家在什么场景下怎么选
具体想请教几类场景，欢迎分享真实案例（脱敏即可）：
- 你们团队的错误预算是「软约束」还是「硬约束」？卡在哪个环节（CI / 发布平台 / 审批流）？卡多久了，有没有被绕开过？
- 预算阈值怎么定？我看过的有 50% / 30% / 20% 的，你们是怎么算出那个数字的？有没有基于历史故障反推过？
- 解冻权归谁？SRE？架构师？业务负责人？你们怎么处理「SRE 自己也判断错了」的情况？
- 多服务 / 多业务线共享错误预算时怎么切？比如一个公共网关服务同时服务 10 条业务线，预算烧超了，是冻结所有业务线，还是只冻结「贡献最多错误」的那条？
- 有没有人试过把错误预算和容量规划 / 压测 / 混沌演练联动？我个人的直觉是这三件事应该共享同一套「稳定性账本」，但没看到成熟实践。
抛砖引玉，想听大家真实踩过的坑和踩完之后怎么改的。