周期任务触发规则要解决的是重复工作“什么时候生成、生成什么、交给谁、怎样算完成”的问题。设计时先把重复工作拆成触发条件、生成内容、责任人、完成判定四件事，再选择日历周期、完成后排期或事件触发，最后用字段表固定口径。本文给出一套可填写的规则字段表、角色分工、完整示例和上线检查清单，适合行政、运维、研发支持等存在例行工作的团队参考。
要点总览（TL;DR）
- 周期任务触发规则先拆四件事：触发条件、生成内容、责任人、完成判定；字段定清楚再选承载工具。
- 触发方式按工作性质选：固定节奏用日历周期，间隔依赖上次完成用完成后排期，状态变化引起动作用事件触发，混合使用时约定合并与顺延口径。
- 字段表至少保留频率、起算点、跳过与顺延、负责人、交付物、完成判定六类，频率写清单位，顺延设上限。
- 规则所有者、执行人、验收人职责分开，变更时交接字段表与变更记录，已生成任务按原规则执行完毕。
- 上线前核对字段完整与责任人，运行一个周期后核对生成时间、内容、分配和验收记录，出现逾期、跳过或人员变更时发起复审。
周期任务触发规则先定哪四件事
一条周期任务规则本质上是一份约定：满足什么条件时，系统或流程生成一条任务；这条任务包含哪些信息；由谁接收；做到什么程度算完成。四件事没有定清楚，规则上线后就会出现任务生成了没人认领、做完了没人确认、或者频率与实际节奏对不上等问题。
建议按以下顺序建立规则，每一步都有明确的输入、动作和完成标志：
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 定义触发条件 | 这项工作的实际发生节奏、依赖的前置状态 | 确定用日历周期、完成后排期还是事件触发，写明频率、起算点和时区 | 一句可判断真假的触发描述 | 任何人读完后能说出“下一次任务何时生成” |
| 2. 定义生成内容 | 任务标题、说明、检查项、关联文档或模板 | 把执行人需要的信息写进任务内容，避免生成一条只有标题的空任务 | 任务内容模板 | 执行人不询问他人即可开始工作 |
| 3. 指定责任人 | 团队分工、值班或轮值安排 | 明确默认负责人、替补人和交接方式 | 责任人字段与替补规则 | 每条生成的任务都有唯一当前负责人 |
| 4. 定义完成判定 | 交付物形态、验收标准 | 写明完成时需要提交的记录、附件或确认动作 | 完成判定条件 | 验收人可依据记录直接判断通过或不通过 |
顺序上先定字段再选承载方式。字段是规则的内容，工具只是承载形式。如果先挑工具再想规则，容易把工具默认的选项当成业务规则，后续调整时说不清哪些是业务要求、哪些是配置习惯。字段表确定后，再评估用项目管理工具、工单系统还是表格加提醒来承载，判断依据是任务量、协作人数和是否需要留痕。
触发方式怎么选：日历周期、完成后排期与事件触发
三类触发方式对应三种不同的工作性质，选择时看的是“下一次任务应该从什么时候开始算”，而不是哪种方式更先进。
| 触发方式 | 适用工作 | 起算依据 | 不适用的情况 |
|---|---|---|---|
| 日历周期 | 固定节奏的例行工作，如月度巡检、每周例会准备、季度对账 | 固定日期或固定间隔，与上一次是否完成无关 | 工作间隔取决于上一次完成时间，或完成时间波动很大 |
| 完成后排期 | 间隔依赖上一次完成的维护类工作，如设备保养、数据备份验证、版本发布后的回归检查 | 上一次任务标记完成后，按设定间隔生成下一次 | 存在外部截止日期，不能因上次延误而整体后移 |
| 事件触发 | 由状态变化引起的重复动作，如工单关闭后发起回访、需求变更后重新评估 | 某个对象状态变化或字段满足条件 | 没有可靠的状态信号，或状态变化过于频繁 |
实际工作中经常混合使用。例如月度巡检用日历周期保证固定节奏，巡检发现的问题整改用完成后排期跟踪复查，设备告警则用事件触发即时生成处理任务。混合使用时需要约定优先级和冲突处理：同一对象在短时间内被多个规则命中时，先判断是否重复，重复则合并为一条任务并注明来源规则；日历周期任务尚未完成又到了下一个生成点时，按字段表中“跳过与顺延”的口径处理，避免任务堆积。
选择时可以问三个问题：这项工作有没有外部规定的固定时间点？下一次工作的开始是否必须等上一次结束？是否有明确的状态变化可以作为信号？三个问题分别指向日历周期、完成后排期和事件触发。答案不唯一时，以外部时间约束优先，其次考虑依赖关系。
规则字段表：频率、起算点、跳过与顺延怎么写
字段表是规则设计的核心交付物。下表给出可直接填写的字段和填写口径，团队可以按实际需要增减，但频率、起算点、跳过与顺延、负责人、交付物、完成判定这六类字段建议保留。
| 字段 | 填写口径 | 示例 |
|---|---|---|
| 规则名称 | 对象加动作，能与其他规则区分 | 机房月度巡检 |
| 触发方式 | 日历周期、完成后排期、事件触发三选一或注明组合 | 日历周期 |
| 频率与间隔 | 写清单位，避免“定期”这类模糊表述；完成后排期写“完成后N天” | 每月1次；完成后3个工作日 |
| 起算点 | 日历周期写明具体日期或“每月第几个工作日”；完成后排期写明从上一次哪个状态开始计算 | 每月第一个工作日 09:00 |
| 时区 | 跨地区团队必须写明，单地区团队也建议标注 | UTC+8 |
| 生成时点 | 任务在起算点立即生成，还是提前若干时间生成 | 提前1个工作日生成 |
| 跳过规则 | 遇到节假日、上一周期未完成时如何处理：跳过、合并还是照常生成 | 遇法定节假日顺延至下一工作日 |
| 顺延与补做 | 顺延上限和补做方式，避免无限顺延 | 最多顺延3个工作日，超期标记为逾期并通知规则所有者 |
| 任务内容 | 标题、说明、检查项、关联模板或文档 | 标题“机房月度巡检-{月份}”，附巡检项清单 |
| 负责人 | 默认负责人及替补人，轮值规则写清轮值顺序 | 运维A，替补运维B |
| 交付物 | 完成时需要提交的记录、附件或链接 | 巡检记录表、异常项处理单 |
| 完成判定 | 由谁确认、依据什么确认 | 运维负责人确认巡检记录完整且异常项已登记 |
| 暂停与失效 | 什么情况下暂停规则，什么情况下规则作废 | 机房搬迁期间暂停；设备退役后失效 |
频率表达要避免歧义。“每月”需要配合起算点才能确定具体日期；“每两周”要说明从哪一周开始计算。跳过与顺延是实际运行中最容易出问题的字段：如果上一周期任务未完成，照常生成会造成任务堆积，直接跳过又可能漏掉必要检查，常见做法是照常生成但在任务中标注上一周期未关闭，由负责人决定合并处理。顺延要设上限，超过上限转为逾期提醒，防止规则在无人注意时长期空转。
角色与交付物：谁维护规则、谁执行、谁验收
规则的生命周期涉及三类角色，职责和交付物需要分开写清楚，避免规则建好后无人维护、任务生成后无人认领。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 规则所有者 | 维护字段表，决定频率、跳过与顺延口径，处理暂停与失效，定期复审 | 规则字段表、变更记录、复审结论 |
| 执行人 | 接收生成的任务，按任务内容执行，提交交付物，反馈无法执行的原因 | 执行记录、交付物、异常说明 |
| 验收或复核人 | 依据完成判定检查交付物，确认通过或退回 | 验收结论、退回原因 |
规则所有者通常由这项工作所属团队的负责人担任，而不是由搭建工具的人长期兼任。执行人收到任务后，如果发现任务内容缺失或时间不合理，应在执行前反馈给规则所有者，而不是自行修改规则。验收人依据完成判定逐项核对，判定标准写在字段表里，避免每次验收标准不一致。
规则变更时需要交接：所有者变更时移交字段表和变更记录；执行人轮换时更新负责人和替补人字段；频率或口径调整时，在变更记录中写明调整原因和生效时间，并通知受影响的执行人和验收人。变更生效前已生成的任务按原规则执行完毕，避免中途改变判定标准。
在工具承载层面，规则最终要落到具体的工作项上。以ONES为例，周期任务可以按设定的周期自动生成工作项，任务内容、负责人和完成状态在同一处记录，规则调整后新生成的任务按新口径执行，历史任务保留原记录，便于规则所有者对照检查。这里的关键是让规则的字段与工作项字段对应起来，而不是把规则散落在聊天记录和口头约定中。
示例：一条月度巡检规则从定义到跑通
以下示例为演示情景，用于说明规则从填写到执行、验收的全过程。
规则定义。某团队负责一间机房的日常运维，需要每月执行一次巡检。规则所有者按字段表填写：规则名称“机房月度巡检”；触发方式为日历周期；频率每月1次；起算点为每月第一个工作日09:00，时区UTC+8；提前1个工作日生成；遇法定节假日顺延至下一工作日，最多顺延3个工作日；任务标题“机房月度巡检-{月份}”，附巡检项清单，包括温湿度、供电、网络设备指示灯、消防设施四项；负责人为运维A，替补运维B；交付物为巡检记录表和异常项处理单；完成判定为运维负责人确认记录完整且异常项已登记；机房搬迁期间暂停，设备退役后失效。
生成与分配。3月第一个工作日为3月3日，规则在2月28日提前生成任务“机房月度巡检-3月”，分配给运维A。任务内容中包含四项巡检清单和记录表模板，运维A打开任务即可开始工作，无需再询问巡检范围。
执行中的异常。运维A在巡检中发现一处网络设备指示灯异常，按任务内容登记异常项处理单，并将该异常项转给网络负责人跟进。巡检记录表在任务中提交，任务状态改为待验收。此时运维A没有直接关闭任务，因为完成判定要求异常项已登记，登记动作已完成，但验收尚未进行。
验收与调整。运维负责人核对巡检记录表四项齐全、异常项处理单已登记，确认通过并关闭任务。运行两个月后，规则所有者发现巡检项清单中缺少空调滤网检查，在变更记录中注明增加该项并写明生效月份，通知运维A和验收人。此后生成的任务按新清单执行，已关闭的历史任务保留原记录。
这个示例说明，规则跑通的关键不在触发配置本身，而在任务内容是否完整、异常是否有去处、验收是否有依据。三者缺一，规则就会退化为一条定期出现的提醒。
上线前与运行中的完成检查
规则设计完成后，用以下清单逐项核对，判断是否可以上线；上线运行一个周期后，再用运行检查项确认规则是否有效。
上线前检查：
- 字段表中频率、起算点、时区、跳过与顺延均已填写，没有“定期”“视情况”这类无法判断的表述。
- 每条规则都有明确的规则所有者和替补人，负责人字段不为空。
- 任务内容包含执行人开始工作所需的全部信息，抽查一名未参与设计的执行人，确认其能独立理解任务要求。
- 完成判定写明验收人和判定依据，验收人确认认可该标准。
- 暂停与失效条件已写明，并告知相关角色。
运行一个周期后的检查：
- 生成时间与起算点一致，提前生成的天数符合设定。
- 生成的任务内容完整，负责人分配正确，没有出现无人认领的任务。
- 跳过与顺延按口径执行，节假日或上一周期未完成时的处理结果符合预期。
- 验收记录可追溯，退回原因具体，没有出现“默认通过”的情况。
异常排查：出现重复生成时，先检查是否有多个规则命中同一对象，再检查事件触发是否因状态反复变化而多次触发；出现该生成而未生成时，检查规则是否处于暂停状态、起算点是否因顺延被推后、负责人是否已离职导致任务无法分配。暂停的规则要记录暂停原因和恢复条件，失效的规则从活跃列表中移除但保留历史记录。
定期复审：建议在以下情况触发复审：业务节奏变化导致频率不再匹配、连续两个周期出现逾期或跳过、负责人或验收人变更、相关设备或流程退役。复审由规则所有者发起，输出复审结论并更新字段表和变更记录。通过标准是：规则仍能生成执行人可直接开始的任务，验收仍能依据记录做出判断，跳过与顺延没有造成任务堆积或漏检。
常见问题
上一周期的任务还没完成，下一个周期的任务要不要照常生成？
这取决于字段表中“跳过规则”的口径，常见做法有三种：照常生成并在任务中标注上一周期未关闭，由负责人决定合并处理；直接跳过本周期；暂停规则直到上一周期关闭。照常生成适合检查项之间相互独立的例行工作，跳过适合上一周期未完成时本周期执行没有意义的情况。无论选哪种，都要在规则中写明，并设置顺延上限，超过上限转为逾期提醒，避免任务长期堆积或规则空转。
跨地区团队设置周期任务时，时区和起算点怎么处理？
字段表中单独设“时区”字段，写明规则按哪个时区计算起算点，例如 UTC+8。跨地区团队常见两种处理：统一按一个基准时区生成，各执行人按本地时间执行；或按执行人所在时区分别生成。前者规则简单、便于统一核对，后者更贴合本地工作节奏但规则数量会增加。起算点写具体日期或“每月第几个工作日”时，要说明工作日按哪个地区的日历计算，节假日顺延规则也随之一致。
规则所有者换人或者执行人轮换，已经生成的任务怎么处理？
变更生效前已生成的任务按原规则执行完毕，避免中途改变判定标准。所有者变更时移交字段表和变更记录，新所有者确认当前口径后再调整；执行人轮换时更新负责人和替补人字段，已分配给原负责人的任务由原负责人完成或明确交接给新负责人，并在任务中留下交接说明。频率或口径调整时，在变更记录中写明原因和生效时间，通知受影响的执行人和验收人。
运行一段时间后发现任务重复生成，应该从哪里排查？
先检查是否有多个规则命中同一对象，例如日历周期规则和事件触发规则同时覆盖同一类工作，重复时合并为一条任务并注明来源规则。再检查事件触发是否因状态反复变化而多次触发，必要时增加触发条件或设置去重窗口。还要确认完成后排期规则是否在上一次任务被重新打开后再次生成。排查后把结论写进变更记录，并调整字段表中的触发条件或优先级约定。
周期任务规则多久复审一次比较合适？
固定周期复审不是必须，更实用的是按触发条件复审：业务节奏变化导致频率不再匹配、连续两个周期出现逾期或跳过、负责人或验收人变更、相关设备或流程退役。复审由规则所有者发起，核对规则是否仍能生成执行人可直接开始的任务、验收是否仍能依据记录做出判断、跳过与顺延是否造成堆积或漏检，输出复审结论并更新字段表和变更记录。
