业务验收阶段发现关键流程不可用，是迁移切换前最常见的卡点。此时团队往往面临两难：继续切换可能把问题带进生产，暂停切换又担心影响整体进度。本文给出一套可操作的判定方法，先把“不可用”拆成具体症状，再用业务影响面、发生频率、绕行方案、数据可恢复性四条标准判断是否阻断，最后落到分级处置与修复后的复验安排，帮助团队用同一口径做决策。
要点总览（TL;DR）
- 先把“关键流程不可用”拆成功能缺失、功能异常、数据缺失三类症状，附件缺失要区分“数据未迁移”和“迁移后不可见”，两类问题的排查方向不同。
- 用业务影响面、发生频率与触发条件、绕行方案、数据可恢复性四个维度判定是否阻断：四维同时命中高风险判为阻断，暂停切换；部分命中进入有条件放行评估。
- 处置按三档分级：P0阻断级暂停切换并指定修复责任人与复验时点；P1有条件放行级限期修复、设临时绕行和观察窗口；P2不阻断级纳入切换后整改清单。
- 修复后以原验收用例重跑为主，补充边界数据与权限组合验证，关键流程端到端跑通、附件可正常打开、数据抽样一致后才重新申请切换。
- 把本次问题补进验收用例库和迁移检查清单，在迁移前核对数据完整性与权限，减少同类问题在下次迁移中重现。
业务验收中的“不可用”具体指什么
“关键流程不可用”是一个笼统描述，直接拿它讨论是否阻断，容易各说各话。验收阶段需要先把现象记录成可判定的症状，再判断它属于功能缺失、功能异常还是数据缺失。三类症状的处置路径不同，混在一起讨论会拖慢决策。
典型症状可以归为以下几类：
| 现象 | 所属类型 | 初步影响对象 |
|---|---|---|
| 提交审批后流程停在中间节点，无法继续流转 | 功能异常 | 发起人、审批人、下游执行角色 |
| 工作项状态无法从“处理中”推进到“已完成” | 功能异常 | 一线执行人员、项目负责人 |
| 迁移前存在的附件在迁移后找不到，或点击后无法打开 | 数据缺失或功能异常 | 依赖历史资料开展工作的角色 |
| 原本能查看的记录，迁移后提示无权访问；或低权限角色看到了不该看的数据 | 功能异常（权限配置） | 数据归属角色、合规责任人 |
| 报表统计条数与源系统对不上，字段值出现错位 | 数据缺失或数据错误 | 管理层、报表使用方 |
| 原系统有的某个操作入口，新系统里不存在 | 功能缺失 | 使用该操作的角色 |
区分三类症状的意义在于：功能缺失通常需要评估替代方案或调整流程；功能异常要定位是配置、权限还是环境问题；数据缺失则要先确认是“数据未迁移”还是“迁移后不可见”。附件问题尤其典型——文件根本没迁过来，属于数据完整性问题；文件已迁入但打不开，可能是权限、存储路径或格式问题，排查方向完全不同。
本文讨论的范围限于验收阶段发现的问题如何判定和处置。数据映射规则、字段转换方案的设计属于迁移准备阶段的工作，不在本文展开；切换后的人员培训与推广机制也另作安排。
判断是否阻断切换的四条标准
判定是否阻断，建议固定使用四个维度，每个维度给出高、中、低三档，再按组合规则得出结论。这样做的目的是让不同角色在同一张表上讨论，减少“我觉得能上”和“我觉得不能上”的拉锯。
| 维度 | 高 | 中 | 低 |
|---|---|---|---|
| 业务影响面 | 核心业务链路中断，多个角色无法开展主业务 | 核心链路可走通，但某个环节效率明显下降或部分角色受影响 | 非核心流程或个别角色的体验问题 |
| 发生频率与触发条件 | 必现，且覆盖常规数据与常规权限 | 在特定数据、特定权限或特定时段出现 | 偶发，难以稳定复现，影响有限 |
| 绕行方案 | 无临时绕行，业务只能停摆 | 有短期绕行方案，但需要人工补录或旁路操作，成本可接受 | 有成熟替代路径，切换后业务基本不受影响 |
| 数据可恢复性 | 数据无法补齐，或补齐成本与时间不可接受 | 数据可补齐，但需要明确责任人和补录窗口 | 数据完整，或缺失数据不影响业务判断 |
组合判定规则如下：四个维度同时落在“高”，判为阻断，暂停切换；影响面为高但存在可执行的绕行方案，或数据可在短期内补齐的，进入有条件放行评估；影响面为中及以下、且绕行方案成熟的，一般不阻断。需要提醒的是，影响面是首要维度——非核心流程的问题即使必现，通常也不构成阻断；核心链路的问题即使偶发，也要谨慎对待，因为偶发往往意味着触发条件尚未摸清，切换后可能放大。
判定时还要记录证据，而不是只写结论。例如“审批流程在测试环境用三组常规数据复现，均停在二级审批”，比“审批流程有问题”更有助于后续决策和复验。
问题分级与对应处置动作
判定结果落到处置上，建议分为三档，每档明确判定条件、处置动作、决策角色和复验要求。分级不是给问题贴标签，而是让每个问题都有明确的下一步和责任人。
| 级别 | 判定条件 | 处置动作 | 决策角色 | 复验要求 |
|---|---|---|---|---|
| P0 阻断级 | 核心链路完全不可用，无绕行方案，或数据无法补齐 | 暂停切换；评估回退或延长并行期；指定修复责任人与修复时限 | 业务负责人与迁移负责人共同确认 | 原验收用例全部重跑通过，方可重新申请切换 |
| P1 有条件放行级 | 核心链路可用，存在明显缺陷但有短期绕行方案，数据可补齐 | 限期修复；明确临时绕行流程与责任人；设置切换后观察窗口和升级触发条件 | 业务负责人确认绕行方案可接受 | 修复后按原用例复验，观察期内每日检查关键流程 |
| P2 不阻断级 | 非核心流程或体验类问题，不影响主业务开展 | 纳入切换后整改清单，约定跟踪方式与完成时间 | 迁移负责人登记，业务方知会 | 按整改清单节点验收，不阻塞切换 |
附件缺失需要单独走一遍定位流程再归级。第一步确认文件是否在迁移范围内、迁移记录中是否存在该文件，判断是“数据未迁移”还是“迁移后不可见”。前者按数据完整性规则处理：如果缺失的是核心业务依赖的历史资料且无法补齐，按 P0 处理；如果缺失范围有限、可通过源系统导出补录，可归入 P1。后者先排查权限配置、存储路径和文件格式三个方向，多数情况下属于配置问题，修复后复验即可，通常归入 P1；若排查发现是系统性格式不兼容，影响面扩大，则重新按四维标准评估。
每一级决策都要留下记录：问题单中写明现象、影响范围、判定依据、决策人和决策时间。决策记录的价值在切换后复盘时尤为明显——它能说明当时为什么放行，以及放行时约定的观察点是否被执行。
验收问题从发现、定级、修复到复验，如果分散在聊天记录和表格里，决策依据容易丢失。ONES 的工作项可以承载问题单，把现象描述、影响范围、级别、责任人和复验结论放在同一条记录上，通过状态流转标记“待定级—修复中—待复验—已关闭”，让业务负责人和迁移负责人看到同一份进展。对于 Jira 或 Confluence 迁移场景，ONES 的迁移方案覆盖项目、工作项、状态、字段、流程、附件和历史记录，以及空间、页面、附件和权限结构，验收阶段发现的问题可以直接对应到迁移范围内的对象，便于定位是迁移遗漏还是使用配置问题。
修复后的复验与复发预防
问题修复不等于可以切换，复验要回答两个问题：原问题是否真正恢复，以及修复是否引入新的影响。复验方法以原验收用例重跑为基础，再补充边界数据和权限组合验证。例如审批流程修复后，除了跑通常规审批，还要用多级审批、退回重提、代理人审批等场景验证；权限问题修复后，要用不同角色账号交叉验证可见范围。
恢复确认建议对照以下清单逐项打勾：
- 关键流程端到端跑通，从发起、流转到归档无中断；
- 附件可正常上传、下载和预览，抽查的历史附件能打开且内容一致；
- 数据条数与源系统抽样比对一致，关键字段值无错位；
- 各角色权限符合预期，越权访问和无权访问两类情况均已验证；
- 原问题单中的复现步骤已无法重现，复验人和复验时间记录在案。
对于 P1 有条件放行的问题，切换后要设置观察期，明确观察时长、每日检查项和升级触发条件。例如连续两天出现同类报错，或绕行方案使用量超过约定阈值，即触发升级，重新评估是否暂停。观察期内一旦发现核心链路受影响，按预案回退，回退触发条件应在切换前就写清楚，而不是临时判断。
复发预防的重点是把本次问题转化为下次迁移的检查项。具体做法包括：把问题现象和复现步骤补进验收用例库；在迁移检查清单中增加数据完整性核对项（条数、抽样、附件可读性）和权限核对项（角色矩阵、越权测试）；对插件依赖或定制场景，在迁移前逐项评估功能匹配情况，避免验收阶段才发现替代功能不可用。ONES 的迁移实践也建议把迁移工具、原厂服务和分阶段切换结合起来，在正式迁移前确认数据范围、功能匹配和系统适配，这与验收阶段的问题预防思路一致。
完成复验并确认恢复后，由决策角色在问题单上签署复验结论，切换申请才重新进入审批。整个过程留下的问题记录、决策依据和复验证据，既是本次切换的放行依据，也是下一次迁移验收的参考底稿。
常见问题
核心流程只是偶发失败，也要按阻断处理吗？
不一定判为阻断，但要谨慎对待。偶发失败往往意味着触发条件尚未摸清，切换后可能被真实数据量或并发放大。建议先做两件事：一是记录复现条件，尽量用不同数据、不同角色账号多跑几轮，判断是特定数据触发还是环境不稳定；二是评估绕行方案是否可执行。如果偶发问题落在核心链路、且暂时无法稳定绕行，按有条件放行处理，设观察窗口和升级触发条件；如果排查后确认影响面有限、有成熟替代路径，可归入不阻断级并持续跟踪。
附件缺失时，怎么快速判断是迁移遗漏还是权限问题？
先查迁移记录：确认该文件是否在迁移范围内、迁移任务中是否存在对应条目。记录中不存在，倾向迁移遗漏，按数据完整性规则处理；记录中存在但用户打不开，倾向迁移后不可见，继续排查权限配置、存储路径和文件格式三个方向。可以用管理员账号与普通业务账号分别访问同一附件做对比，管理员能打开而业务账号打不开，多半是权限问题；都打不开则重点看存储路径和格式兼容性。定位清楚后再归入 P0 或 P1，避免把配置问题误判为数据丢失而过度反应。
P1有条件放行后，观察期内出现什么情况应该升级为暂停？
升级触发条件应在切换前写清楚，常见的有三类：一是同类问题在观察期内重复出现，例如连续两天出现相同报错；二是绕行方案的使用量超过约定阈值，说明临时流程已难以支撑正常业务量；三是核心链路出现新的中断或数据错误。触发后由业务负责人和迁移负责人共同复核，确认影响面扩大就按预案回退，并重新走阻断判定。观察期的每日检查项建议固定下来，包括关键流程是否跑通、附件是否可正常打开、数据条数是否与源系统一致。
多个问题同时存在时，分级处置的先后顺序怎么排？
先处理阻断判定的问题，再处理有条件放行的问题，最后安排不阻断的整改项。同一级别内，按业务影响面排序：影响核心链路和多个角色的问题优先，影响个别角色或非核心流程的靠后。如果多个 P1 问题叠加后导致核心链路实际不可用，应合并评估，按 P0 处理。排好序后把每个问题的责任人、修复时限和复验时点写进问题单，避免修复资源分散在低优先级问题上。
复验通过后，还需要保留哪些记录？
至少保留三类记录：问题单本身，包含现象描述、复现步骤、影响范围、判定依据和级别；决策记录，写明决策人、决策时间和放行时约定的观察点；复验证据，包括重跑的用例、复验人和复验时间、附件抽查结果和数据比对结果。这些记录在切换后复盘时能说明当时为什么放行、约定是否被执行，也可以作为下一次迁移验收的参考底稿。用工作项承载问题单时，把复验结论随状态流转一并留存，比分散在聊天记录里更便于追溯。
