评估研发历史记录遗漏的影响范围，需要把“感觉少了一些记录”转成可复核的结论：先界定评估对象与时间窗，再以应有记录数为基线计算遗漏率和覆盖率，然后按追溯、审计、业务影响三个维度判断后果。结论要说明遗漏集中在哪些对象、哪些时间段、波及哪些下游用途，而不只是一个总数。
要点总览（TL;DR）
- 评估遗漏影响范围先固定对象清单与时间窗，以源端应有记录数为分母，计算遗漏率（遗漏记录数÷应有记录数）与覆盖率，两者互补。
- 基线数据优先用可重复执行的源端导出或接口计数，并保存筛选条件与导出时间；字段合并、状态映射、时间戳精度差异等不可比项单独标注，不并入遗漏数。
- 影响范围按对象类型、项目、月份分层统计，再分别判定追溯影响（关联引用断链数）、审计影响（关键状态变更无法还原条数）、业务影响（受影响版本与发布记录）。
- 分母为零时写“无可评估记录”，不写遗漏率为零；抽样结论需标注抽样比例与置信边界，跨期比较前先统一分母口径。
- 遗漏率反映数据完整性，结论应落到补录清单、切换决策输入或审计说明材料，并附证据清单保证可复核。
评估目标：遗漏影响范围要回答哪几个问题
影响范围评估服务于具体决策，先写清结论将被谁用于什么判断，后续取数和统计才有取舍依据。常见的决策问题有三类：是否需要补录、补录到什么程度；是否具备切换或上线条件，还是先处理高风险遗漏；是否需要向审计、合规或业务方出具说明。三类决策对精度的要求不同，补录决策更关注遗漏集中在哪些对象，切换决策更关注关键链路是否断链，审计说明则要求证据可追溯。
围绕这些决策，评估结论按三个维度展开。追溯维度看记录之间的关联是否还能走通，例如需求与任务、任务与提交记录、缺陷与修复版本之间的引用是否因遗漏而断开。审计维度看状态变更、审批意见、字段修改等过程信息能否还原，重点是有没有关键节点缺失。业务影响维度看遗漏是否波及版本发布记录、验收结论、对外交付物等业务对象。三个维度共用同一套遗漏数据，但判定标准不同，需要分别给出结论。
评估对象和时间窗要在开始前固定。对象类型通常包括需求、任务、缺陷、评论、附件、变更历史等，逐类列出清单，避免只统计主工作项而忽略评论和附件。时间窗按源系统的创建时间或更新时间划定，并明确边界包含规则，例如“2023-01-01 至 2024-12-31 创建且未删除的记录”。时间窗一旦确定，分子分母都按同一口径取数。
本评估聚焦迁移数据内容的完整性，流程配置与插件行为的迁移评估、迁移后的结果核验与切换管理分别属于其他工作，不在本文展开。评估产出是一份目标说明，包含决策问题清单、三个维度的定义、对象清单与时间窗边界，作为后续指标和取数的依据。
指标与范围：遗漏率、覆盖率与影响面怎么定义
指标定义要写到可以复算的程度：每个指标给出公式、分子、分母、单位和统计粒度。遗漏率与覆盖率共用同一个分母，即应有记录数，两者互补，相加为 1（在口径一致的前提下）。分母的确定方式直接决定结果是否可信，通常以源系统在约定时间窗内、按约定对象类型和删除口径统计出的记录数为准。
| 指标 | 公式 | 分子 | 分母 | 单位 | 统计粒度 |
|---|---|---|---|---|---|
| 遗漏率 | 遗漏记录数 ÷ 应有记录数 | 源端存在、目标端缺失的记录数 | 源端应有记录数 | 百分比 | 按对象类型、项目、时间段 |
| 覆盖率 | 实际迁移记录数 ÷ 应有记录数 | 目标端可核对的记录数 | 源端应有记录数 | 百分比 | 同上 |
| 受影响工作项数 | 直接计数 | 存在任一类型遗漏的工作项 | — | 个 | 按项目、版本 |
| 受影响项目数 | 直接计数 | 存在遗漏的项目 | — | 个 | 全量范围 |
| 受影响时间区间长度 | 区间末减区间初 | 遗漏集中出现的时间段 | — | 天 | 按对象类型 |
分层统计是影响范围评估的关键动作。同一遗漏率下，遗漏集中在某个项目的缺陷评论，与均匀分散在所有对象上，处理方式完全不同。因此需求、任务、缺陷、评论、附件、变更历史要分别统计，再按项目和月份交叉分层，找出遗漏集中的区间。统计单位要统一：记录数用“条”，工作项用“个”，时间区间用“天”，同一张表内不混用。
影响面指标回答“波及多大范围”，遗漏率回答“缺了多少”。两者配合使用：遗漏率低但集中在核心项目的发布相关记录上，影响面可能仍然很大；遗漏率偏高但集中在已归档项目的附件上，对当前业务的影响相对有限。评估报告应同时给出这两类结果。
数据口径与证据：应有记录数从哪里来
应有记录数是整个评估的分母，来源必须可追溯。常见取数来源包括源系统按条件导出的记录清单、接口返回的计数、系统日志中的创建记录，以及按项目整理的抽样清单。优先使用可重复执行的导出方式，并保存导出时间、筛选条件和操作人，便于复核。若源系统已停用或权限受限，抽样清单可以作为替代，但要在结论中说明覆盖比例。
源端与目标端的计数口径要对齐。字段映射会改变记录形态：多个源字段合并为一个目标字段、状态值经过映射转换、时间戳精度从秒变为天，这些都会让直接计数失去可比性。处理办法是先列出映射规则，对每条规则标注是否影响计数，再把不可比的部分单独列出，不并入遗漏数。例如状态映射导致两个源状态合并为一个目标状态，这类差异属于口径变化，不应计为遗漏。
抽样核验要留下证据。记录抽样比例、抽样方法（随机、分层、按项目全量）、比对字段和比对结果。抽样比例较低时，结论应写成区间估计或标注置信边界，避免把样本结果直接当作全量结论。对缺失值、重复记录、软删除记录，评估前约定处置口径：软删除记录是否计入应有数、重复记录以哪条为准、空值字段是否算缺失，都要在口径说明中写明。
证据清单建议包含：源端导出文件及筛选条件、目标端对应导出、字段映射规则表、抽样比对记录、不可比项标注表。这份清单既支撑本次结论，也为后续补录和复核提供依据。
计算与评估步骤：从基线到影响结论
评估按固定顺序执行，保证结果可复算、可复核。
- 确定对象清单与时间窗，按对象类型统计源端应有记录数，形成分母基线表。
- 按同一口径统计目标端实际迁移记录数，计算遗漏率与覆盖率，先出总体结果。
- 对遗漏记录按对象类型、项目、月份分层，定位遗漏集中的区间，标出异常集中的项目或时间段。
- 按追溯、审计、业务影响三个维度逐项判定后果：追溯看关联引用断链数量，审计看状态变更和审批记录缺失条数，业务影响看受波及的版本、发布记录和交付物。
- 处理异常情形：分母为零时结论写“无可评估记录”，不写遗漏率为零；存在不可比项时，在总体结果之外单列可比口径下的结果。
- 形成结论，标注置信度和待补证据，明确结论支持的决策类型。
三个维度的判定需要具体标准。追溯维度可统计“关联目标缺失的工作项数”，即引用的需求、任务或提交记录在目标端找不到对应项的数量。审计维度可统计“关键状态变更无法还原的条数”，关键状态由业务方事先指定，例如评审通过、发布完成。业务影响维度可统计“受影响版本数”和“发布记录不完整的版本数”。每个维度给出计数和占比，并注明判定所依据的字段和比对方式。
在记录留存与追溯环节，可以把迁移方案中列明的迁移范围作为核对清单的参照。ONES 的 Jira 迁移方案覆盖项目、工作项、状态、字段、流程、附件和历史记录，Confluence 迁移覆盖页面正文、附件、图片、常用宏及批注，并支持批量迁移与数据包导入。评估时可以按这些对象类型逐项核对目标端记录，具体迁移结果仍以实际比对为准。ONES 也提示定制场景和插件相关功能需要在迁移前逐项评估，这类差异应单列，不计入记录遗漏。
例子：一次缺陷历史遗漏的影响范围测算
以下为演示情景，数字用于说明计算方法。某团队从源系统迁移缺陷数据，时间窗为 2023 年全年，源端导出缺陷记录 12,000 条，其中软删除 200 条，按约定不计入应有数，应有记录数为 11,800 条。目标端核对到缺陷记录 11,328 条，则遗漏记录数为 472 条，遗漏率约为 4.0%，覆盖率约为 96.0%。
| 分层 | 应有数（条） | 实际数（条） | 遗漏数（条） | 遗漏率 |
|---|---|---|---|---|
| 项目 A | 6,000 | 5,940 | 60 | 1.0% |
| 项目 B | 4,500 | 4,140 | 360 | 8.0% |
| 项目 C | 1,300 | 1,248 | 52 | 4.0% |
| 合计 | 11,800 | 11,328 | 472 | 4.0% |
分层结果显示遗漏集中在项目 B，且按月份看集中在 2023 年 7 月至 9 月，该区间遗漏 300 条，占项目 B 遗漏数的八成以上。进一步核对发现，该区间源端缺陷的评论记录缺失较多，部分缺陷的变更历史只有创建记录，状态流转记录缺失。
三个维度的判定如下。追溯维度：472 条遗漏缺陷中，有 180 条在目标端找不到关联的需求或任务引用，其中 120 条属于项目 B 的 7 至 9 月区间，这些缺陷的修复链路无法完整还原。审计维度：项目 B 该区间有 95 条缺陷的状态变更记录无法还原，涉及“评审通过”和“关闭”两个关键状态，无法据此判断当时的处理结论。业务影响维度：受影响版本共 6 个，其中 2 个版本的发布记录中缺陷清单不完整，需要业务方确认是否影响发布说明和验收结论。
异常处理示例：项目 C 在 2023 年 1 月没有缺陷记录，分母为零，结论写“该月无可评估记录”，不参与遗漏率汇总。项目 B 的部分缺陷字段在迁移中经过状态映射，两个源状态合并为一个目标状态，这部分差异标注为不可比项，不计入遗漏数，但在报告中单列说明。
解读与限制：结论能说明什么、不能说明什么
遗漏率反映的是数据完整性，说明有多少记录没有到达目标端，不能直接换算成业务损失或团队绩效。遗漏 4% 是否可接受，取决于遗漏集中在哪些对象和用途上：核心项目的发布相关记录缺失，即使比例很低也需要处理；归档项目的附件缺失，可能只需记录说明。结论应写成“哪些对象、哪些时间段、影响哪些下游用途”，并给出对应的处理建议。
抽样结论有外推边界。抽样比例、抽样方法和样本分布决定了结论能覆盖的范围，样本量较小时应给出区间估计，避免用点估计描述全量情况。跨期比较前要确认分母口径没有变化，对象类型增减、删除口径调整、时间窗边界变化都会让两期遗漏率不可直接比较，需要先统一口径再比较。
评估中遇到资料未覆盖的能力项，例如迁移工具是否提供记录条数比对报告、变更历史的映射细则、核对清单的导出方式，应列为待查证项，在具体项目中向实施方确认，不据此推断产品能力的有无。结论向行动的转化分三条路径：遗漏集中在可补录对象时，制定补录清单和优先级；遗漏影响关键链路时，作为切换决策的输入条件；遗漏涉及审计要求时，形成带证据清单的说明材料。每条路径都应引用本次评估的分层结果和证据清单，保证结论可复核。
常见问题
源系统已经停用、拿不到全量导出，还能评估遗漏影响范围吗？
可以评估，但结论的覆盖范围要相应收窄。可用替代基线包括：迁移前留存的导出文件、接口返回的计数记录、系统日志中的创建记录，以及按项目整理的抽样清单。使用抽样清单时，需在报告中写明抽样比例、抽样方法（随机、分层或按项目全量）和比对字段，结论以区间估计或带置信说明的形式呈现，避免把样本结果直接当作全量结论。若连抽样清单都无法取得，可先对关键项目做定向核对，结论限定在这些项目范围内。
遗漏率算出来是 4%，这个数字能直接用来判断是否阻断切换吗？
不能单独作为阻断依据。遗漏率说明整体缺了多少记录，切换决策更依赖遗漏的分布和用途：遗漏集中在核心项目的发布相关记录、关键状态变更或需求与提交的关联引用上，即使比例不高也需要先处理；遗漏集中在已归档项目的附件上，可能只需记录说明。建议把分层结果与追溯、审计、业务影响三个维度的判定一起提交，由业务方和迁移负责人共同确认哪些属于切换前必须补齐的项。
状态映射导致源端两个状态合并成一个，这部分差异要不要算进遗漏数？
不计入遗漏数，但要单列说明。状态映射属于口径变化，记录本身已经到达目标端，只是形态与源端不同。处理办法是在字段映射规则表中标注每条规则是否影响计数，把字段合并、状态映射、时间戳精度变化等列为不可比项，在总体遗漏率之外给出可比口径下的结果。这样既不会虚增遗漏，也能让阅读报告的人知道哪些差异来自映射设计而非数据丢失。
评估时发现迁移工具是否提供记录条数比对报告不清楚，该怎么处理？
把这类问题列为待查证项，在具体项目中向实施方确认，不据此推断产品能力的有无。评估本身可以不依赖工具自带报告：用源端导出与目标端导出按同一口径自行比对，同样能得出遗漏率和分层结果。待查证项单列在报告末尾，注明它影响的是取数便利性还是结论精度，便于后续补证。ONES 的 Jira 迁移方案覆盖项目、工作项、状态、字段、流程、附件和历史记录，Confluence 迁移覆盖页面正文、附件、图片、常用宏及批注，可按这些对象类型逐项核对目标端记录，具体迁移结果以实际比对为准。
跨两个季度分别评估，遗漏率从 3% 变成 5%，能说明数据质量在下降吗？
先确认两期的分母口径是否一致再下结论。对象类型增减、软删除记录是否计入、时间窗边界规则调整，都会改变分母，使两期遗漏率不可直接比较。口径统一后仍有上升，再结合分层结果看变化来自哪些项目和时间段，判断是迁移批次差异还是源端记录形态变化。若两期口径无法统一，应分别报告各自口径下的结果，并说明不可比的原因。
