跨城链路基线 RTT 本身就抖（5–30ms 波动），告警阈值到底怎么定才不漏报也不刷屏？

【背景】 我是网络工程师，负责一组跨城双活数据中心（华北 ↔ 华东，单程物理延迟约 18ms，走运营商专线 + 自研 SD-WAN 兜底）。核心业务是同步复制 + 在线交易，对链路劣化非常敏感：单程 RTT 基线中位数约 25–35ms（RTT 含来回），但天然抖动很大——同一时刻不同探针、不同时段，RTT 在 25ms–90ms 之间波动是常态，偶发 150ms+ 的长尾在业务高峰期（晚 20:00–24:00）几乎每天都有。

【现象 / 卡点】 当前告警规则是「RTT > 80ms 持续 3 分钟」+「丢包 > 0.1% 持续 2 分钟」两条硬阈值。跑了半年，问题很明显：

1. 漏报：有一次真实劣化（运营商侧设备异常，RTT 基线从 35ms 抬到 65ms、持续 40 分钟），因为没破 80ms 阈值，一条告警都没出，是客户投诉后回看才发现的；
2. 误报：晚高峰天然长尾，80ms 阈值每天平均触发 2–3 次，值班同学已经"脱敏"，真正异常混在里面没人当回事。

【已尝试的排查与结果】

• 换过告警引擎（Zabbix → Prometheus + Alertmanager），规则本身重写过三版，问题依旧；
• 试过用「环比突增」替代绝对阈值（RTT > 基线 P50 × 3），结果基线本身抖，P50 也跟着抖，误报更严重；
• 试过 eBPF（bcc 的 tcpretrans）抓内核重传做旁证，重传计数能抓到，但告警侧没有把 RTT 劣化和重传关联起来，还是两条独立的规则；
• 拨测侧从 1 条探针加到 4 条（不同机房出口），多探针多数表决能压掉一部分瞬时毛刺，但「基线整体抬升」这种慢劣化依然抓不到。

【期望得到的答案形态】

1. 你们团队对「基线抖动大」的链路，告警规则具体怎么写的？能给一段 PromQL / 伪代码最好；
2. 是用动态基线（如 7 天同时段分位数、Holt-Winters、STL 分解）还是多指标联合（RTT + 丢包 + 重传 + 队列延迟）？
3. 慢劣化（基线抬升但没破绝对阈值）你们怎么兜底？有没有周期性"链路体检"的机制？
4. 告警分级：什么情况打电话、什么情况只进工单？

我这边环境：Linux kernel 5.15，Prometheus 2.x + Alertmanager 0.2x，SD-WAN 控制器有北向 API 能拉每条隧道的 RTT/丢包/抖动历史。