缺陷老化看的是年龄
缺陷老化看的是开放式缺陷的年龄分布：有多少问题已经挂了三个月、半年甚至一年还没有结论。长期挂起的老缺陷会持续消耗注意力，每次评审都要重新判断一遍；也会让列表失去可信度，当列表里全是「永远不会修」的条目，真正紧急的问题就被淹没。
基本信息
| 度量 | 开放缺陷的存续时长分布，如中位数与超期占比 |
|---|---|
| 问题 | 越陈越无人敢碰，列表逐渐失信 |
| 动作 | 专项清理：修复、明确降级或关闭并说明 |
| 配套 | 清理前按模块导出老化列表，逐条给出结论 |
典型使用场景
- 季度清理周：集中处理超过阈值的老缺陷，避免常年滚动积压
- 发布前复核：候选版本的涉及模块先清一遍高优先级老缺陷
- 模块健康度：把老化分布按模块拆分，识别长期无人维护的区域
- 交接场景：交接前把无人负责的老缺陷重新指派或给出结论
- 复盘输入：老缺陷的成因常指向同一类缺失，例如缺测试或缺监控
分档治理示例
分档治理示例
# 按存续时长分档
超过 180 天：逐条复核 —— 修复、明确接受、或关闭归档
90 至 180 天：指定负责人与目标版本
小于 90 天：走正常排期流程
# 关闭时写明结论：重复、无法复现、设计如此、风险已知并接受老化分档与处置
| 存续时长 | 风险 | 建议处置 |
|---|---|---|
| 小于 90 天 | 属正常排期范围 | 按优先级正常推进 |
| 90 至 180 天 | 开始失去上下文 | 明确负责人与目标版本 |
| 大于 180 天 | 成因信息可能已丢失 | 逐条复核并给出结论 |
| 大于 365 天 | 大概率不会被修 | 关闭归档或转为已知限制 |
关闭不等于掩盖：把「不修」写成明确的决策记录，包括已知限制、风险接受人与复审时间，比沉默地挂着更有价值；带复审时间的接受项还能在条件变化时被重新捡回来。
一刀切关闭老缺陷会把真实风险静默掉：关闭前确认影响面，涉及安全、数据正确性或资金损失的问题即便暂时不修，也要保留可见性与负责人。