错误预算政策是什么
错误预算政策把预算状态与工程动作绑定：预算充足时正常发布，快速消耗时收紧变更并投入可靠性工作，告急时冻结高风险发布。它的作用是把“要不要暂停发布”从现场争论变成事先约定的规则。政策需要在风平浪静时评审通过，写入服务说明书，并明确谁有权触发、冻结范围多大、什么条件下解除，否则执行时会被质疑为临时加码。
基本信息
| 目标 | 让可靠性决策可预期、可执行 |
|---|---|
| 输入 | 燃烧率与预算余量 |
| 输出 | 发布策略调整与可靠性优先事项 |
| 决策人 | 服务负责人，必要时上升到技术管理层 |
| 覆盖范围 | 应用发布、配置变更、基础设施变更需一并定义 |
| 解除条件 | 必须写明，避免冻结无限期 |
典型使用场景
- 季度规划：把可靠性改进项与预算消耗来源对照，排进迭代
- 发布评审：发布前查看预算余量，决定批次大小与观察窗口
- 重大活动前：大促前收紧高风险变更，保留修复类通道
- 复盘改进：预算反复告急时，从架构与测试环节找系统性原因
- 跨团队协同：把政策作为共同规则，避免研发与运维各说各话
政策触发示例
| 预算状态 | 发布策略 | 配套动作 |
|---|---|---|
| 消耗小于 50% | 正常节奏，允许实验性发布 | 持续观察趋势与燃烧率 |
| 消耗 50% 到 80% | 限制高风险变更，发布需评审 | 排入可靠性任务并指定负责人 |
| 消耗大于 80% | 冻结高风险发布，仅修复类放行 | 集中修复并每日通报进展 |
| 预算耗尽 | 只允许修复与安全类变更 | 组织专项改进，明确解除条件 |
政策要素
政策要素
适用范围：哪些服务、哪些变更类型
触发阈值与判定频率（如每日计算燃烧率）
决策人与授权链：谁宣布冻结、谁可例外放行
冻结范围：应用发布 / 配置变更 / 基础设施变更
解除条件与回顾机制：何时恢复发布，由谁确认政策的价值在于事先约定：事后临时宣布冻结会引发资源争夺与合理性争论，执行成本远高于事前评审。