错误预算把服务可靠性目标转换为发布与改进决策

服务等级目标（SLO）规定一个时间窗口内希望达到的可靠程度，错误预算则是允许未满足目标的空间。例如可用性目标为 99.9%，对应窗口内有 0.1% 的合格事件可以失败。预算的价值不在计算一个百分比，而在预先约定预算消耗后怎样调整发布和可靠性工作。

从有效 SLO 得到预算

预算必须建立在面向用户的服务等级指标上。请求成功率、延迟达标率、数据新鲜度或作业按时完成率，都可能成为指标。若指标只反映内部进程存活而不反映用户能否完成任务，预算再精确也无法指导体验。

统计窗口可以是滚动 28 天、自然月或其他业务周期。滚动窗口持续反映近期状态，日历窗口便于结算，但月初可能产生预算重置效应。窗口和目标应在政策中固定，仪表盘与告警使用相同口径。

请求量差异会影响解释。按事件比例计算时，高流量阶段允许的失败绝对数更多；按不可用时间计算又可能忽略部分用户失败。系统有多个用户旅程时，应为关键旅程分别设定目标，而不是把大量低价值请求稀释核心故障。

只看“本月还剩多少预算”可能太迟。燃烧率表示错误预算消耗速度相对于均匀使用速度的倍数。短窗口高燃烧率用于发现快速故障，长窗口中等燃烧率用于发现持续退化。多窗口告警可以兼顾响应速度和噪声。

单次事故消耗大量预算时，应触发复盘和高优先级改进。小故障长期重复也可能耗尽预算，需要按故障类别聚合。政策应说明哪些事件进入分母、维护窗口如何处理、测量缺失时怎样判断，避免事故发生后临时修改口径。

外部依赖造成的失败是否计入预算，要从用户体验和团队控制范围分别考虑。用户确实受到影响时不应从指标中隐藏，但政策可以规定责任协调和发布措施。完全豁免依赖故障，会让 SLO 与用户现实脱节。

错误预算政策应由产品、开发和可靠性责任方共同批准。服务处于预算内时，正常发布按既定门禁进行；预算耗尽时，可以暂停普通功能变更，仅允许安全修复、最高优先级故障修复和经过审批的风险降低变更。暂停不是惩罚，而是把资源转向恢复可靠性。

政策要定义恢复条件。仅等待滚动窗口自然移出故障而不修复原因，会让发布冻结失去意义。可以要求关键行动项完成、燃烧率恢复、重复故障受到控制，并由明确角色批准恢复发布。

不是所有变更都同等危险。配置修复、容量扩展和回滚可能降低风险，应该有快速审批路径。大规模迁移、数据模式变更和非必要发布则可延后。政策比“一刀切停发”更有用，因为它明确了风险分类和决策者。

错误预算依赖监控数据，采样遗漏、重复请求、机器人流量和遥测中断都会影响结果。指标管道本身要有完整性检查，并保存 SLO 定义和版本。修改查询后，应能解释历史曲线为何变化。

客户端重试可能把一次用户操作计为多次请求，也可能掩盖首次失败。应尽量选择接近用户结果的事件，并针对地区、客户端版本和关键客户分层。总体达标不代表每个群体都获得同等可靠性。

政策需要升级路径。产品和工程可能对故障归因、豁免或恢复时间有分歧，预先指定最终决策角色和证据要求，可以避免事故期间临时博弈。每次例外都应记录原因、期限和批准者。

SLO 过宽会允许用户体验在政策触发前已经不可接受；过严会让团队长期冻结且无法通过合理成本达到。应定期比较支持工单、用户流失、事故影响和预算状态，调整目标时保留原因和生效日期。

预算没有用完不代表必须主动制造故障，也不意味着可以跳过测试。它提供的是可承担风险上限，不是消费配额。相反，如果服务长期远高于目标且可靠性投入很高，可以评估是否降低成本或把目标调整到真正需要的水平。

错误预算应与容量规划、发布记录和事故行动项连接。仪表盘显示剩余预算，发布系统执行政策，复盘解释消耗，规划会议决定可靠性投资。只有形成闭环，预算才从一个指标变成工程决策机制。

一个用户旅程往往穿过多个服务。每个服务分别达到 99.9%，不代表组合旅程仍达到相同目标。关键路径上的串行依赖会叠加失败概率，共享依赖还会造成相关故障。团队应从端到端 SLI 出发，再用组件指标定位贡献，避免各组件仪表盘都显示绿色而用户旅程已经超出预算。

异步作业还要定义何时算失败：暂时排队、超过截止时间和最终丢失对用户影响不同，应使用适合任务的时限指标。

批处理服务可按承诺时间内完成的任务比例计算预算，并把主动取消与系统失败分开记录。

Google SRE：Example Error Budget Policy，https://sre.google/workbook/error-budget-policy/
Google：Site Reliability Engineering Books，https://sre.google/books/