Linux定时任务需错峰避峰、显式声明环境、内置错误处理、优先用systemd timer替代cron、定期审计清理，确保稳、省、可溯、易维护。
Linux 运维自动化策略里，定时任务不是“加个 cron 就完事”，而是要让任务跑得稳、省资源、可追溯、易维护。核心不在调度本身，而在怎么设计、怎么落地、怎么兜底。
避免资源争抢，把任务错峰安排
系统负载不是均匀的，凌晨 2 点可能安静，但 1 点半若同时跑备份、日志压缩、监控快照，磁盘和 CPU 就会卡顿。
- 查看历史负载：用
sar -q或uptime回溯过去 24 小时峰值时段，避开这些窗口 - 同类任务分散执行：比如 3 个服务的日志清理，不要都设成
0 2 * * *，改用0 1 * * *、15 1 * * *、30 1 * * * - 关键任务优先级更高：数据库备份建议用
nice -n 10降低 CPU 优先级，避免影响线上请求
脚本必须自带环境与错误处理
crontab 默认 shell 是 /bin/sh，不加载用户 profile，PATH 很窄，很多命令（如 python3、jq）直接报 “command not found”。
- 显式声明解释器和路径：脚本开头写
#!/bin/bash，并在 crontab 中用绝对路径调用，例如/bin/bash /opt/scripts/backup.sh - 每个关键步骤加判断：
[ -f /data/db.bak ] || { echo "$(date): backup failed" >> /var/log/backup.err; exit 1; } - 重定向 stdout/stderr：
0 3 * * * /opt/scripts/clean-journal.sh >> /var/log/clean-journal.log 2>&1
日志清理这类高频任务，优先用系统原生机制
比如 /var/log/journal，别写复杂脚本反复 find + rm，直接用 journalctl 的 vacuum 功能：
- 设定空间上限（推荐）：
journalctl --vacuum-size=300M - 设定保留时长（适合审计场景）：
journalctl --vacuum-time=2weeks - 写进 crontab 示例：
0 4 * * * /usr/bin/journalctl --vacuum-size=300M >/dev/null 2>&1
用 systemd timer 替代 cron 处理依赖型任务
cron 只管时间，不管前序任务是否成功；systemd timer 可绑定 service，支持 After=、Requires=、失败自动重试等。
- 适合场景：备份 → 压缩 → 上传 → 校验，一环断则整链停
- 关键配置项：
Persistent=true（错过时间后补执行）RandomizedDelaySec=300（防集群雪崩）StartLimitIntervalSec=3600+StartLimitBurst=3（防脚本死循环反复拉起）
定期审计与失效清理
没人维护的 crontab 最终会变成“定时炸弹”：旧脚本路径失效、权限变更、业务下线但任务还在跑。
- 每月执行一次检查：
crontab -l | grep -v '^#' | awk '{print $6}' | xargs -I {} sh -c 'test -x "{}" || echo "MISSING: {}"' - 删除超过 6 个月无修改记录的任务文件：
find /opt/scripts/ -name "*.sh" -mtime +180 -delete - 统一记录入口：所有任务在脚本头部加注释，标明用途、负责人、最后更新时间
运维自动化的价值，不在于“能不能跑”，而在于“出问题时能不能快速定位、快速恢复”。定时任务只是载体，背后是清晰的责任边界、可验证的执行逻辑、以及随时能接管的手动路径。
