4. 多窗口燃烧率预警策略：为什么需要同时监控1小时、6小时、24小时、3天等多个时间窗口的燃烧率
单一时间窗口的燃烧率监控存在固有盲区：短窗口对突发故障敏感但容易误报，长窗口趋势准确但响应延迟。多窗口燃烧率预警策略通过组合不同粒度的观测窗口，在检测灵敏度与告警可靠性之间取得平衡，是SRE实践中避免误报和漏报的核心手段。
4.1 单窗口预警的局限性
仅依赖单一时间窗口的燃烧率会面临以下两类典型问题：
| 窗口类型 | 优势 | 固有缺陷 | 典型后果 |
|---|---|---|---|
| 短窗口（1小时） | 快速感知突发故障 | 对瞬时抖动过于敏感 | 频繁误报，告警疲劳 |
| 中窗口（6小时） | 平衡灵敏度与稳定性 | 无法区分持续恶化与偶发尖刺 | 中等误报率，漏报风险并存 |
| 长窗口（24小时/3天） | 反映真实趋势，过滤噪声 | 响应延迟，错过早期干预窗口 | 漏报严重，SLO消耗过度 |
关键洞察： 任何单一窗口都无法同时满足"快速发现"和"准确判定"两个目标。多窗口策略的本质是利用窗口间的逻辑与/或组合来弥补各自的盲区。
4.2 多窗口预警的数学基础
多窗口燃烧率预警基于时间窗口聚合与阈值分层两个核心机制。每个窗口独立计算燃烧率，再通过预设的告警规则进行综合判定。
燃烧率计算公式（以任意窗口T为例）：
BurnRate(T) = (1 - SLO_actual) / (1 - SLO_target) × (T / T_total)
其中：
- SLO_actual：窗口T内的实际可用性
- SLO_target：目标可用性（如99.9%）
- T_total：SLO的合规周期（如30天）
- T：当前观测窗口长度当 BurnRate(T) > 1 时，表示当前窗口的故障消耗速度已超过SLO预算的线性分配速率，需要触发告警。
4.3 四窗口协同预警模型
业界最佳实践通常采用1小时 + 6小时 + 24小时 + 3天的四窗口组合。每个窗口承担不同的检测角色：
4.4 误报与漏报的消除机制
多窗口策略通过以下三种组合逻辑消除单一窗口的缺陷：
- 短窗口触发 + 中窗口确认： 1小时窗口检测到异常后，等待6小时窗口验证。若6小时窗口未触发，判定为瞬时抖动，抑制告警。这消除了因突发流量尖刺、短暂网络抖动等引起的误报。
- 中窗口持续触发 + 长窗口验证： 6小时窗口持续燃烧率偏高时，检查24小时窗口是否也进入消耗状态。若24小时窗口确认，则判定为持续性故障，升级为紧急告警。这避免了因周期性任务（如夜间批量作业）导致的误报。
- 长窗口缓慢消耗 + 短窗口未触发： 3天窗口显示燃烧率缓慢上升但1小时窗口正常，表明存在慢性性能退化（如内存泄漏、慢查询累积）。此时发出趋势预警，避免漏报。
实践建议： 在Prometheus或Grafana中配置多窗口告警时，使用
max_over_time 和 min_over_time 函数组合不同窗口的聚合结果。例如：max(rate(error_budget_burn[1h])) > 14.4 AND max(rate(error_budget_burn[6h])) > 2.4 实现双重确认。
4.5 窗口阈值校准方法
阈值并非固定不变，需要根据实际SLO目标和历史故障模式进行校准。以下为通用校准步骤：
- 确定SLO预算周期： 通常为30天（720小时）。计算总允许错误预算 = (1 - SLO_target) × 总请求量。
- 计算各窗口的预算分配： 1小时窗口的预算 = 总预算 / 720；6小时窗口的预算 = 总预算 / 120；24小时窗口的预算 = 总预算 / 30；3天窗口的预算 = 总预算 / 10。
- 设定初始阈值： 以燃烧率=1为基准线，短窗口设置较高阈值（如14.4倍），长窗口设置较低阈值（如0.2倍）。
- 历史回测： 使用过去3-6个月的故障数据回放，调整阈值使误报率 < 5%，漏报率 < 1%。
- 持续迭代： 每季度根据SLO达成情况和告警质量重新校准一次。
4.6 多窗口告警的优先级映射
不同窗口组合触发时，应映射到不同的告警优先级，以便运维人员快速判断响应级别：
| 触发窗口组合 | 告警优先级 | 响应要求 | 典型场景 |
|---|---|---|---|
| 1h + 6h 同时触发 | P0（紧急） | 立即响应，5分钟内介入 | 大规模服务中断、全链路故障 |
| 6h + 24h 同时触发 | P1（严重） | 15分钟内响应 | 持续性能退化、部分功能不可用 |
| 仅24h 触发 | P2（一般） | 1小时内确认 | 慢查询增加、错误率缓慢上升 |
| 仅3d 触发 | P3（预警） | 下一个工作日分析 | 容量趋势变化、长期资源瓶颈 |
| 1h 单独触发（6h未触发） | 抑制（不告警） | 记录日志，自动降噪 | 瞬时流量尖刺、网络抖动 |
避坑指南： 不要对所有窗口使用相同的燃烧率阈值。短窗口阈值过低会导致告警风暴，长窗口阈值过高会失去预警意义。建议初始值：1h/14.4x、6h/2.4x、24h/0.6x、3d/0.2x，然后根据实际告警质量逐步微调。
4.7 多窗口策略的工程落地
在Prometheus生态中，多窗口燃烧率告警的典型配置如下：
groups:
- name: error_budget_burn_rate
rules:
- alert: SLO_BurnRate_1h
expr: |
(1 - (sum(rate(http_requests_total{status=~"5.."}[1h]))
/ sum(rate(http_requests_total[1h]))))
/ (1 - 0.999) * (1/720) > 14.4
for: 5m
labels:
severity: critical
window: 1h
- alert: SLO_BurnRate_6h
expr: |
(1 - (sum(rate(http_requests_total{status=~"5.."}[6h]))
/ sum(rate(http_requests_total[6h]))))
/ (1 - 0.999) * (6/720) > 2.4
for: 10m
labels:
severity: warning
window: 6h
- alert: SLO_BurnRate_24h
expr: |
(1 - (sum(rate(http_requests_total{status=~"5.."}[24h]))
/ sum(rate(http_requests_total[24h]))))
/ (1 - 0.999) * (24/720) > 0.6
for: 30m
labels:
severity: info
window: 24h通过上述配置，系统能够自动区分瞬时故障、持续恶化和慢性退化，在保证告警准确性的同时，将运维人员的认知负载降到最低。