迁移定时任务，先管住重复执行和业务时间

任务类型对应不同保护

发现所有任务触发源，清单不能只来自应用代码

旧任务可能存在系统 crontab、数据库作业、容器平台、应用内部调度、办公脚本和第三方控制台。每个触发源都应纳入接手与迁移。

记录任务名称、用途、负责人、运行账号、执行环境与调用命令，再补充输入来源和输出位置。月末、年末与人工触发的作业需要业务确认，近期没有日志不能证明不存在。特别留意同一任务在多个机器上被复制配置的情况，新平台接管前先说明当前实际由谁触发。

• 逐环境核对系统、应用、数据库与外部平台的调度配置。
• 记录执行频率、最长周期和人工补跑入口。
• 把无负责人或用途不明的任务列入待确认清单。

区分触发时间与业务数据截止时间

每天零点触发不等于处理前一天的全部数据。要明确时区、统计区间、迟到数据、节假日与人工重算的口径。

将业务周期作为输入，而不是每次执行都按“当前时间减一天”推算。这样任务延迟后仍知道原本要处理哪个周期。不同调度器对时区、漏触发和夏令时的支持不同，应按目标产品文档确认；即使只面向中国业务，也要检查服务器时区与应用格式是否一致。

依赖上游文件或同步结果的任务，还要区分到达时间与是否完整。可通过清单、完成标志或其他约定判断数据准备好，超时进入明确处理流程。单纯每天固定时间开始读取，可能把未完成的数据当成正式结果。

• 规定业务时区、区间开闭边界与数据截止规则。
• 为迟到数据与跨周期修正定义重算或补偿方式。
• 测试延迟触发、手动补跑和重复周期输入。

将幂等保护放在业务处理边界

调度层锁可以减少同一任务重叠，但不能独立保证每条业务只处理一次。实际写入、发送和状态变化应有持久化识别方式。

任务按稳定对象与业务周期确定处理标识，执行前后记录状态及结果。外部发送超时可能已经成功，重试前需要根据接口能力查询或去重。仅在内存中标记“处理过”会在重启后丢失；全任务加一个大锁也无法解释中途失败的位置。保护应与具体副作用的可重复能力相匹配。

• 明确业务去重标识、保留时间和冲突处理。
• 记录成功、失败和不确定结果，支持按对象调查。
• 模拟中断与超时，验证重跑不会重复产生副作用。

重叠、漏跑和资源使用分别设策略

上一轮尚未结束时，新一轮可以跳过、排队或并行，选择取决于业务。并发策略只是调度行为，最终数据正确性仍由任务负责。

目标平台通常有并发、截止时间和历史记录等配置，但语义需按平台版本确认。比如 Kubernetes CronJob 的并发策略针对同一 CronJob，不是全系统业务去重；Celery 周期调度也需要避免多个调度器重复发任务。为任务设批次、资源上限和执行进度，避免迁移后全部作业在同一时刻争用数据库。

• 定义重叠执行、漏触发与长时间运行的处理。
• 调整批次、频率和错峰方式，并观察依赖资源。
• 保留任务进度、耗时与业务失败数量的记录。

迁移按演练、关闭旧触发与启用新触发推进

先在脱敏或隔离环境验证任务，再确定最后一个旧周期与第一个新周期。只有调度主责清楚，才能解释切换附近是否漏跑或重跑。

演练应使用固定业务周期，检查输入对象、输出结果及副作用。切换时停止旧触发并核对仍在执行的实例，记录处理边界后启用新触发。新平台不宜靠影子运行再次发送通知或修改真实状态；可把计算与副作用拆开，仅比较计算结果。切换后的首个周期由负责人检查，不依赖任务绿色状态。

• 第一步：用固定周期运行并比较业务结果。
• 第二步：关闭旧触发，确认活跃任务与处理进度。
• 第三步：启用新调度，核对首周期及失败补跑。

按业务结果交接运行手册与补跑权限

运维人员需要知道如何定位未处理对象、如何安全补跑，以及什么时候必须由业务负责人确认。任务脚本交付只是其中一部分。

本文适合周期性后台作业升级，不替代在线交易或大规模数据迁移方案。长周期结算应覆盖完整周期或明确采用何种验证证据；无法等待时，把剩余核验事项和责任写入阶段验收。业务成功数量、错误明细和输出对账应有可靠证据，日志不要记录不必要的敏感内容。

补跑工具应要求明确周期与对象范围，提供执行前的影响确认和执行后的结果清单。维护人员需要能够区分“未执行”“执行失败”和“结果不确定”，不同状态采用不同处理，不把整批重跑作为唯一按钮。

• 交付触发配置、周期定义、依赖和处理标识说明。
• 演练指定周期补跑、暂停与失败对象隔离。
• 为重要作业定义业务告警与责任人确认方式。

需求讨论中的问题