3. 核心概念：错误预算的定义、计算方式（基于SLI/SLO的剩余预算）

3.1 错误预算的起源与核心思想

错误预算（Error Budget）是 Google SRE 实践中的核心管理机制，它连接了系统可靠性与产品迭代速度。其核心思想是：100% 的可靠性不仅不可能，而且成本过高。SRE 团队与产品团队需要一种共同的语言来决策：在追求新功能与保障系统稳定性之间，如何分配资源。

错误预算的本质是 “允许系统不达标的时间或次数”。它不是一个技术指标，而是一个管理契约：只要系统消耗的错误预算在允许范围内，产品团队可以自由发布新版本；一旦错误预算耗尽，所有非必要的变更必须停止，优先恢复可靠性。

3.2 错误预算的数学定义

错误预算的计算基于两个前置指标：SLI（服务等级指标） 和 SLO（服务等级目标）。

通用计算公式：

错误预算总量 = 1 - SLO（以小数表示）
剩余错误预算 = 错误预算总量 - 已消耗的错误比率

以时间窗口计算（更常用）：

错误预算总量（秒） = 时间窗口总秒数 × (1 - SLO)
已消耗错误预算（秒） = 时间窗口内 SLI 未达标的总时长
剩余错误预算（秒） = 错误预算总量 - 已消耗错误预算

3.3 计算示例：基于 SLI/SLO 的剩余预算

假设一个 API 服务的 SLO 为 99.9%（月度），时间窗口为 30 天（2,592,000 秒）。

步骤 1：计算错误预算总量

错误预算总量 = 2,592,000 秒 × (1 - 0.999) = 2,592,000 × 0.001 = 2,592 秒

这意味着该服务在 30 天内最多允许 43.2 分钟（2,592 秒）的不可用或低质量时间。

步骤 2：计算已消耗的错误预算

假设过去 30 天内，系统发生了以下事件：

• 一次 15 分钟的数据库故障（900 秒）
• 两次 5 分钟的延迟毛刺（600 秒）
• 持续的低质量时段累计 10 分钟（600 秒）

已消耗错误预算 = 900 + 600 + 600 = 2,100 秒

步骤 3：计算剩余错误预算

剩余错误预算 = 2,592 秒 - 2,100 秒 = 492 秒（约 8.2 分钟）

步骤 4：计算剩余预算百分比

剩余预算百分比 = (492 / 2,592) × 100% ≈ 18.98%

3.4 错误预算的联动机制：从指标到行动

错误预算的真正价值在于它与发布流程的联动。下图展示了从 SLI 采集到决策触发的完整链路。

3.5 错误预算的消耗速率与预警

仅看剩余预算的值是不够的，还需要关注消耗速率。一个在月初就消耗了 50% 预算的服务，比月底消耗 50% 的服务风险更高。

关键监控指标：

• 预算消耗率（Burn Rate）： 当前消耗速度 / 允许消耗速度。例如，如果允许每天消耗 86.4 秒（2,592 秒 / 30 天），但实际每天消耗 200 秒，则 Burn Rate = 2.31。
• 预计耗尽时间（TTB, Time to Burnout）： 按当前速率，剩余预算还能支撑多久。
• 多窗口预警： 同时监控 1 小时、6 小时、1 天的消耗率，避免短时突发导致预算快速耗尽。

3.6 错误预算与压测水位的联动关系

在压测场景中，错误预算为压测水位提供了量化边界。压测不是无限制地压垮系统，而是要在“不耗尽错误预算”的前提下，找到系统的极限。

3.7 错误预算的常见陷阱与应对

1. 陷阱：SLO 设置过高（如 99.999%）
   导致错误预算极少（每年仅 5.26 分钟），任何变更都容易耗尽预算，团队趋于保守，不敢发布。
   应对： 区分关键路径与非关键路径，为不同模块设置不同的 SLO。
2. 陷阱：忽略错误预算的“不可消耗”部分
   某些故障（如机房断电）可能一次性消耗全部预算。需要为“黑天鹅事件”预留缓冲。
   应对： 设置预算消耗上限（如单次事件最多消耗 50% 预算）。
3. 陷阱：预算重置后立即发布
   月初预算重置后，团队可能集中发布高风险变更，导致月初就消耗大量预算。
   应对： 采用滚动窗口（如 28 天），避免周期性冲动。
4. 陷阱：错误预算与业务指标脱节
   系统可用性达标，但用户感知体验差（如慢请求未计入 SLI）。
   应对： SLI 必须反映真实用户体验，如使用 Apdex 标准定义“满意”与“容忍”阈值。