多窗口多烧蚀（Multi-window, Multi-Burn-Rate, MWMBR）

1) 核心概念（一句话版）

• SLO：比如“30 天内可用率 ≥ 99.9%”。

• 误差预算：允许失败占比 $e=1-\text{SLO}$（例：0.1%）。

• 烧蚀率（Burn rate, BR）：当前失败率 / 允许失败率。BR=1 表示“按这个速度，刚好在评估周期末把预算烧完”。([sre.google][1])

  单一窗口的阈值告警很容易“要么太敏感、要么太迟”。MWMBR 用短+长两个窗口、配对的 burn rate 阈值，同时满足才告警：既能快速探测大事故，又能抑制抖动，是 SRE Workbook 推荐的最佳实践。(sre.google)

  ---

  2) 公式与推导（可直接套用）

  • 设评估周期 PP（例：30 天 = 720 小时），允许失败率 ee（例：0.001）。
  • 选一个告警窗口 LL（例：1 小时），希望在该窗口里消耗月度预算的 cc 比例（例：2%）。
  • 则 Burn rate：
    $$\text{BR}=c\times \frac{P}{L}$$

• 对应的失败率阈值：

$$\text{阈值失败率}=e\times \text{BR}$$

例：99.9% 月度 SLO（$e=0.001$），若取 $c=2\%$，$L=1h$：
$\text{BR}=0.02\times 720/1=14.4$，失败率阈值 $=0.001\times 14.4=1.44\%$。
这是 SRE Workbook 给出的“2%/1h→BR=14.4”的经典设置。([sre.google][1])

---

3) 推荐的组合与含义

SRE Workbook 的“起步值”常用：

• 分页（Page）级
  • 短窗 5m + 长窗 1h，阈值：BR=14.4（等价于“2% 预算在 1 小时内被烧掉”）
  • 短窗 30m + 长窗 6h，阈值：BR=6（等价于“5% 预算在 6 小时内被烧掉”）
• 工单（Ticket）级
  • 长窗 3d，BR=1（约“10% 预算在 3 天内被烧掉”，按需加短窗配对）

这样既能尽快发现快灾难，又能捕捉慢性劣化；并且“短窗+长窗同时越阈才报警”，复位更快、误报更少。上述数值与示例在 SRE Workbook 的“Alerting on SLOs”中有表格说明与 Prometheus 例子。(sre.google)

---

4) PromQL 落地（以 apiserver 为例，基础设施口径=只把 5xx 当失败）

若你想把 429（限流）也计为失败，把 {code=~"5.."} 改成 {code=~"429|5.."} 即可。

短窗 5m + 长窗 1h（BR=14.4，SLO=99.9%）

# 失败率（5m）
sum(rate(apiserver_request_total{code=~"5.."}[5m])) 
/ sum(rate(apiserver_request_total[5m])) > 0.001 * 14.4
AND
# 失败率（1h）
sum(rate(apiserver_request_total{code=~"5.."}[1h])) 
/ sum(rate(apiserver_request_total[1h])) > 0.001 * 14.4

短窗 30m + 长窗 6h（BR=6）

sum(rate(apiserver_request_total{code=~"5.."}[30m])) 
/ sum(rate(apiserver_request_total[30m])) > 0.001 * 6
AND
sum(rate(apiserver_request_total{code=~"5.."}[6h])) 
/ sum(rate(apiserver_request_total[6h])) > 0.001 * 6

这些写法与 Workbook 的“多 burn rate、多窗口”思路一致（书中有 1h/6h 配对与 5m/1h 的重置时间说明）。(sre.google)

---

5) 选择窗口与阈值的“操作步骤”

1. 定 SLO 与周期：如 99.9% / 30 天。
2. 挑通知等级：分页与工单各自要几个层级（通常 2 个分页 + 1 个工单）。
3. 选 $c$ 与 $L$：例如分页用 $c=2\%$@1h 与 $c=5\%$@6h；工单用 $c=10\%$@3d。
4. 算 BR 与阈值：用上面的公式一键算出 14.4、6、1 及对应失败率阈值。
5. 配短窗：给每个长窗配一个短窗（通常短窗=长窗的 1/12，比如 5m↔1h、30m↔6h），用于快复位与抑制噪声。([docs.datadoghq.com][2], [sre.google][1])
6. 实现与去重：多个规则都满足时要抑制重复报警（Workbook 亦有提醒）。([sre.google][1])

---

6) 常见坑 & 处理

• 统计口径混乱：分子分母的标签过滤要一致（verb、resource、instance、cluster 等），否则会出现 >100% 等怪相。
• 短窗太短：流量低时抖动大，考虑最低流量门槛或夜间静默策略（Workbook 有“低流量服务”讨论）。(sre.google)
• 复位太慢：只用长窗会导致报警“挂太久”，务必配短窗（5m/30m）。(sre.google)
• 多条同时触发：实现“高优先级覆盖低优先级”的去重逻辑（通知链路抑制/分组）。(sre.google)

---

7) 速查表（以 30 天、99.9% 为例）

目的	窗口（短/长）	BR	失败率阈值 (= 0.001×BR)	建议动作
快速分页	5m / 1h	14.4	1.44%	Page
稳健分页	30m / 6h	6	0.6%	Page
慢性劣化	（可配 30m）/ 3d	1	0.1%	Ticket

上述推荐与示例来自 SRE Workbook“Alerting on SLOs”（第 5 节到第 6 节）。(sre.google)

---

如果你把**当前 SLO（小数值/周期）**贴一下，我可以按上面公式帮你把 BR 与阈值精确算出来，并给出与你现有指标（例如 apiserver_request_total）完全匹配的 PromQL 规则片段。