周期任务规则已经配置，实际却没有按预期生成，排查时先别急着改配置。把“不生效”拆成完全没生成、生成时间偏移、生成内容或负责人错误三类，再按规则状态与时间口径、触发前置条件与权限、执行记录验证、修复后观察完整周期的顺序逐项核对。每一步都以生成记录或运行日志为依据，能更快定位是规则未触发，还是触发后生成失败。
要点总览（TL;DR）
- 先把“不生效”拆成完全未生成、生成时间偏移、生成内容或负责人错误三类，记录预期时间、实际结果和影响范围，排查才有明确起点。
- 规则自身优先核对四项：启用状态与生效起止日期、周期表达式与重复方式、时区与系统时间口径、触发时间点是否晚于规则创建或修改时间。
- 规则配置正确仍可能不生成，需检查负责人与参与人是否有效、任务状态与模板字段是否满足条件、执行身份权限是否覆盖目标项目、目标项目是否归档或锁定。
- 判断规则未触发还是触发后失败，关键证据是执行记录或运行日志中是否存在触发尝试；无记录回到规则与前置条件，有记录则看失败原因与报错。
- 修复后至少观察一个完整周期，以连续两个周期按预期生成且无报错作为恢复标准，并把上线前四项核对写入团队约定。
先确认症状：没生成、生成晚了还是生成错了
“不生效”是一个笼统描述，不同表现对应的原因范围差别很大。先把它归入下面三类之一，排查才有明确起点。
| 症状类型 | 可观察表现 | 优先怀疑方向 |
|---|---|---|
| 完全未生成 | 到了预期时间，目标项目或任务列表中没有出现任何新任务 | 规则未启用、已过生效期、前置条件不满足、权限不足 |
| 生成时间偏移 | 任务生成了，但比预期早或晚，或落在非工作日 | 周期表达式、时区口径、触发时间点与创建时间的关系 |
| 生成内容或负责人错误 | 任务出现了，但负责人、状态、字段值与模板预期不一致 | 模板字段映射、负责人已停用、规则取值来源变化 |
记录症状时，至少写清三项信息：首次发现的时间、规则的预期生成时间、实际结果。再确认影响范围——是单条规则异常，某个周期（如每月末）异常，还是全部周期任务都没有生成。影响范围能直接缩小排查面：单条规则异常多指向该规则的配置，全部周期任务异常则要优先看系统时间、执行服务或整体权限。
建议用一张简单的症状记录表固定下来，后续排查和复盘都基于同一份事实：
| 规则名称 | 预期生成时间 | 实际结果 | 首次发现时间 | 影响范围 |
|---|---|---|---|---|
| （填写） | （填写） | 未生成 / 晚于预期 / 内容错误 | （填写） | 单条规则 / 某周期 / 全部 |
规则设置层面的边界条件排查
症状记录完成后，先回到规则自身。规则配置中有几类边界条件容易被忽略，它们单独出现时往往不会报错，只会让规则“安静地不执行”。
状态与生效范围
确认规则处于启用状态，没有被手动停用或保存为草稿。检查规则是否设置了生效起止日期，当前日期是否已超出该区间。若规则是从其他项目复制或由他人转交的，还要确认生效范围是否覆盖了目标项目，而不是仍指向原项目。
周期表达式与重复方式
逐项核对重复方式与业务预期是否一致：按天、按周、按月的规则，起始日和间隔设置不同，生成日期会明显不同；按工作日重复的规则，遇到法定节假日和调休时是否顺延，取决于规则本身的定义。月末、闰年2月29日、跨年周次等特殊日期，要单独确认规则在这些日期上的实际行为，不能默认它一定按自然月最后一天处理。
时区与系统时间口径
规则中设置的触发时间按哪个时区解释，与团队实际查看任务的时间口径是否一致，是时间偏移类问题的高发点。跨时区协作的团队尤其要确认：规则按服务器时区还是按成员本地时区计算，夏令时切换期间触发时间是否发生偏移。系统时间与规则时间口径不一致时，规则可能“按时”执行，只是执行时刻与预期相差数小时。
触发时间点与任务创建时间的关系
如果规则的触发时间点早于规则创建或最近一次修改的时间，当天这一次触发通常已经错过，需要等到下一个周期。排查时把规则创建时间、最近修改时间与触发时间点放在一起对照，能解释“配置完当天没生成、第二天才正常”这类现象。
把以上各项整理成核对清单，逐项标注“符合”或“存疑”，存疑项进入下一步验证：
- 规则启用状态：启用 / 停用 / 草稿
- 生效起止日期：是否覆盖当前日期
- 生效范围：是否包含目标项目
- 重复方式与间隔：与预期是否一致
- 特殊日期处理：月末、闰年、节假日、调休
- 时区口径：与团队查看口径是否一致
- 触发时间点：是否晚于规则创建或修改时间
触发前置条件与权限范围的影响
规则本身配置正确，仍可能因为缺少触发所需的条件而不生成任务。这类问题不会体现在规则设置页，需要到任务、项目和权限层面核对。
人员条件
检查规则依赖的任务负责人、参与人是否为空，相关成员账号是否已停用或移出项目。以“负责人”作为分配依据的规则，如果原负责人离职或账号停用，规则可能找不到可分配对象而跳过生成。规则由谁创建、以谁的身份执行，也要确认该账号仍然有效。
状态与模板字段
部分规则要求源任务处于特定状态，或要求模板中的必填字段已有值。源任务状态被改动、模板字段被清空或字段选项被删除，都会让规则在判断阶段就不满足条件。核对时以规则定义中列出的条件为准，逐条对照当前数据。
权限与可见范围
规则创建者和执行者的权限需要覆盖目标项目。若规则执行身份对目标项目只有只读权限，或目标项目不在其可见范围内，规则可能无法写入新任务。项目成员调整、角色变更后，这类问题会延迟暴露。
项目与列表状态
目标项目或任务列表处于归档、锁定等不可写入状态时，规则即使触发也无法落地生成。排查时确认目标项目未归档、列表未锁定，且没有其他限制写入的配置。
对以上每一项给出明确结论，形成前置条件与权限的验证记录：符合、不符合、无法确认。无法确认的项，留到下一节用执行记录和最小化复现来验证。
用执行记录和日志验证原因
前面的核对产生的是假设，这一节要把假设变成证据。核心判断只有一个：规则到底有没有被触发。
先看有没有触发尝试
查看规则的执行记录或运行日志，确认在预期时间点前后是否存在触发尝试。ONES Automation 提供详细的运行日志，可展示规则的运行状态，用于排查规则问题；统一的管理平台也便于对规则做集中监测。日志中是否存在对应时间点的执行条目，是区分两类原因的关键证据。
有触发记录但未生成
说明规则已被触发，失败发生在执行阶段。此时重点看失败原因与报错信息：是权限不足、目标对象不可写入、字段校验未通过，还是执行超时。报错信息通常能直接指向具体条件，按报错逐项修正即可。
无触发记录
说明规则没有进入执行阶段，回到前两节继续排查：规则状态与生效范围、周期表达式与时区口径、触发前置条件是否满足。此时修改执行侧配置通常无效，应优先修正规则定义或前置数据。
用最小化复现控制变量
对存疑项做单次最小化复现：复制一条规则，只保留最少的条件和最简单的周期，指向一个测试项目，观察是否按预期生成。每次只改动一个变量——先改时区，再改负责人，再改权限——记录每次改动后的结果。这样能把多个可疑因素逐一排除，避免一次性改多处后无法判断哪一处起了作用。
| 原因假设 | 验证方式 | 证据 | 结论 |
|---|---|---|---|
| 规则未启用或已过生效期 | 查看规则状态与生效日期 | （填写） | 成立 / 排除 |
| 时区口径不一致 | 对照日志时间与预期时间 | （填写） | 成立 / 排除 |
| 负责人停用导致无法分配 | 查看成员状态与日志报错 | （填写） | 成立 / 排除 |
| 执行身份权限不足 | 最小化复现，替换执行身份 | （填写） | 成立 / 排除 |
| 目标项目不可写入 | 检查项目归档与锁定状态 | （填写） | 成立 / 排除 |
处置步骤与恢复验证
原因确认后，按风险从低到高处置。配置类问题优先直接修正，涉及批量操作时先备份、再动手。
第一步：修正配置类问题
按顺序处理状态、时间、负责人、权限四类问题：启用规则并调整生效日期；统一时区口径并核对触发时间点；更换或补充有效负责人；为执行身份补齐目标项目权限。每改一项，记录修改前后的值，便于回溯和对比。
第二步：批量修改前先备份
需要批量调整多条规则或重建规则时，先导出或截图保存现有规则配置，明确本次操作的停止点——例如只处理受影响的规则，不触碰其他正常运行中的规则。批量修改后先在小范围验证，确认无误再推广。
第三步：观察完整周期
修复后不要立即下结论，至少观察一个完整周期，核对生成时间、任务内容和负责人是否符合预期。对于按月或按季度的规则，观察窗口相应拉长。
恢复的判断标准
以连续两个周期按预期生成、且执行记录中无报错作为恢复标准。只恢复一个周期就关闭问题，容易漏掉与时序相关的偶发因素。恢复验证记录中写明：修复动作、验证周期、生成结果、是否仍有报错。
减少复发的日常检查与交接约定
本次排查的结论值得沉淀为固定动作，让同类问题在下次上线前就被拦住。
上线前四项核对
新规则上线前，固定核对状态、时区、负责人、权限四项：规则已启用且在生效期内；时区与团队查看口径一致；负责人和参与人账号有效；执行身份对目标项目有写入权限。四项都确认后再启用规则。
人员变动与项目归档时同步检查
成员离职、转岗或项目归档时，把相关周期规则列入检查范围：负责人是否需要替换，规则生效范围是否仍指向有效项目，归档项目上的规则是否需要停用。这类变动是规则静默失效的常见诱因。
定期查看执行记录
安排固定频率查看规则执行记录，发现连续失败及时处理，避免小问题积累成整月任务缺失。ONES Automation 的统一管理平台可用于集中监测规则运行状态，降低逐条排查的成本。
写入团队约定
把规则负责人和检查时点写进团队约定：每条周期规则有明确的责任人，上线前核对与定期复查有固定节奏。规则责任人变更时同步更新约定，确保检查动作有人承接。
| 检查项 | 检查时点 | 责任人 |
|---|---|---|
| 规则状态与生效期 | 上线前 | （填写） |
| 时区与触发时间口径 | 上线前、跨时区协作调整时 | （填写） |
| 负责人与参与人有效性 | 上线前、人员变动时 | （填写） |
| 执行身份权限 | 上线前、角色变更时 | （填写） |
| 执行记录复查 | 按固定频率 | （填写） |
常见问题
规则配置后当天没有生成，第二天却正常了，是什么原因？
常见原因是触发时间点早于规则的创建或最近一次修改时间。当天那一次触发时刻已经过去，规则只能等到下一个周期执行，所以表现为“配置完当天没生成、第二天才正常”。
排查时把规则创建时间、最近修改时间与触发时间点放在一起对照。如果确认是这个原因，属于正常行为，无需修改配置；若业务要求当天立即生成一次，可以手动创建一次任务，或把触发时间点调整到当前时间之后。
执行记录里没有任何触发条目，还需要继续查权限吗？
可以先查，但优先级放在规则定义之后。没有触发记录说明规则没有进入执行阶段，此时权限问题通常不是首要原因，更常见的是规则未启用、已过生效期、周期表达式或时区口径不符、触发前置条件不满足。
建议先核对规则状态与时间口径，再检查负责人、状态与模板字段等前置条件。权限问题更多表现为“有触发记录但生成失败”，可以在确认规则确实被触发后再重点验证。
按月重复的规则在月末和闰年2月表现不一致，怎么确认是否符合预期？
月末和闰年属于特殊日期，不同规则定义对“每月最后一天”的处理方式可能不同：有的按自然月最后一天，有的固定为某一天，遇到该月没有这一天时顺延或跳过。这类差异不会报错，只会让生成日期与预期不同。
确认方法是查看规则定义中对特殊日期的说明，再用一个测试项目做单次最小化复现，观察2月、4月等月份的实际生成日期。把观察结果与业务预期对照，不一致时调整重复方式或触发日期，而不是等到月末才发现任务缺失。
修复后观察一个周期就恢复正常，可以关闭问题吗？
建议再观察一个周期。只恢复一个周期就关闭，容易漏掉与时序相关的偶发因素，例如跨时区协作在特定日期偏移、月末与工作日规则叠加等情况。
恢复的判断标准是连续两个周期按预期生成，且执行记录中无报错。对于按月或按季度的规则，观察窗口相应拉长。恢复验证记录中写明修复动作、验证周期、生成结果和是否仍有报错，便于后续复盘。
团队成员离职或项目归档后，周期规则需要做哪些检查？
人员变动和项目归档是规则静默失效的常见诱因。成员离职或转岗时，检查以该成员为负责人的规则是否需要替换负责人，规则执行身份是否仍然有效；项目归档时，检查生效范围是否仍指向有效项目，归档项目上的规则是否需要停用。
建议把这类检查写入交接约定：人员变动或项目归档发生时，同步核对相关周期规则的状态、负责人、生效范围和权限，确认后再继续运行，避免任务在无人察觉的情况下停止生成。
