引言：凌晨的“定时炸弹”

1. 引言：凌晨的“定时炸弹”

运维群里经常半夜被叫醒，原因大多是“定时任务又挂了”。排查后发现，多数问题并非偶发，而是由几个隐蔽的工程细节埋下的雷。本文结合真实故障案例，拆解定时任务在半夜高频失败的五大类原因，并给出可落地的修复方案。

2. 时区错位：cron 的“隐形偏移”

最常见的坑：crontab 默认使用系统时区，而应用代码可能使用 UTC 或容器时区。假设服务器设置为 Asia/Shanghai，但你在 crontab 里写了 0 2 * * *，期望凌晨2点执行。如果应用内部用 datetime.now(timezone.utc) 比对时间，实际执行时对应 UTC 前一天18点，逻辑判定“未到时间”直接跳过。曾有案例：数据同步任务每天凌晨2点跑，连续一周失败，最后发现是 pytz 时区库未安装导致 ZoneInfo 回退到 UTC。

• 检查：date 与 timedatectl 确认系统时区；crontab -l 确认表达式。
• 修复：在 cron 命令前显式设置 TZ=Asia/Shanghai，或在应用启动时固定时区，例如 os.environ['TZ']='Asia/Shanghai'。
• 系统d 定时器使用 OnCalendar=*-*-* 02:00:00 时，同样需注意 Persistent=true 是否因错过的任务补跑而撞上其他任务。

3. 资源争抢：OOM 与超时

半夜是批处理的高峰期，数据库备份、日志聚合、离线计算纷纷启动。一个典型的故障：某爬虫任务凌晨3点执行，日志显示 Killed，dmesg 中发现 Out of memory: Kill process。原因是同一台 2C4G 服务器上，备份进程内存占用飙升，把爬虫挤掉了。

• 排查：dmesg -T | grep -i killed 看 OOM 记录；free -h 确认内存水位。
• 预防：为任务设置资源上限（ulimit -v 或 systemd 的 MemoryMax），错峰调度，比如将备份改到凌晨4点。
• 关键：定时任务一定要加上超时控制，如 timeout 3000 python job.py，防止任务卡死占用资源。

4. 依赖服务的“深夜维护”与网络抖动

云厂商的维护窗口常安排在凌晨，数据库主备切换、Redis 升级、对象存储故障转移都会发生。如果你的定时任务依赖外部 API，恰好碰上维护窗口，连接超时、5xx 错误就会让任务失败。我们遇到过：每天凌晨2点半调用第三方物流接口，连续三天失败，最终确认对方在1:00-3:00 做系统升级。

• 设计：必须给任务加指数退避重试，如 retry(tries=5, delay=60, backoff=2)。
• 幂等性：任务要支持重复执行不产生副作用，例如用 INSERT ... ON DUPLICATE KEY UPDATE 或去重表。
• 监控：为任务单独设置告警，记录每次执行的耗时、重试次数，便于发现异常窗口。

5. 日志轮转与文件句柄泄漏

这个坑很隐蔽：半夜 logrotate 轮转日志，默认策略是 create，即重命名旧文件并新建。如果长时间运行的应用仍持有旧文件描述符，日志会继续写入已轮转的文件，导致新日志丢失，同时可能引发“No space left”或“Too many open files”。某次排查中，任务在凌晨1:30准时报错 OSError: [Errno 24] Too many open files，原因是轮转后的旧日志占满了 inode。

• 解决：在 logrotate 配置中加入 copytruncate，或者让应用在收到 SIGHUP 时重新打开日志文件（如 Python 的 logging.handlers.WatchedFileHandler）。
• 额外：检查 ulimit -n 是否过小，建议至少 65535；用 lsof | grep deleted 查找持有已删除文件句柄的进程。

6. 总结：让半夜任务“安睡”

定时任务在半夜失败，多数是时区、资源、依赖、日志四类问题叠加。建议你建立一套“夜间任务健康检查”：在任务开始前记录时间戳，结束后发送心跳；如果连续两天失败，自动告警。同时，把所有任务纳入统一调度平台（如 systemd timer 或 Airflow），并设置 Timezone 参数。最后，请记住：真正可靠的定时任务，不是靠运气，而是靠工程细节的滴水不漏。