缺陷积压清理后仍然反复增长或长期不收敛，通常说明积压的增量来源没有被切断，清理只处理了存量。要判断问题出在入口、修复验证还是排期环节，需要先把积压拆成可观测的口径，再用状态流转数据、重开记录和新增来源分布逐项取证。本文按症状界定、原因假设、排查顺序、处置动作、验证与复发预防的顺序展开，帮助确定先处理什么。
要点总览（TL;DR）
- 清理后仍反复增长，先看新增速率是否持续高于关闭速率；总量持平但尾部滞留增加，属于不收敛而非稳定。
- 四类常见原因按取证成本排序：入口把关失效、修复与验证脱节、优先级与排期缺位、清理只动存量未动规则。
- 排查顺序建议先核对新增来源，再查待验证停留与重开率，最后查长期滞留缺陷的优先级与责任人。
- 处置动作要对应已确认的原因；批量关闭或批量状态变更前需导出清单、经过审批并保留操作记录。
- 收敛验证看关闭速率与新增速率的相对关系、重开率和尾部滞留数量，观察期覆盖至少两个迭代或连续四周。
先界定症状：积压是增长还是不收敛
“反复增长”和“长期不收敛”是两种不同的症状，处置方向也不同。前者表现为新增速率持续高于关闭速率，总量在清理后重新爬升；后者表现为总量可能持平，但一批缺陷长期停留在待处理或待验证状态，尾部越拖越长。只用总量一个指标判断，容易把两种问题混在一起。
建议先确定观察窗口。窗口太短会把正常的版本波动当成增长趋势，窗口太长又会掩盖近期的流程变化。可以取清理完成后的连续若干迭代或连续四周作为观察期，并与清理前同样长度的窗口对比。数据来源优先选择缺陷工作项的状态变更记录、创建时间、关闭时间和重开记录，这些字段能支撑下面四个口径的计算。
| 指标 | 计算方式 | 判断方向 |
|---|---|---|
| 积压总量 | 观察窗口结束时处于未关闭状态的缺陷数 | 与清理完成时对比，看是否回到清理前水平 |
| 新增速率 | 窗口内新建缺陷数 ÷ 窗口长度 | 与清理前对比，明显上升说明入口流入未减少 |
| 关闭速率 | 窗口内关闭缺陷数 ÷ 窗口长度 | 低于新增速率时总量必然净增长 |
| 重开率 | 窗口内重开缺陷数 ÷ 窗口内关闭缺陷数 | 偏高说明关闭质量不足，缺陷在验证环节循环 |
| 尾部滞留数量 | 停留超过约定天数仍未关闭的缺陷数 | 总量持平但该值上升，属于不收敛而非稳定 |
四个口径要一起看。新增速率和关闭速率决定净增长方向，重开率决定关闭是否真实有效，尾部滞留数量决定积压是否在结构上固化。如果新增速率下降、关闭速率持平，但重开率上升，总量可能暂时稳定，实际是在待验证与重开之间空转。
原因假设与排除证据：四类常见来源
清理后仍不收敛的原因，常见集中在四类。诊断时把每类当作假设，先明确需要什么证据才能确认，再明确什么情况下可以排除，避免凭印象下结论。
入口把关失效
假设：低质量缺陷或重复缺陷持续流入，新增速率降不下来。验证证据是新增缺陷的来源分布，包括按提交人、按模块、按发现阶段的分布，以及严重级别构成。如果大量新增集中在少数模块或少数提交入口，且轻微级别占比明显上升，入口问题的可能性较大。排除条件是新增来源分散、严重级别构成与历史一致，且新增速率与关闭速率基本匹配。
修复与验证脱节
假设：缺陷被标记为已修复，但在待验证队列停留过久，或被验证退回后重新进入修复，形成循环。验证证据包括待验证停留时长分布、重开率、验证退回原因分类。如果待验证停留时长中位数明显高于修复时长，或退回原因集中在同一类问题，说明验证闭环存在断点。排除条件是待验证停留时长短、重开率低且退回原因分散。
优先级与排期缺位
假设：缺陷进入积压后没有明确的处理决策，长期滞留在低优先级区间。验证证据是长期未处理缺陷的优先级分布和责任人分布。如果尾部滞留缺陷大量集中在未定优先级或无明确责任人的状态，说明排期机制没有覆盖这部分存量。排除条件是滞留缺陷均有明确优先级和排期结论，只是受资源限制延后。
清理只动存量未动规则
假设：上一轮清理批量关闭或批量降级了存量缺陷，但提交规范、验证标准和排期规则没有变化，增量按原方式继续产生。验证证据是清理前后新增速率与关闭速率的对比。如果清理后新增速率很快恢复到清理前水平，说明流入端未受影响。排除条件是清理后新增速率持续下降，说明规则调整已经生效。
| 原因假设 | 验证证据 | 排除条件 |
|---|---|---|
| 入口把关失效 | 新增来源分布、严重级别构成 | 来源分散、级别构成稳定、新增与关闭基本匹配 |
| 修复验证脱节 | 待验证停留时长、重开率、退回原因 | 停留时长短、重开率低、退回原因分散 |
| 优先级与排期缺位 | 长期未处理缺陷的优先级与责任人分布 | 滞留缺陷均有明确优先级和排期结论 |
| 清理未动规则 | 清理前后新增与关闭速率对比 | 清理后新增速率持续下降 |
按证据排序的排查顺序
四类原因的影响面和取证成本不同，排查顺序建议从数据最容易拿到、影响最直接的一步开始，每步设定明确的停止点，避免一次铺开所有方向。
第一步：核对新增速率与来源
输入数据是观察窗口内的新增缺陷列表及其来源字段。判断分支是：新增速率接近或超过关闭速率，且来源集中，进入入口问题处置；新增速率正常但关闭速率偏低，转入第二步；两者都正常而总量仍不降，直接查尾部滞留。这一步的停止点是确认新增端是否为主要增量来源。需要协同的角色是提交缺陷的一线测试人员和对应模块负责人。
第二步：核对重开与待验证停留
输入数据是待验证队列的停留时长、重开记录和退回原因。判断分支是：待验证停留时长或重开率明显偏高，进入验证闭环处置；两项均正常，转入第三步。停止点是确认关闭动作是否真实有效。需要协同的角色是验证人员和修复负责人，必要时抽样复核若干条重开缺陷的实际原因。
第三步：核对优先级与责任归属
输入数据是长期未处理缺陷的优先级、责任人和最近一次状态变更时间。判断分支是：滞留缺陷缺少优先级或责任人，进入排期机制处置；已有明确结论但受资源限制，则属于容量问题，需要在上层排期讨论中解决。停止点是确认尾部滞留是否由决策缺位造成。需要协同的角色是产品负责人和研发负责人。
三步走完后，通常能确定一到两个主要原因。如果证据指向多个原因并存，按影响增量速率的程度排序处置，先处理对新增或关闭速率影响最大的那一项。
处置动作与风险边界
处置动作要对应已确认的原因，未取证的原因不提前动手。以下动作按原因分类，每项标注适用条件和风险控制点。
入口侧：调整提交规范与准入条件
适用入口把关失效的情形。动作包括明确缺陷提交的必填字段，如复现步骤、影响范围、发现阶段；对重复缺陷和无法复现的提交设置统一的合并或退回规则；按严重级别约定提交前的自检项。责任角色是测试负责人和模块负责人。风险控制点在于规则收紧后要观察一段时间的提交量变化，避免把有效缺陷挡在门外，规则调整前应与提交人沟通并保留申诉通道。
验证侧：清理待验证队列并归类重开原因
适用修复验证脱节的情形。动作包括设定待验证停留时限，超时缺陷进入提醒或升级；对重开缺陷强制填写退回原因，并按原因分类统计；定期复核高频退回原因对应的修复环节。责任角色是验证负责人。风险控制点在于批量变更待验证状态前，先导出当前队列清单并留存，变更后通知相关修复人，避免状态跳变导致责任不清。
排期侧：对长期滞留缺陷做出处置决策
适用优先级与排期缺位的情形。动作是对尾部滞留缺陷逐条或分批给出结论：安排修复、降级为改进项、合并到其他缺陷或关闭并记录理由。责任角色是产品负责人和研发负责人共同确认。风险控制点在于批量关闭属于破坏性操作，执行前必须备份缺陷清单和关键字段，明确通知范围，并在关闭理由中写明依据，便于后续复查。
批量操作前的通用条件
任何批量关闭、批量降级或批量状态变更，都应满足三个条件：操作前导出受影响工作项的完整记录；操作范围和理由经过对应负责人审批；操作后保留可追溯的操作记录。缺少任一条件时，改为分批小范围执行，先验证一批的效果再扩大范围。
这些处置动作涉及缺陷状态流转、待验证队列和重开记录的持续管理。ONES 的工作项类型与状态流转配置可以承载缺陷从提交、修复、待验证到关闭或重开的完整记录，重开原因和停留时长可作为字段与状态变更历史保留，便于按上述口径取数核对。将提交规范、验证时限和排期结论写入工作项字段与流转规则后，规则调整本身也会留下可查的记录。
验证恢复与复发预防
处置是否有效，要看积压是否真正收敛，而不是看某一次清理后的总量数字。验证应围绕新增与关闭的相对关系、关闭质量和尾部结构三个方向展开。
| 验证指标 | 观察方式 | 收敛的判断方向 |
|---|---|---|
| 新增速率与关闭速率 | 按周或按迭代统计两者比值 | 关闭速率持续不低于新增速率 |
| 重开率 | 按窗口统计重开数占关闭数比例 | 较处置前下降并保持稳定 |
| 尾部滞留数量 | 统计超过约定停留天数的未关闭缺陷 | 逐窗口减少，不再累积 |
| 待验证停留时长 | 统计待验证状态的中位停留时间 | 回落到约定时限以内 |
观察周期建议覆盖至少两个完整的迭代或连续四周，并在第一个周期结束时做一次复查，确认指标方向而非单点数值。复查节点上如果发现新增速率回升或重开率反弹，先回到对应原因假设重新取证，不直接重复上一轮清理动作。
复发预防的关键是把三类规则固化到日常流程：入口规则写入缺陷提交模板和准入检查；验证规则写入待验证时限和重开原因必填项；排期规则写入长期滞留缺陷的定期评审机制。规则固化后，积压的变化可以从状态流转记录中持续观察，而不依赖临时清理。
设置再诊断触发条件有助于及时回退。例如连续两个观察窗口新增速率高于关闭速率，或重开率回升到处置前水平，或尾部滞留数量重新累积，就应启动新一轮原因排查，并检查此前固化的规则是否被绕过或失效。触发后先核对规则执行情况，再判断是否需要调整处置动作。
常见问题
清理后总量暂时下降，过一段时间又回到清理前水平，最先应该查什么？
先查新增速率和新增来源分布。如果清理后新增速率很快恢复到清理前水平，说明流入端没有变化，上一轮清理只处理了存量。此时按提交人、模块和发现阶段拆解新增缺陷，判断是否集中在少数入口或少数模块，再决定是否调整提交规范和准入条件。
待验证队列很长，但重开率不高，这算验证闭环问题吗？
需要分开看。重开率不高说明关闭质量尚可，但待验证停留时长偏长说明缺陷在修复完成到验证之间排队。可以统计待验证状态的中位停留时间，与修复时长对比；如果停留时间明显更长，问题更可能出在验证资源或验证排期上，处置方向是设定待验证时限并明确验证责任人，而非收紧重开规则。
长期滞留的缺陷数量不多，是否可以先不处理？
要看滞留缺陷的构成。如果滞留缺陷集中在核心模块或高严重级别，即使数量不多也可能持续消耗排查精力，并影响后续版本判断。建议先看长期未处理缺陷的优先级分布和责任人分布：缺少优先级或责任人的，补上决策结论；已有结论但受资源限制的，放入排期讨论，避免长期悬空。
批量关闭积压缺陷时，怎样降低误关风险？
批量关闭前先导出受影响工作项的完整记录，包括状态、优先级、责任人和最近变更时间；关闭范围和理由经过对应负责人审批；关闭理由中写明依据，便于后续复查。如果条件不具备，改为分批小范围执行，先验证一批的效果再扩大范围。批量降级和批量状态变更同样适用这些条件。
处置后指标好转一段时间又反弹，应该怎么处理？
先核对此前固化的规则是否仍在执行，例如提交模板是否被绕过、待验证时限是否仍生效、长期滞留缺陷是否还有定期评审。规则执行正常但指标反弹时，回到对应原因假设重新取证，判断是否出现了新的流入来源或验证瓶颈，再决定调整处置动作，避免直接重复上一轮清理。
