4. 报警通知机制：邮件、短信、电话、钉钉/企微/飞书机器人
报警通知，说白了就是故障发生后，怎么把消息准确、快速地传递到该知道的人手里。我见过不少团队，监控系统做得挺漂亮，但通知环节一塌糊涂——要么半夜被无关的邮件轰炸，要么核心故障没人知道。嗯，这里面的门道其实不少。
4.1 通知渠道的选型与定位
不同的通知渠道，有不同的适用场景。我个人习惯把它们分成三个梯队：
| 渠道 | 适用场景 | 实时性 | 干扰程度 |
|---|---|---|---|
| 邮件 | 非紧急通知、日报、周报、审计记录 | 低（分钟级） | 低 |
| 短信 | 核心指标异常、值班人确认 | 中（秒级） | 中 |
| 电话 | P0/P1级故障、长时间未确认 | 高（即时） | 高 |
| 钉钉/企微/飞书 | 日常告警、协同处理、图文详情 | 中（秒级） | 中 |
你想想看，如果每个小抖动都打电话，运维团队不用干别的了，光接电话就行。所以，分级通知是核心原则。
4.2 邮件通知：最基础也最容易被忽视
邮件虽然慢，但它有两个不可替代的优势：可追溯和内容完整。我建议把邮件作为所有告警的“归档通道”。
邮件通知的最佳实践：
- 使用独立的告警邮箱，别用个人邮箱，方便过滤和归档
- 邮件标题要包含：
[告警级别] [服务名] [故障摘要] - 正文要包含：故障时间、影响范围、当前状态、处理人、相关链接
- 别发HTML格式的复杂邮件，纯文本最可靠
我曾经遇到过一个案例：某团队把所有告警都发到同一个邮箱，结果邮件堆积了几万封，真正重要的故障被淹没了。后来我们改了策略——P3以下级别的告警才发邮件，P0/P1直接走电话+机器人。
4.3 短信通知：轻量但可靠
短信的优势在于普适性——任何手机都能收到，不需要装App。但缺点也很明显：有字数限制（通常70个汉字），而且成本不低。
我个人习惯把短信用于值班人确认和核心指标异常。比如磁盘使用率超过90%，或者QPS跌了一半，这种级别的告警才值得发一条短信。
小技巧：短信内容要精简到极致。我常用的模板是：
【XX公司】P1告警：订单服务响应超时（5s），影响用户下单，请立即处理。值班人：张三 138xxxx控制在70字以内，确保一条短信能说完。
4.4 电话通知：最后的防线
电话通知是“核武器”，不能轻易用，但必须要有。我见过太多团队，P0级故障发生了，值班人没看手机、没看钉钉，结果故障持续了半小时没人处理。
电话通知的触发条件一般是：
- P0/P1级故障持续超过5分钟未确认
- 短信通知后3分钟无人响应
- 核心服务完全不可用
注意：电话通知一定要做防骚扰设计。我曾经遇到过半夜电话轰炸——一个故障触发了20次电话通知，值班人直接关机了。后来我们加了“同一故障30分钟内最多打3次电话”的逻辑。
电话通知的实现方式，我推荐用语音合成（TTS）或者预录语音。TTS灵活但听着生硬，预录语音效果好但维护成本高。我个人偏向TTS，因为故障类型太多，不可能每个都预录。
4.5 钉钉/企微/飞书机器人：协同作战的核心
这是目前最主流的通知方式。机器人可以做到：
- 实时推送告警详情
- 支持图文、Markdown格式
- 可以@具体的人或群
- 支持交互式操作（如确认、升级、关闭）
我以钉钉机器人为例，展示一个典型的告警推送配置：
# 钉钉机器人Webhook配置示例
import requests
import json
def send_dingtalk_alert(alert_data):
webhook_url = "https://oapi.dingtalk.com/robot/send?access_token=YOUR_TOKEN"
# 构建Markdown消息
content = f"""
### 🚨 P0级故障告警
**服务名称**: {alert_data['service']}
**故障时间**: {alert_data['time']}
**影响范围**: {alert_data['impact']}
**当前状态**: {alert_data['status']}
**处理人**: @{alert_data['assignee']}
---
**故障详情**:
{alert_data['detail']}
[点击查看监控面板]({alert_data['dashboard_url']})
"""
payload = {
"msgtype": "markdown",
"markdown": {
"title": f"【P0】{alert_data['service']} 故障",
"text": content
},
"at": {
"atMobiles": [alert_data['phone']],
"isAtAll": False
}
}
response = requests.post(webhook_url, json=payload)
return response.status_code == 200
这里要注意几个细节：
- Webhook URL要放在配置中心，别硬编码在代码里
- Markdown内容要简洁，别超过2000字，否则会被截断
- @人的时候要传手机号，不是工号
4.6 通知策略的“避坑指南”
做通知机制这么多年，我踩过不少坑。这里分享几个最典型的：
我曾经踩过的坑：
- 通知风暴：一个故障触发了所有渠道的通知，结果值班人手机被打爆。解决方案：做“通知抑制”，同一故障在N分钟内只发一次同渠道通知。
- 无人认领：告警发出去了，但没人确认。解决方案：加“升级机制”——5分钟无人确认，自动升级到上一级负责人。
- 渠道失效：短信通道挂了，电话通道也挂了，结果故障没人知道。解决方案：做“渠道健康检查”，定期测试每个通知渠道是否可用。
- 内容冗余：一条告警里塞了太多信息，反而看不清重点。解决方案：用“摘要+详情”模式，通知里只放关键信息，详情通过链接查看。
4.7 知识体系总览
下面这张图，是我对报警通知机制的整体理解。你可以把它当作一个“决策树”来看：
说白了，通知机制的核心就三件事：分级、渠道、确认。分级决定了用什么渠道，渠道决定了怎么触达，确认决定了要不要升级。这三件事做好了，报警通知就不会乱。
我的个人建议：刚开始做通知机制时，别追求大而全。先搞定机器人通知和邮件归档，再逐步加入短信和电话。每加一个渠道，都要想清楚：这个渠道解决了什么问题？会不会带来新的问题？
公众号:蓝海资料掘金营，微信deep3321