告别 cron 盲区：用 systemd Timer 做可观测的服务器定时任务

很多服务器的定时任务都写在 cron 里：凌晨跑备份、每小时清缓存、每周轮转日志。写的时候很顺手，出问题的时候却很难查——任务到底跑没跑、跑了多久、有没有报错，往往只能靠翻日志和猜时间。把这类任务换成 systemd Timer，等于给每个定时任务配了一个可查询、可重试、可审计的“运行档案”。

cron 的三处盲区

第一，执行结果不可见。cron 只负责到点启动，脚本中途失败、超时、被系统重启打断，都不会主动留下统一的状态记录。第二，环境不一致。cron 的环境变量和 PATH 通常比交互式 Shell 精简，本地能跑的脚本放到 cron 里就可能因为找不到命令而失败。第三，并发和错峰难控制。机器重启后，错过的任务不会补跑；上一次还没跑完，下一次又启动，容易互相干扰。

一对文件，拆开职责

systemd 的做法是把“做什么”和“何时做”分开。service 文件描述任务本身，timer 文件描述触发规则。

# /etc/systemd/system/backup.service
[Unit]
Description=每日数据备份

[Service]
Type=oneshot
ExecStart=/usr/local/bin/backup.sh

# /etc/systemd/system/backup.timer
[Unit]
Description=每天凌晨两点备份

[Timer]
OnCalendar=*-*-* 02:00:00
Persistent=true

[Install]
WantedBy=timers.target

Persistent=true 是关键：机器在凌晨两点关机或重启，恢复后会把错过的这次补跑一次，避免备份悄悄缺了一天。

让任务可观测

启用后，用三条命令就能回答过去需要翻半天日志的问题：

systemctl enable --now backup.timer
systemctl list-timers --all
systemctl status backup.service
journalctl -u backup.service --since today

list-timers 会显示下一次触发时间和上一次触发时间；status 能看到最近一次的退出码和运行时长；journalctl 则把该任务的标准输出和标准错误集中在一起，不用再猜脚本把日志写到了哪个文件。

四个实用习惯

一是给脚本设超时和失败动作。可以在 service 里写 TimeoutStartSec=600，并根据需要用 OnFailure 触发告警脚本，让失败第一时间被发现，而不是等用户反馈才知道备份停了三天。

二是控制并发。加上 Persistent 之外，还可以在 timer 里用 RandomizedDelaySec=300 给多台机器的同一任务加随机延迟，避免所有服务器在同一秒访问数据库或对象存储。

三是先用 --dry-run 思路验证。正式启用前，先手动跑一次 systemctl start backup.service，确认退出码为零、产物完整，再交给 timer 调度。

四是定期做“下次触发时间”巡检。把 systemctl list-timers 的输出纳入每周巡检清单，重点看有没有 timer 被误禁用、有没有任务长期处于失败状态。

迁移时的注意事项

从 cron 迁移不要一次性全切。先挑一个影响小、失败可重试的任务试点，比如清理临时文件；确认一周运行稳定后，再迁移备份、报表这类关键任务。迁移时注意工作目录和用户身份：service 默认以 root 运行，如果原来 cron 任务属于普通用户，要在 service 里显式写 User= 和 WorkingDirectory=，避免权限和相对路径带来的差异。

cron 并没有错，它简单可靠，适合一次性、临时性的任务。但对需要长期运行、需要留痕、需要被巡检的生产任务，systemd Timer 的可观测性和补跑能力更值得投入。把定时任务从“黑盒”变成“有档案的任务”，是服务器运维里成本很低、收益很稳的一步。