半夜两点十七分，网站我的监控手机突然像触电一样震动起来。屏幕上跳出一条短信：“【监控告警】服务器 172.16.3.8 CPU 使用率 98.7%，短信持续 5 分钟。网站”我揉着眼睛爬起来，监控打开笔记本连上 VPN，短信果然，网站某个业务进程因为内存泄漏已经快把 CPU 吃干了。监控重启进程，短信三分钟后第二条短信进来：“【恢复通知】服务器 172.16.3.8 CPU 使用率已降至 12%。网站”我躺回去，监控却再也睡不着——脑子里全是短信三年前那次事故。 那时我们还没有短信报警，网站只有邮件告警。监控某个周五晚上十一点，短信营销活动流量突然暴涨，数据库连接数打满。邮件确实发了，但没人看。等到周一早上大家上班，系统已经瘫了整整两天。业务方拍桌子，技术团队背锅，最后查监控才发现，其实故障发生后十五分钟，告警邮件就躺在邮箱里了。没人会在周五深夜盯着收件箱。 所以后来我们决定，所有 P1 级告警必须走短信通道。这个决定救过我们很多次，但真正让我觉得“值了”的，是上个月那次。凌晨四点，机房温度传感器报警——空调故障，温度飙到 42 度。短信发到运维老张手机上，他住在离机房三公里的地方，骑电动车十分钟赶到，手动切了备用空调。如果那晚没短信，等早上发现，机柜里那批服务器估计得报废一半。老张后来跟我喝酒时说：“手机响那一下，我他妈还以为家里出事了呢。但看到是机房温度，反而踏实了——至少知道哪儿坏了。” 短信报警这事儿，听着简单，做起来全是坑。一开始我们图省事，直接用邮件网关转短信，结果延迟五分钟起步。后来又试过第三方短信平台，价格倒是不贵，但偶尔会漏发。最离谱的一次，某平台半夜做系统升级，所有短信都卡在队列里，我们愣是到第二天早上才发现。所以现在我们的方案是双通道：主用运营商直连短信，备用走钉钉机器人推送到手机。两条路都断的概率，比机房同时停电还低。 还有阈值设计，这玩意儿比大多数人想的更讲究。设得太灵敏，半夜三点 CPU 抖一下都能把你吵醒，一周下来人先疯了。设得太迟钝，真出事又来不及。我们现在的做法是分级：CPU 超 90% 持续 3 分钟才发短信，但如果是磁盘满这种致命问题，只要出现就立刻发。另外，恢复通知必须带当前数值，不然你看到“已恢复”还得登录系统确认，多一步操作就多一分焦虑。 有人可能会问，现在都有企业微信、钉钉这些即时通讯工具了，谁还看短信？但短信有个不可替代的优势：它不需要任何 App 在后台活着，不需要网络连接，甚至不需要手机解锁。只要基站信号还在，它就能到。我们有个同事试过，把手机开飞行模式再关掉，微信消息要等十几秒才涌进来，但短信是秒到。这种可靠性，在服务器着火的时候就是生死线。 当然，短信也不是万能药。它只能告诉你“出事了”，不能告诉你“为什么出事”。所以我们的短信里永远带着 IP、指标名、当前值、持续时间，还有一条跳转监控平台的短链接。收到短信的人能立刻判断：是自己能处理的，还是需要拉群叫人的。有一次新来的同事半夜收到告警，直接点了链接去看监控图，发现是某个测试环境在跑压测脚本，虚惊一场。他后来在群里说：“还好短信里带了链接，不然我大半夜还得找电脑。” 说到底，网站监控短信报警不是技术问题，是人的问题。它解决的是“如何在最糟糕的时间点，用最直接的方式，把最关键的信息送到最需要的人手里”。我们试过更聪明的方案——AI 预测故障、自动修复脚本，但最后都败给了现实：预测不准，修复不敢全自动。反而是这条朴素的短信，在无数个深夜里，用一声震动把我们从崩溃边缘拉回来。它不够酷，但它管用。就像机房角落里那台老旧的备用发电机，平时没人看它一眼，真停电的时候，它是唯一能让你笑出来的东西。