RPA 定时任务怎么配，配之前先想清这三件事

问题基本不出在流程上

手工点着跑的时候好好的，改成定时就出事。半夜跑失败没人知道，第二天补跑把前天的数据又处理了一遍，两个任务撞一起把库锁住了。

回头看，这几件事几乎都不是流程逻辑的锅，是排期没配对。

第一件，排在数据就绪之后

每天零点半生成昨天的日报，听着没问题。但如果上游数据零点四十才同步完，这份日报就是空的。

所以排期不要挑日历上好看的位置，要挑上游跑完之后。心里默念一遍，这个时间点我依赖的东西都就绪了吗。没就绪就往后挪。

第二件，节假日怎么办

每月三十一号跑任务，二月没有这天，多数调度器会顺延到当月最后一天。如果那天系统正在跑别的定时，就撞上了。

节假日更麻烦。法定假日业务不上班，调度器不知道，照跑不误。数据源是空的，生成了一份空报表还发了出去。

做法不复杂，但必须做。任务启动的时候先判断今天该不该跑，不该跑就记一条今日跳过的日志，然后正常退出。别静默失败，也别硬跑。

第三件，重试几次算够

重试不是越多越好。

对账任务重试三次，同一天的数据处理了三遍。推送任务重试三次，用户收到三条一模一样的通知。

比次数更要紧的是幂等。重试之前先问一句，这件事是不是已经做过了。判断依据最好用业务字段，比如这张单子的状态是不是已经从 A 变成 B 了。不要用今天跑过没这种判断，手工重跑的时候它会出错。

然后是上限。三次够了。到顶就停下来，让人来看。继续重试只是把一个小问题放大成积压。

任务之间怎么排序

先拉数据，再做处理，最后推送，这三步常见。

• 串成一条流程。顺序有保证，失败在哪一步一眼看得见。缺点是任一步挂了，后面都得等重跑。
• 拆成多个任务靠状态衔接。灵活，但要处理上一步昨天成功今天还没跑的悬挂状态。

能用一条流程串起来就别拆。拆开之后你会花大量时间排查为什么第二步没触发，而这个问题是第一步的失败被藏起来了。

排期的时候顺手定三件事

1. 跑多久算异常。没有预期，就判断不了今天是不是慢了；
2. 能不能并发。多数情况不允许，要显式配成单例；
3. 失败了发给谁。企微、钉钉还是邮件，必须配，不能靠出问题自然会知道。

这三件事排期时顺手定好，比事后补省事得多。排期是个配置动作，但它背后每个决定都在影响这个流程将来稳不稳。

收尾

定时器能不能触发，其实是最不重要的问题。真正要盯的是，触发之后出问题能不能及时发现、准确重跑、不产生重复副作用。