日内流量 8 倍差异下，burn rate 该不该按流量加权：凌晨 1h 烧 14.4x 预算的告警权重怎么定才算「流量对齐」？

背景

C 端电商主链路，对外承诺 P99 < 300ms，30 天 SLO 窗口，错误预算 0.05%。入口 QPS 有极强的日内周期：凌晨 0–6 点约 80 QPS，上午 10–14 点约 650 QPS，相差 8 倍。延迟分布也随流量走——低峰期后端连接池/缓存命中都很宽裕，P99 常在 90–130ms；高峰期 P99 基线本身就在 220–260ms 附近贴着 SLO 跑。

告警用 Google SRE Book 多窗口 burn rate：fast 1h/2h @ 14.4x（page），slow 6h/3d @ 3x（ticket），公式是标准那套「窗口内错误率 / 允许错误率」。

现象

1. 凌晨 1 小时 P99 抖到 320ms（错误率约 0.7%），按标准公式算 burn rate ≈ 14x，直接 page。但同样 0.7% 错误率发生在上午高峰，对 30 天预算的实际消耗只相当于凌晨的 1/8（因为分母是请求数，不是时间）。
2. 反过来，凌晨误报我们目前只能 mute，但 mute 之后真故障也一起被压掉了；上个月凌晨一次真实的下游超时（持续 40 分钟，烧掉全月预算约 3%）就是被值班同学当成「夜间抖动」关掉的。
3. 团队里两种声音：一种说「错误预算本来就是按请求数算的，公式已经天然按流量加权，不用改」；另一种说「那 page 的『严重度』没加权，凌晨一次 page 和高峰一次 page 被同等对待，值班响应成本完全不对等」。

已尝试的排查与结果

• 按请求数核算：0.7% 错误率 × 80 QPS × 1h ≈ 2000 个 bad request，占 30 天总请求（约 4.5 亿）的 4.4e-6，相当于烧 0.0088 个月预算；高峰同错误率烧 0.07 个月。结论：公式层面确实已按流量加权，预算消耗没问题。
• 卡点在「告警严重度」这一层：14.4x 的阈值对低峰是「时间对齐」的 burn rate，但低峰触发 14.4x 时的绝对预算消耗只有高峰的 1/8，值班按 P1 响应就过度了；如果为低峰单独降阈值，又要维护两套规则。
• 想过把 SLO 本身按流量分层（低峰 SLO 放宽到 500ms），但和产品对齐不了，且 SLO 一旦分时段，对外承诺口径就乱了。

期望得到的答案形态

1. 一个可落地的判定规则：给定 burn rate 数值（如 14x）+ 当时段流量占比（如 12%），怎么定量判断这次告警应该 page / ticket / 静默？希望是有公式或决策表的，不是「看情况」。
2. 如果社区主流做法是「告警权重按流量对齐」，给出一种在 Prometheus / 告警系统里可实现的写法（哪怕是伪代码或表达式），而不是只讲思路。
3. 如果主流做法是「不区分时段、靠值班纪律消化」，也请给一个论证：为什么低峰 14x 的过度响应成本可以接受，以及你们用多久验证过这个成本是可承受的。

引用

• #1858「SLO 多窗口 burn rate 告警抄 Google 14.4x/6x 上线后 30+ 误报」——那篇问的是阈值抬多高，本篇问的是同一阈值在不同流量时段下的严重度怎么对齐，两题互补。
• #1551「告警阈值：静态硬编码 vs 动态基线」——讨论的是基线取法，本篇假设基线已经算好，问的是 burn rate 触发后的告警分级要不要再叠一层流量权重。