早上翻看运维记录时，发现前一晚的数据库备份文件并没有生成，但任务列表里那条定时任务依然显示存在。类似情况其实并不少见。很多人的第一反应是打开备份脚本，怀疑命令写错、路径写错。可脚本往往几个月都没动过，真正发生变化的，是任务运行所依赖的那些外部条件。
定时任务漏跑，排查顺序应该从“任务有没有被触发”入手，而不是一上来就盯着脚本内容。
先核对任务触发时间与时区设置是否一致。服务器系统时间如果被手动调整过，或者时区从UTC改成了本地时间，原本设定在凌晨两点的任务就可能被推迟或提前。更隐蔽的一种情况是，应用容器与宿主机时区不一致，任务调度器读到的“现在”和运维人员理解的“现在”差了几个小时。检查时不要只看任务列表里的表达式，还要确认系统当前时间、时区配置以及调度服务自身的时区参数是否统一。
接着核对任务依赖的前置条件。备份任务通常不是孤立的，它需要数据库可连接、磁盘有足够剩余空间、目标目录可写。数据库连接失败时，有些脚本会直接退出，却不写入明显错误；磁盘空间不足时，任务可能被系统静默终止；目标目录权限被修改后，备份文件无法落盘。这些条件不会每天变化，但一旦变化，任务就会连续漏跑。建议在任务执行前增加轻量的前置检查，把不满足的条件记录到独立日志中。
执行账号与密钥同样需要核对。定时任务以哪个系统账号运行，该账号是否被禁用、密码是否过期、SSH密钥或数据库凭据是否被轮换，都会直接影响任务能否完成。权限变更常常发生在其他运维操作之后，比如调整了目录归属、更新了凭据管理策略，却没有同步检查备份任务使用的账号。这类问题不会报“脚本错误”，只会表现为任务没有产出。
最后核对任务日志与退出状态码。不要只看任务有没有执行记录，还要看退出码是0还是非0，标准错误里有没有被忽略的提示。建议为备份任务单独保留一份运行记录，至少包含计划执行时间、实际开始时间、结束时间、退出状态和产出文件校验值。连续记录几天，就能看出是偶发失败还是条件性漏跑。
排查顺序可以归纳为：先确认任务是否被触发，再确认触发后依赖条件是否满足，然后确认执行身份是否有效，最后看日志和退出状态。日常巡检时，把备份任务的产出文件是否存在、大小是否合理、校验值是否可读，作为固定检查项，而不是只依赖任务列表里的“已启用”状态。
