上周凌晨三点，监控告警突然炸了——数据库连接池耗尽。值班同事手机同时收到两条消息：一条是钉钉机器人推送的告警卡片，另一条是运营商发来的短信。他点开钉钉只用了1.2秒，而翻出短信看了两遍才确认内容。不是他手慢，是短信真比主流告警系统慢了一截。
延迟不是玄学，是链路决定的
短信走的是传统信令通道：应用服务器 → 短信网关（SMSC）→ 运营商核心网 → 基站 → 手机。中间至少跨4个异构系统，任一环节排队或拥塞，就会卡住。尤其在节假日、促销大促时，某省移动网关队列积压超30秒并不罕见。
而现代告警通知系统（比如基于Webhook+企业微信/飞书/钉钉的方案）走的是HTTP/TCP直连：监控平台 → 云服务商API → 终端App。全程在公网骨干网跑，没信令转换，没基站调度，平均端到端延迟稳定在300ms–800ms之间。
实测对比：同一告警，不同通道
我们在IDC机房部署Zabbix，配置三路通知：
## 短信通道（使用某云短信SDK）
trigger: "CPU usage > 95%"
action: send_sms(to: "138****1234", content: "[CRIT] db01 CPU 97.2% @2024-06-15 02:17")
## 飞书机器人（Webhook）
action: post_webhook(url: "https://open.feishu.cn/bot/v2/hook/xxx",
json: {"msg_type":"text","content":{"text":"[CRIT] db01 CPU 97.2%"}})
## 邮件（SMTP）
action: send_mail(to: "ops@eiyongduoshi.com", subject: "[ALERT] db01 high CPU")连续触发100次告警，取中位数延迟：
- 飞书机器人：420ms
- 邮件（自建Postfix）：1.8s
- 短信：6.3s（其中网关排队占4.1s）
那为什么还有人坚持用短信？
不是不知道慢，是图它“不挑环境”。Wi-Fi断了、App被杀后台、手机静音、甚至iOS用户关闭了通知权限——这些情况下，短信依然能弹窗（只要信号格有1格）。我们线上有个老系统，至今还挂着短信兜底：当飞书连续3次推送失败，自动降级发短信，哪怕晚6秒，也比没通知强。
所以别问“哪个快”，先问“你要快到什么程度，又容不容错”。核心支付接口告警必须毫秒级触达，上飞书+电话语音双通道；而备份任务完成通知，发个短信+邮件完全够用。
提速小技巧：别让短信更慢
如果真得用短信，避开这些坑：
- 不用长链接：把「http://xxx.com/log?tid=abc」缩成「log#abc」，短信字数少，编码快，网关处理优先级更高；
- 避开整点：运营商每小时整点做话单结算，此时发短信容易排队；
- 测试真实号码：别只测自己手机号，多试几个号段（尤其联通老年机、移动IoT卡），不同终端解析速度差得离谱。