2026 年 3 月盘了一下我们跑的定时任务，六个，每周大概省下六小时机械劳动。定时任务的风险不在写，在没人管。一个静默失败的任务，比没有这个任务更危险，因为你会以为数据是对的。
六个任务
GSC 数据拉取，每周一凌晨；站点地图提交检查，每周一上午；死链扫描，每周二；排名快照，每周三；日志简报，每天 9 点；收录抽查，每周五。
这六个覆盖了我们日常要看的全部数据。再往上加就是过度自动化，比如自动改 titles、自动发文章，这类我们不做，改错了没人拦。
排期原则
别都放周一。周一凌晨是好时间，但六个任务一起跑，一个失败会影响后面的。我们按数据依赖排：先拉 GSC 数据，再跑排名快照，最后生成报告。
每个任务要能单独重跑，不依赖前面的中间文件。这条听着简单，实际写的时候很容易把状态存在临时文件里，一失败就得从头来。
失败处理
最危险的是静默失败。脚本报错退出，但没人看到，第二天报表是空的，大家以为这个站没数据。
我们的做法是心跳：每个任务跑完写一行记录到表里，包括时间和状态。另有一个检查任务，早上 8 点看所有任务最近一次成功时间，超过 26 小时没成功就在群里 @ 人。
26 小时这个阈值是因为日任务和月任务混在一起。日任务超过 26 小时没跑肯定有问题，周任务则由它自己的下一次运行覆盖。
谁维护
指定一个人负责，不是“大家一起看”。没有明确负责人，出问题就是互相等。
每季度 review 一次，把过去三个月没被任何人看过的任务删掉。我们上个季度删了一个排名监控任务，因为客户根本不看那份数据，白跑半年。
上线前先手动跑三次
定时任务最坑的是“看起来在跑”。第一次跑就写错字段的情况太常见，凌晨出错，三天后才被发现。
我们现在的规矩是手动跑三次，三次输出一致再挂 crontab。多花十分钟，省掉一次事故。
我们的排期表长什么样
任务用 crontab 跑，配置文件进 git，改动要提交合并请求。听着像小题大做，但你不会想体验“谁上周改了这个脚本”这种排查。
每个任务旁边写一行注释：它解决什么问题、失败会怎样、谁负责。三个月后自己都忘了当初为什么加。
日志统一写到固定目录，按任务名命名，保留 30 天。出问题先看最后 50 行，八成错误都在那里。
自动化不是越多越好。六个够用，第七个开始就是给自己找活干。
元析智能
为软件公司做 SEO 和 GEO 优化