1. 适用场景
适用于业务系统多、责任分工明确、存在共享资源的客户环境。告警已经能够产生，但”发给谁、怎么发、发多急”缺少统一规则。2. 为什么要建设通知配置？
通知一锅端，故障响应全靠运气
- DBA 每天被 200+ 条告警轰炸，其中 80% 是核心业务无关的，慢慢”选择性忽略” → 重要告警被淹没
- 凌晨 3 点一条”磁盘剩余 20%“短信把值班人员吵醒 → 告警疲劳导致麻木
- 共享数据库异常，所有业务负责人同时收到告警 → 互相踢皮球，无人认领
- 没人看、没人回：告警缺少升级机制，从故障发生到响应超过30分钟，未确认的问题容易停留在群里无人跟进。
3. 通知配置最佳实践
核心设计思路： 按业务建分类、按等级建规则。每条规则 = 约束类型 + 接收人 + 通知媒介+告警等级，让每条告警只到达对应负责人的对应渠道。3.1 建立通知规则分类
通知规则多了之后直接堆在根目录，找不到、改不动。先建分类树，相当于给通知规则建立目录结构。分类只按”业务”一个维度划分，简单清晰，后续所有规则都挂在分类下面，便于按业务、按等级批量维护。金融行业示例，可按实际业务调整
3.2 创建告警规则
每个业务分类下，按告警等级建立多条规则。告警等级是通知规则最重要的约束，决定了告警的紧急程度和通知渠道强度。 告警等级标准划分（与触发器严重性一一对应）：
进阶用法：
除告警等级外，约束类型还支持标签、时段、维护期过滤等组合，可实现共享资源精细化分时段不同强度（夜间走值班排班）等场景；
升级机制也可通过多条规则叠加实现，如 P2 告警 15 分钟未确认自动升级发短信，30 分钟未确认升级转工单。
建议：建好一条规则后，可以克隆到其他业务分类下，只改触发主机组、接收用户组和媒介组合，能省 80% 重复工作。
3.3 通知规则配置示例
4. 典型应用场景
场景一：共享数据库精细化告警
原有问题： 核心交易、报表、OA 共用 MySQL 集群，数据库指标异常后统一发给 DBA，DBA 还要判断该通知哪个业务方。 解决：- 为数据库监控项打业务标签，例如 tag: business=trade、tag: business=report
- 触发器按“指标阈值 + 业务标签”分流
- 告警动作按标签发送到交易运维组或数据团队。
场景二：业务迁移后的通知调整
原有问题： 业务迁移或下线后，如果通知规则绑定在单台主机上，需要逐台调整，容易漏配。 解决： 通知规则绑定业务目录、业务标签或者业务分组；业务整体迁移时，只调整资源和目录归属。 效果： 通知规则随业务批量生效，降低迁移后的漏告警和误告警风险。