crontab 编排矩阵：把零散脚本串成一套自动巡检体系

这个系列写到这里，你的机器上应该已经攒了不少脚本：日志转 CSV 的、死链监控的、排名追踪的、收录核查的。共同的问题是——跑过一次就躺在目录里吃灰，下周想起来了再手动跑一遍，再下周就忘了。SEO 工具链的最后一块拼图是例行化：让脚本自己按点上班，人只看产出。Linux 站长手里最顺手的调度器就是 crontab，一行配置管到天荒地老。

动手之前先定规矩：不是所有任务都值得每天跑，频率要按数据的新鲜度和接口成本分层。日志类任务天然每日跑——今天的日志今天入库，隔天再跑就要处理跨文件；排名追踪受接口额度限制，每周全量查一次已经够用；全站死链扫描一周一轮，核心落地页可以加密到每日；月报这种聚合任务，每月一号跑一次就够了。频率写进任务表注释里，半年后回看不用猜。

# crontab -e 任务矩阵（SEO 巡检版）

CRON_TZ=Asia/Shanghai

S=/var/www/seo

# ---- 每日 ----

30 6 * * * python3 $S/log2csv.py      >> $S/cron.log 2>&1

40 6 * * * python3 $S/status_dist.py  >> $S/cron.log 2>&1

50 6 * * * python3 $S/daily_report.py >> $S/cron.log 2>&1

# ---- 每周一 7 点 ----

0 7 * * 1 python3 $S/rank_track.py    >> $S/cron.log 2>&1

20 7 * * 1 python3 $S/deadlink.py     >> $S/cron.log 2>&1

# ---- 每月 1 号 8 点 ----

0 8 1 * * python3 $S/month_report.py  >> $S/cron.log 2>&1

长任务必须防重叠。假如死链扫描要跑四十分钟，而 crontab 安排它每天跑一次倒还好；怕的是手动跑了一次没结束、调度时间又到了，两个进程抢着写同一个 CSV，数据错乱还查不出原因。flock 是文件锁工具，加 -n 参数表示拿不到锁就放弃本轮——上一个实例还在跑，这一轮直接跳过，比让两个进程打架体面得多。每个可能超时的任务都套一层。

# 防重叠写法：拿不到锁就放弃本轮

30 6 * * * flock -n /tmp/seo_log.lock python3 $S/log2csv.py >> $S/cron.log 2>&1

# 核对任务是否真的在跑（Ubuntu/Debian）

grep CRON /var/log/syslog | tail -20

# CentOS / 新版 systemd 系统

journalctl -u cron --since "1 hour ago"

验证流程固定三步：新任务先手动执行一遍确认能跑通，再 crontab -l 核对配置无误，第二天早上看 cron.log 和 syslog 里的 CRON 记录确认调度触发。cron 环境有两个经典坑要提前防：一是它的 PATH 极简，Python、脚本路径全用绝对路径最稳，别指望环境变量；二是 cron 默认用系统时区，服务器是 UTC 的话“早上六点”其实是下午两点，加 CRON_TZ 或干脆把系统时区改对。这套任务矩阵是前面十几篇脚本的骨架，骨架立住了，工具链才算真正自动跑起来。

相关阅读：本篇是《SEO 自动化总清单：日、周、月、季各该跑什么》的执行器——总纲定节奏，本篇的 crontab 矩阵负责让脚本按时跑，两篇配合着用。