缺陷根因复核要回答的是“这个根因结论能不能站得住”，依据由四类材料构成：缺陷本身的客观记录、根因分析过程的产物、修复后的验证证据，以及评审与预防措施的过程责任信息。复核以这些材料能否相互印证为准，结论需写明根因类别、证据链摘要和预防措施，并由独立于原分析人的角色确认。
要点总览（TL;DR）
- 缺陷根因复核的依据分四类：缺陷客观记录、根因分析过程产物、修复验证证据、过程与责任信息，复核以材料能否相互印证为准。
- 复核围绕三个判断取证：根因是否成立、证据是否充分、预防措施是否可执行，按判断逐项核对比通读全部材料更高效。
- 复核按提交复核包、核对证据链、提出补充要求、结论确认四步推进，每步有输入、动作、输出与完成标志。
- 复核人应独立于原分析人，结论需写明根因类别、证据链摘要和预防措施负责人及期限。
- 证据链断裂或结论与证据矛盾时不予通过，先补齐材料再重新核对；同类缺陷需回溯确认是否存在相同根因。
复核前先明确：依据要支撑哪三个判断
收集依据之前先确定复核要下什么判断，材料才不会堆成档案。一次缺陷根因复核通常只回答三个问题：根因是否成立、证据是否充分、预防措施是否可执行。三项判断各有对应的依据类型，复核人按判断逐项取证，比通读全部材料更高效。
| 判断项 | 所需依据 | 判定标准 |
|---|---|---|
| 根因是否成立 | 缺陷客观记录、分析过程产物（假设与排除证据、定位到的变更点） | 根因能解释缺陷的全部可观察现象；被排除的假设有对应证据；根因与定位到的代码、配置或流程变更点对得上 |
| 证据是否充分 | 复现步骤、环境与版本、日志截图、修复后的复现验证与回归结论 | 关键结论至少有两类独立材料支撑；复现与验证在同一环境下可重复；回归范围覆盖受影响功能 |
| 预防措施是否可执行 | 预防措施描述、负责人、期限、跟踪记录 | 措施指向根因而非表面现象；有明确负责人和完成期限；能在现有流程中落地并验证效果 |
复核范围限定在单个或一组同类缺陷的根因结论上。跨团队质量指标体系的设计与度量、服务事件根因分析与问题管理流程属于另外的主题，不在本文展开；涉及这些内容时，应转入对应的管理流程处理。
缺陷根因复核的证据清单与字段
下表按四类依据列出字段、合格标准和提供人，可直接作为复核包的对照清单。字段不必全部填满，但凡支撑结论的字段必须可查、可追溯。
| 依据类别 | 字段 | 合格标准 | 提供人 |
|---|---|---|---|
| 缺陷客观记录 | 复现步骤、环境与版本、日志与截图、影响范围、发现阶段 | 步骤可被他人按序复现；环境与版本精确到构建号；日志与截图对应缺陷发生时刻；影响范围写明受影响的用户、功能或数据；发现阶段注明是开发自测、测试执行还是线上反馈 | 缺陷提交人、测试 |
| 根因分析过程 | 分析方法、假设列表、排除证据、定位到的代码/配置/流程变更点 | 每个假设都有“成立/排除”的结论和依据；排除证据指向具体日志、代码行、配置差异或提交记录；变更点能关联到版本或提交 | 分析人、开发 |
| 验证证据 | 修复内容、复现验证结果、回归范围与结论 | 修复内容说明改了什么、为什么这样改；复现验证在原环境下执行并记录结果；回归范围列出覆盖的关联功能，结论写明通过项与遗留风险 | 开发、测试 |
| 过程与责任信息 | 分析人、评审人、结论确认时间、预防措施负责人与期限 | 评审人独立于原分析人；确认时间可查；每项预防措施有唯一负责人和完成期限，并留有跟踪记录 | 分析人、复核人、质量或过程负责人 |
判断证据是否充分，看的是印证关系而非材料数量。例如根因结论指向某次配置变更，就应有变更记录、变更前后的日志差异和复现验证三方面材料相互对应；只有分析人的文字描述，属于单点陈述，不足以支撑结论。
复核怎么走：从提交到结论确认的操作步骤
复核按四个步骤推进，每步都有明确的输入、动作、输出和完成标志，避免复核停在“看过了”的层面。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 一、提交复核包 | 按证据清单整理的四类材料 | 分析人对照清单自查后提交；复核人先做完整性检查，缺项列明并退回补充，缺项不影响结论成立的可在复核记录中标注 | 复核包与缺项清单 | 必备材料齐全，或缺失项已登记并说明处理方式 |
| 二、核对证据链 | 复核包 | 独立复核人逐项核对：根因能否解释全部现象；每个被排除的假设是否有排除证据；变更点与缺陷现象是否对应；验证结果是否在原环境下取得 | 证据链核对记录 | 三个判断均有明确结论，存疑项已列出 |
| 三、提出补充要求 | 核对记录中的存疑项 | 对证据不足项写明需要补什么、由谁补、何时补；补充材料回来后重新核对对应项 | 补充要求清单及回填记录 | 存疑项全部关闭或转为明确的遗留风险 |
| 四、结论确认 | 核对完成的证据链 | 复核人确认结论，写明根因类别、证据链摘要、预防措施及负责人期限；与原分析人意见不一致时记录分歧点 | 复核结论记录 | 结论经复核人签署，预防措施进入跟踪 |
复核包和结论记录需要与缺陷本身放在同一处可查的位置，否则后续回溯时依据容易散落在聊天记录和个人文档里。使用 ONES Project 时，缺陷可作为工作项记录状态与修复过程，支持一键提交 Bug 至对应项目或迭代并跟踪修复情况；分析结论和复核记录可借助 ONES Wiki 的文档关联任务能力与缺陷工作项对应，使证据链在同一个工作项体系内可追溯。具体字段与流程配置需按团队实际情况设置。
角色分工与各角色交付物
复核流于形式，常见原因是角色重叠：分析人自己确认自己的结论，或没有人对预防措施负责。下表按角色列出交付物和交接时点。
| 角色 | 交付物 | 交接时点 |
|---|---|---|
| 缺陷提交人/测试 | 复现步骤、环境与版本、日志截图、影响范围；修复后的复现验证与回归结论 | 提交缺陷时提供第一组材料；修复完成后提供验证材料 |
| 分析人/开发 | 根因分析记录、假设与排除证据、定位到的变更点、修复内容说明 | 提交复核包时一次性交付 |
| 复核人 | 证据链核对记录、补充要求清单、复核结论 | 收到复核包后启动核对；补充材料回填后出具结论 |
| 质量或过程负责人 | 预防措施的跟踪记录与关闭确认 | 结论确认后接手跟踪，按期限核对完成情况 |
复核人应独立于原分析人，可以由同团队其他开发、测试负责人或质量角色担任，关键是未参与该缺陷的根因分析。测试环节产生的缺陷，ONES TestCase 支持由未通过的用例快速创建缺陷任务并在测试与研发团队间流转，使提交与验证材料随缺陷一起流转；其测试报告与缺陷分布统计可用于回溯同类问题，具体报表口径需按团队配置。
一个复核示例：从证据缺失到结论确认
以下为演示情景，用于说明证据如何相互印证以及缺口如何处置。
某版本上线后，部分用户提交订单时出现重复扣款提示。缺陷记录包含复现步骤、发生时间段的日志和受影响用户范围，发现阶段为线上反馈。分析人初步结论是“支付回调接口超时导致重复处理”，并提交了修复代码。
复核人核对时发现两处缺口：一是分析记录只写了结论，没有列出被排除的其他假设，例如前端重复提交、消息队列重投；二是回归范围只写了“支付相关功能”，未说明是否覆盖退款与对账。复核人据此提出补充要求：补充消息队列重投记录的排查证据，明确回归覆盖的功能清单。
补充材料显示，消息队列在该时间段确有重投，但重投记录与重复扣款的时间点不吻合，该假设被排除；回调接口超时日志与扣款时间点一一对应，根因成立。回归范围补充为支付、退款、对账三项并全部通过。最终结论写明根因类别为接口超时下的幂等处理缺失，证据链摘要引用日志时间对应关系与排除记录，预防措施为补充幂等校验并增加超时告警，负责人与期限明确，由质量负责人跟踪关闭。
这个示例的可迁移规律是：复核的价值主要体现在发现“结论之外缺了什么”，补充证据的过程往往同时修正了预防措施的指向。
复核完成检查与常见失效点
结论确认前，按下表逐项检查。任一项不满足即视为未完成，需回到对应步骤处理。
- 四类依据齐全，缺失项已登记并说明是否影响结论；
- 根因结论有证据链支撑，每个被排除的假设都有排除证据；
- 修复验证在原环境下完成，回归范围明确且结论可查；
- 预防措施有唯一负责人和完成期限，并已进入跟踪；
- 复核人独立于原分析人，结论确认时间可查；
- 同类缺陷已做回溯，确认是否存在相同根因的其他记录。
常见失效点集中在三处：只确认结论不查证据，复核记录里只有“同意”二字；预防措施停留在口头约定，没有负责人和期限；同类缺陷未回溯，同一根因在其他模块重复出现。出现证据链断裂，或结论与证据相互矛盾时，属于阻断项，不予通过，应先提出补充要求并记录缺口，待材料补齐后重新核对。
常见问题
复核人由谁担任比较合适？
复核人应独立于该缺陷的原分析人，可以由同团队其他开发、测试负责人或质量角色担任，关键是未参与本次根因分析。若团队规模较小、难以找到完全独立的人选，可请相邻模块的开发或测试负责人交叉复核，并在复核记录中注明关系，避免分析人自证结论。
复核包提交时材料不全，是退回还是先受理？
按缺项是否影响结论成立区分处理：影响根因判断或证据链完整性的缺项，退回补充后再受理；不影响结论成立的辅助材料缺失，可在复核记录中登记并说明处理方式，继续核对。无论哪种情况，缺项都要留痕，避免后续回溯时说不清当时依据了什么。
复核结论与原分析人意见不一致时怎么办？
在结论记录中写明分歧点，并列出双方各自依据的证据。复核人按证据链核对结果给出结论；若分歧源于证据不足，先提出补充要求，材料补齐后重新核对。分歧记录本身也是后续回溯和预防措施调整的依据，不宜在结论中隐去。
预防措施确认后由谁跟踪、跟踪到什么程度算关闭？
预防措施在结论确认时即指定唯一负责人和完成期限，由质量或过程负责人接手跟踪。关闭条件通常是措施已落地并有可查的验证结果，例如新增的校验已上线、告警已配置并触发过一次。仅有口头承诺或计划排期，不能视为关闭。
同类缺陷回溯要做到什么范围？
至少回溯同一根因类别下已关闭和未关闭的缺陷记录，确认是否存在相同根因的其他实例。回溯范围可结合缺陷分布统计确定，例如按模块或发现阶段筛选。发现相同根因的，并入同一预防措施跟踪，避免同一问题在不同模块重复修复。
