定时自动化任务上线前：重试、降级交付与告警检查清单

手动能跑通，不等于可以定时运行

很多 AI 自动化任务的起点是这样的：员工发现某个任务用 AI 做得不错，比如每天汇总行业资讯、整理前一天的销售数据，于是把它设成每天定时运行。

手动运行时，员工就在旁边，发现结果不对会马上处理。定时运行后，任务在没人盯着的时候执行，数据源临时打不开、账号授权过期、推送渠道出故障，都可能让任务悄悄失败，或者推送出一份残缺的结果，而大家并不知道。

上线门槛：满足这些条件再设定时

• 同样的任务说明，手动运行至少三次，结果都能通过验收；
• 触发时间、数据来源、输出格式、验收标准都已写清楚；
• 已经指定负责人、告警接收人，以及出问题时怎样暂停任务；
• 已经定义质量要求，例如内容相关性、时效性、去重规则、最少条目数。

如果其中任何一项说不清楚，说明任务还在调试阶段，不适合设成定时运行。

部分失败时：降级交付，而不是整体中断

一个任务往往要读取多个数据源。其中一个打不开时，有两种错误做法：整个任务直接失败，什么都不推送；或者假装一切正常，推送一份缺了一块的结果。

更好的做法是事先定好降级规则，例如：

• 大部分来源正常：推送完整结果，注明哪个来源缺失；
• 只有少数来源正常：推送简化结果，明确标注“本次结果不完整”；
• 几乎所有来源都失败：不推送结果，只发送告警。

关键是让收到结果的人知道这份结果完整到什么程度。

重试：分清哪些故障值得重试

临时故障可以自动重试。 网络超时、服务限流、推送渠道暂时不可达，等一会儿再试往往就能成功。重试次数要有上限，间隔要逐渐拉长，避免对方服务压力更大。

配置和授权问题不要重试。 账号授权过期、权限被收回、数据源地址变更，这类问题重试多少次都不会自己好，应该立即转给负责人处理。

避免重复推送和重复写入

定时任务失败后重新运行，或者有人在定时运行的同时又手动触发了一次，都可能导致同一份结果推送两遍，或者同一条记录写入两次。

解决办法是给每次运行一个批次编号，比如按日期命名。推送和写入前先检查这个批次是否已经完成，已完成的就跳过。同时记录每次运行已完成到哪一步，重新运行时从失败的那一步继续，而不是从头再来。

告警：让收到的人知道该做什么

一条只写着“任务失败”的告警，收到的人还得自己去查原因。有用的告警应该包含：

• 哪个任务、哪个批次；
• 在哪一步失败，失败原因是什么；
• 已经完成了哪些步骤，影响范围有多大；
• 建议怎样处理，从哪里恢复。

原则是：正常运行时尽量少打扰人，出问题时准确找到该处理的人。

上线前演练这几种情况

正式上线前，有意模拟以下情况，确认任务按预期处理：

• 所有数据源正常；
• 某个数据源限流或打不开；
• 当天没有符合要求的内容；
• 推送渠道不可达；
• 手动和定时同时触发。

上线后持续关注几个指标：是否按时触发、一次运行成功率、各数据源的可用率、有效内容数量的变化、推送成功率和每次运行的成本。修改任务时，先手动验证几次，再更新定时配置，不要直接在线上的定时任务上试验。

远行者科技的做法

在应用实施中，我们会为每个定时任务写一份任务定义：触发方式、数据来源、质量要求、降级规则、重试策略、告警接收人、负责人和停用方式，并在交接前完成上述失败演练。这份定义也是日后维护和审计的依据。