详细解释
错误预算（Error Budget，简称 EB）是 SRE（站点可靠性工程）方法论中的核心工具，用于量化解决「业务要快（频繁发布）」和「工程要稳（不要宕机）」两大团队的永恒冲突。其数学定义极其简单：错误预算 = 1 − SLO，即「如果你的服务等级目标 SLO 是月度可用性 99.9%，那么一个月（720 小时）内，你允许自己失败或不可用的最大时间配额就是 720 × (1 − 99.9%) = 0.72 小时 = 43.2 分钟」——超过这个数字，本月 SLO 就失败了，客户可按 SLA 条款申请赔付。
错误预算的核心价值不在「算数字」，而在于「它是全公司统一的决策货币」：① 有错误预算结余时，研发团队可以放心发布新功能、做灰度、做架构重构、上线新模型版本；② 错误预算消耗到 60% 至 80% 时，触发「黄灯期」，发布必须经过额外稳定性评审；③ 错误预算耗尽时，触发「红灯期」，冻结所有非紧急发布，全团队转入稳定性修复模式，直到错误预算在下一周期重新恢复。这样做的好处是：产品和研发不用再和 SRE 反复拍脑袋争吵「能不能上线」，一切由预算数字说了算。
对大模型 API 场景而言，错误预算的定义通常不止于「可用性」，而是同时绑定「可用性 + P95 延迟 + P99 延迟 + 幻觉率/拒答率」四项指标合成综合错误预算，任何一项穿底都会消耗对应权重的预算。唯元智创 的企业级客户控制台每月会展示 4 项独立错误预算与综合错误预算的实时消耗曲线，并在剩余 30%/10%/耗尽三档自动触发工单与邮件告警。若某模型版本的错误预算在月中就已经耗尽，平台会自动降权，不再推荐路由分发该版本给新客户，直到错误预算由下一周期重置或版本修复。
错误预算四大核心指标与 SLO 建议阈值表（LLM API 场景）
| 指标名称 | SLO 目标（月度，企业级推荐） | 对应错误预算（月度，30 天=720h） | 消耗触发黄灯 | 消耗触发红灯（冻结发布） | 指标归属 |
|---|---|---|---|---|---|
| 可用性 Availability（成功返回率，不含 4xx） | 99.9% | 43.2 分钟失败时间 | 预算剩 40%（失败 25.9 分钟） | 预算剩 0（失败 43.2 分钟） | 稳定性 |
| P95 首字延迟 TTFT | ≤ 2 秒，命中率 ≥ 99% | 7.2 小时内可以有 P95 超阈值 | 命中率低于 99.5% | 命中率低于 99% | 体验 |
| P99 总端到端延迟 | ≤ 8 秒，命中率 ≥ 99% | 7.2 小时内可以有 P99 超阈值 | 命中率低于 99.5% | 命中率低于 99% | 体验 |
| 关键业务指标（例：代码一次通过 / 拒答率合规） | 代码通过率 ≥ 85% / 合规拒答率 ≥ 98% | 对应指标的不达标占比配额 | 通过率 ≤ 87% / 合规率 ≤ 98.5% | 通过率 ≤ 85% / 合规率 ≤ 98% | 质量/合规 |
| 综合加权错误预算（以上四项加权） | 四项加权后月度综合分 ≥ 99.5% | 3.6 小时综合失败配额 | 剩余 ≤ 50% 综合预算 | 剩余 = 0% 综合预算 | 全局决策 |
实战经验与避坑
- 错误预算的统计窗口不能选 1 天，必须按「28 天滚动窗口 + 自然月固定窗口」双轨并行：1 天窗口波动太大，周一挂了 30 分钟当天预算直接耗尽，第二天预算重置后大家又乱发，完全失去管控力；28 天滚动窗口（4 周）可以平滑掉偶发事故的长期影响，自然月窗口用于对客户 SLA 做结算和赔付，两者同时跑，决策时看哪个更严就按哪个来——SRE 界叫「双计时制」，能避免 90% 的边界争议。
- 错误预算必须按「客户等级 + 地域 + 模型规格」分别计算，绝不能拿全量均值糊弄：举反例——你有 100 个免费客户 + 1 个百万年度付费大客户，免费客户的请求占 95% 且经常失败，大客户请求只占 5% 但一次失败赔 10 万。如果只算全量均值，可用性可能高达 99.9%，但大客户那一侧其实失败了 3 次，SLA 照样穿底并赔钱。正确做法：① 白金/金牌客户单独算错误预算，权重是普通客户的 10 至 100 倍；② 核心地域（如国内华北/华东）和海外分开算；③ 每个模型规格（7B/70B/多模态）独立算预算。任何一个子维度穿红灯，全局进入稳定性优先模式。
- 黄灯期是最关键的管控环节，别等到预算耗尽才管：大量真实数据显示，当错误预算在月中（15 号）消耗超过 60%，有 80% 的概率该月会最终穿底耗尽；黄灯期（剩余 40% 至 50%）就应该执行以下动作——① 所有非紧急发布增加 1 位 SRE 审批；② 灰度比例从 10% 降到 1%，观察时间从 2 小时延长到 24 小时；③ 停止任何架构重构和模型大版本升级，只允许小步 Bugfix；④ 自动扩缩容的目标利用率下调 5%，热备副本加 5%。黄灯期管控得好，有 60% 至 70% 的概率能把月度预算重新拉回安全区。
- 错误预算耗尽后的「冻结期」必须有明确解封标准，而不是等月底自动重置：如果红灯期一到，大家就坐在那里摸鱼等下月初重置，错误预算就完全失去了改进意义；正确的解封标准至少三条满足其二：① 最近一次事故的 5 Whys 根因分析 + 修复方案已经 Code Review 通过并上线；② 最近连续 7 天滚动窗口可用性恢复到 SLO + 0.1%（目标 99.9% → 恢复到 99.99% 以上）；③ 针对事故的自动化回归/压测用例写进 CI/CD，且通过压测。解封后一周内仍维持「小步灰度 + SRE 二次审批」，避免二次翻车。
- 故意「把错误预算省到 100%」也是失败，因为说明你发布太慢了：很多团队看到错误预算剩下 90%，就宣布「我们本月很稳，很好」，这其实是「过度保障」，意味着你牺牲了产品迭代速度去换稳定性。错误预算的哲学是「预算花掉 70% 至 90%，月底刚好剩 10% 至 30%」才是最优——说明你在本月 SLA 不违约的前提下，发布了最多的功能，做了最大胆的创新。如果连续两个月剩余预算都超过 50%，SRE 应该主动发起「目标利用率是否过高」的复盘，并建议适当调高灰度比例或增加新模型版本的发布频次。
- LLM 专属的「质量类错误预算」（如幻觉率/合规率）消耗速度要和「可用性类错误预算」加权合并：大模型 API 场景里，「服务返回 200 但内容胡说八道」和「服务返回 500」对用户的伤害可能前者更大；所以错误预算必须加权合成——例如可用性占比 40%、P95/P99 延迟占比 30%、合规拒答率占比 15%、事实一致性/幻觉率占比 15%——任何一项消耗过快都会拖累全局预算，这样 AI 合规与隐私 的质量指标和传统基础设施的稳定性指标才能放在同一个决策平面上。
常见问题
错误预算和 SLA 有什么区别？两者冲突了以谁为准？
一句话区分：SLA 是「对外给客户的合同承诺 + 赔付条款」，SLO 是「对内给工程团队的内部目标（通常比 SLA 更严 0.5% 至 1%）」，错误预算 = 1 − SLO 是「团队内部决策货币」。三者的数值关系通常是：对外 SLA = 99.5%（不达标要赔钱），对内 SLO = 99.9%（比 SLA 严 0.4%），对应错误预算 = 43 分钟/月。为什么对内 SLO 要比对外 SLA 更严？因为要留「安全垫」：即使你对内耗尽了错误预算、SLO 穿底了，对外 SLA 还有 0.4% 的缓冲区（720 × 0.4% = 2.88 小时）不至于立刻赔客户钱，给团队留出修复窗口。两者冲突的裁决规则非常明确：① 对外 SLA 永远是底线，任何时候不能违反，违反了就按合同赔钱，这是法律+财务层面的硬约束；② 对内 SLO + 错误预算是内部管控工具，穿底后按红灯期冻结发布，但不直接产生财务赔付；③ 如果某事故导致对外 SLA 被击穿，不管对内错误预算剩多少，本月一律进入严格冻结期，并做跨团队事故复盘会。实践中最常见的错误是「把 SLA 当 SLO 用」——对外承诺 99.5%，对内目标也定 99.5%，这样任何一次小事故就直接穿 SLA，赔付成本极高。经验法则：对内 SLO = 对外 SLA + 0.3% 至 1.0%（越重要的客户，安全垫越大），这样内部错误预算耗尽 2 至 3 次，才可能伤到对外 SLA 一次，风险可控。
大模型 API 的「质量错误预算」（如幻觉率/合规率）到底怎么量化？太主观没法算吧？
「用客观可自动化度量的代理指标」替代人工主观判断，90% 场景都可量化，并纳入统一错误预算。不要试图直接定义「幻觉率 = 多少」，那样必然陷入人工审核的高昂成本泥潭；正确做法是针对不同业务选对应 3 至 5 个高度相关的可自动化代理指标（Proxy Metrics），加权合成质量错误预算。以下是四类常见场景的成熟代理指标模板：第一，通用知识问答类：① 事实一致性得分（用 RAG 检索上下文和答案做语义相似度或用裁判 LLM 打分 0/1）目标 ≥ 95%；② 答案完整度（是否包含用户要求的 5 个关键信息点）目标 ≥ 92%；③ 引用覆盖率（答案中关键陈述是否有 上下文压缩 后的来源片段匹配）目标 ≥ 88%；第二，代码生成类：① 静态语法检查通过率（lint/compile）目标 ≥ 99%；② 单测自动通过率（在沙箱运行）目标 ≥ 85%；③ 函数签名 / JSON Schema 合规率目标 ≥ 98%；第三，安全合规类：① 越狱与违规内容拒绝率（安全分类器自动打标）目标 ≥ 98%；② PII 个人信息泄露率（NER 自动检测手机号/身份证/邮箱/地址）目标 ≤ 0.1%；③ 敏感话题分类合规率目标 ≥ 97%；第四，结构化输出 / 工具调用类：① JSON / XML 语法解析成功率目标 ≥ 99%；② Schema 字段完整度目标 ≥ 97%；③ 工具调用参数合法率（在白名单内）目标 ≥ 96%。——每个代理指标都可以在 1000 请求/分钟的量级下全自动化统计，完全不用人工。最后把各指标按业务重要性加权（如合规类权重 2×，代码类权重 1.5×），得到单一的「月度质量综合达标率 SLO」，比如 ≥ 97%，对应错误预算就是 3%。任何一天某个代理指标低于阈值，就按权重比例扣减预算；指标恢复后按滚动窗口重新计算。按此方法落地，大模型的「主观质量问题」就能和传统基础设施的「5xx 错误」放在同一个错误预算框架里统一决策，质量问题不会再被「服务没报错所以不算事故」的借口掩盖。
新功能发布和错误预算冲突时，怎么判断是「正常消耗预算」还是「事故浪费预算」？
用「发布前风险等级评估 + 三段式灰度策略」做预算消耗归因，可把「必要消耗」和「可避免浪费」分开，90% 的跨团队争论可直接消除：第一步，每次发布前做风险等级分级（R1 至 R4）：R1=配置变更 + 回滚 1 分钟；R2=小功能/Bugfix + 回滚 5 分钟；R3=大模型版本升级 + 架构改造 + 回滚 30 分钟；R4=数据库迁移/协议升级/不可逆变更 + 回滚 2 小时。每级对应允许的「预算消耗配额上限」：R1 允许消耗当月预算的 0% 至 1%，R2 允许 1% 至 3%，R3 允许 3% 至 8%，R4 必须预留 10% 以上预算才能启动。第二步，所有发布必须走 1% → 10% → 100% 三段式灰度：1% 阶段观察 1 小时，如果该阶段错误预算被消耗了当月总量的 1% 以上，立即自动回滚，不进入 10%；这类在 1% 阶段被截住的消耗，归为「正常试错预算」，不算事故。第三步，归因判定的四条黄金规则：① 灰度 1% 阶段截住的回滚 → 正常消耗，计入团队 OKR「试错活跃度」正向指标；② 灰度到 10% 以上才发现问题且超过该级允许配额 2 倍 → 轻度浪费，要求在 24 小时内提交改进项（如增加自动化回归用例），但不处罚；③ 全量发布后 6 小时内导致错误预算消耗超过 R3 级配额（3% 至 8%）→ 严重浪费，当月该团队冻结所有 R3 级以上发布，并写 5 Whys 复盘；④ 同一根因在 6 个月内重复出现 2 次并消耗预算 → 系统性事故，上升到部门级专项治理。最后补充一个兜底：由外部原因导致的预算消耗（云厂商机房故障、第三方模型供应商整体故障）不计入自家团队的错误预算，走单独的外部依赖风险台账，避免团队为完全不可控的事情背锅。规则落地后，「能不能发布」就变成了纯数学题：当前剩余预算 − 本次发布等级允许配额 ≥ 0 → 可以发，否则就该等下月重置或者先修稳定性。没有灰色地带，也不需要吵架。