云上定时任务与批处理调度实战：别让脚本跑了三年没人管

去年一个客户半夜打来电话，数据库挂了。查了半天，不是攻击，不是流量高峰——磁盘满了。再往下查，发现有个日志清理脚本，写在crontab里，应该每天跑一次。但三年前，这台机器迁移过，crontab没迁过来。脚本三年没跑了。

没人发现，因为没人看日志。日志清理脚本没跑，日志一直写，三年后磁盘爆了。

这是定时任务最真实的尴尬：它跑了，没人知道；它没跑，也没人知道。

今天聊聊云上定时任务与批处理调度。不是那种“cron很重要”的废话，而是帮你理清楚：怎么让任务可靠地跑？失败了怎么重试？怎么监控？怎么管理任务依赖？

01 cron不是运维工具，是触发器

很多人把crontab当成了“调度系统”。写一行cron，脚本就每天跑，以为完事了。

但cron只做一件事：到时间执行命令。它不管：

• 任务失败了怎么办？（不重试）

• 上一次任务没跑完，下一次又开始了怎么办？（不防并发）

• 任务依赖另一个任务怎么办？（不支持依赖）

• 任务跑了没有？（没日志、没告警）

反常识观点：cron不是调度平台，是定时触发器。 真正的调度平台要有重试、监控、依赖管理。

那家客户的日志清理脚本，用cron跑，没人监控，没人告警。迁移时漏了，三年没人知道。

02 云上定时任务工具怎么选？

云上跑定时任务，有几种常见方案。

方案一：云函数 + 定时触发器

• AWS Lambda + EventBridge、阿里云函数计算 + 定时触发器

• 适合：短任务（几分钟内）、轻量级、无状态

• 优点：不用管服务器，自动重试（可配置）

• 缺点：执行时间有限制（Lambda最长15分钟）

方案二：托管任务调度

• AWS Batch、Azure Batch、阿里云BatchCompute

• 适合：批处理、大数据计算、长时间任务

• 优点：托管计算资源，按需付费

• 缺点：配置相对复杂

方案三：自建调度平台

• Apache Airflow、DolphinScheduler、Jenkins

• 适合：复杂任务依赖、DAG编排、需要UI界面

• 优点：功能强大，支持重试、告警、依赖

• 缺点：需要自己运维

方案四：cron + 监控

• 最小方案：cron + 脚本内写日志 + 外部监控（比如跑完发心跳到监控系统）

• 适合：简单任务，团队规模小

• 缺点：没有重试、没有依赖管理

那家客户后来改了：日志清理脚本迁到AWS Lambda + EventBridge，每天触发。Lambda有重试机制，失败了会自动重试2次。用CloudWatch监控执行次数，连续失败告警。运维负责人说：“以前是盲跑，现在至少知道它跑没跑。”

03 可靠性设计：假设一定会失败

定时任务设计的第一原则：假设它会失败。

重试

• 临时故障（网络抖动、下游超时）→ 自动重试，间隔指数退避

• 永久故障（代码bug、配置错误）→ 重试也没用，告警人工介入

幂等性

• 同一个任务重复执行，结果应该一样。防止重试导致重复扣款、重复发通知。

• 实现方式：记录上次执行位置、用唯一请求ID去重、先查询再写入

超时控制

• 任务不能无限跑。设超时时间，超时后主动终止并告警。

并发控制

• 防止上一个任务还没跑完，下一个又开始了。用锁（Redis锁、数据库锁）或队列。

那家客户的日志清理脚本，没有重试、没有幂等、没有超时。好在这次是“没跑”，如果是“跑错了”或“重复跑”，可能更糟。

04 监控与告警：让沉默的任务发出声音

定时任务最怕的是“沉默了”。跑了没，成功了没，没人知道。

关键监控指标：

• 调度是否触发：任务有没有按时启动

• 执行成功/失败：每次执行的结果

• 执行耗时：是否有性能下降趋势

• 数据量：处理了多少条记录，是否有突增突减

告警策略：

• 任务失败：立即告警

• 任务超时：超过预期耗时告警

• 任务未按时触发：比如5分钟了还没启动，告警

• 连续失败N次：升级告警

工具：

• AWS：EventBridge记录调度事件，CloudWatch监控Lambda执行

• 自建Airflow：自带任务监控和告警

• 通用：任务结束时主动发心跳到Prometheus，用Prometheus监控心跳缺失

那家客户后来在日志清理脚本里加了最终行：echo "cleanup completed" | aws sns publish --topic-arn xxx。每次跑完发一条SNS。用CloudWatch监控这个SNS消息，超过24小时没收到就告警。再也不会“跑没跑都不知道”。

05 任务依赖：当一件事等另一件事

简单的定时任务，各自独立跑就行。复杂的业务流程，任务之间有依赖。

例如：数据同步任务跑完 → 数据清洗任务才能跑 → 报表生成任务才能跑。

怎么实现？

• 编排工具：Airflow、DolphinScheduler、Step Functions

• 事件驱动：上游任务完成后发消息到队列，下游任务消费

• 状态检查：下游定时检查上游的执行状态（轮询），不优雅

那家客户有个数据报表任务，每天早晨9点要发出。数据同步到8点才跑完，但报表8点就跑了，数据不全。后来改Step Functions：先跑同步，成功后才跑报表。完美。

写在最后

定时任务和批处理，是系统里“看不见的齿轮”。它们安静地跑着，帮你清理日志、同步数据、发送报表。但当它们出问题的时候，往往是灾难性的——磁盘满了、数据不对、报表没发。

那家客户的运维负责人后来总结：“以前觉得cron是成熟技术，不会出问题。现在知道了，不是cron出问题，是我们没管它。”

你的定时任务，现在有人管吗？