很多站点的问题不是出在白天的编辑和发布上，而是出在夜里那些没人看的计划任务里：内容没按时发出来、站点地图半年没重新生成、备份跑了一半就断了。这些事情不会弹窗，也不会有人打电话告诉你，只会安静地积累成事故。

为什么定时任务容易变成盲区

定时任务的特点是「成功了没人看，失败了也没人看」。它不像页面报错那样有访客投诉，也不像磁盘写满那样立刻有反应。等到某天发现数据对不上、新页面迟迟没被抓取，回头看日志才发现任务已经停了几个月。

所以定时任务需要一份自己的巡检清单，而且最好固定周期做，而不是出问题才想起来查。

值得列进清单的常见任务

• 内容定时发布：排好期的文章是否按点上线，有没有卡在草稿状态。
• 站点地图生成：新页面是否被写进 sitemap，删除的页面是否还留在里面。
• 日志轮转与清理：轮转是否生效，临时文件有没有越滚越大。
• 数据备份：备份文件的大小和时间是否正常，能否恢复。
• 缓存预热或刷新：更新后是否真的把旧内容替换掉了。
• 统计与报表同步：外部数据拉取失败时，是否只剩一张空表。

自查时重点看这几项

1. 有没有执行记录

每个任务至少留下一行「几点开始、几点结束、结果如何」的记录。没有记录就无从判断它是正常跑完了，还是根本没启动。看记录时不要只看最后一行，往前翻两周，更容易发现间歇性失败。

2. 失败之后谁来知道

连续失败几次就发一条通知，这是最省事的做法。通知渠道不必复杂，邮件或群消息都行，关键是要有人在看。如果告警发到一个没人订阅的邮箱，等于没有告警。

3. 并发与重复执行

上一轮还没跑完，下一轮又启动了，容易出现重复写入或者数据错乱。检查任务有没有加锁，或者有没有设置「上一次未结束则跳过」。在任务耗时变长时，这个问题会突然冒出来。

4. 耗时与超时

记一下每个任务最近几次的耗时。如果从几秒涨到几分钟，说明数据量在增长或者有慢查询，继续拖下去迟早会撞上超时上限，被系统直接掐断。

5. 时间表达式与时区

「每天凌晨三点」到底是服务器时间还是本地时间，写表达式时容易搞混。跨时区或者夏令时切换的服务器，更要确认一次实际触发时间。

6. 依赖顺序

先抓数据再生成页面，先备份再清理旧文件，顺序反了就会得到空数据或者残缺备份。把有依赖关系的任务排好先后，别让它们扎堆在同一分钟。

留一个手动兜底的口子

不管自动化做得多顺，都要保留手动触发的方式，并写清楚在哪执行。真出事的时候，能手动补跑一次，比从头排查调度器快得多。同时把关键任务的说明记在运维文档里，别只存在某个人的收藏夹中。

定时任务不需要多复杂，但需要有人定期确认它还在跑。一次十分钟的巡检，往往能省掉一次几小时的排查。

建议把这件事和服务器维护的其他检查放在同一个周期里，比如每周固定看一次执行记录和告警记录，顺手确认备份文件的时间和大小。时间长了，这份习惯本身就会成为站点稳定的一部分。