通知策略是云监控 2.0 告警中心的核心调度单元，负责将告警规则与外部集成产生的可观测事件进行订阅、降噪、路由、生命周期管理与自动化行动。本文沉淀云监控 2.0 通知策略的常用最佳实践，覆盖日常配置思路、典型业务场景，帮助您以最少的策略数量满足复杂的通知诉求。
背景信息
当用户通过告警规则或第三方集成持续产生大量告警事件后，希望及时收到通知，但不同业务、不同等级、不同时段的通知诉求差别很大；同时还需要对告警进行认领、屏蔽、升级等生命周期管理。云监控 2.0 通知策略针对这些诉求提供了统一抽象：
按需精准订阅：通过事件订阅条件（任意 / 所有 / 复合表达式）从所有事件中过滤出真正关心的事件。
合并降噪：通过指定降噪字段将同维度事件聚合为一个告警，减少风暴打扰。
路由分派：通过路由规则把同一事件按照标签维度分派到不同的通知对象与渠道。
生命周期：覆盖恢复通知、自动恢复、重复通知、升级策略，避免漏报与过度打扰。
行动集成：在告警触发或恢复时自动执行 Webhook、函数计算、ITSM 等行动。
AI 辅助：内置数字员工连接，自动提供根因分析（RCA）。
本文中事件指可观测事件（Observability Event），是告警规则或集成产生的结构化数据；问题指经过通知策略合并降噪后用于通知和管理的实体。一条通知策略可以被多条告警规则共享，修改后立即对所有引用规则生效
通知策略处理流程
使用通知策略的前提是已经准备好了告警事件的来源。目前云监控2.0的告警事件有三种来源：
来源类型 | 说明 |
云监控告警规则 | 云监控 2.0 默认集成自身产生的告警规则，包括云产品监控、Prometheus、应用监控、AI Agent观察、用户体验监控等多种规则类型。规则触发后产生的事件可被通知策略订阅。 |
事件集成 | 支持将自建 Prometheus、Grafana、Zabbix、Skywalking、自定义 Webhook 等第三方事件接入告警中心，事件接入后即可被通知策略订阅。 |
云监控1.0及SLS告警事件 | 云监控1.0及SLS的告警事件，将自动写入至云监控2.0事件中心。 |
集成：告警管理支持第三方产品的集成，云监控2.-支持将自建Prometheus、Grafana、Zabbix、Skywalking等产品的事件快速发送到云监控2.0事件中心进行管理，在配置好集成后，来自集成的事件可以被通知策略匹配到。
事件订阅
事件订阅是通知策略的入口。每条事件携带结构化字段（Label），例如告警等级、告警来源、服务名称、资源类型、集群名称、命名空间、自定义标签等。事件订阅按字段进行过滤，仅匹配命中的事件才会进入后续处理。
匹配模式 | 说明 | 推荐场景 |
任意 | 事件满足任意一条订阅条件即命中（OR）。 | 多种告警都需要发送给同一个对象，或多源接入同一团队。 |
所有 | 事件需同时满足全部条件（AND）。 | 面向特定环境 + 特定团队 + 特定等级的精细化订阅。 |
复合 | 通过编号自定义表达式，例如 | 需要同时支持两个独立子条件分支的复杂筛选。 |
通知配置（合并降噪 / 路由规则 / 通知模板）
通知配置是通知策略的核心，由三个子模块组成，按顺序执行：
合并降噪：选择一个或多个 Label 作为降噪字段，相同字段值的事件被聚合为一个告警。降噪字段是后续路由分派的前置依赖。
路由规则：基于聚合后的告警按标签维度分派到具体的通知对象（联系人 / 联系组 / 值班表）和通知渠道。支持多条规则按顺序匹配，规则之间是非互斥的。
通知模板：分别为不同渠道（电话 / 短信 / 邮箱 / 钉钉 / 飞书 / 企业微信）选择内容模板，未配置的渠道使用系统默认模板。
生命周期管理（恢复 / 自动恢复 / 重复 / 升级）
本步骤决定告警在没有恢复或没有响应时的后续行为：
配置 | 建议 |
恢复通知 | 除非事件本身不重要，否则建议开启，让相关人员感知状态变化。 |
自动恢复 | 规则本身能产生恢复事件时选择"告警不会自动恢复"；事件源不会主动恢复（如自定义 Webhook）时选择"定时自动恢复"。 |
重复通知 | P0/P1 等高优先级告警建议开启重复通知，避免漏看；P3/P4 不建议开启。 |
升级策略 | 关键业务建议同时配置升级策略，超时未认领时自动升级到值班长 / 主管。 |
行动集成
行动集成默认关闭。开启后可在告警触发或恢复时分别执行行动，常见类型包括 Webhook（钉钉 / 飞书 / 企业微信群机器人）、HTTP 回调、函数计算、ITSM 工单等。该模块用于实现告警的自动化闭环（如自动扩容、自动重启、工单自动创建/关闭）。
通知策略设计原则
在动手配置之前，建议先按照以下原则做整体规划，可以有效减少后续维护成本。
策略数量与"通知对象群体数"对齐：不要按照告警规则数量来创建通知策略。建议先梳理"哪些人接收哪类告警"，每一种通知对象群体（例如 SRE 团队、业务 A 钉钉群、生产值班表）对应一条通知策略，然后通过事件订阅条件挑选事件。
按"等级 × 域 × 时段"三维度规划：常见的拆分维度是：告警等级（P0/P1 vs P2/P3）× 业务域（命名空间 / 服务名 / 标签）× 时段（工作时间 vs 非工作时间）。通过路由规则的"路由条件 + 生效时间"组合，往往一条通知策略就能覆盖多种组合，无需为每个组合单独建策略。
永远准备一条"兜底路由"：在路由规则列表的最后追加一条"路由条件 = 不限"的兜底规则，指向 SRE 团队或集中收件人。即使前面所有路由都未命中，也能保证事件不会被静默丢失。
最佳实践新增告警规则时只调整规则本身，无需重复维护通知策略；当人员或团队发生变化时，只调整通知策略中的通知对象，不动告警规则。这是云监控 2.0 通知策略与告警规则多对多解耦设计的核心价值。
场景一：告警发送到个人并认领、处理
个人开发或小团队的基础场景
将集群下若干 Prometheus 告警规则产生的事件发送到一个钉钉群，群内成员通过 IM 卡片直接认领、屏蔽、关闭告警。
需求拆解
已经接入Prometheus（或自定义集成），并配置了若干告警规则，例如
容器CPU告警-测试、容器内存告警-测试。希望
alert-dev集群下的这两条规则产生的事件全部发到团队钉钉群，其他集群的告警不要发过来。每条规则独立通知，每条告警在持续期间每 5 分钟提醒一次。
配置步骤
在通知管理 > 通知对象中创建钉钉群机器人或联系人。详情参见通知对象。
事件订阅：精准过滤目标集群。
匹配模式选择所有，添加条件以排除其他集群与其他规则的事件：
cluster_name等于alert-dev。alert_nameIN(容器CPU告警-测试, 容器内存告警-测试)。
合并降噪：按规则维度独立成组。
降噪字段添加
_cms_rule_id（即按告警规则 ID 分组）。两条规则的事件会形成两个独立的问题，各自有独立的触发、通知、恢复生命周期。路由规则：单条路由直达钉钉群。
新增路由规则：路由条件 = 不限；通知对象类型 = 机器人 / 钉钉机器人；目标对象 = 步骤 1 创建的对象；通知方式勾选"钉钉"。
重复 / 恢复策略。
恢复通知：开启；自动恢复：告警不会自动恢复（依赖规则本身的恢复事件）；重复通知：按间隔重复10 分钟。
保存策略后，等待告警事件产生（或通过测试事件触发），即可在钉钉群收到告警卡片。
在钉钉群中处理告警
钉钉卡片下方提供认领 / 屏蔽 / 解决 / 关注 / 推送工单等操作按钮。第一次操作需要绑定已注册至云监控2.0通知对象的手机号，并在卡片内验证码校验。
场景二：告警发送到多个不同的业务团队
SRE 与多业务团队按域分发
SRE 团队统一配置告警规则，但需要按业务团队将告警分派到不同钉钉群与联系组，并在测试 / 生产环境采用不同的通知频率。
需求拆解
组织包含 SRE 团队与三个业务团队（A、B、C），分别在其相关资源配置了
team-a、team-b、team-c三个tag。集群分为测试
cluster-dev与生产cluster-prod-1、cluster-prod-2。测试环境告警仅发送到对应业务团队钉钉群，频率较低（30 分钟重复）。
生产环境告警同时发送给 SRE 团队（电话 / 短信 / 钉钉）与对应业务团队（钉钉），频率较高（5 分钟重复）。
解决方案
通常情况下，这种复杂的环境需要为每个团队 × 每个环境分别建一条策略。云监控 2.0 通过多路由规则 + 路由条件，可在每种环境一条策略内完成全部分派，结构更清晰。实现用 2 条策略 + 多路由规则替代多条策略。
策略 1：测试环境策略（cluster-dev）
阶段 | 关键配置 |
事件订阅 | 所有： |
合并降噪 | 降噪字段： |
路由规则 | ① 路由条件 |
重复 / 升级 | 30 分钟重复通知；不配置升级策略。 |
策略 2：生产环境策略（cluster-prod-1 / cluster-prod-2）
阶段 | 关键配置 |
事件订阅 | 任意： |
合并降噪 | 降噪字段： |
路由规则 | ① 路由条件 = 不限，对象 = SRE 联系组（电话 + 短信）+ SRE 钉钉群（钉钉） |
重复 / 升级 | 5 分钟重复通知；可叠加升级策略（详见场景三）。 |
云监控 2.0 同一条事件可同时命中多条路由规则且全部生效（非互斥），因此 SRE 与业务团队可以在同一条策略内通过两条规则并行分派，无需建多条策略。
场景三：告警按照轮值人员和应急响应机制进行通知
值班轮换 + 应急升级
工作时段由 A/B/C 三人每两天一轮值班，非工作时段由 D 值班；正常情况下短信通知，10 分钟未认领升级电话，20 分钟未认领电话通知主管。
配置步骤
创建联系人
分别创建联系人 A、B、C、D 与"团队主管"，并提前在通知对象中配置好钉钉群。
创建值班表
在通知管理 > 值班表中创建：
班次 1：成员 A、B、C，每天 09:00-18:00 接收告警，每 48 小时轮换；
班次 2：成员 D，每天 18:00-09:00 接收告警，不轮换。
创建升级策略
在通知管理 > 升级策略中创建升级链：
第 1 级：10 分钟未认领，通知人选值班表，电话类型通知；
第 2 级：20 分钟仍未认领，通知人选团队主管，电话类型通知。
创建通知策略
事件订阅与合并降噪按场景一/二的方式配置；路由规则中通知对象类型选择"值班表"，目标对象选刚才创建的值班表；通知方式仅勾选"短信"；在升级策略下拉中选择步骤 3 创建的升级策略。
升级策略与重复通知可以同时启用：升级策略按"等级"扩散通知对象，重复通知按"时间"持续提醒原对象，两者独立工作互不冲突。
场景四：行动集成自动化闭环
告警触发 / 恢复时自动执行外部行动
告警触发时自动调用函数计算扩容；告警恢复时自动关闭 ITSM 工单。
典型行动模式
触发时机 | 典型行动 |
触发时行动 |
|
恢复时行动 |
|
配置步骤
在集成管理中提前创建好行动目标（Webhook、函数计算、HTTP 回调等），这是行动集成的前置条件。
编辑通知策略 > 行动集成，开启"行动集成"开关。
在触发时行动区域选择已创建的行动目标，可添加多条；在恢复时行动区域配置恢复行动。
保存策略后，可结合"集成管理 > 调用日志"查看每次行动的执行结果与失败原因。
请为行动目标设置幂等接收逻辑，避免因网络重试或重复通知造成重复扩容、重复创建工单等副作用。涉及变更类操作建议先通过测试通知策略灰度验证。
反模式与排查
下面是项目实战中较常见的几类配置反模式，建议在评审通知策略时对照检查。
反模式一：把告警规则和通知策略 1:1 绑死
不推荐
每条告警规则单独维护一条通知策略。
规则数增多后通知策略爆炸式膨胀，维护成本高。
调整接收人需要逐条修改策略。
推荐做法
按"接收人群体"维度建立通知策略，一条策略服务一类对象。
新增告警规则只调整事件订阅条件即可纳入。
调整接收人或频率只动通知策略，不动规则。
反模式二：所有告警都开启 1 分钟重复通知
不推荐
不分等级一律 1 分钟重复，造成大量打扰。
低等级告警淹没真正紧急的 P0/P1。
处理人员逐渐忽略所有通知。
推荐做法
按等级差异化配置：P0/P1 5 分钟重复 + 升级策略，P2 30 分钟重复，P3/P4 不重复。
对夜间使用更长的重复间隔，避免无效叫醒。
结合数字员工 RCA 在第一次通知中提供更多决策信息。
反模式三：只配静默不配兜底路由
不推荐
仅依赖静默规则屏蔽噪音，没有兜底路由。
静默规则误配后所有告警都会被吃掉。
新增的资源 / 命名空间没有对应路由时无人接收。
推荐做法
每条通知策略都保留一条"路由条件 = 不限"的兜底路由，指向 SRE 收件箱。
静默规则仅用于明确已知噪音，使用截止时间防止永久静默。
定期巡检通知策略命中率，发现长期不命中的路由及时下线。
常见问题
一条通知策略最多支持多少条路由规则？
单条通知策略支持的路由规则数量较多，足以覆盖大多数场景。建议按业务域拆分到不同策略中，避免单条策略路由规则过多导致维护困难（实际配额以控制台限制为准）。
通知策略的路由规则与告警规则的"通知策略"字段是什么关系？
告警规则通过引用通知策略获得通知能力（一条告警规则可引用多条通知策略）；通知策略内部的路由规则负责把命中的事件分派到具体的通知对象。两者是上下游关系，分别解决"哪些规则用这条策略"与"事件命中后发给谁"。
在云监控 2.0 中如何实现"工作日发团队 A、周末发值班表 B"？
在同一条通知策略中创建两条路由规则：路由规则 1 生效星期勾选"周一至周五"，对象选团队 A；路由规则 2 生效星期勾选"周六、周日"，对象选值班表 B。无需建多条通知策略。
升级策略和重复通知冲突吗？
不冲突。重复通知按固定间隔向原通知对象持续提醒；升级策略在指定时间未认领时通知更高级别人员。建议高优先级告警同时启用，确保不漏。
如何为不同环境（开发 / 测试 / 生产）配置不同的通知策略？
推荐每种环境一条通知策略，事件订阅按 cluster_name 或自定义环境标签过滤。环境内的不同业务团队、不同时段差异通过该策略内的多条路由规则与生效时间实现，无需为每个团队再单独建策略。
通知策略修改后多久生效？
保存后立即对所有引用该策略的告警规则生效，无需重新关联。请谨慎评估修改对共享该策略的所有告警规则的影响。