服务数从 5 个扩到 15 个后 on-call 每周被叫醒 10+ 次，告警到行动比怎么算、怎么降？

背景

15 年 SRE，最近接手一个 8 人小团队，他们从 5 个微服务扩到了 15 个。告警体系是去年搭的——Prometheus + Alertmanager + 飞书 webhook，规则 47 条。当时 5 个服务的时候 on-call 一周被叫醒 2-3 次，大家觉得"刚刚好"。扩到 15 个服务后，on-call 一周被叫醒 10-15 次，有人开始抱怨"又被叫醒"，但每次去看了，真正需要动手处理的其实只有 3-4 次，剩下的大概率是阈值太紧、服务扩容/缩容时的抖动、或者同一个根因触发了 3-5 条不同指标告警。

已尝试的排查

1. 把告警分成 P0/P1/P2 三级——但分完之后 P2 那堆照样发飞书，on-call 还是被叫醒，因为飞书群通知不分级别。
2. 把部分阈值从 1 分钟调到 5 分钟——效果有限，有些告警本质上是"瞬时尖刺"，5 分钟窗口反而错过了真正的异常。
3. 讨论过做告警聚合（同一个 pod 的 CPU / Memory / 网络合并成一条）——但 Alertmanager 的 group_by 只能按 label 聚合，跨指标的合并需要自己写逻辑，团队没人愿意接这个活。

卡点

我想知道的不是"要不要降噪"（答案显然是要），而是两个具体的问题：

1. 怎么量化"告警疲劳"？ 我目前的想法是算「告警到行动比」= 真正需要 on-call 动手的告警数 / 总告警数，目标是 ≥ 50%。但我不确定这个比例在业界有没有共识，或者大家用什么别的指标（比如人均每周被叫醒次数 ≤ N 次、告警平均处理时长 ≤ M 分钟）。

2. 降噪的决策框架是什么？ 47 条规则里哪些该降级（P0→P2）、哪些该合并、哪些该直接删？我看到过 Google SRE 的 "alert on symptoms not causes"，但落到具体规则上还是靠感觉。有没有人分享过一套可操作的 checklist 或者评分标准？

期望的回答形态

最好是有人贴出他们团队的实际规则清单（脱敏后），标注每条的级别、触发条件、聚合方式，以及"这条为什么保留 / 这条为什么删"的决策理由。纯理论（"要做 SLO-based alerting"）我大概能想到，但落到 47 条具体规则上怎么逐条过，这才是我卡住的地方。