严重程度最佳实践：跨部门团队Bug / 缺陷最佳实践，常见问题

跨部门缺陷评审里，最容易引发争论的往往不是“这是不是 Bug”，而是同一个问题：研发标成中等，客服却认为客户已经无法完成下单；测试认为只是低概率边界条件，运维看到的却是错误日志正在持续增长。严重程度一旦被当成谁声音大谁定级，团队就会把时间花在争论标签上，而不是控制影响。我的核心判断是：严重程度应描述缺陷造成的实际影响，优先级应描述组织现在要多快处理，两者不能混为一谈。

一、先讲核心结论：严重程度不是催办按钮

1. 先区分影响等级和处理顺序

严重程度回答“缺陷造成了多大损害”，通常关注功能是否可用、影响范围、数据与安全风险、是否存在可行绕行方案。优先级回答“在当前资源和业务安排下，团队什么时候处理”，还要考虑合同承诺、发布窗口、工作量和依赖关系。

例如，某个低频报表字段错位可能严重程度不高，但如果当天要向监管方提交报告，处理优先级就可能很高。相反，一个影响少数内部用户的界面缺陷，技术根因很复杂，却有可靠绕行方式，严重程度可以中等，优先级也未必高。

把严重程度和优先级写进同一个字段，是跨部门协作中最常见的制度性误差。它会造成两个后果：业务方通过抬高严重程度争取排期，研发方则通过降低严重程度保护迭代承诺。双方看似在评估缺陷，实际是在谈判资源。

2. 用可观察后果定级，不用职位和情绪定级

我建议先用“用户能否完成关键任务”作为第一判断，再依次看影响用户范围、损害持续时间、数据或安全风险、替代方案是否有效。客户说“很急”是重要输入，但不是等级本身；开发说“改起来很麻烦”是排期信息，也不是严重程度。

一条可执行的严重程度定义，至少要让客服、测试、研发、产品和运维看到同一组事实后，大致能得出相近结论。不能要求每个人完全一致，但应尽量避免同一类影响在不同团队被随意标成最高级、中等级和最低级。

3. 先确定分级体系，再讨论等级名称

团队可以采用四级或五级严重程度，但不应先争论“P0 到底怎么定义”。字母和数字只是标签，真正重要的是每一级对应的用户影响、范围、数据风险和响应动作。以下示例采用 S1 至 S4，S1 表示影响最严重；具体阈值需要根据业务形态、服务承诺和监控能力调整。

这张表是分级框架，不是行业统一标准。金融交易、医疗信息、工业控制等场景，数据和安全后果可能让原本看似局部的问题直接进入高等级；内容管理或内部工具则可能更看重任务阻塞程度和替代流程。

二、背景和真实场景：跨部门争议通常从信息不对称开始

1. 同一个缺陷，在不同岗位眼里不是同一个问题

客服接触的是客户原话和受影响账户；测试关注复现条件、覆盖范围和回归风险；研发关注代码路径、故障原因和修复成本；运维看到的是服务指标、告警和日志；产品则需要判断业务任务是否被阻断。每一方拿到的都是真实信息，但都只覆盖缺陷的一部分。

典型场景是：客服收到“页面一直转圈”的反馈，先按高风险提交；测试在单一测试账户上无法复现，认为只是偶发现象；研发发现问题与某个浏览器版本有关，倾向于降低等级；运维却看到同一时段某接口错误率上升。若没有统一的证据字段，各方会把自己的局部观察当成全貌。

因此，严重程度评审不应变成“谁来给标签”，而要变成“我们当前知道什么、还不知道什么、哪些信息会改变判断”。这是我更看重的流程设计：允许初始等级暂定，但必须把不确定性和复核条件记录下来。

2. 影响范围不能只看报告数量

十条客服工单不一定比一条工单严重。十条可能来自同一位用户重复提交，也可能是十个用户各遇到一次；一条也可能来自高价值客户，或暴露出所有用户都可能受影响的系统性风险。

评估范围时，至少要区分“已确认受影响人数”“可能受影响人数”“受影响账户占比”和“关键客户或关键流程覆盖情况”。如果数据暂时拿不到，应标为未知，不要用“目前只有一例”推导“只有一例”。缺少可观测性本身，也是判断风险时应记录的事实。

3. 缺陷等级会影响组织成本，而不只是看板颜色

等级升高往往会触发更多投入：暂停发布、调集值班人员、通知客户、启动数据核验或安排回滚。等级定得过高，团队会出现告警疲劳，真正的重大问题反而不容易被辨认；定得过低，则可能错过止损窗口，把一个可逆故障拖成客户损失或数据修复事件。

所以，我不建议把“高等级比例越低”当成管理目标。更有意义的是观察：高等级缺陷是否有明确证据、发现到止损用了多久、降级是否及时、同类问题是否反复发生、误报是否消耗了关键响应资源。

4. 示例数据说明：这是一组推演，不是行业统计

为了说明等级分布怎样影响协作，我会使用一组情景模拟数据，而不是把它冒充成公开行业基准。假设一个跨部门产品团队每月处理 120 条缺陷，初始评审中 S1、S2、S3、S4 分别占 6%、24%、48%、22%。若复核发现不少高等级缺陷缺少影响范围证据，问题就不只是“等级偏高”，还可能是报障入口没有收集用户数、发生频率和绕行情况。

这组数字不能告诉我们某个团队“应该有多少 S1”。它只用于提醒：看等级比例时，必须结合业务类型、产品成熟度、缺陷来源和证据完整度；孤立地比较不同团队的等级占比，很容易把产品差异误读成管理质量差异。

三、常见误区：看似简单的分级规则为何会失效

1. 把“严重程度”当作“谁先做”

如果一个字段既承载影响等级又承载排期，填报人就会用它表达催办诉求。随后团队看到大量“严重”缺陷，却无法判断哪些真需要立即响应，哪些只是业务窗口临近。解决办法不是禁止业务方表达紧急性，而是把“严重程度”“优先级”“目标处理时间”拆开记录。

2. 用修复难度反向降低严重程度

缺陷难修，不等于影响轻；缺陷容易修，也不等于影响重大。修复工作量影响的是计划和资源安排，不能改变用户已经承受的损害。否则，复杂但严重的问题会被长期留在低等级，简单但不影响关键任务的问题反而被拔高。

在评审记录中，我会把“影响判断”和“估算工作量”分栏。如果暂时无法修复，就补充临时缓解措施、风险接受人和复核日期，而不是把等级降下来让它看起来更容易管理。

3. 把“无法复现”当成“没有影响”

无法复现只说明当前复现条件不足，不能证明缺陷不存在。环境差异、账号权限、数据状态、时区、缓存、设备型号和网络质量都可能导致问题间歇出现。正确做法是收集日志时间、用户标识、请求编号、版本、操作路径和失败截图，并明确哪些条件尚未确认。

如果缺陷可能影响资金、权限、隐私或数据正确性，无法复现不应自动降级。相反，团队应先降低潜在风险，例如暂时关闭相关功能、增加监控、核对受影响记录，再继续调查。

4. 用影响人数取代影响性质

受影响人数是重要维度，但不能独立决定严重程度。一个影响人数很少的权限绕过问题，可能比大量用户遇到的视觉偏差严重得多；一个只影响一名操作员的故障，也可能阻塞整个仓库的出库流程。

评估时应同时问：影响了谁、影响了什么任务、后果是否可逆、是否涉及敏感数据或资金、是否存在人工补救、补救成本由谁承担。人数是范围指标，不是价值判断的替代品。

5. 默认“有绕行方案”就可以降级

绕行方案只有在可执行、可持续、风险可接受、用户能理解的情况下，才应纳入降级判断。要求客户反复刷新、手工重录几十项数据、联系专人等待人工处理，这些都可能只是把系统成本转嫁给用户。

我会要求评审记录绕行方案的负责人、执行时间、失败概率和适用范围。若方案只适用于内部员工，不适用于客户；或只能覆盖部分账户，就不能写成“已有替代方案”而不注明边界。

6. 把安全漏洞等级和运行缺陷等级直接混用

安全漏洞常常需要结合攻击条件、权限边界、受影响资产和潜在后果评估；运行缺陷则还要关注发生概率、用户任务阻塞和恢复能力。安全领域可参考公开的通用漏洞评分方法理解技术严重性，但不能把某个评分直接当作业务事故等级。

例如，一个需要极特殊条件才能触发的漏洞，在技术评分中可能不算最高，但若涉及高敏感数据，组织仍可能要求快速处置。反过来，某个容易触发的低影响输入校验问题，也未必等同于业务全面中断。应保留不同维度的判断结果，再通过明确规则映射到响应动作。

7. 只在缺陷创建时定级，不复核

创建时信息往往最少。随着日志、影响账户、发生频次和临时方案逐渐明确，原等级可能需要上调或下调。若团队把首次定级当成最终结论，就会让错误判断持续影响排期和通知。

建议将等级视为“带证据的当前判断”，而不是永久标签。特别是 S1、S2 缺陷，应在影响范围变化、缓解措施生效、根因确认或恢复完成时重新评估，并保留变更理由。

四、专业判断逻辑：从业务后果走到可复核的等级

1. 用六个维度形成判断，而不是凭印象打分

为了减少跨部门的直觉冲突，我通常让评审围绕六个维度展开。它们不一定都要做成数学公式，但必须形成一致的提问顺序。

• 任务影响：用户能否完成关键任务？是体验变差，还是流程中断、结果错误或无法继续？
• 范围与扩散：影响已确认用户、可能用户、账户或地域有多少？问题是否会随时间扩散？
• 后果性质：是否涉及资金、数据完整性、权限、安全、合规或客户信任？
• 持续时间与发生频率：是一次性异常、间歇发生，还是持续失败？是否正在恶化？
• 可恢复性：是否能回滚、重试、补偿或人工修正？恢复是否会造成二次损害？
• 绕行方案：用户是否能在合理时间和成本内完成任务？方案是否经过验证，覆盖多少人？

维度之间不是简单相加关系。涉及不可逆数据损坏或敏感信息泄露时，后果性质可能压过较小的影响范围；对于纯展示问题，范围可能更重要。团队应先写清楚哪些条件可以触发强制升级，再讨论其余维度的综合判断。

2. 用分流条件识别需要立即响应的缺陷

以下条件适合作为“立即拉齐负责人”的触发器，而不是机械地自动判定所有细节：关键流程大范围中断；数据正在丢失、错写或不可恢复；存在可信的未授权访问迹象；故障影响持续扩大且没有有效止损方法；法律、监管或合同承诺要求立即处置。

触发条件的作用是防止团队在紧急场景里花半小时争论标签。进入响应后，负责人仍需确认影响事实、采取控制措施，并在证据变化后修正等级。快速升级不代表结论永不改变，先保护用户，再完善分类。

3. 建立“默认等级、上调条件、下调条件”三段规则

每个等级都应说明什么情况通常落在该级、哪些信号要求上调、哪些证据允许下调。只有“定义”没有边界，团队就会在相邻等级之间反复争议。

4. 给未知留一个正式位置

“未知”不是偷懒，也不是缺陷等级。它描述的是证据状态。团队可以在缺陷字段中另设“影响范围已确认/部分确认/未知”“绕行方案已验证/未验证”等选项，避免用一个严重程度字段承载全部不确定性。

如果缺陷来源于监控告警，未必知道受影响用户；如果来自客户投诉，可能只看到个例；如果日志保留时间不足，则历史影响范围可能无法精确还原。此时应记录下一步验证动作及负责人，而不是填入看似精确的数字。

5. 把响应时限和修复承诺分开

高严重程度需要快速响应，不代表团队能承诺在同样短的时间内彻底修复。响应时限可以定义为确认、止损、发布状态更新的目标；修复时间则取决于根因复杂度、回归验证和发布风险。

更可靠的约定是先明确“多久内有人负责、多久内提供下一次进展、何时评估缓解方案”，而不是对复杂故障承诺一个无法保证的修复时间。这样既让业务方知道事情有人推进，也避免为了赶时间跳过必要验证。

五、具体案例与数据观察：从争议走到可行动结论

1. 情景案例：结账失败被误判为低频小问题

以下是一个匿名化情景模拟，用于展示判断方法，不代表某家企业的真实事故记录。某线上业务团队发现，部分用户在结账页面点击提交后出现超时。客服最初收到 3 条反馈，测试团队在常规账号上未能复现，研发判断可能是个别网络问题，暂列 S3。

评审时，团队没有继续争论“3 条反馈算不算多”，而是要求补充五项信息：问题发生时间、客户端版本、请求编号、订单是否重复创建、相同时间段的结账接口错误率。运维随后发现，过去 20 分钟内错误率明显上升；数据核验又显示少数订单存在“页面提示失败、后台实际创建成功”的状态不一致。

这时，关键问题已从“多少人反馈”转为“用户是否会重复提交、订单状态是否可信”。团队先暂停有风险的自动重试，对受影响订单做核验，向客服提供查询口径，再修复状态回写逻辑。等级上调的依据不是反馈者的职位，而是错误率、订单状态和潜在重复交易证据。

2. 判断争议的关键：用户反馈不是唯一分母

在这个案例里，3 条反馈只说明有 3 次明确报告，并不能说明只影响 3 人。若把投诉量当作受影响人数，团队会低估没有提交工单的用户、自动化渠道捕获的失败以及静默发生的数据状态异常。

我会将证据分成三类：用户侧证据，例如工单、录屏和操作描述；系统侧证据，例如错误率、请求量、日志和监控；业务侧证据，例如订单、付款、库存或后续补偿记录。三类证据互相印证时，等级结论才更稳健。

3. 用帕累托观察找出真正影响用户的缺陷

模拟一个季度的 100 条缺陷：其中 20 条与关键流程有关，贡献了 72% 的用户任务失败记录；另外 80 条主要是低影响体验问题。这并不是说后 80 条不值得修，而是说明团队不能按缺陷数量平均分配精力。业务后果往往集中在少数缺陷类型上。

实际分析时，应把缺陷类别与用户影响关联，而不是只统计“Bug 总数”。如果同一根因反复产生多个工单，应合并观察根因；如果一条缺陷影响多个关键流程，则不能因为记录条数少就忽略其总损害。

4. 观察等级变更，比观察最终等级更有诊断价值

若一个团队经常在创建后上调等级，可能是报障入口没有收集影响范围，或初始分诊缺少运维、测试参与；若大量缺陷被下调，可能是业务方倾向于高报，或等级边界过于模糊；如果高等级长期不变但恢复时间很长，也可能是缓解方案和事故响应能力不足。

等级变更不是管理失误的直接证据，它是一种流程信号。应抽查变更原因、变更时间和补充证据，判断是正常的信息更新，还是团队系统性地在最初阶段缺少判断条件。

5. 衡量速度时要分解节点，而不是只看“修复耗时”

从缺陷出现到完整修复，可能经过发现、确认、分级、止损、修复、回归、发布和业务核验。只看总时长，无法判断瓶颈在哪里。高等级问题卡在“等待确认”与卡在“复杂修复”是两类完全不同的管理问题。

以下数字仍是用于流程分析的示意值。团队需要根据自身服务等级、工作时间制度、发布方式和业务风险制定目标；不要把这些示意数值直接转成对外承诺。

六、落地流程：让评审变成可重复执行的动作

1. 报障入口收集足够信息，但不要要求用户写技术论文

缺陷报告应让提交者能提供业务事实，不应强迫客服或普通用户猜测根因。必填字段控制在真正能帮助判断的范围：发生时间、操作路径、预期结果、实际结果、影响任务、影响对象或账户、复现频率、是否存在绕行方式。

技术信息可以由系统自动补充，例如版本号、设备、请求编号和日志链接。若某些信息无法自动获得，应允许填写“未知”，并让受理人安排后续确认。入口越复杂，越可能出现线下消息、口头转述和截图散落在聊天记录里的情况。

2. 设置分诊负责人，而不是让所有人同时争论

每条缺陷需要一个明确的分诊负责人。负责人不一定是最终拍板者，但应负责整理证据、召集必要角色、记录暂定等级和推动复核。没有负责人时，常见结果是每个人都给过意见，却没人确认影响范围，也没人更新业务方。

跨部门评审可以采用轻量分工：业务或客服说明用户任务与反馈；测试说明复现条件和覆盖范围；研发说明技术路径和风险；运维说明线上指标与止损能力；产品或业务负责人确认关键任务和客户影响。不是每个缺陷都需要所有人参加，只有触发相应风险时才扩大评审范围。

3. 先止损，再完成精确归因

当缺陷可能造成持续损害时，先做能降低风险的动作，不必等到根因完全确认。关闭风险开关、回滚版本、暂停自动重试、增加人工核验、冻结可疑操作，都可能比立即改代码更稳妥。

止损动作也有副作用：关闭功能可能影响更多正常用户，回滚可能带来数据兼容问题，限流可能延长处理时间。因此每个动作都要有负责人、执行范围、回滚条件和验证指标，而不是只在缺陷记录里写一句“已处理”。

4. 明确状态更新节奏和受众

业务部门不一定需要看到每一次代码提交，但需要知道当前影响、已采取措施、已知风险、下一次更新时间和需要配合的事项。用户沟通与内部技术排查可以使用不同表述，但事实不能互相矛盾。

高等级问题适合由单一协调者汇总信息，避免研发、客服和业务分别发布不同版本的结论。若暂时没有新结论，也应按约定更新“正在验证哪些假设”，而不是等到彻底修复后才首次回复。

5. 关闭缺陷前验证结果，而不只验证代码已合并

“代码已提交”不是用户影响消失的证据。关闭前应确认修复已部署到目标环境、相关场景通过验证、监控恢复到可接受区间、必要的数据修复完成、业务方知晓恢复状态。

若缺陷涉及可能受影响的历史数据，应另设数据核验或补偿任务。代码修好不等于过去发生的错误自动恢复。若无法确认历史范围，应明确记录剩余风险和后续核查负责人。

6. 复盘要产出控制改进，不要只产出“加强测试”

高影响缺陷复盘的价值，不是重复描述故障经过，而是找出为什么影响能持续、为什么没更早发现、为什么绕行无效、为什么不同部门看到的信息不一致。改进动作应尽量具体，例如增加某项业务指标、为特定数据状态增加校验、补充告警路由、建立回滚验证步骤。

“加强测试”“提高意识”“加强沟通”如果没有负责人、完成时间和验证方式，通常无法验证效果。一个合格的复盘动作，应该能回答：谁完成什么变化、如何确认变化有效、如果再次发生会观察到什么不同。

七、不同情况下的行动建议：不要用同一套节奏处理所有缺陷

1. 关键业务中断或损害可能扩大

立即确定单一协调者，先确认故障是否仍在发生，再决定回滚、关闭功能、限流或人工兜底。并行启动影响范围核查，但不要等核查完成才止损。对外沟通使用已确认事实，未知部分明确标注为正在核验。

此类问题应优先关注恢复与损害控制。根因分析、长期修复和历史数据核验可以并行，但不能让“找出完美根因”阻碍可逆的风险控制动作。

2. 只有少量用户受影响，但涉及数据、安全或资金

不要因人数少而直接降级。先判断后果是否可逆、是否有未经授权的访问或数据错写、影响是否可能扩大。限制可疑操作，保存相关日志和审计信息，并让安全、数据或业务负责人参与评估。

如果确认只是局部影响，也应保留为什么没有扩大处理的证据。敏感风险的降级必须依赖验证结果，不宜只凭“目前没收到更多投诉”。

3. 影响范围不清、复现困难

采用“暂定等级加复核时间”而不是僵硬地选一个低等级。为下一步调查设定最小证据清单：请求编号、发生时间、版本、账号类型、操作路径、监控查询区间。若潜在损害高，先采取低成本、可逆的保护措施。

如果监控缺失，明确把“无法知道影响范围”作为风险项，补充临时日志或抽样核验。持续观测期限应由问题性质决定，不应因为短时间没有新反馈就认定问题消失。

4. 有绕行方案，但用户成本高

把绕行成本量化：每名用户多花多少时间、是否需要支持人员介入、是否容易操作错误、能维持多久、是否会导致重复录入或数据不一致。方案若把工作转移给客户或一线员工，不应简单视作“问题已解决”。

优先安排能减少累计损害的修复或自动补偿。若正式修复需要较长时间，应向受影响人群说明临时流程、适用范围和停止使用条件，并监测绕行带来的新增错误。

5. 缺陷发生频率低，但单次后果严重

低频不等于低风险。对于可能造成重大损失的偶发缺陷，应评估最坏可信后果、触发条件和可检测性。若每次发生都难以恢复，团队可能需要提高监控、增加预防性校验或暂停高风险路径，即使样本数量很少。

但也不能把任何“理论上可能”的极端后果都当成最高等级。需要区分有证据支持的可信场景与纯粹假设，并记录触发前提、控制条件和剩余风险。

6. 纯体验问题数量多，挤占核心修复能力

将体验问题按用户任务、重复频率、客户群体和支持成本归类。单个问题低严重，不代表一整类问题的累计成本低。可以把高频、重复、明显影响信任的体验问题合并成主题修复，而不是逐条抢占紧急通道。

此类问题适合通过固定维护容量处理，并设置升级条件：反馈量增长、影响关键客户、导致任务失败、转化或支持工单出现稳定变化时，重新评估等级。

7. 发布窗口临近，业务方要求立即处理

先区分“发布风险”与“缺陷严重程度”。如果某缺陷会导致本次发布不符合合同、合规或关键业务条件，发布优先级可能提高；但等级仍应描述影响本身。必要时选择延迟发布、关闭受影响功能、分批放量或发布后监控，而不是为了赶时间跳过验证。

如果修复本身会带来更大回归风险，决策要同时比较“带缺陷发布”的损害与“带修复发布”的不确定性。可用小范围灰度、功能开关和回滚预案降低两侧风险。

八、取舍与治理：规则要足够清楚，也要给例外留出口

1. 四级和五级分级，各有适用边界

如果团队经常无法说清中间等级的区别，增加等级数量不会自动提高精度。先验证现有定义能否指导响应，再决定是否需要细分。标签越多，越需要成熟的数据和培训来支撑。

2. 统一口径与产品差异之间要做取舍

统一等级有利于跨团队比较和管理汇总，却可能掩盖产品差异。内部知识库工具和支付核心流程，不应机械使用完全相同的影响阈值。比较稳妥的做法是：共享评估维度和核心等级语言，各业务线补充场景化示例与强制升级条件。

这样既能让管理层理解“严重”大致意味着什么，也允许产品团队说明本领域的关键任务。若某业务线需要偏离通用标准，应写出原因并定期复核，而不是形成没有记录的隐性规则。

3. 速度和准确性不可能在所有阶段同时最大化

重大故障需要先快速判断和止损，初始结论可以不完美；低风险体验问题则可以投入更多时间完善影响信息。要求所有缺陷在创建时都完成精确评估，会拖慢响应；完全不复核，又会让早期猜测变成长期事实。

因此，流程应该区分“初始判断”和“确认判断”：前者以快速安全为目标，后者以证据完整为目标。等级变化不应被视为丢脸，真正应避免的是不记录依据、反复改级却没有新增信息。

4. 不要把团队间排名当作改进方法

不同团队的用户规模、产品成熟度、数据风险和报障渠道不同，直接比较高等级缺陷数量，容易制造压低等级的动机。更适合横向观察的是规则执行质量，例如证据字段完整率、首次响应是否有责任人、影响范围多久完成初判、等级变更是否有理由、重复缺陷是否减少。

这些指标也不能单独作为绩效排名。若把“降低高等级占比”设为目标，团队可能会改标签而不是减少风险。治理的目的应是更快识别损害、更稳妥控制影响和减少复发，而不是让报表变得漂亮。

5. 设计指标时，区分输入、过程和结果

输入指标检查信息质量，例如缺陷报告是否包含时间、路径和影响任务；过程指标检查协作效率，例如首次响应、止损和复核耗时；结果指标检查用户影响，例如任务失败、数据修复量、重复发生率和支持成本。只看过程速度，可能鼓励草率关闭；只看结果数量，则难以知道哪里值得改进。

应特别留意平均值掩盖长尾的问题。少数缺陷处理特别久，可能对用户造成远高于平均值的损害。除中位数外，可以观察高分位耗时、超时原因以及不同严重程度的样本分布，但不要在样本量很小时过度解读波动。

6. 工具能减少遗漏，不能代替判断

某项目管理平台可以用来配置严重程度字段、必填证据、响应负责人、状态流转、通知规则和复核提醒。对于中大型企业或 100 人以上组织，工具价值通常在于让跨团队流程留下连续记录，减少信息散落在邮件、聊天和个人表格里的风险。

但工具不会自动知道用户任务有多关键，也不能仅凭关键词判断是否涉及数据风险。自动规则更适合做提醒和分流，例如缺少影响范围时要求补充，高等级缺陷未指定负责人时发出提示；最终等级仍应由掌握业务和技术证据的人共同确认。

九、常见问题：把最容易混淆的边界说清楚

1. 严重程度和优先级到底有什么区别？

严重程度描述缺陷造成的影响，优先级描述组织安排的处理顺序。严重程度高通常会推动优先处理，但两者不必完全一致。发布时间、合同期限、客户承诺、修复依赖和资源约束，都可能改变优先级，而不会改变缺陷已经造成的影响。

2. 客户说“非常严重”，是否应该直接定为最高级？

客户反馈应被认真接收，但不能单独决定等级。先确认受影响的任务、账户范围、失败频率、实际后果和是否有替代方案。若涉及敏感数据、资金或关键流程，即使暂时只有一个报告，也应快速升级排查；若是低影响展示问题，则可以记录客户紧急性并在优先级中处理。

3. 缺陷无法复现时，应该定低级吗？

不应该自动定低级。应记录复现失败的环境、账号和测试条件，补充日志、时间戳和请求编号，并明确下一步核验责任人。若潜在后果较大，先采用可逆的风险控制方式，再根据证据更新等级。

4. 严重程度能否用影响用户人数直接计算？

不宜只用人数。还要考虑任务重要性、后果性质、持续时间、数据或安全风险、可恢复性和绕行成本。少数人遭遇不可逆损失，可能比大量用户遇到短暂视觉问题严重。人数应作为范围证据，而不是唯一公式。

5. 什么时候可以下调等级？

当新证据证明影响范围比预期小、风险已被有效控制、绕行方案经过验证，或原始报告被证伪时，可以下调。必须记录依据、证据来源和时间，并说明还剩哪些风险。仅仅因为修复很难、团队忙不过来，不是合理的下调理由。

6. 是否所有团队都应该使用同一套等级？

应共享基本判断维度和关键响应原则，但不同业务可以有场景化补充。对数据完整性、资金、隐私或安全风险高度敏感的流程，应设更明确的升级规则。统一的目的是协作，不是抹平业务差异。

7. 严重程度和安全漏洞评分是否相同？

不完全相同。漏洞评分关注技术属性和攻击风险，运行缺陷分级还需要考虑实际业务影响、用户范围、恢复方式和组织响应。可以互相参考，但不宜直接把一个评分换算成事故等级而不说明业务判断。

8. 团队应该多久复核一次分级规则？

没有适用于所有团队的固定周期。较实用的做法是，在重大故障复盘、产品业务变化、服务承诺调整或发现等级争议反复出现时复核；也可定期抽查一批缺陷，检查同类问题是否被一致处理。规则修改后，应给提交者、分诊人员和处理团队同步示例。

十、总结：先判断损害，再决定速度

1. 一套能落地的原则

严重程度最佳实践不是找到一张适用于所有企业的分级表，而是建立共同的判断顺序：先看用户任务和实际后果，再看范围、持续时间、数据与安全风险，然后评估可恢复性和绕行成本；证据不足时保留未知，设置复核条件；紧急问题先止损，之后随着事实变化更新等级。

我最反对的做法，是把等级当成跨部门谈判筹码。客服用最高级争取注意，研发用低等级保护排期，产品再靠个人经验裁决。这样的体系即使字段齐全，也不会带来可靠协作。真正有效的分级，是不同岗位基于同一证据做出可解释、可复核的判断。

2. 下一步怎么做

1. 抽取最近 30 至 50 条缺陷：检查严重程度是否有明确用户影响、范围、风险和绕行证据。
2. 找出争议最多的边界：例如“少量用户但高业务损害”“无法复现”“有人工绕行”等，补充场景示例。
3. 拆分字段：至少分开严重程度、优先级、影响范围、证据状态和下一次复核时间。
4. 指定分诊负责人：确保每条高影响问题有人整理事实、协调判断和同步状态。
5. 复盘等级变化：追问上调和下调分别由什么新证据触发，而不是只看最终标签。
6. 按节点改善响应：分别看首次响应、影响初判、止损、修复验证，找到真正拖慢用户恢复的环节。

如果团队只能先改一件事，我建议从“严重程度和优先级分开”开始。它不会立刻修复缺陷，却能减少争标签的时间，让讨论回到用户影响、风险控制和处理顺序上。最好的分级系统，不是让所有人更快地选颜色，而是让团队更早发现正在扩大的损害，并知道下一步该由谁采取什么行动。