SLO 错误预算烧完，到底该先冻功能还是先补稳定性？

背景

我们团队给核心交易链路定了 SLO：月度成功率 99.95%、P99 延迟 < 300ms。前两周一切正常，第三周开始错误预算肉眼可见地往下掉——到第 18 天已经烧掉 60%。按 Google SRE 那套「错误预算耗尽 → 冻结变更、转向可靠性」的剧本，我们该在月底前停止所有新功能上线。

但产品侧下周要上一个大促活动，运营排期已经对外承诺；业务方认为「SLO 是 SRE 自己的指标，业务目标才是 KPI」；开发同学也觉得「预算烧完 ≠ 系统会挂，为什么我的迭代要停」。三方在周会上吵了 40 分钟，最后谁也没说服谁，结果是：功能照上、SRE 加人盯盘、上线前多加了两道灰度。事后看，这套「和稀泥」方案其实风险最高——既没真做稳定性投入，也没真停业务，等于把不确定性叠加了。

几种常见做法

1. 硬冻结：预算耗尽即停，无论业务什么排期。优点是纪律清晰、信号强；缺点是容易和 OKR 打架，长期下去 SRE 会被边缘化成「刹车片」。
2. 软降级：预算耗尽只冻结「非关键路径」变更，关键路径照常上，但要求走加签、加灰度、加回滚预案。优点是现实；缺点是「关键 / 非关键」谁来判，往往变成扯皮。
3. 预算分级：把 SLO 拆成多档（如 99.95% 是红线、99.9% 是黄线），黄线烧完只警告、红线烧完才冻结。优点是把「真出事」和「有点抖」分开；缺点是阈值本身又变成新争议点。
4. 业务共担：让业务方在立项时签字确认「SLO 与业务目标二选一」，预算烧完时由业务方拍板选哪边。优点是把决策权还给真正承担后果的人；缺点是多数团队没这套流程，临时建成本很高。

我的倾向

我偏向做法 3 + 做法 4 的组合：SLO 一定要分档，且「红线烧完」的处置动作（冻结 / 降级 / 回滚）要在 SLO 制定时就和业务方书面约定，而不是烧完那天再开会。理由有两个：一是事后才讨论，情绪和立场都会干扰判断；二是分级能让「P99 抖到 320ms」和「成功率掉到 99.5%」这两种完全不同严重度的事件，触发不同强度的响应，避免一刀切的「全冻」或「全放」。

但我自己也没完全想清楚：「冻结功能」这个动作，对一线开发的心理成本是不是被低估了？ 我见过两个团队执行硬冻结后，开发私下绕路发版，反而更危险。所以「机制」和「人心」之间的平衡，是我真正卡住的地方。

想听大家说

• 你们团队真出过「预算烧完」的场面吗？当时是怎么处置的？
• 冻结功能这件事，是 SRE 单方面宣布，还是必须业务方点头？谁有最终否决权？
• 如果业务方坚持要上线，你会用什么「可量化」的条件去交换（比如：必须 5% 灰度 24h、必须有回滚预案、必须由 P8+ 加签）？
• 有没有人试过「SLO 分档 + 预算分池」这种更细的玩法？踩了什么坑？

欢迎带具体场景来聊，越具体越好，空对空的「要重视稳定性」就免了。