Jira 替换上线后，原插件承载的自动化规则突然不跑了，是迁移后最常见也最容易被误判的问题之一。它可能表现为状态变更后无人流转、字段更新后通知不发、定时规则不再执行。定位时建议按“先界定失效范围，再核对字段与数据映射，然后检查权限与触发器，最后验证自动化执行链”的顺序推进，每一步先取证再改配置，避免在原因未明时反复调整生产规则。
要点总览（TL;DR）
- 先界定失效范围：区分全部自动化失效与仅原插件相关规则失效，记录触发条件、执行动作、报错信息和失效起始时间，再决定排查方向。
- 按四类原因假设取证：字段与选项映射缺失、权限与执行账号变更、触发器事件不等价、原插件私有逻辑无对等能力，每类都用代表性工作项验证。
- 处置顺序为字段映射、权限与工作流条件、触发器与规则重建、单条规则重放，每次只改一条规则，改前备份生产配置。
- 恢复验证要覆盖事件触发、条件判断和通知类规则，走完真实业务链路并记录结果；同时建立规则巡检告警和插件能力对照清单防止复发。
失效表现与影响范围怎么界定
排查的第一步是把“自动化失效”拆成可观察、可记录的症状，并划定边界。范围界定清楚，后续才能判断问题指向平台级配置还是个别插件规则的映射缺失。建议先回答四个问题，再动手改任何配置。
第一，分清是全部自动化失效，还是仅原插件相关规则失效。如果新系统中所有自动化规则都不执行，问题更可能出在执行环境、全局权限或事件机制层面；如果只有原来由插件承载的那部分规则失效，而标准规则正常运行，排查重点应放在插件能力的映射与替代上。
第二，逐条记录失效规则的关键信息：触发条件是什么（状态变更、字段更新、定时、评论等），执行动作是什么（流转、赋值、通知、创建子任务等），是否有报错信息或执行日志，最近一次成功执行是什么时候。这些记录是后续验证原因假设的基础证据。
第三，确认失效发生的时间点与替换上线节点的关系。规则是在切换当天开始失效，还是在某个配置调整之后才失效，指向的原因并不相同。如果失效时间与上线时间吻合，优先怀疑迁移过程中的配置映射；如果滞后出现，则要检查上线后的权限或流程调整。
第四，明确受影响的工作项类型、字段和团队范围。是某一类工作项的全部规则失效，还是特定字段、特定项目、特定团队范围内失效。范围越具体，越容易用少量代表性工作项做对照验证。
| 记录项 | 填写内容示例 | 用途 |
|---|---|---|
| 失效范围 | 全部自动化 / 仅原插件相关规则 | 判断问题层级 |
| 触发条件 | 状态从“进行中”变为“已完成” | 核对触发器是否有等价事件 |
| 执行动作 | 自动指派给测试负责人并发送通知 | 核对动作所需权限与字段 |
| 报错与日志 | 无报错 / 提示字段不存在 | 直接指向原因类别 |
| 失效起始时间 | 替换上线当日 | 关联迁移节点 |
| 受影响对象 | 缺陷类工作项、严重程度字段、A 团队 | 确定验证样本 |
完成这张表后，排查边界基本清晰：哪些规则需要逐条核对，哪些可以先排除。接下来再进入原因分析，避免把范围问题误当成能力问题。
原插件能力断点的常见原因与排除证据
替换后原插件自动化失效，常见原因可以归为四类：字段与选项映射缺失、权限与执行账号变更、触发器与事件机制差异、原插件私有逻辑缺少对等能力。每一类都需要用证据确认，未经验证的假设不能直接写成结论，更不能据此判定新系统不支持某项能力。
字段与选项映射缺失或类型不兼容
原插件常依赖特定字段类型或选项值来驱动自动化，例如单选字段的某个选项、级联字段的层级值、自定义字段的数值区间。迁移后如果字段类型改变、选项值未完整迁移或字段键名变化，规则即使存在也无法正确匹配。验证方式是选取少量代表性工作项，逐项对照原系统与新系统中该字段的类型、选项集合和取值，确认规则条件中引用的字段在新系统中确实存在且取值一致。发现缺失项时记录为映射缺口，而不是直接归因于自动化功能本身。
权限与执行账号变更
自动化规则通常以某个执行账号身份运行。替换后如果执行账号未建立、权限范围收窄，或目标工作项所在项目的权限方案不同，动作就会被拦截，表现为规则“静默失败”。验证方式是核对规则的执行身份，确认该账号对目标工作项类型具备读取、编辑和状态流转权限，并检查工作流条件是否在特定状态下阻止了动作。可以用一条规则在测试工作项上手动触发，观察是否出现权限相关提示。
触发器与事件机制差异
原插件可能监听特定事件来触发规则，例如字段值变更事件、评论添加事件或定时扫描。新系统的触发点定义、事件粒度和触发时机可能不同，导致规则条件成立却不触发。验证方式是确认规则配置的触发事件在新系统中是否存在等价项，并用一次真实操作（如实际修改状态或字段）观察规则是否被唤起。若手动执行可以成功而事件触发不生效，问题通常集中在触发器配置而非动作本身。
原插件私有逻辑缺少对等能力
部分插件提供的是厂商私有逻辑，例如复杂的条件计算、跨项目汇总或特定格式的自动生成。这类能力在替换后可能没有直接对应项。识别方法是把规则拆解为“输入条件—处理逻辑—输出动作”，逐段判断新系统的标准能力、流程自动化或开放能力能否承接。无法立即承接的部分应登记为待评估项，通过配置替代或接口扩展解决，在评估完成前不将其定性为不支持。
| 原因假设 | 验证证据 | 处置方向 |
|---|---|---|
| 字段或选项映射缺失 | 代表性工作项字段类型、选项值对照结果 | 补齐字段与选项，修正规则条件 |
| 权限或执行账号受限 | 执行账号权限核对、手动触发提示 | 调整账号权限或工作流条件 |
| 触发器事件不等价 | 真实操作后规则是否被唤起 | 改用等价触发点或调整触发时机 |
| 私有逻辑无对等能力 | 规则拆解后逐段能力匹配结果 | 用标准能力、流程自动化或开放能力承接 |
在 ONES 的 Jira 迁移场景中，迁移方案覆盖项目、工作项、状态、字段、流程、附件和历史记录，也覆盖问题类型、工作流、字段配置、权限配置等系统配置，这为字段与权限层面的对照提供了基础。对于原来依赖 Jira 插件的功能，ONES 的建议是先梳理实际使用的插件，再通过 ONES Project、Wiki、TestCase、流程自动化和开放能力进行功能匹配，企业已有的定制场景在迁移前逐项评估。这一思路同样适用于失效后的原因定位：先确认原插件规则依赖了什么，再确认新系统中对应配置是否到位。
按什么顺序逐层排查与处置
原因假设列出后，按由静到动、由数据到执行的顺序处置，可以把改动控制在最小范围。建议按以下四步推进，每一步留下处置记录。
第一步，核对字段与选项映射并补齐缺失项。以失效规则引用的字段为清单，逐项确认新系统中的字段是否存在、类型是否一致、选项值是否完整。缺失的字段或选项先补齐，再回到规则中修正条件引用。这一步只做数据与配置的对照和补全，暂不调整规则逻辑，便于区分“映射问题”与“规则问题”。
第二步，检查权限、执行账号与工作流条件。确认每条规则的执行身份有效，具备目标工作项的读写与流转权限；检查工作流中是否存在阻止动作的条件或校验。若执行账号需要新建或授权，按最小必要权限配置，并记录变更内容。
第三步，重建或调整触发器与自动化规则。在字段和权限确认无误后，再处理触发机制。对触发事件不等价的规则，改用新系统中语义最接近的触发点；对私有逻辑无法直接对应的规则，按“条件—逻辑—动作”拆解后重组。调整时保留原规则的条件描述作为对照，避免重建过程中遗漏分支。
第四步，单条规则重放验证。每次只启用或重放一条规则，用真实或测试工作项走完整流程，观察触发、条件判断、动作执行和结果记录。一条通过后再处理下一条，避免多条规则同时变更导致问题难以归因。
涉及生产配置的修改需要设定风险边界：改动前导出或备份当前规则与相关字段配置；条件允许时先在测试环境或小范围灰度项目中验证；出现非预期结果立即停止后续改动并回退到备份版本。对于影响面广的全局规则，建议安排在业务低峰期操作，并提前告知受影响的团队。
恢复验证与复发预防
规则重放通过不等于自动化已完全恢复。需要用代表性规则做端到端验证，并建立机制防止同类断点再次出现。
端到端验证应覆盖不同类型的规则：至少包含一条事件触发型、一条条件判断型和一条涉及通知或跨对象动作的规则。验证时从真实业务操作开始，走完触发、执行、结果可见的完整链路，并记录验证时间、操作人、工作项编号和结果。验证记录既是恢复依据，也是后续排查的基线。
复发预防可以从三个方面着手。其一，建立替换后自动化规则的巡检机制，定期检查规则启用状态、最近执行记录和失败次数，对连续失败或长期未触发的规则设置告警，让问题在影响业务前被发现。其二，在迁移清单中登记原插件能力与替代方案的对应关系，注明每条规则的触发条件、执行动作、承接方式和负责人，后续新增或调整规则时可直接对照，减少遗漏。其三，明确复发时的回退与上报路径：先判断影响范围，必要时暂停相关规则并回退到已验证版本，同时按登记的责任人上报，保留现场证据供后续分析。
在 ONES 中，工作项字段、状态流转和流程自动化规则的配置可以在同一套项目体系内核对，迁移方案也把数据完整、业务连续和系统稳定作为目标，并支持国产化、私有化以及安全合规相关要求。把字段映射表、规则对照清单和验证记录沉淀在迁移文档中，能让替换后的自动化维护从一次性排查转为可复用的日常管理。
常见问题
替换上线后只有部分自动化规则失效，还需要检查全局配置吗？
可以先做一次快速排除：确认新系统中与失效规则无关的标准自动化是否正常运行。如果标准规则正常，全局执行环境和事件机制大概率没有问题，排查重点应放在失效规则自身的字段引用、执行账号和触发条件上。如果标准规则同样不执行，再检查全局权限、自动化服务状态和事件机制。这个判断能避免在个别规则上反复调整，却漏掉平台层面的原因。
原插件规则依赖的字段在新系统中类型变了，应该改字段还是改规则？
先确认该字段在业务上的实际用途和已有数据。如果新系统支持更合适的字段类型，且历史数据可以重新映射，优先调整字段并同步迁移数据，再修正规则中的条件引用；如果字段类型受流程或报表依赖，改动成本高，则保留字段并在规则层做取值转换。两种做法都需要在测试工作项上验证规则条件能否正确匹配，确认后再推广到生产规则。
规则手动执行成功但事件触发不生效，问题通常出在哪？
手动执行成功说明动作本身和权限基本可用，问题集中在触发环节。依次核对三点：规则配置的触发事件在新系统中是否存在语义等价项；触发条件中的字段或状态判断是否与实际操作产生的值一致；事件发生时执行账号是否有权读取触发对象。用一次真实的状态变更或字段修改观察规则是否被唤起，可以快速缩小范围。
原插件的复杂逻辑在新系统中找不到直接对应项，怎么处理？
把规则拆成“输入条件—处理逻辑—输出动作”三段，逐段判断新系统的标准能力、流程自动化或开放能力能否承接。能承接的部分先配置替代规则并验证；暂时无法承接的部分登记为待评估项，注明业务影响和负责人，通过配置调整或接口扩展解决。评估完成前按待办项管理，避免把未验证的假设当成能力缺失的结论。
多条规则同时失效时，如何避免改一条坏一片？
按依赖关系排序处理：先修被其他规则引用的字段和选项，再修权限与执行账号，最后处理触发器和规则逻辑。每次只启用或重放一条规则，用真实或测试工作项走完整链路，通过后再处理下一条。改动前导出当前规则和字段配置，影响面广的全局规则安排在业务低峰期操作，出现非预期结果立即停止并回退到备份版本。
