滚动发布窗口内的冷启动 P99 尖刺烧掉 SLO 错误预算、反复触发 burn rate 告警：发布期流量到底该不该计入错误预算？有没有可落地的「发布期豁免」机制而不是人肉 mute？

背景

5 年 SRE，最近负责一条核心查询链路：K8s 1.28，Java 17 / Spring Boot 3，JVM 堆 8G，4 副本（maxSurge=1 / maxUnavailable=0，滚动发布），入口稳态 1200 QPS。SLO：P99 < 80ms，30 天窗口，错误预算 0.05%。告警用的是 Google SRE Book 那套多窗口 burn rate：fast 窗口 1h/2h @ 14.4x（page），slow 窗口 6h/3d @ 6x（ticket）。

现象

1. 每次滚动发布，新 Pod 的 readiness 探针通过后（health 接口 200），JIT 还没热、连接池刚建完，头 30–90 秒接到的请求 P99 普遍在 150–400ms，持续 1–2 分钟。
2. 这个尖刺落在 fast 窗口里，burn rate 瞬间飙到 20x+，每次发布必 page。一个月发了 8 次，page 了 7 次（有一次发布时点凑巧窗口内其他错误少，没触发）——全是发布噪声，全是误报。
3. 更糟的是：这 1–2 分钟的尖刺真实消耗了错误预算。月底一算，错误预算的消耗曲线里能清楚看到 8 个发布尖峰，占了月度总消耗的约 35%。也就是说，即使我们把误报压下去了，发布本身也在"合法地"花掉我们的预算，月底预算经常提前烧完，发布被 SLO 政策卡死——这反而逼着团队走"挑凌晨发"的灰色路径。

已尝试的排查与结果

1. 拉长 readiness 预热：给 health 接口加 90s 预热期再返 200。结果：滚动发布总时长拉长，但尖刺仍在——因为流量切过来后前 30s 依然是冷的，readiness 只是把"接流量"的时间推后了，没消除尖刺。
2. AlwaysPreTouch + CDS：JVM 加了 -XX:+AlwaysPreTouch 和类数据共享，冷启动 P99 尖刺从 400ms 降到 ~180ms，但没消除，14.4x 照样触发（这条站内 id=917 那位同学复盘过 AlwaysPreTouch 的页错误机制，方向一致）。
3. 告警端加静态 delay（3 分钟）：治标，而且期间真出故障时也要多忍 3 分钟，oncall 不答应。
4. 发布平台发 webhook 自动 mute 告警 5 分钟：目前线上就是这么跑的，纯人肉规则。问题：mute 窗口是拍脑袋的 5 分钟，发布卡住 20 分钟时反而没有告警；而且 mute 期间如果真是新版本有 bug，我们也看不见——等于把发布期变成了监控盲区，这是我最不满意的。

想请教的具体问题

1. 预算口径：发布窗口内（比如新 Pod readiness 通过 → P99 回落到稳态的区间）的失败请求，业界主流做法是计入还是排除错误预算？如果排除，判定"发布窗口"的信号源用什么（Deployment rollout 事件？发布平台状态机？逐 Pod 的启动时间戳）？
2. 可落地的豁免机制：有没有人做过"发布期 burn rate 豁免"——比如发布平台把 rollout 窗口写成一个 label/annotation/独立指标，Prometheus 规则里对 fast 窗口做分段计算（发布窗口用更低的 burn rate 或不 page，只记 ticket）？求具体实现路径，不要"建议做灰度"这种方向性回答。
3. 一个更根本的取舍：如果发布尖刺本身就该被消灭而不是被豁免，那"把冷启动尖刺压到对 SLO 无感"的目标值你们定在多少（比如发布期 P99 峰值 < 稳态 2 倍且持续 < 60s）？达到这个目标后你们还保留发布期豁免吗？

期望答案形态：给过实际落地方案的同学，最好带上你们的判定信号源、Prometheus 规则片段（或等价实现）、以及"豁免窗口"和"发布卡死时的兜底告警"是怎么设计的。纯理论讨论也可以，但请标明是经验还是推断。