错误预算燃烧响应工作流

目标

错误预算的存在意义是仲裁速度与可靠性，前提是烧钱有后果。把燃烧速率告警与匹配的节流手段绑定，预算才从仪表盘装饰变成运行策略：变更快烧就收紧发布，容量慢烧就调整规划，窗口结束时的复盘修正 SLO 本身而不是永远和它缠斗。

步骤要点

1. 配置多窗口燃烧告警：快烧（一小时烧掉 2% 预算）立即打页，慢烧（三天烧掉 10%）开规划工单。
2. 燃烧触发后先归类来源：变更引入的回归、容量不足还是依赖故障，三类对应不同杠杆。
3. 施加匹配的节流：变更类开启发布门禁直到修复，容量类触发扩容，依赖类走依赖预案，不做一刀切冻结。
4. 透明汇报预算：向干系人公开余额与燃烧曲线，以及剩余预算花在什么可靠性工作上。
5. 窗口边界复盘：回顾燃烧来源与节流决策，慢性合法的燃烧要调整 SLO 或容量规划。

排错提示

预算烧光却没任何后果说明门禁没接线，把部署门禁真正挂到预算状态上；全面冻结拖慢了修复说明节流没分级，修复类变更应始终放行；每个窗口都耗尽而用户毫无怨言，是 SLO 定得比需求严，开紧急评审而不是硬执行。

适用边界

预算策略依赖 SLO 与监控的真实性，拍脑袋的 SLO 只会制造政策噪音；节流决策涉及产品节奏，需产品与技术共同签署政策。

代码示例

SLO: 99.9% availability  (budget 43.2 min / 30d)
alerts:
  fast burn: >2% budget in 1h    -> page
  slow burn: >10% budget in 3d    -> planning ticket

14:20Z fast burn page (14.1% err = 25x budget rate)
  source: v1.8.4 regression (deploy 14:02)
  throttle: deploy gate ON (risk-tiered)
    -> fixes proceed, risky changes queue
  fix + verify 15:31Z, gate OFF

window review: 3rd chronic capacity burn
  -> capacity plan +200ms headroom, not another freeze