3. Error Budget 的数学计算：基于时间窗口的实时度量

Error Budget 的数学计算是告警阈值调优的量化基础。只有精确掌握 总量、消耗速率 和 剩余 Budget，SRE 团队才能判断当前系统的可靠性是否“超支”，并决定是否触发自动化熔断或降级策略。本节将围绕 30 天滑动时间窗口，给出完整的计算公式与实时计算方法。

3.1 核心概念与时间窗口定义

Error Budget 的计算基于一个固定的 滑动时间窗口（通常为 30 天）。窗口长度决定了 Budget 的“刷新周期”和“历史记忆长度”。

3.2 基于 30 天滑动窗口的 Error Budget 总量计算

在真实生产环境中，Error Budget 总量并非静态值，而是随着滑动窗口内总请求量的变化而动态更新。计算分为两个步骤：

1. 统计窗口总请求量：聚合过去 30 天（精确到秒）的所有合法请求计数。
2. 计算允许错误量：EB_total = R_total × (1 - SLO_target)。

以下是一个基于 Prometheus 查询语言的实时计算示例：

# 计算 30 天滑动窗口内的总请求量（假设指标名为 http_requests_total）
sum(
  rate(http_requests_total[30d])
) * 30 * 24 * 3600

# 计算 30 天滑动窗口内的 Error Budget 总量（SLO = 99.9%）
sum(
  rate(http_requests_total[30d])
) * 30 * 24 * 3600 * 0.001

3.3 消耗速率与剩余 Budget 的实时计算方法

消耗速率决定了 Error Budget 的“燃烧速度”，是触发告警和自动化策略的核心指标。剩余 Budget 则直接反映当前系统的“健康余量”。

3.3.1 消耗速率计算

消耗速率定义为 单位时间内实际错误量的滑动平均值。通常使用 1 小时、6 小时或 24 小时的窗口来计算瞬时速率。

# 实时错误速率（每秒错误数）
rate(http_errors_total[5m])

# 消耗速率占允许速率的百分比（燃烧率）
rate(http_errors_total[5m]) / (EB_total / (30 * 24 * 3600))

3.3.2 剩余 Budget 实时计算

剩余 Budget 的计算公式为：

EB_remaining = EB_total - E_actual_window

其中 E_actual_window 是过去 30 天滑动窗口内的实际错误总数。

# 实时剩余 Error Budget（值）
EB_total - sum(increase(http_errors_total[30d]))

# 实时剩余 Error Budget（百分比）
(EB_total - sum(increase(http_errors_total[30d]))) / EB_total * 100

3.4 Error Budget 实时计算流程（SVG 架构图）

下图展示了从原始指标采集到剩余 Budget 输出的完整实时计算链路：

3.5 实时计算示例：30 天窗口下的 Budget 演化

假设某服务 SLO = 99.9%，30 天总请求量稳定在 10,000,000 次。下表展示了不同时间点的 Budget 状态：

3.6 多时间窗口的 Budget 消耗速率对比（SVG 图）

下图对比了不同时间窗口下消耗速率的变化趋势，帮助理解为何需要多窗口联合告警：

3.7 实时计算的工程实现要点

• 数据源选择：优先使用分布式追踪或请求日志中的精确错误计数，避免依赖采样数据。
• 窗口对齐：确保所有计算使用相同的滑动窗口边界（如精确到秒的 30 天），避免因时间偏移导致 Budget 计算不一致。
• 缓存与预计算：对于高 QPS 服务，建议每 1 分钟预计算一次 EB_total 和 EB_remaining，避免每次告警评估都全量扫描 30 天数据。
• 指标命名规范：在 Prometheus 或类似系统中，建议使用 error_budget_total、error_budget_remaining、error_budget_burn_rate 作为标准指标名，便于团队统一理解。