用好 notification policy 是实现企业级告警分层、按责派发的核心，需基于标签精准路由，构建“严重性>业务域>环境”三级策略链，绑定差异化 contact point 与模板化消息，并通过测试和灰度机制保障上线可靠性。
用好 Notification Policy 是实现企业级告警分层、按责派发的核心。它不是简单地把告警发给某个人，而是基于标签（labels）做精准路由，让不同系统、不同严重等级、不同业务线的告警自动流向对应负责人或值班组。
明确告警标签体系是前提
所有告警规则必须打上可区分、可组合的标签，比如：
-
service：如
payment、user-center、order-api -
severity：如
critical、high、medium、low -
team：如
finance-sre、core-platform、data-engineering -
env：如
prod、staging（非生产环境通常不走强通知）
这些标签需在 Alert Rule 的 Labels 区域统一配置，不能只靠 Rule Name 或 Annotations 区分——Policy 只认 labels 字段。
设计多级路由策略链
Notification policies 支持嵌套和优先匹配，推荐按“严重性 > 业务域 > 环境”三级递进：
-
顶层兜底策略（Root policy）：设置为
critical且env=prod的告警，立即触发电话+钉钉+短信，并升级至 on-call 轮值表 -
中间层业务策略（Specific routing）：匹配
team=finance-sre的所有告警，发到该团队专属钉钉群 + 企业微信机器人；同时对service=payment的high告警加一条静默期（例如 5 分钟内重复不发） - 底层默认策略：未匹配任何条件的告警，仅推送到内部 Slack #alerts-all 频道，供 SRE 日常巡检
注意：策略按从上到下顺序匹配，第一个完全匹配的策略生效，后续不再继续。
绑定 Contact Point 并启用模板化消息
每个策略节点必须指定一个或多个 Contact Point，但关键在于——不同策略应关联不同 Contact Point，而每个 Contact Point 可独立绑定 Notification Template：
- 给
critical策略绑定名为cp-pagerduty-webhook的 Contact Point，其模板突出显示恢复链接、影响范围和 SLA 违反提示 - 给
finance-sre策略绑定cp-finance-dingtalk，模板中自动插入财务系统当前 TPS、最近 3 次失败交易 ID - 给默认策略绑定
cp-slack-internal，模板精简，仅含告警名、状态、发生时间、跳转链接
模板支持 Go text 语法，可安全引用 .Alerts.Firing、.CommonLabels.service、(index .Alerts 0).Annotations.description 等字段，避免硬编码。
验证与灰度上线机制
策略上线前务必测试，Grafana 提供 Test rule 和 Test notification 功能：
- 在 Notification Policies 页面，点击某条策略右侧的 Test，输入模拟告警 JSON（含你定义的全部 labels），看是否命中预期 Contact Point
- 首次上线时，先将新策略设为 Continue matching（即匹配后仍继续往下找），并把动作设为发送测试群，确认无误后再关闭 Continue、切到正式通道
- 建议配合
team=xxx-test标签创建灰度告警规则，只对小范围服务启用新策略，观察 48 小时再全量推广
