定时任务的可靠性：cron 失败了，你怎么知道

定时任务是小项目里最容易被高估可靠性的部分。cron 写好了、手动跑通过一次，就默认它会每天准时跑下去——直到某天发现：备份已经三周没跑了，日报停在了上个月，清理脚本悄悄失败了两个月，磁盘就是这么满的。

定时任务的问题从来不是"写不出来"，而是"失败时没人知道"。它不像接口请求，失败了用户会马上投诉；它失败时安静得很，什么都不发生，而"什么都不发生"恰恰最难察觉。

一、默认假设要反过来：没收到成功信号，就是失败

很多人给定时任务加监控的方式是"失败了告警"，这有个前提：失败时任务本身还能发出告警。但现实中常见的失败模式是任务根本没跑起来：服务器重启后 cron 服务没起来、时区改了、脚本路径变了、依赖的环境变量丢了——这些情况下，任务连"失败"这个动作都没有，自然也不会有任何告警。

更可靠的做法是反过来：用"成功心跳"代替"失败告警"。任务每次成功跑完，主动向一个外部地址发一次心跳（可以是监控服务，也可以是自己写的一个简单接口）；监控端按预期时间检查：到点没收到心跳，就告警。没消息就是坏消息，这个原则对定时任务尤其适用。

心跳不用复杂：curl 一下带任务名的 URL 就够了。关键是心跳要发在任务真正做完之后，而不是脚本一启动就发——否则"启动了但中途挂了"也会被误判为成功。

二、日志要写在能找到的地方，而不是只打到屏幕上

cron 任务的输出默认发邮件，没配邮件就丢了；写到某个临时目录，几个月后连自己都忘了路径。等到出问题要排查时，第一步不是修 bug，而是先找日志在哪——这一步就经常卡住。

我的做法是三条规矩：第一，所有定时任务的输出统一重定向到一个固定目录，文件名就是任务名加日期；第二，标准输出和标准错误分开写，出错时不用在一堆正常日志里翻；第三，日志里第一行就写任务名、开始时间、关键参数，最后一行写结束时间和结果（成功/失败/处理了多少条）。这样排查时一眼就能定位：哪天、哪个任务、做到哪一步停的。

另外，日志要定期轮转。定时任务每天跑，日志不清理，一年下来就是几十万行，磁盘满了反过来又会让任务失败——用 logrotate 之类工具按大小或天数切分，是写任务时就该顺手配好的事，不是出事后才补的。

三、幂等和锁：失败重跑不能比不跑更糟

定时任务失败后最常见的补救是"手动再跑一次"，但如果任务本身不是幂等的，重跑一次就可能把问题变大：重复发通知、重复扣减、重复写入脏数据。写任务时就要假设它会被重复执行：用唯一键去重、处理前先查状态、写操作可重入——这些不是"高级优化"，是定时任务的基本素养。

反过来也要防重复执行本身：上一次还没跑完，下一次又到点了，两个实例同时跑，互相抢资源、写冲突。简单的办法是文件锁（flock）：拿到锁才跑，拿不到就直接退出并记一条日志。锁的超时也要设好，否则一次死锁会让之后所有的执行都静默跳过——而这又回到了"失败时没人知道"的问题。

四、给任务分级：不是所有失败都值得半夜叫醒你

定时任务一多，告警疲劳很快就来了：备份失败和"每周清理临时文件"失败如果用同一种告警强度，几次无关痛痒的告警之后，真正重要的那次也会被忽略。

我的分级很简单：核心任务（备份、账单、对账、数据同步）失败，立即告警；辅助任务（清理、统计、日报）失败，只记日志、第二天汇总看一次；可重试的瞬时失败（网络抖动、对方接口 500），先自动重试两次带退避，连续失败才告警。分级的目的是让告警保持"值得被打断"的含金量——告警一响，就知道是真要处理的事。

五、定期演练：像备份一样，定时任务也要"真的跑一次给你看"

和备份恢复演练同理，定时任务也需要定期验证：每月挑一天，把核心任务在测试环境手动触发一次，确认它在当前环境下真的还能跑通。环境是会变的：依赖升级了、磁盘路径变了、对方接口改了字段——这些变化不会通知你的 cron，但会在某个凌晨让它静默失败。

演练不用全量：核心任务每月一次，辅助任务每季度看一眼执行记录就够了。顺手把任务清单也维护一下：每个任务是干什么的、多久跑一次、失败了找谁、依赖什么——这份清单在接手项目或排查问题时，比任何文档都值钱。

结语

定时任务的可靠性不靠"写的时候小心"，靠三样东西兜底：成功心跳（没消息就是坏消息）、可定位的日志（找得到、看得懂）、幂等加锁（重跑不闯祸）。再加上分级告警和定期演练，一套小项目的定时任务就能从"希望它每天都跑"变成"知道它每天都跑了"。

最危险的定时任务，永远是那个你以为在跑、其实早就停了的任务。给它一个心跳，今晚就能睡得踏实一点。