制定缺陷严重程度标准，核心是让不同的人面对同一个缺陷时能得出相同判定。做法上，先明确分级要服务的决策，再确定档位数量，用功能可用性、数据影响、影响范围、有无绕过方式等可观察维度写出判定问句和边界示例，最后配套争议仲裁与定期校准。本文聚焦分级标准本身，处理归属、排队顺序和 SLA 另行讨论。在 ONES 中，缺陷的严重程度字段、判定依据和流转记录可以随缺陷工作项一并保存，便于后续回放校准。
要点总览（TL;DR）
- 先明确分级要支撑的决策（是否阻断发布、修复排期、对外通报），再倒推档位数量；缺陷量不大的团队用三档，产品线多、对外承诺强的团队可用四档。
- 判定依据固定为功能可用性、数据影响、影响范围、有无绕过方式四类维度，每类写成是非问句或程度问句，并预设冲突时的优先顺序：数据安全与数据丢失优先于功能不可用，功能不可用优先于影响范围，影响范围优先于绕过方式。
- 规则按“条件组合+结论”写，一条规则只对应一个档位；每档配两个正例和一个易混淆反例，数据丢失、安全相关、仅特定环境复现等边界情形单独约定。
- 明确提报人、初判人、模块负责人、质量负责人的职责，设定争议仲裁路径与时限，并用版本号、变更记录和生效日期维护标准。
- 严重程度只作为分诊输入，处理归属与排期由分诊决定，工单紧急性与 SLA 由优先级体系承载；标准发布前用历史缺陷双人独立回放，一致率达标后再正式使用。
先定分级要回答的问题与分级数量
分级标准常见的失败，是从“严重、一般、轻微”这类名称出发，结果每个人对名称的理解不同。更稳妥的起点是先列出分级要支撑哪些决策，再倒推需要几个档位。缺陷严重程度通常服务三类决策：是否阻断本次发布、修复排期的先后、是否需要对外通报或升级处理。三类决策对档位的敏感度不同，档位数量应覆盖这些差异，又不至于细到难以判断。
三档划分适合缺陷量不大、发布节奏较稳定的团队。典型定义是：阻断级影响核心功能可用或造成数据错误，必须修复后才能发布；严重级影响主要功能但有临时绕过方式，需在本次发布或紧邻版本内修复；一般级影响次要功能或体验，可排入常规迭代。三档的优点是判定负担小，缺点是中间地带容易挤压，适合团队对业务影响已有较清晰共识的情况。
四档划分适合产品线较多、对外服务承诺较强的团队。可在三档基础上拆出“致命”与“阻断”，或把“一般”再分为“轻微”和“建议”。四档能更细地区分发布阻断与高优修复，但要求每个档位都有清晰的判定问句，否则新增档位只会增加争议。档位数量确定后应稳定一段时间，频繁增减会让历史数据失去可比性。
需要强调的是，严重程度只描述缺陷造成的影响程度，不承担责任归属，也不等于修复排队顺序。一个严重程度高的缺陷由谁修、什么时候修，取决于分诊结果和优先级安排。把责任和排期塞进严重程度档位，会让定级变成部门博弈，判定标准随之失效。
| 档位 | 决策含义 | 典型处置方向 |
|---|---|---|
| 致命/阻断 | 核心功能不可用、数据错误或安全风险，发布必须停止 | 立即组织修复，修复前不进入发布 |
| 严重 | 主要功能受损，存在绕过方式但代价明显 | 本次发布前修复，或经批准后带条件发布 |
| 一般 | 次要功能异常或体验受损，不影响主流程 | 排入常规迭代修复 |
| 轻微/建议 | 外观、文案或低频场景问题 | 批量处理或随版本优化 |
严重程度标准的判定维度与判定问句
要让定级可复现，判定依据必须是可观察的事实，而非“感觉严重”这类主观描述。建议固定四类维度：功能可用性、数据影响、影响范围、有无绕过方式。每个维度写成判定问句，回答者只需回答“是/否”或选择程度，减少解释空间。
功能可用性关注缺陷是否让某项功能无法完成其预期任务。可写成：该功能是否完全无法使用？是否只能完成部分操作？是否仍可正常完成主要操作？数据影响关注数据是否正确、完整、可恢复。可写成：是否造成数据丢失、错乱或对外泄露？是否可通过重试或手工修正恢复？影响范围关注受影响的用户和场景广度。可写成：是否影响全部用户？是否影响特定角色、特定租户或特定终端？是否只在测试环境或特定配置下出现？有无绕过方式关注用户能否继续完成业务。可写成：是否存在无需额外成本的替代操作？绕过是否需要人工介入或数据修复？
维度组合映射到档位时，需要预设冲突时的优先顺序。常用顺序是：数据安全与数据丢失优先于功能不可用，功能不可用优先于影响范围，影响范围优先于有无绕过方式。也就是说，一个只在少数用户出现但造成数据错误的缺陷，仍应判为高档位；一个影响全部用户但只是文案错位的缺陷，不应因范围广而抬高严重程度。这个优先顺序应写入标准正文，作为判定问句之后的补充规则。
| 维度 | 判定问句示例 | 回答形式 |
|---|---|---|
| 功能可用性 | 该功能是否完全无法完成预期操作？ | 完全不可用 / 部分可用 / 可用 |
| 数据影响 | 是否造成数据丢失、错乱或未授权访问？ | 是（不可恢复）/ 是（可恢复）/ 否 |
| 影响范围 | 受影响的是全部用户、特定角色还是特定环境？ | 全部 / 特定群体 / 特定环境 |
| 绕过方式 | 是否存在无需额外成本的替代操作？ | 有低成本绕过 / 有高成本绕过 / 无绕过 |
编写分级判定规则与边界示例
判定维度确定后，下一步是把维度组合固化为规则。规则的标准写法是“条件组合 + 结论”，一条规则只对应一个档位，避免一条规则同时指向两个档位。例如：“功能完全不可用，且无绕过方式，且影响全部用户 → 阻断级”；“功能部分可用，存在高成本绕过，影响特定角色 → 严重级”。规则条目不宜过多，通常每档两到四条即可覆盖大多数情形，剩余情形通过边界示例和仲裁处理。
每档至少配两个正例和一个易混淆反例。正例帮助判定人快速对齐，反例用来区分相邻档位。例如阻断级的反例可以是“功能不可用但仅出现在已下线的旧版本中”，说明环境条件会改变结论；严重级的反例可以是“主要功能报错但刷新后恢复”，提示偶发与持续的区别。反例应来自团队真实遇到过的争议场景，而不是凭空构造。
几类边界情形需要单独约定。数据丢失类缺陷，无论影响用户多少，通常按最高档处理，并明确是否触发安全响应流程。安全相关缺陷，按风险类型和可利用条件判定，不因“尚未被利用”而降档。仅特定环境复现的缺陷，需要区分环境是否属于受支持的生产配置：生产配置下可复现按正常规则判定，非生产配置下可复现则记录环境条件并适当降档，但不得直接关闭。边界约定应写成独立小节，与规则清单放在一起，方便判定人查阅。
角色分工、争议仲裁与标准维护
标准要落地，需要明确每个角色在定级链条上做什么、交付什么。提报人负责提供可复现的步骤、环境、实际结果与预期结果，并给出初步严重程度建议；初判人通常是测试或质量角色，依据判定问句给出定级并填写判定依据；模块负责人对涉及本模块技术影响的判定提供确认；质量负责人维护标准本身，组织校准并处理跨模块争议。角色可以兼任，但职责要写清楚，避免出现“谁都可以改级别”的情况。
争议仲裁需要一条明确路径和时限。常见做法是：初判人与提报人意见不一致时，先由模块负责人依据判定问句和边界示例给出结论；仍不一致的，提交质量负责人在约定时限内仲裁，例如一个工作日内。仲裁结论要记录理由，并判断是否暴露了标准缺口。若同一类争议反复出现，应触发标准修订，而不是每次靠个人裁量解决。
标准维护包括版本号、变更记录和生效日期。每次修订记录改了哪条规则、为什么改、从哪个日期起适用，历史缺陷保留原判定和原标准版本，便于回放对比。标准宜设定固定评审周期，例如每季度一次，并在发布流程、组织架构或产品形态发生明显变化时临时评审。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 提报人 | 提供复现信息与初步定级建议 | 缺陷记录、复现步骤、环境说明 |
| 初判人 | 依据判定问句给出定级 | 严重程度、判定依据 |
| 模块负责人 | 确认技术影响，处理模块内分歧 | 影响确认意见 |
| 质量负责人 | 维护标准、组织校准、仲裁跨模块争议 | 标准版本、仲裁记录、校准报告 |
与缺陷分诊和工单优先级的衔接
严重程度是分诊的输入之一，不是分诊结果。分诊要结合严重程度、业务紧急度、当前发布计划和资源情况，决定由谁处理、进入哪个排期。把严重程度直接当作处理顺序，会让所有高档位缺陷同时争抢资源，反而失去排序意义。工单的紧急性与 SLA 由优先级体系承载，严重程度档位中不写入响应时限，避免同一字段承担两种含义。
交接时需要携带一组固定字段，保证分诊人不必回头追问。建议包括：严重程度及判定依据、影响范围、复现条件（环境、步骤、频率）、是否存在绕过方式、关联的发布或客户信息。这些字段在缺陷工作项中作为结构化属性保存，分诊时直接读取，争议时也可作为回放材料。严重程度变更应留下记录，说明变更人和理由，便于后续统计定级稳定性。
在 ONES 中，可以把严重程度设为缺陷工作项的固定属性，将判定依据、复现条件和影响范围放入描述或自定义字段，通过状态流转记录初判、仲裁和变更过程。这样标准中的规则与系统中的字段一一对应，校准阶段抽取历史缺陷时也有完整数据可用。
试点校准与完成检查
标准写完后，先用历史缺陷做回放验证。抽取一批覆盖各档位和争议场景的历史缺陷，隐去原判定，由两名判定人独立按新标准定级，统计一致率。一致率偏低时，不要急于调整档位数量，先定位分歧集中在哪条规则或哪个维度，补充判定问句或边界示例。分歧反复出现在同一类场景，说明该场景需要单独写规则。
校准应形成固定节奏。首次校准可在标准发布前完成，之后每个评审周期抽取一定数量的新缺陷复核。参与角色包括初判人和模块负责人，质量负责人汇总结果。修订触发条件可以设为：一致率低于约定阈值、同类争议重复出现、发布流程或产品形态发生明显变化。每次校准留下记录表，包含样本、判定结果、分歧点和处理结论。
标准是否可以落地，可用一份检查清单逐项核对：档位定义是否写明决策含义；每个档位是否有判定问句；是否配有正例和反例；边界情形是否有约定；争议仲裁路径和时限是否明确；与分诊、优先级交接的字段是否确定；标准版本和生效日期是否记录。清单全部满足，且回放一致率达到团队约定水平，即可进入正式使用。
- 档位定义表：档位名称、决策含义、典型处置方向
- 判定维度表：四类维度及对应判定问句
- 判定规则清单：条件组合与结论，一规则一档位
- 边界示例集：每档正例与易混淆反例
- 角色职责表与仲裁流程说明
- 严重程度到分诊、优先级的字段交接清单
- 校准记录表与标准落地完成检查清单
常见问题
团队缺陷量很少，是否也需要完整的四档分级和仲裁流程？
档位数量可以按决策需要裁剪。缺陷量不大、发布节奏稳定的团队用三档即可覆盖“阻断发布、本次或紧邻版本修复、常规迭代修复”三类决策，判定负担更小。仲裁流程也可以简化：初判人与提报人不一致时，由模块负责人依据判定问句给出结论即可，不必设置多层上报。需要保留的是判定问句、边界示例和版本记录，这三项决定了标准能否被稳定复现，与团队规模无关。
同一个缺陷在不同环境下严重程度不同，应该按哪个环境定级？
以受支持的生产配置为准。生产配置下可复现的缺陷按正常规则判定；只在非生产配置或已下线版本中出现的，记录环境条件后可适当降档，但不直接关闭。若缺陷在多个环境表现不同，在缺陷记录中分别写明各环境下的实际结果，定级取生产配置下的结论，并在判定依据中注明环境差异，避免后续回放时误判。
严重程度定级后又被修改，历史数据还能用于校准吗？
可以，前提是保留变更痕迹。每次修改记录变更人、变更理由和变更时间，历史缺陷保留原判定与原标准版本。校准抽取样本时，以缺陷首次定级或仲裁后的最终判定为基准，并注明标准版本；跨版本对比时先确认规则是否发生变化，避免把标准修订带来的差异误判为判定不一致。
标准发布后，什么情况下应该启动修订而不是靠个案仲裁解决？
出现以下信号时优先修订标准：回放一致率低于团队约定阈值；同一类争议在多个模块重复出现；发布流程、组织架构或产品形态发生明显变化，导致原有判定问句不再适用。个案仲裁解决的是单次分歧，若同类分歧反复出现，说明规则或边界示例存在缺口，应补充判定问句或新增规则条目，并记录修订原因与生效日期。
严重程度高的缺陷是否应该自动进入最高优先级队列？
不建议直接绑定。严重程度描述影响程度，优先级还要结合业务紧急度、发布计划、客户承诺和当前资源综合判断。把高档位自动映射为最高优先级，会让多个缺陷同时争抢同一批资源，排序反而失效。更稳妥的做法是把严重程度作为分诊输入字段，由分诊人结合其他信息确定处理顺序，并在工单优先级体系中单独承载响应时限与 SLA。
