两百台机器的 cron 任务：一次集中治理

两百台机器上散落的 crontab 是一笔糊涂账：谁的脚本、还在不在用、失败了谁知道，没人答得上来。一次脚本误删生产目录后，专项治理启动。

盘点先行。写了个采集脚本把所有机器的 crontab 拉到中心库，去重后 470 条任务，逐条找 owner。结果吓人：87 条无人认领，41 条的 owner 已离职，12 条指向不存在的目录，每次执行都在报错没人看。

治理分三类处置。无人认领且无业务影响的直接下线，观察两周无事即归档；有价值的任务迁移到统一调度平台，我们选了 DolphinScheduler，获得重试、告警、依赖编排能力；确实只适合本机跑的，留在 crontab 但纳入配置管理，脚本进 Git，crontab 由 Ansible 幂等分发。

迁移的过程顺手解决三个老大难：任务间的依赖顺序原来靠 sleep 硬凑，平台里配置 DAG；失败原来写日志了事，现在告警到人；执行历史可查，排查昨晚三点谁跑了什么不再靠猜。

规范落地：新任务一律上平台，机器本地 crontab 冻结只减不增，每季度复核一次。执行账号也统一：全部用专用低权账号跑，禁止 root，历史上有条 root 的清理脚本路径写错就是事故现场。

定时任务是隐形的基础设施，治理的本质是让它显形。这事不难，只是没人愿意先做，做完之后夜里的报警电话确实少了。

再补一个平台化的细节：调度平台的任务支持依赖变量传递，上游任务的输出能直接当下游入参，原来靠落盘文件传递的土办法废除了。数据流转的确定性提高后，失败重跑也变得干净，不会出现半新半旧的中间状态。

治理完成后调度平台的任务数反而增长了一倍：以前散落的暗任务被收编后，大家发现原来还有这么多自动化可做，新需求源源不断提上来。秩序带来的不是限制，是更多可能，因为可信的调度平台让每个想到自动化点子的人都敢落地，而不必担心没人知道任务在跑什么。