很多站点的日常运轉，靠的不是編輯每天手動点發布，而是一批看不见的定时任務：到点自動發布内容、每天生成一份站点地图、定期清理缓存、凌晨备份資料库、把新地址推送给搜尋引擎。這些任務大多數跑在深夜，成功了没人夸，失敗了也没人知道，直到某天你發現站点地图里還是上個月的内容，或者备份文件停在了三個月前。
一、先把站点上的定时任務列成清單
不少团队的任務是歷史遗留，加的时候记得，過两個月就忘了。做自查的第一步不是检查執行狀態，而是先搞清楚到底有哪些任務。
- 服務器层面的 crontab、系統計划任務
- 主机面板里的計划任務（宝塔、cPanel 等）
- 應用内部的調度器，比如框架自带的任務队列、内容系統的定时發布
- 外部服務里的定时任務，比如监控探针、CDN 的刷新脚本
把這三四處的任務合並成一張表，标注执行频率、负责脚本、輸出位置和负责人。有了清單，後面每一步才有對照物。
二、確認任務是不是真的在跑
寫進 crontab 不等于在執行。命令行环境和你在终端里手動敲命令的环境差別很大，常见翻车点包括：脚本里用的是相對路径、脚本依赖的环境變量在 cron 里根本不存在、命令行調用的 PHP 或 Node 版本與網站執行版本不一致、脚本文件没有执行權限。
驗證方法很简單，看产物：
- 站点地图文件的最後修改時間是不是今天
- 备份目錄里最新一個压缩包是哪天的
- 日誌文件有没有按天切割
- 定时發布的内容是否按計划上线
判断一個任務有没有执行，最直接的办法不是看配置文件，而是看它产出的文件或資料的最後修改時間。
三、失敗的时候要让运维知道
定时任務最大的問题是静默失敗。系統預設會把 cron 的輸出通過邮件發给本地用戶，而很多服務器压根没配邮件服務，等于把错誤信息直接丢掉了。
輸出不要直接扔進 /dev/null
至少把标准輸出和错誤輸出重定向到一個日誌文件，保留最近若干次执行的记錄。出問题时，這几行日誌往往比什么都管用。
關键任務要配告警
- 任務失敗时發一封邮件或一條 IM 消息
- 重要任務可以設定失敗重试一次
- 连續多次失敗时升級通知，而不是每次都重复刷屏
四、留意任務之間的依赖和冲突
單個任務正常，不代表放在一起正常。多個任務同时段执行，很容易互相踩脚：备份脚本鎖表时前台訪問變慢、生成站点地图的同时正在批量發布内容、清缓存和生成静態頁撞在一起，结果谁都没做干净。
- 把對资源敏感的任務错開時間，不要都堆在整点
- 给任務加鎖，防止上一次還没跑完下一次又被触發
- 备份、批量生成這類吃 IO 和 CPU 的任務，尽量安排在訪問低谷，並适当限制资源占用
五、改版之後要回头复查一遍
站点改版、目錄調整、資料库改名之後，很多任務會悄悄失效。比如内容發布脚本還指向舊路径，站点地图生成脚本還在讀已经废弃的表，URL 推送脚本的接口密钥早就換了。這些任務表面上還在执行，實际上产出的全是空结果或舊資料。
- 每次结构或路径調整後，對照任務清單逐條回归
- 删掉已经没用的任務，减少噪音
- 把硬编碼的路径、域名、密钥集中到配置文件里
- 在运维文档里记錄任務的變更歷史
把這項检查和备份演练、日誌检查一起放進月度运维清單，花不了多少時間，却能避免很多说不清来源的問题。
定时任務是站点的後台流水线，平时看不见摸不着，一旦停摆，最先受影响的往往是内容更新和 URL 發現這類基础环节。與其等發現異常再回头翻日誌，不如定期花半小时核對一遍清單和执行结果，让自動化真正可靠地替你干活。