> ## Documentation Index
> Fetch the complete documentation index at: https://doc.lwops.cn/llms.txt
> Use this file to discover all available pages before exploring further.

# 通知配置实践（通用）

<Tip>
  操作手册：[通知配置](https://doc.lwops.cn/notif-config)
</Tip>

**核心结论：** 通知配置的关键是把告警准确路由到责任团队，并按业务和等级选择提醒强度，让重要告警不被淹没，普通告警不打扰值班。

## 1. 适用场景

适用于业务系统多、责任分工明确、存在共享资源的客户环境。告警已经能够产生，但"发给谁、怎么发、发多急"缺少统一规则。

| 环境特点    | 典型表现                            | 通知配置如何解决             |
| ------- | ------------------------------- | -------------------- |
| 业务系统多   | 不同业务由不同人员负责，告警统一发送后容易无人认领       | 按业务负责人和资源类型建立通知对象    |
| 共享服务多   | 多个业务共用数据库、FTP 等资源，底层告警和业务告警混在一起 | 按业务标签和监控项拆分告警路由      |
| 告警等级差异大 | 核心故障和磁盘预警进入同一个群，重要告警被刷屏淹没       | 按等级配置短信、微信、邮件等不同提醒强度 |
| 值班响应有要求 | 夜间和交易时段故障需要快速触达负责人              | 重要告警强提醒，未确认告警升级转工单   |

## 2. 为什么要建设通知配置？

<Danger>
  **通知一锅端，故障响应全靠运气**
</Danger>

监控上线初期，告警量会很快从每天几十条膨胀到上千条。如果没有精细化的通知设计，会出现这些典型场景。

* DBA 每天被 200+ 条告警轰炸，其中 80% 是核心业务无关的，慢慢"选择性忽略" → 重要告警被淹没
* 凌晨 3 点一条"磁盘剩余 20%"短信把值班人员吵醒 → 告警疲劳导致麻木
* 共享数据库异常，所有业务负责人同时收到告警 → 互相踢皮球，无人认领
* 没人看、没人回：告警缺少升级机制，从故障发生到响应超过30分钟，未确认的问题容易停留在群里无人跟进。

<Warning>
  "一个群接收所有告警"的方式，是通知混乱的根源！
</Warning>

## 3. 通知配置最佳实践

**核心设计思路：** 按业务建分类、按等级建规则。每条规则 = 约束类型 + 接收人 + 通知媒介+告警等级，让每条告警只到达对应负责人的对应渠道。

### 3.1 建立通知规则分类

通知规则多了之后直接堆在根目录，找不到、改不动。先建分类树，相当于给通知规则建立目录结构。分类只按"业务"一个维度划分，简单清晰，后续所有规则都挂在分类下面，便于按业务、按等级批量维护。

> 金融行业示例，可按实际业务调整

<img src="https://mintcdn.com/lerwee/5Z8OzhWB0XCCgTnW/images/tongzhiguizeshu.png?fit=max&auto=format&n=5Z8OzhWB0XCCgTnW&q=85&s=3402b3f43902c5281921ef90856c809e" alt="通知规则树" width="2864" height="1536" data-path="images/tongzhiguizeshu.png" />

### 3.2 创建告警规则

每个业务分类下，按告警等级建立多条规则。告警等级是通知规则最重要的约束，决定了告警的紧急程度和通知渠道强度。

告警等级标准划分（与触发器严重性一一对应）：

| 告警等级  | 业务含义                | 推荐媒介组合   |
| ----- | ------------------- | -------- |
| P0 紧急 | 核心交易宕机、数据库主库故障、主备切换 | 短信+微信+钉钉 |
| P1 严重 | 重要业务异常、容量接近阈值、主从延迟高 | 邮件+短信+微信 |
| P2 次要 | 一般性能告警、资源使用率偏高      | 邮件+微信    |
| P3 警告 | 提示性告警、配置变更          | 仅邮件      |
| P4 信息 | 状态通知、巡检结果           | 仅邮件      |

**进阶用法：**

除告警等级外，约束类型还支持标签、时段、维护期过滤等组合，可实现共享资源精细化分时段不同强度（夜间走值班排班）等场景；

升级机制也可通过多条规则叠加实现，如 P2 告警 15 分钟未确认自动升级发短信，30 分钟未确认升级转工单。

<Note>
  建议：建好一条规则后，可以克隆到其他业务分类下，只改触发主机组、接收用户组和媒介组合，能省 80% 重复工作。
</Note>

### 3.3 通知规则配置示例

<img src="https://mintcdn.com/lerwee/5Z8OzhWB0XCCgTnW/images/tongzhiguizepeizhishili.png?fit=max&auto=format&n=5Z8OzhWB0XCCgTnW&q=85&s=cc358394e2153a9520838bebe4ca39b4" alt="通知规则配置示例" width="906" height="1504" data-path="images/tongzhiguizepeizhishili.png" />

**规则含义：** 当核心交易业务产生标题含「宕机」的告警时，触发紧急告警通知，初始通知对象：张三、李四。若告警产生 10 分钟仍未确认且未恢复，告警自动升级推送至李四、陈威、王五。

## 4. 典型应用场景

### 场景一：共享数据库精细化告警

原有问题： 核心交易、报表、OA 共用 MySQL 集群，数据库指标异常后统一发给 DBA，DBA 还要判断该通知哪个业务方。

解决：

* 为数据库监控项打业务标签，例如 tag: business=trade、tag: business=report
* 触发器按“指标阈值 + 业务标签”分流
* 告警动作按标签发送到交易运维组或数据团队。

<img src="https://mintcdn.com/lerwee/5Z8OzhWB0XCCgTnW/images/changj01.png?fit=max&auto=format&n=5Z8OzhWB0XCCgTnW&q=85&s=5b2879296036280ce5e4a5e5e9c76a88" alt="场景01" width="1912" height="948" data-path="images/changj01.png" />

<img src="https://mintcdn.com/lerwee/5Z8OzhWB0XCCgTnW/images/changj011.png?fit=max&auto=format&n=5Z8OzhWB0XCCgTnW&q=85&s=161a10d2e3c7bb467829937179c4a8bc" alt="场景011" width="1912" height="948" data-path="images/changj011.png" />

### 场景二：业务迁移后的通知调整

原有问题： 业务迁移或下线后，如果通知规则绑定在单台主机上，需要逐台调整，容易漏配。

解决： 通知规则绑定业务目录、业务标签或者业务分组；业务整体迁移时，只调整资源和目录归属。

效果： 通知规则随业务批量生效，降低迁移后的漏告警和误告警风险。

<img src="https://mintcdn.com/lerwee/5Z8OzhWB0XCCgTnW/images/chanj02.png?fit=max&auto=format&n=5Z8OzhWB0XCCgTnW&q=85&s=b9ec0f5f247e8d70966764547bd586ad" alt="场景02" width="2864" height="1536" data-path="images/chanj02.png" />