缺陷影响确认解决的是“这个缺陷会波及到哪里、由谁来判断、判断到什么程度可以收口”的问题。它发生在缺陷受理之后、修复方案确定之前，沿缺陷、受影响功能、关联需求与接口、受影响版本、受影响用户场景逐层排查，最终形成一份可评审的影响清单。本文给出影响清单的字段要求、六步排查操作、角色分工、完整示例和关闭检查条件，适合测试、开发、产品与发布角色协同执行。
要点总览（TL;DR）
- 缺陷影响确认的交付物是一份可评审的影响清单，首轮在缺陷受理后、修复方案确定前完成，修复后按同一清单补充回归影响。
- 排查按六步推进：固定缺陷事实、定位受影响模块、关联需求与接口、判断受影响版本、评估用户与业务场景、形成影响程度结论与处置建议。
- 影响确认由测试、开发、产品、发布和缺陷管理角色分段完成，每个维度都要有确认人和证据，结论回写缺陷单。
- 关闭影响确认前，五个影响维度均需有结论，判定不受影响的维度也要写明依据；未确认项要注明责任人与时限并升级评审。
- 修复后的回归范围从影响清单派生，覆盖直接受影响模块与间接受影响的上下游。
缺陷影响确认要产出什么：一份可评审的影响清单
缺陷影响确认的交付物是一份影响清单，而不是群里的口头结论。清单把“影响到哪里、谁确认的、依据是什么、准备怎么处理”固定成可查、可评审的记录。首轮确认在缺陷受理后、修复方案确定前完成；修复完成后，再按同一份清单补充回归影响，形成闭环。
影响清单建议包含以下字段，每个字段都要有明确的填写要求，避免出现“影响范围：部分功能”这类无法评审的描述。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 缺陷标识 | 缺陷单编号与标题，保证清单可回溯到原始报告 | BUG-2317 支付回调重复处理导致订单状态异常 |
| 复现条件 | 环境、数据前提、操作步骤，他人可按此复现 | 测试环境，同一回调通知重复推送两次 |
| 受影响功能/模块 | 从触发点向外列到共用组件与上下游调用 | 支付回调处理、订单状态机、对账任务 |
| 关联需求或接口 | 需求条目编号、接口名称与契约要点 | REQ-108 订单状态同步；回调接口幂等约定 |
| 受影响版本 | 区分已发布版本与在研版本，注明具体版本号 | 已发布 v3.2；在研 v3.3 |
| 受影响用户或业务场景 | 按使用路径描述波及的业务动作 | 重复支付用户的退款流程、日终对账 |
| 影响程度 | 给出等级并写明判断依据，如资金差错、主流程阻断 | 高：可能产生重复入账 |
| 确认人 | 每个影响维度对应一名确认人 | 模块影响：开发A；业务影响：产品B |
| 证据 | 日志、截图、复现记录、代码位置或接口文档片段 | 回调日志两条相同流水号 |
| 处置结论 | 修复、规避、暂不处理，并说明理由与后续动作 | 修复幂等校验，补充重复回调回归用例 |
清单与缺陷单的关系要固定下来：清单作为评审附件保留完整排查过程，结论摘要回写到缺陷单的影响范围与严重程度字段，让后续修复、测试和发布人员不必翻附件就能看到关键判断。回写时保持两边一致，清单更新后同步修订缺陷单，避免出现两套说法。
按链路逐层排查：从缺陷到受影响范围的操作步骤
排查顺序从确认缺陷事实开始，逐层向外扩展，每一层都有明确的输入、动作、输出和完成标志。按顺序推进的好处是：前一层没有确认清楚，后一层的影响判断就缺少依据，容易把“可能影响”写成“确定影响”。
第一步：固定缺陷事实与复现条件
输入是缺陷报告与复现步骤，动作是补齐环境、数据前提和操作序列，输出是一段他人可照做的复现说明。完成标志是另一位同事在不询问提出者的情况下能复现同一现象。复现不稳定的缺陷，要记录出现频率和已尝试的条件，作为后续判断影响面的前提。
第二步：定位受影响功能与模块
输入是可复现的缺陷描述，动作是从缺陷触发点向外扩展：先看直接承载该功能的模块，再检查被它调用的共用组件、工具类和上下游服务。输出是受影响模块列表，标注直接受影响与间接受影响。完成标志是每个列出的模块都有对应的代码位置或调用关系作为依据，而不是凭印象罗列。
第三步：关联需求、接口与数据
输入是受影响模块列表，动作是反查这些模块承载的需求条目、对外接口契约和涉及的数据结构。重点确认三类牵连：需求条目中是否有同一能力被其他场景复用；接口的入参、出参与错误码约定是否被破坏；数据结构或状态字段的变化是否影响读写方。输出是关联需求与接口清单，完成标志是每条关联都能说明“为什么受牵连”。
第四步：判断受影响版本与发布计划
输入是缺陷引入时间与修复所在分支，动作是区分已发布版本与在研版本：已发布版本要判断是否需要补丁发布，在研版本要判断是否阻塞当前发布计划。输出是受影响版本列表与发布影响说明。完成标志是每个版本都有明确结论，包括“不受影响”的版本及判断依据。
第五步：评估受影响用户与业务场景
输入是受影响功能与版本，动作是按真实使用路径推演：哪些用户角色会走到这条路径，走到时会发生什么，是否产生资金、数据或对外承诺方面的后果。输出是受影响用户与场景描述。完成标志是能回答“谁在什么操作下会遇到这个问题”，而不只是“某个功能有问题”。
第六步：形成影响程度结论与处置建议
输入是前五步的记录，动作是综合功能阻断程度、业务后果、波及用户量和版本紧迫性给出影响等级，并提出修复、临时规避或暂不处理的建议。输出是影响程度结论与处置建议。完成标志是结论有证据支撑、建议有明确责任人和时间要求，并已提交评审。
谁确认哪一段：角色分工与交付物
影响确认由多个角色分段完成，每个角色只对自己有判断依据的部分签字确认。分工清楚可以减少两类问题：一类是影响范围被漏判，另一类是同一维度被多人重复判断、结论互相矛盾。
| 角色 | 确认范围 | 交付物 | 确认方式 |
|---|---|---|---|
| 缺陷提出者/测试 | 缺陷事实、复现条件、出现频率 | 可复现的缺陷描述与复现记录 | 在缺陷单中确认复现信息完整 |
| 模块负责人/开发 | 受影响代码范围、共用组件、接口影响 | 受影响模块列表与代码位置说明 | 在影响清单对应行签署确认 |
| 产品/需求负责人 | 关联需求条目、业务场景与用户影响 | 需求关联结论与业务影响判断 | 评审会上确认或清单批注 |
| 发布或版本管理角色 | 受影响版本、补丁需求、发布计划影响 | 版本影响说明与发布建议 | 在发布评审记录中确认 |
| 缺陷管理角色 | 清单汇总、结论回写、状态推进 | 完整影响清单与更新后的缺陷单 | 关闭确认项并推进状态流转 |
确认签字不必追求形式上的签名，关键是每个维度都能在清单里找到“谁确认、依据是什么”。对于跨团队接口的影响，由接口提供方与调用方各自确认自己一侧，缺陷管理角色负责把两方结论合并，出现分歧时提交评审而不是私下折中。
当影响清单需要在多人之间流转、逐项补充证据并回写缺陷状态时，可以把清单作为文档与缺陷工作项关联，让每个确认人在同一处更新结论，缺陷单同步显示影响范围与严重程度。ONES 支持工作项关联与文档协同，可用于承载这类清单汇总和结论回写的动作；具体字段与流程按团队现有缺陷管理规范配置。
示例：一个支付回调缺陷的影响确认过程
以下为演示情景，用于说明步骤与角色如何衔接，不代表任何真实系统。
缺陷背景：支付平台的回调通知在超时重试时被重复处理，同一笔订单被更新两次状态，出现订单状态与实际支付结果不一致。测试在测试环境通过模拟重复推送稳定复现，提交缺陷单并附上两次回调的日志流水号。
按链路排查的过程如下：
- 固定事实：测试补充了重试间隔、重复推送次数和订单初始状态，另一名同事按步骤复现成功，缺陷事实确认完成。
- 模块定位：开发从回调处理入口向外排查，确认受影响的是回调处理服务、订单状态机和对账任务，其中对账任务属于间接受影响，因为它读取订单状态生成对账文件。
- 需求与接口关联：产品反查发现回调接口契约中约定了幂等要求，但实现未校验；关联需求条目为订单状态同步，另有退款流程复用同一状态字段。
- 版本判断：发布角色确认该逻辑在已发布的 v3.2 中存在，在研 v3.3 同样未修复，需要评估补丁发布。
- 用户与场景评估：产品按使用路径判断，受影响的是遇到支付超时重试的用户，可能触发重复入账与退款金额错误，日终对账会出现差异。
- 结论与处置：综合资金差错风险，影响程度定为高；处置建议为修复幂等校验、对已产生的异常订单做数据核查、补充重复回调的回归用例，并安排在最近一次补丁窗口发布。
各角色留下的证据包括：测试的复现记录与日志、开发的受影响模块与代码位置说明、产品的需求关联与业务影响判断、发布角色的版本影响说明。缺陷管理角色把这些内容汇总进影响清单，将影响范围与严重程度回写缺陷单，并据清单派生回归范围。
从这个示例可以提炼出可迁移的习惯：先让缺陷事实稳定可复现，再向外扩展模块与接口；每扩展一层都记录依据；版本判断区分已发布与在研；业务影响按真实使用路径推演；结论形成后立即回写并派生回归范围。
完成检查：影响确认可以关闭的判断标准
影响确认是否可以关闭，按下面的清单逐项核对。全部满足即可进入修复方案确定环节；存在未确认项时，不应以“先修再说”的方式跳过。
- 缺陷事实可复现，复现条件、环境与出现频率记录完整，他人可按记录复现。
- 受影响功能与模块、关联需求与接口、受影响版本、受影响用户与业务场景五个维度均有明确结论；判定为不受影响的维度也写明判断依据。
- 每项影响都有对应确认人和证据，证据可指向日志、复现记录、代码位置或接口文档。
- 影响程度结论与处置建议已回写缺陷单，清单与缺陷单内容一致。
- 修复后的回归范围已从影响清单派生，覆盖直接受影响模块与间接受影响的上下游。
- 存在无法确认的影响项时，已注明原因、责任人和确认时限，并按团队约定升级到评审，而不是默认忽略。
满足以上条件后，影响确认的结论即可作为修复方案与发布决策的输入；修复完成后，按同一份清单核对回归结果，补充实际影响与预估影响的差异，为后续同类缺陷的排查提供参照。
常见问题
缺陷复现不稳定时，影响确认是否要等复现稳定后再开始？
不必等到完全稳定复现才开始，但要把不稳定本身记录清楚。先记录已观察到的出现频率、触发条件和已尝试的环境与数据，再据此判断影响面，并在清单中标注“复现条件待补充”。后续每确认一项影响，都注明它依赖的复现前提；如果关键影响维度因复现不稳定无法判断，按未确认项处理，注明责任人和确认时限，提交评审决定是否先做临时规避。
已发布版本和在研版本都受影响时，影响确认的结论要怎么区分？
在影响清单的版本字段中分别列出，并给出不同处置：已发布版本判断是否需要补丁发布、影响哪些线上用户；在研版本判断是否阻塞当前发布计划、是否需要在合并前修复。两个版本的确认人可以相同，但结论要分开写，避免用一句“都受影响”覆盖发布决策所需的差异。发布角色据此给出补丁窗口或发布调整建议。
跨团队接口受影响时，由哪一方确认影响？
由接口提供方与调用方各自确认自己一侧：提供方确认接口契约、错误码和实现是否被破坏，调用方确认自身数据处理和业务逻辑是否受牵连。缺陷管理角色负责合并两方结论，写入同一份影响清单。两方判断出现分歧时，提交评审讨论，以接口文档和日志证据为准，不在私下折中后只留一个口头结论。
影响确认完成后，修复过程中发现新的受影响范围怎么办？
把新发现的范围补进同一份影响清单，标注发现时间和补充确认人，同步更新缺陷单的影响范围与严重程度，并重新评估影响程度结论和处置建议。如果新范围涉及此前判定不受影响的维度，要写明原判断为何需要修正。回归范围随之扩展，避免修复完成后才发现遗漏的模块没有验证。
影响清单放在文档里还是直接写在缺陷单里？
两者配合使用：清单作为评审附件保留完整排查过程、证据和各角色确认记录；缺陷单保留结论摘要，包括影响范围、影响程度和处置建议。这样修复、测试和发布人员查看缺陷单即可掌握关键判断，需要追溯依据时再打开清单。清单更新后同步修订缺陷单，保持两边一致。ONES 支持工作项关联与文档协同，可用于承载清单汇总和结论回写，具体字段按团队现有缺陷管理规范配置。
