Error Budget：SRE错误预算

可视化演示

展示Error Budget三模式：预算计算（SLI→SLO→EB三层关系+EB%/T_ERR/BURN/CONS公式+预算消耗进度条OK/WARN/FREEZE三阈值+99%-99.999%四级SLO）、多窗口告警（燃烧率时间线+P1 14x/P2 6x/T 3x三阈值+1H/5M/6H/1D四窗口+多窗口多燃烧率告警规则）、发布策略（NRM正常/RST限制/FRZ冻结三阶段+发布节奏时间线+REL/REV/CAN/BLK四决策矩阵+速率/稳定/创新/风险平衡指标）。

错误预算定义

李家立下的“糟心额度”不是拍脑袋定的，而是先把“一家人想要的安全感”写下来。他们不追求永远不出事，只追求大事不出格、小意外能被接住。这就像 SRE 不追求 100% 可用，而是先定一个可靠底线，也就是 SLO。SLO 是向用户承诺的“可靠等级”，比如这个月 99.9% 的请求都要成功。剩下的 0.1%，就是错误预算。

从家庭账本过渡到技术术语：SLO 是承诺，错误预算则是承诺之外留出的容错空间。两者的关系非常简单，可靠底线加上容错空间，必须等于 100%。如果承诺越高，容错空间就越小；如果承诺越低，容错空间就越大。SRE 用这个互补关系把“可靠性”这个抽象概念，变成了每个月可以量化、可以被消耗、可以被监控的数字。

在监控系统中，SLI 是实际测量出来的指标，比如请求成功率、延迟达标率。SLO 是根据 SLI 定下的目标，而错误预算就是 1 减去 SLO。假设某服务 SLO 是 99.9%，那么错误预算是 0.1%。如果本月有 1000 万次请求，最多可以允许 1 万次失败；如果按时间算，一个月大约允许 43 分钟不可用。错误预算一旦被设定，团队就可以围绕它建立发布门禁和告警规则。

最后再回到李家的冰箱。他们把“每月十次糟心事”写在最醒目的地方，SRE 则把“错误预算还剩多少”放在监控大屏上。只要额度还没花完，大家就能安心尝试新事物；一旦额度见底，所有人都知道该收手了。

预算计算方法

李家记账的第一步，是搞清楚这个月到底有多少钱可以被“糟心事”花掉。这个数字不是固定的，它取决于两件事：家庭本月的活动总量，以及全家能接受多大比例的计划外风险。对应到 SRE，就是总请求量和容错比例。总请求量越大，在同样的 SLO 下，允许失败的绝对次数就越多；容错比例越高，错误预算也越宽裕。

把记账逻辑翻译成监控指标：错误预算的绝对数量，应该用“总请求量乘以容错比例”来计算。容错比例就是 1 减去 SLO。例如 SLO 是 99.9%，容错比例是 0.001；如果本月总请求量是 1000 万，允许失败量就是 1 万次。当 SLO 是延迟类指标时，思路也完全一样：那些延迟超过阈值的请求，就是账本里的“坏账”，同样占用了错误预算。

实际工作中，错误预算通常按一个周期计算，比如一个月或一个季度。团队先把周期内的总请求量统计出来，再乘以容错比例，得到本周期“最多能坏多少笔”。之后每发生一次 5xx 错误、超时或超延迟响应，就从预算里扣一笔。这样，团队不仅能回答“现在系统好不好”，还能回答“这个月还能承受多少坏情况”。

李家月底对账时，不会只看“还剩多少钱”，而会看每一笔支出的来龙去脉。SRE 也一样，错误预算不仅是一个总数，更是由一次次失败请求累计出来的消费记录。只要把账记清楚，团队就能随时回答“容错额度还剩多少”。

预算消耗速率

李家不会等到月底才看账本，他们会每天都问一个问题：这个月的“糟心额度”是按计划花，还是花得太快？如果十天就把额度用掉了一半，后面二十天就只能躲在家里不出门。这个“花钱速度”，就是 SRE 里的燃尽率 Burn Rate。燃尽率回答的不是“还剩多少”，而是“按这个速度还能撑多久”。

燃尽率的计算逻辑是：用实际错误率除以可容忍错误率。可容忍错误率就是 1 减去 SLO。如果实际错误率和可容忍错误率相等，燃尽率等于 1，说明预算正按计划消耗；如果实际错误率是可容忍错误率的两倍，燃尽率等于 2，说明预算会以两倍速度烧完；如果燃尽率是 0.5，说明系统比预期更稳定，预算消耗得很慢。

举个例子：SLO 是 99.9%，可容忍错误率是 0.1%。某天实际错误率达到 0.2%，燃尽率就是 2。如果这不是偶发峰值，而是一直持续，那么 30 天的预算大约会在 15 天左右耗尽。SRE 通常会用短窗口观察突发，用长窗口观察慢性消耗，避免被瞬时抖动欺骗。

李家的经验是：余额下降不可怕，可怕的是下降速度越来越快。燃尽率就是那个“速度计”。当速度超过红线时，哪怕账面上还有钱，也要提前踩刹车，而不是等归零后再行动。

开发节奏管理

当李家额度过半时，他们仍然会去爬山、露营，因为这些冒险带来的快乐值得承受风险；可当额度只剩 10% 时，他们连新滑板都不敢买。服务的发布节奏也是如此。错误预算就是 SRE 手里的“开发节奏开关”：预算充裕时，团队可以大胆上线新功能；预算紧张时，团队应该主动收缩，把重心从“新增价值”切换到“保住稳定”。

在实际开发流程中，错误预算可以成为发布门禁的一部分。一次高风险发布，比如大版本升级、数据库迁移、模型替换，上线前先看剩余预算。如果剩余预算高，团队可以按正常流程评估后发布；如果剩余预算低于阈值，比如不足 20%，就进入稳定性冻结期。冻结期间不是所有人停摆，而是只允许低风险修复，比如配置调整、容量扩容、日志增强，不再引入新的不确定性。

这里要特别留意：错误预算没有“自动恢复”机制，它只会在下一个周期重置。想要让剩余预算变多，唯一办法是减少故障，而不是等待。冻结期结束的信号，不是“团队后悔了”，而是“故障率降下来了”。当系统重新回到稳定状态，燃尽率回到 1 以下，开发节奏再逐步恢复。

李家会为不同的“冒险项目”设不同门槛：骑车摔跤可以，带病开车不行。SRE 也一样，发布门禁的松紧应该由错误预算决定。预算充足时，门开大一点；预算紧张时，门关小一点。门禁不是阻碍创新，而是保护最后一个额度不被冲动耗尽。

告警策略设计

李家的预警器不能设计成“只要家里有任何小意外就响”，否则一天响二十次，最后大家会直接把它关掉。好的预警器应该只在两种情况响：要么突发风险太大，要么风险正在持续消耗额度。SRE 的告警策略也一样，不能只盯着剩余预算，因为等剩余预算归零再报警，系统已经出事了。

错误的告警方式只看“剩余预算百分比”，这样的指标有滞后性。更好的方式是多窗口、多速率告警：短窗口关注突发，比如过去 1 小时内燃尽率过高；长窗口关注慢性消耗，比如过去 6 小时或 24 小时，燃尽率虽然不高，但一直大于 1，预算正在被慢慢烧光。只有当某个窗口的燃尽率持续超过阈值时，才触发分页告警。

以 30 天预算窗口为例，如果 1 小时内就消耗了 2% 的预算，对应的燃尽率大约是 14.4，说明系统正在经历严重故障，要立刻叫醒值班人。如果只是偶发一次抖动，持续时间很短，就不该打扰任何人。这就是多窗口设计的价值：既能对突发快速响应，又能对“温水煮青蛙”式的慢性消耗保持敏感。

李家的预警器只在“概率高、后果重”的时候响，SRE 的告警也一样。多窗口设计让告警既不过度灵敏，也不过度迟钝。报警不是目标，让团队在错误预算彻底烧完之前采取行动，才是目标。

可靠性与创新平衡

李家如果要求“一次糟心事都不许发生”，那他们只能整天待在家里，什么新鲜事都不做。可靠性与创新天然存在张力：为了多一个 9 的可用性，团队要付出更多冗余、监控和运维成本，而换来的用户体验提升却越来越小。错误预算的价值，就是把这笔账摆到桌面上，让团队诚实地回答：我们愿意用多少容错空间，换取多少发展速度。

从 99.9% 提升到 99.99%，听起来只是多了一个 9，实际上允许故障时间从每月约 43 分钟缩短到约 4 分钟。为了实现这 39 分钟的差距，可能需要多机房容灾、更复杂的自动恢复、更昂贵的架构设计。这种投入指数级增长，但用户可能根本感知不到差别。因此，SLO 定多少，应该是一个产品决策，而不是工程师追求完美的技术决策。

错误预算还有一个更关键的作用：它把“风险”变成可管理的资源。预算花得快，说明这阶段的风险选择过于激进；预算一直花不完，说明目标可能定得太松，团队其实可以更大胆。理想状态不是永远不出错，而是错误预算被有意识地使用，并在周期结束时刚好接近耗尽。这样，每个错误预算都用在了产品创新和用户价值上。

李家最终发现，幸福不是“永远不倒霉”，而是在可承受的风险里活得丰富。服务也一样，可靠性的终点不是 100%，而是在用户可接受的范围内，让团队跑得更快、试得更多。错误预算就是那把守住边界的尺子。

落地文化实践

再好的账本，如果家里只有一个人认，也执行不下去。李家的家规之所以有效，是因为全家都同意这套规则，并且知道它不是为了惩罚某个成员，而是为了共同目标。错误预算文化也是这样：SRE、开发团队、产品经理，甚至业务方，都要认同“这本账”的权威性，并愿意按它做决定。

在实际落地时，SRE 不再单方面说“不行”，而是和开发一起看剩余预算：如果预算充足，风险变更得到批准；如果预算不足，大家共同接受冻结安排。错误预算因此变成一种沟通语言，减少“SRE 阻碍创新”和“开发破坏稳定”的对立。团队复盘时，重点也不是追责某次改动，而是分析为什么燃尽率会突破预期、监控窗口是否覆盖到位、下次如何更早发现。

从用户视角看，错误预算其实是在回答一个问题：用户是否能明确感知到这次故障？如果用户完全无感，说明 SLO 可能太严；如果用户已经大量流失，说明 SLO 可能太松。每一个错误预算消耗，都应该能够回到“对用户体验的实际影响”上。这样，错误预算才不会沦为内部数字游戏。

李家的冰箱贴写着“十次额度，全家共守”；SRE 团队的文化则应该是“错误预算，共同负责”。一旦所有人都把账本当默认决策依据，发布、告警、复盘就不再靠嗓门，而是靠数据。这才是错误预算从工具走向文化的真正意义。

AI 应用场景

Python 演示

#!/usr/bin/env python3# Simulate a 30-day error budget ledgerimport math SLO = 0.999TOTAL_DAYS = 30REQUESTS_PER_DAY = 1_000_000 total_requests = REQUESTS_PER_DAY * TOTAL_DAYSerror_budget_count = int(total_requests * (1 - SLO))remaining = error_budget_countlow_threshold = error_budget_count * 0.2 print("total requests:", total_requests)print("error budget:", error_budget_count)print("low budget threshold:", low_threshold) for day in range(1, TOTAL_DAYS + 1):    failure_ratio = 0.00105 + 0.0004 * math.sin(day / 4)    failed = int(REQUESTS_PER_DAY * failure_ratio)    remaining -= failed    daily_error_rate = failed / REQUESTS_PER_DAY    burn_rate = daily_error_rate / (1 - SLO)    print(f"day {day:2d}: failed={failed:4d}, burn_rate={burn_rate:.2f}, remaining={remaining:6d}")    if remaining < low_threshold:        print(" -> freeze high-risk releases")

1. error_budget_count = int(total_requests * (1 - SLO))在 30 天窗口里把 SLO 之外的 0.1% 转成具体失败次数。
2. remaining -= failed每一笔失败都要从账本里扣掉，这就是“消费”动作。
3. failure_ratio = 0.00105 + 0.0004 * math.sin(day / 4)模拟真实波动，某些日子的错误率会超过允许值。
4. burn_rate = daily_error_rate / (1 - SLO)计算当天燃尽率是否大于 1。
5. if remaining < low_threshold:当剩余预算低于阈值，自动触发“冻结高风险发布”门禁。

常见误区

面试题