冷启动噪声污染灰度信号：2% 金丝雀前 5 分钟 P99 被 JIT/连接池预热虚高 3 倍，怎么把「预热期」从自动回滚判据里干净地剔除？

背景 我们后端 30+ 个 Java 微服务（Spring Boot 3 + HikariCP + Dubbo），发布走 2% → 10% → 50% → 100% 金丝雀，每档自动回滚判据是「灰度组 P99 > 对照组 2 倍，且绝对值 > 80ms，连续 2 个 30s 窗口」。上周一次纯重构（无 SQL 变更、无依赖变更）触发了 2% 档自动回滚，事后看是误伤。

现象

• 灰度组前 5 分钟 P99 约 420ms，对照组稳定 110ms，比值 3.8 倍，判据命中 → 流水线自动回滚。
• 把回滚关掉手动观察，灰度组 P99 在 第 6 分钟回落到 105ms，之后与对照组完全重合（差 < 5ms）。
• 抓了那个 5 分钟窗口的火焰图：热点集中在 JIT C2 还没升满、HikariCP 池子 5→20 的扩张、以及 Dubbo 消费者建连 + 订阅。没有一条业务代码路径变慢。
• 更糟的是：因为回滚了，这次「新机器」又得重新冷启动，下次发布还会再撞一次。

已尝试的排查与结果

1. 把观察窗口从 2 分钟拉到 10 分钟：缓解了，但有一次真实回归（连接池 maximumPoolSize 被误调小）恰好在第 7 分钟才显形，10 分钟窗口直接漏报了——拉长窗口和冷启动噪声是两个方向相反的旋钮，拧不动。
2. 按「请求级」做 warmup 标记：在网关给前 N 个请求打标，判据聚合时剔除。问题是我们不知道「前 N 个」的 N 到底是多少，每个服务、每种依赖（DB/MQ/下游 RPC）冷启动时长都不一样，写死 N 很脆。
3. 预热脚本：发布前跑一次 curl 打 200 个请求触发 JIT + 建连。JIT 确实好了，但 HikariCP 的池子扩张和 Dubbo 订阅还是把前 3 分钟 P99 顶起来了——预热脚本能覆盖 JIT，覆盖不了连接池。
4. 对比 arthas 在线 dump 的 JIT 状态：确认是 C2 没升满，但「C2 升满」这个状态没有一个可以直接读、可直接进判据的指标。

期望得到的答案形态

• 一个能落地的「预热期剔除」方案：判据聚合时怎么定义「这段流量属于冷启动」——是固定时间窗、请求数、还是某个可观测信号（如 arthas 读 JIT 状态 / HikariCP pool.fill 完成事件）作为「预热结束」的边界？
• 冷启动误伤和真实慢启动回归（比如真的把 maximumPoolSize 改小了）在指标上到底长什么样？有没有可区分的特征（斜率、收敛曲线、依赖侧信号）？
• 你们团队（用 Argo Rollouts / Flagger / 自研）在 2%–5% 小流量档是怎么处理「样本量太小 + 冷启动噪声」这个双重矛盾的？有没有真实配置可以贴？

相关参考（站内已读到的）：

• 沈若衡-756《2% 灰度看 48 小时「一切正常」，全量后 30 分钟被工单打穿：一套可直接抄的灰度护栏指标与自动回滚配置》——讲了大盘指标在 2% 下不报警，但没提冷启动噪声这一层。
• 顾星河-584 的提问（前端灰度回滚判据）——同类矛盾在前端侧的体现，想看看服务端侧有没有更干净的解法。