错误预算与燃尽管理方法

可视化演示

展示软件测试金字塔的三层结构：单元测试、集成测试和端到端测试，点击按钮切换查看各层特点。

预算基石：SLI、SLO 与错误预算

小明家的容错金为什么定500元，而不是5000元？因为他和妻子先定下一条“月度正常运转标准”：一个月里，至少要有99%的日子按计划平稳度过。那么，剩下的1%就是可以容忍的意外额度。换算下来，一个月30天约有7个小时的“容错空间”——500元不过是对这7小时风险的一个价值估算。关键是顺序：先有标准，后有额度。

在服务可靠性里，这个“月度正常运转标准”就是SLO（Service Level Objective，服务等级目标），比如“季度内API请求成功率不低于99.9%”。而“每天实际过得怎么样”的度量，叫SLI（Service Level Indicator，服务等级指标），比如当天实测的成功率是多少。SLO是我们设定的底线，SLI是账本上真实记下的数字。

有了SLO，错误预算（Error Budget）就水到渠成了——它是SLO与100%之间留出的那片空间，是服务允许出错的“容错金”。它本质是一个设计值，不是测出来的，而是团队主动承诺的。

回头看小明家：500元容错金不是鼓励家人犯错，而是承认“意外总会发生”，给过日子留出呼吸感。对服务也一样——错误预算不是故障许可证，而是给研发团队的一个信号：只要还在预算内，你就可以放心大胆地发布新版本。

计算要素：预算怎么算出来

容错金的账本要发挥作用，首先得把每一笔“意外支出”记清楚。小明的记账规则很明确：什么算支出？只有那些让家庭偏离“正常运转标准”的事才算——迟到、跑空、生病都算；正常买菜做饭不算。定义不清晰，月底账就对不上。

服务这边同理。最常见的基础指标是可用性：把一段时间内的所有请求当作总盘子，成功处理的比例就是可用性。工程上常用失败率来反推：

除了公式，记账的口径也要约定。固定日历月（每月1日0点重置预算）简单直观，适合和财务、管理节奏对齐；滚动窗口（如过去30天连续滚动）则更平滑，避免月初搞事月末才爆雷。两种口径各有利弊，关键是与团队和业务的节奏一致。就像小明家规定“每月1日发新的容错金”，如果改成“每30天滚动一次”，家里的计划节奏也要跟着变。

燃尽率监控：花钱的速度

到了月中，小明看账本时会问两个问题：还剩多少？花得多快？第二个问题往往更关键——如果月初三天就花掉300元，那这个月注定要进入守成模式；如果到月中才花了100元，那月底前还能松口气。这个“花钱的速度”，在SRE里就叫燃尽率（Burn Rate）。

燃尽率定义为：错误预算的消耗比例与时间流逝比例的比值。如果燃尽率恰好为1，预算会在周期结束时刚刚好用完，这是“计划内”的节奏；如果大于1，说明花钱太猛，预算将提前见底。

实战中单看一个燃尽率会“一叶障目”：突发大故障可能在一小时内烧掉2%的月度预算，相当于约14.4倍燃尽率，这种急性问题要靠短窗口（如1小时）迅速发现；而某些性能退化像慢性渗水，一天只消耗一点点，需要长窗口（如3天）才能看出趋势。因此成熟团队会同时部署多组窗口：短窗口配高阈值用于快速告警，长窗口配低阈值（如1倍）用于捕捉慢性恶化。就像小明既看单笔开销是否异常，也看整月累计是否超标。

耗尽与应对：守成模式

当容错金见底，小明家的家规立刻切换：取消所有非必要的出行与采购，连网购都改成“只买必需品”。这套守成模式在服务侧就是发布冻结——错误预算耗尽后，停止一切高风险变更，包括新功能上线、配置调整和实验性流量，把精力全部转向稳定性和止血。

发布冻结不是终点，而是进入了一个规范化的升级流程：先是值班工程师定位，再拉研发负责人决策，必要时升级到技术总监和产品负责人共同评估。冻结期间要回答三个问题：故障根因是什么？止血措施有哪些？预算何时能恢复？如果服务已经恢复稳定，但预算要等下一个周期才重置，那就得靠人工“续费”机制——比如经审批临时追加少量预算，或从低优级服务“借调”预算，但这必须走流程、留记录。

如何判断预算会不会提前耗尽？可以用一个简单的预测公式：

如果算出的 \(T_{\text{exhaust}} \le 1\)，说明预算能撑到月底，一切照旧；如果大于1，说明要提前亮红灯。预算恢复则不用焦虑——到了新周期，容错金自动充满，团队又能重新出发。当然，每次耗尽后都要复盘：是发布太激进，还是容量预估不足？把这些教训写进下个周期的计划，容错金才算花得值。

落地工具：监控大盘与自动化门禁

小明家的账本后来从纸质换成了手机App：每一笔开销自动记录，月初自动发新额度，快超支时自动提醒。服务侧的“账本App”就是监控大盘——实时展示剩余预算的进度条、燃尽率的动态曲线，以及各窗口告警状态。SRE一打开仪表盘，就像小明看一眼App首页，当前“家庭财务状况”一目了然。

比“看”更高级的是“自动执行”。把错误预算接进CI/CD流水线，就形成了门禁自动化：每次提交发布时，流水线自动检查当前剩余预算；如果预算充足，放行；如果耗尽或燃尽率超标，直接阻断并通知负责人。这样人类就不必时刻盯着大盘，判断标准变成一段确定性的逻辑：

工具链之外，团队协同同样关键：SRE是“账房先生”，负责盯预算和解释告警；开发团队是“花钱的人”，在预算内自由发布；产品经理则是“家庭会议成员”，当真金白银的需求和预算冲突时，一起坐下来定优先级。任何一方都不能单独改规则——就像小明不能一个人偷偷把容错金从500改成5000。

多级SLO与例外管理

日子过久了，小明发现“一刀切”的容错金不好使：日常买菜和全家旅行，风险等级完全不同。于是他把容错金拆成两个账户：日常账户300元，每月覆盖早餐、通勤这类高频小事；旅行账户200元，专为季度性的大宗活动储备。这就是多级SLO的朴素原型——不同服务、不同调用链环节，各有各的可靠性与预算配额。

大型系统通常分三层设SLO：底层基础设施（网络、存储）设99.99%，中间平台（消息队列、服务网格）设99.95%，上层业务API设99.9%。每一层消费自己的错误预算，互不挤占。不过要注意：当一次用户请求跨越多个子服务时，整体成功率等于各子服务成功率的乘积，错误预算也遵循同样的叠加逻辑：

例外场景也要提前写进“家规”。计划内维护（比如数据库版本升级）消耗的预算应该提前申报，独立记账；而“不可恢复”的状态——比如某次大故障已经烧光了整月预算，且服务短时间无法恢复——就需要启动最高级别的应急发布通道，由管理层签字追加预算。这些例外不是给规则开后门，而是让规则更贴近真实世界的复杂。

AI负载联动：推理服务的特殊挑战

AI推理服务有个鲜明特点：流量像外卖平台的高峰时段，来得又急又猛。上一个整点还风平浪静，下一秒用户集体涌入，GPU集群算力被瞬间吃紧——排队请求增多，推理延迟飙升。此时即便每个请求最终都返回了“成功”，P99延迟也可能已经超标。对这类服务，错误预算的账本上不只看“成功率”，更要看延迟SLO。

一个请求只要延迟超过阈值，无论业务结果对错，都算“消费了错误预算”。因此，AI推理服务的燃尽率与负载强度直接挂钩。容量规划团队做负载测试时，除了测“扛不扛得住”，更要测“压测期间烧掉多少预算”：

当燃尽率因为流量突增而快速上升，扩缩容联动就登场了：监控系统检测到燃烧速率超过阈值时，自动触发GPU节点扩容，把排队请求分散到新实例上，将燃尽率拉回安全区。反过来，在预算充裕的凌晨低峰，还可以适度缩容降低成本。AI服务的错误预算管理，本质上是把“模型效果、算力成本、服务质量”三者放到同一本账里算——这就是为什么它会成为AI负载测试与容量规划一线的标配工具。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-# 错误预算与燃尽率计算模拟器# 模拟一个 SLO=99.9% 的 AI 推理服务一个月的运行情况 import random SLO = 0.999MONTH_HOURS = 720       # 一个月的总小时数 (30天)TOTAL_BUDGET = 1 - SLO  # 月度错误预算  class ErrorBudgetMonitor:    """按小时记录请求数据, 计算剩余预算与燃尽率"""     def __init__(self, target_slo):        self.target_slo = target_slo        self.total_budget = 1 - target_slo        self.hourly = []   # 每小时 (总请求数, 失败数)     def record_hour(self, ok_reqs, bad_reqs):        self.hourly.append((ok_reqs + bad_reqs, bad_reqs))     def cumulative_sli(self, hours):        total = sum(r for r, _ in self.hourly[:hours])        bad = sum(b for _, b in self.hourly[:hours])        return 1 - bad / max(1, total)     def burn_rate(self, hours):        elapsed_ratio = hours / MONTH_HOURS        sli = self.cumulative_sli(hours)        consumed = max(0.0, (1 - sli) / self.total_budget)        return consumed / max(elapsed_ratio, 0.0001)     def remaining_budget(self, hours):        return self.total_budget - (1 - self.cumulative_sli(hours))     def can_deploy(self, hours):        return self.remaining_budget(hours) > 0  def simulate(seed, failure_modes):    rng = random.Random(seed)    monitor = ErrorBudgetMonitor(SLO)    for h in range(MONTH_HOURS):        base_rate = 1000        fail_rate = 0.0005        for start, end, bad_rate in failure_modes:            if start <= h < end:                fail_rate = bad_rate        total = max(1, int(rng.gauss(base_rate, base_rate * 0.1)))        bad = max(0, int(total * fail_rate * rng.uniform(0.8, 1.2)))        monitor.record_hour(total - bad, bad)    return monitor  def main():    normal = simulate(42, [])    outage = simulate(42, [(72, 216, 0.02)])  # 第4-9天持续故障     for name, m in [("平稳运行", normal), ("持续故障", outage)]:        print("=" * 46)        print("[" + name + "]")        for h in (72, 168, 432, 720):            sli = m.cumulative_sli(h)            ratio = m.burn_rate(h)            remain = m.remaining_budget(h)            action = "正常发布" if m.can_deploy(h) else "冻结发布"            print(" 第%3d小时 SLI=%.6f%% 燃尽率=%4.2fx 剩余预算=%+.4f%% -> %s"                  % (h, sli * 100, ratio, remain * 100, action))        print()  if __name__ == "__main__":    main()

1. self.total_budget = 1 - target_slo用SLO算出整月错误预算，相当于“500元容错金”。
2. def cumulative_sli(self, hours)累计前N个小时的成功率，是预算计算的“流水账”。
3. consumed = max(0.0, (1 - sli) / self.total_budget)已消耗预算占总预算的比例，对应“已经花掉多少钱”。
4. return consumed / max(elapsed_ratio, 0.0001)消耗比例除以时间比例得到燃尽率，分母加极小值防止除零。
5. def can_deploy(self, hours)判断剩余预算是否大于零，就是自动化发布门禁的核心条件。

常见误区

面试题