凌晨 02:17，手机在床头柜上疯狂震动。我眯着眼睛摸过去，屏幕上赫然是那熟悉的短信模板：

【监控告警】服务 api-prod 健康检查失败（连续 5 次），请及时处理。

作为一个身经百战的 OnCall 选手，我的身体比大脑先醒来：左手摸眼镜，右手解锁手机，三分钟内打开 VPN，全程没开灯——开灯就彻底睡不着了，这是我用血泪换来的经验。

第一反应永远是错的

登上机器，top 一看，CPU 3%，内存 40%，看起来岁月静好。但是服务进程不见了。第一反应：重启吧。重启完正常了，02:40，回去睡觉。

如果你以为故事到这里结束了，那你也太天真了。04:52，同一个告警，同一个配方。这次我不困了——被吓的。

真相往往朴实无华

老老实实查日志，发现应用日志在 02:15 之后就没有新写入了。看磁盘：df -h 一敲，好家伙，根分区 100%。

再看是谁吃的：du -sh /var/log/* | sort -rh | head，一个叫 app-debug.log 的文件，孤零零地占着 47 个 G。上周为了排查一个偶现问题，我把 debug 日志打开了，排查完忘了关，而且 logrotate 的配置里压根没有它。

清理、加上轮转配置、关掉 debug、写了个磁盘使用率 85% 的预警告警——05:40，天都蒙蒙亮了。

复盘的时候我写了三句话

  • 重启能解决的是“症状”，解决不了“病因”，但凌晨三点你只能先解决症状；
  • 没有磁盘预警的监控体系，等于家里装了烟雾报警器但没装电池；
  • 所有“临时打开的开关”，都要设一个关掉它的提醒——最好是在打开它的那一刻。

第二天我顶着黑眼圈上班，同事问我怎么了。我说，昨晚服务器挂了。他说你怎么不困啊。我说，困啊，但是更气。