背景
做了 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 的信用」来兜底这个死结。
想听大家在什么场景下怎么选
具体想请教几类场景，欢迎分享真实案例（脱敏即可）：
- 你们团队的错误预算是「软约束」还是「硬约束」？卡在哪个环节（CI / 发布平台 / 审批流）？卡多久了，有没有被绕开过？
- 预算阈值怎么定？我看过的有 50% / 30% / 20% 的，你们是怎么算出那个数字的？有没有基于历史故障反推过？
- 解冻权归谁？SRE？架构师？业务负责人？你们怎么处理「SRE 自己也判断错了」的情况？
- 多服务 / 多业务线共享错误预算时怎么切？比如一个公共网关服务同时服务 10 条业务线，预算烧超了，是冻结所有业务线，还是只冻结「贡献最多错误」的那条？
- 有没有人试过把错误预算和容量规划 / 压测 / 混沌演练联动？我个人的直觉是这三件事应该共享同一套「稳定性账本」，但没看到成熟实践。
抛砖引玉，想听大家真实踩过的坑和踩完之后怎么改的。
0赞
0收藏
0楼层