严重程度怎么做？研发团队最佳实践：Bug / 缺陷从0到1

研发团队讨论“这个 Bug 到底算不算严重”时，真正拖慢交付的往往不是缺少等级，而是同一个故障在产品、研发、测试和客服手里有四种解释：有人看影响人数，有人看修复成本，有人看客户声音，还有人只看是否挡住上线。严重程度要从 0 到 1，关键不是先造一套漂亮的 S0，S4 标签，而是把“影响有多大”与“现在有多急”分开，再把判断依据、升级条件和处置动作写进流程。否则，等级越细，争论可能越多。

一、先讲核心结论：严重程度描述影响，不等于优先级

1. 严重程度回答“坏到什么程度”

我建议团队把严重程度定义为：缺陷在当前版本、当前用户和当前业务条件下造成的实际或潜在损害。它衡量的是影响面和后果，不是开发人员觉得改起来麻不麻烦，也不是提单人有多着急。

例如，一个低频页面的文案错字，修起来可能只需几分钟，但通常不构成高严重程度。反过来，一个需要重构才能解决的数据越权问题，虽然修复成本高，也不能因此被降级。严重程度应由影响事实决定，不能被估算工时反向定义。

2. 优先级回答“什么时候处理”

优先级是资源和时间的决策：什么时候修、由谁修、是否打断当前迭代。它会受到严重程度影响，但还要考虑版本冻结时间、客户承诺、替代方案、修复风险和团队容量。

同一严重程度的两个缺陷，优先级可以不同。一个影响少数内部用户、存在可靠绕行办法的缺陷，可能排在大版本后续修复；一个影响范围较小但已经触发监管时限的缺陷，则可能必须立即处理。严重程度是对影响的判断，优先级是对行动顺序的判断。

3. 从 0 到 1，先建立四级判断，不要先追求精细

对多数正在建立缺陷管理机制的团队，我通常建议先用四级严重程度，必要时增加“待评估”状态，而不是一开始就设计七八个等级。等级太多会制造虚假的精确感，团队未必能稳定区分相邻级别。

这里的等级不是跨公司通用的行业标准，而是一个可落地的起点。团队可以采用其他命名，但必须让每个等级对应明确的影响特征和动作。若两个等级在实际评审中经常无法区分，就应合并，而不是再补一段更长的定义。

4. 先让标签改变行动，再让标签变得精细

等级存在的价值，不在统计报表里颜色是否丰富，而在于是否触发不同的响应机制。S0 应该触发事件响应和风险控制；S1 应该触发负责人确认、发布评估和时间承诺；S2、S3 则可以进入有节奏的迭代管理。

如果所有等级最终都走同一条队列、同一套响应时间、同一类验收，那么团队不需要更多等级，先把动作差异补齐更重要。等级是流程开关，不是装饰性字段。

二、背景和真实场景：为什么一个 Bug 会被评成四个等级

1. 同一故障在不同角色眼里不是同一件事

产品经理可能把“用户能不能完成任务”作为判断核心；研发更关注故障范围、复现概率和修复风险；测试会看缺陷是否阻断验收；客服则最先感知到投诉量和客户级别。这些视角都重要，但若没有共同的影响模型，会议就容易变成谁的声音更大，谁的等级更高。

我在缺陷评审中更愿意先问事实，再谈等级：哪些用户受影响？从哪个版本开始？关键任务是否能完成？数据有没有写错或丢失？是否有安全边界被突破？有没有经过验证的替代方案？这些问题能把“严重不严重”的情绪讨论，转成可复核的判断。

2. 以企业协作平台为例，影响不能只按用户数计算

以 PingCode 这类面向中大型企业、尤其是 100 人以上组织的研发协作平台为例，用户可能分布在多个团队、项目和权限边界中。一个问题即使只影响一个项目负责人，如果导致跨项目权限暴露，也可能比影响几十名用户的界面错位更严重。

相反，某个报表加载缓慢可能涉及较多用户，但如果核心操作不受阻、数据准确、存在替代查询方式，其严重程度未必高于少量用户遇到的审批数据丢失。用户数量是影响面的一部分，却不能代替业务后果。

3. 组织规模越大，缺陷影响越容易沿流程传导

在小团队里，提单人常常能直接找到开发人员补充上下文；在多团队、多项目、多角色组织中，一个缺陷可能先进入服务台，再进入产品分流，最后才到研发。传递环节变多后，缺少统一的严重程度定义，会带来重复澄清、错误升级和责任悬空。

因此，中大型组织不只需要“严重程度”字段，还需要一套配套信息：受影响的业务流程、版本与环境、影响对象、是否有绕行方案、数据风险、临时处置人和复核时间。工具可以承载字段、状态与通知，但最终质量取决于团队是否按同一规则填报和评审。

4. 先区分“发现时影响”与“修复后风险”

严重程度判断常有一个容易忽略的时间维度：刚发现时，团队掌握的信息可能不完整；修复过程中，又可能发现影响范围比原先更大。等级因此不应被视为一次填写、永不变化的静态事实。

建议保留变更记录，并在关键证据出现时重新评估。例如，原来认为只是一个用户配置异常，排查后发现同一版本批量写入了错误数据；此时应升级等级、扩大回归范围并通知相关负责人。重新评估不是前一次判断失职，而是事实变化后的正常动作。

三、常见误区：看似简单的定级规则为什么会失效

1. 把客户声音大小当成严重程度

重要客户反馈当然需要认真处理，但客户的业务影响和缺陷的客观严重程度不是一回事。少数客户遇到资金损失或数据泄露，严重程度可能很高；大量用户遇到可绕行的非核心展示问题，也不必自动定为 S0。

更稳妥的做法是把“客户重要性”放在优先级决策中，把“实际损害”放在严重程度判断中。对于有合同承诺或时限要求的客户问题，可以提高处理优先级，但不要为了让问题排到队列前面而篡改影响等级。

2. 把复现概率直接等同于影响大小

容易复现的缺陷不一定严重，难复现的缺陷也不一定轻微。复现概率描述的是问题出现条件是否容易满足；严重程度描述的是问题发生时造成什么后果。两者相关，却不是同一个维度。

例如，一个每月才出现一次的权限绕过，频率低却可能造成越权访问；一个每次刷新都会发生的轻微错位，频率高但未必妨碍任务完成。正确做法是同时记录发生频率、受影响范围和后果，不要用其中一项替代全部判断。

3. 用修复工时决定严重程度

“改起来很麻烦”不是降低等级的理由，“很容易修”也不是提高等级的理由。修复成本属于处置计划和技术风险评估，不属于影响严重程度本身。

如果一个高严重缺陷需要大范围改造，正确处理方式是保留其高严重判断，再评估临时止损、功能开关、数据修复或分阶段上线；不能因为修复困难就把它降级，让队列看起来更轻松。

4. 把“阻断上线”当作唯一判断标准

发布是否被阻断是重要决策，但并非所有严重缺陷都必须以同一种方式阻断整个版本。有时可以关闭受影响功能、限制特定入口、回滚部分服务或分批放量；也有些缺陷不影响发布，却需要上线后立即采取监测和补救措施。

团队要分别回答两个问题：这个缺陷影响有多大？以当前发布计划和缓解措施看，是否允许上线？前者是严重程度，后者是发布决策。把二者混在一起，会让等级跟着发布节奏摇摆。

5. 只写“高、中、低”，没有可观察的判据

“高”对甲团队可能意味着核心功能不可用，对乙团队可能只是影响重要客户。缺乏定义的等级会造成跨团队比较失真，也会让新成员依赖口口相传。

定义应该使用可观察的业务事实，例如关键任务能否完成、数据是否正确、影响是否跨租户、是否有安全风险、替代方案是否经过验证。抽象形容词可以留在标签里，但必须由具体判据支撑。

6. 用“已安排修复”掩盖尚未控制的风险

缺陷进入迭代，不代表风险已经消失。对于持续发生的数据损坏、权限异常或关键服务故障，团队还需要明确临时控制措施、影响用户通知、数据修复方式和回退条件。

如果只盯着“修复日期”，可能错过更重要的止损动作。严重程度较高的问题，处置计划至少应写明当前风险是否仍在扩大、谁负责监控、什么条件触发升级或回滚。

四、专业判断逻辑：把影响拆成可讨论、可复核的维度

1. 先收集事实，再做等级判断

我建议评审按“现象，对象，后果，控制，决策”的顺序进行。先确认发生了什么，再确认谁受影响、损害是什么、是否有可验证的缓解方式，最后才给等级并决定行动。这个顺序可以减少先贴标签、后找理由的锚定效应。

1. 现象：记录实际表现、版本、环境、复现步骤和发生时间，不用“系统坏了”代替事实。
2. 对象：明确受影响的用户类型、租户、团队、项目、设备或数据范围。
3. 后果：判断关键任务是否受阻，是否产生数据、资金、安全、合规或声誉损害。
4. 控制：确认绕行方案是否存在、是否有效、是否需要人工操作，以及风险是否仍在扩大。
5. 决策：确定严重程度、优先级、负责人、响应时限、发布影响和复核时间。

2. 用五个维度检查影响，而不是机械打分

为了让讨论完整，我会检查五类维度：业务关键性、影响范围、损害后果、可恢复性和风险敏感性。它们不是必须相加的评分表，更适合作为防漏项清单。特别是安全、隐私和数据完整性风险，不应被其他维度的低分平均掉。

3. 设定升级规则，处理“低频但高后果”问题

一些影响不适合做平均分。安全越权、隐私泄露、不可逆数据损坏等情况，即使发生概率较低，也应设置升级规则。实践中可以规定：只要触发某类风险，就至少进入 S1 评估；若正在发生且范围不明，则先按较高响应级别止损，调查后再调整。

这不是夸大问题，而是避免用“目前只发现一个案例”推断整体风险很低。若影响边界尚未查清，团队要把“不确定性”当作需要处理的信息，而不是自动当作没有影响的证据。

4. 区分已证实影响、潜在影响和未知影响

严重程度评审最好标注证据状态：已证实、合理推断、尚不明确。三者对应不同的处理方式。已证实影响用于确认当前等级；合理推断用于评估风险边界；尚不明确则需要指定调查任务和更新时间。

当未知范围涉及重大损害时，先按保护性原则处置，再用调查结果校准等级。例如暂时关闭入口、限制访问或停止相关任务，等日志与数据核查完成后再决定是否恢复。把不确定性显式写出来，比强行给出一个看似确定的数字更专业。

5. 等级之外，必须明确优先级和时限

建议在缺陷记录中把严重程度、优先级、响应时限和目标解决时间分开。响应时限是团队何时确认和采取行动；目标解决时间是计划完成修复或形成替代方案的时间。两者都不等于“问题一定在这段时间内彻底消失”。

如果团队使用某项目管理平台或缺陷跟踪工具，可以配置不同等级对应的必填字段、负责人通知和状态流转。自动化应减少漏处理，而不是替代判断：规则可以提示风险，最终等级仍应由了解业务影响的人确认。

五、案例与数据观察：用一次订单重复提交说明如何定级

1. 场景设定：页面超时后，用户再次提交

下面用一个情景案例演示判断过程，数据为示意数据，不代表任何企业的真实线上事故。某企业服务系统在网络抖动时，用户提交订单后页面显示超时；部分用户再次点击提交，后台偶发生成重复订单。问题在周一上午被客服转给研发。

最初的提单写着“订单页偶尔卡住”，如果只看页面表现，容易被评成 S2。进一步核对后发现：问题集中于特定接口重试条件；重复订单比例约为受影响提交的 0.8%；订单可人工识别，但对账需要客服和财务共同处理。

2. 定级不能只看 0.8%：还要看后果是否可控

0.8%看上去不高，但分母是什么非常重要。如果一天只有几十笔提交，实际影响可能有限；如果该功能每天处理数万笔业务，受影响绝对数量就可能不可忽略。百分比不能脱离统计窗口、样本量和业务价值解释。

团队接着确认：重复订单暂未导致重复扣款；客服可以通过订单标记识别；系统没有稳定的自动去重机制；问题影响一个版本的部分客户，且发生条件仍在。基于这些事实，团队可以先评为 S1 或 S2，并把判断依据写清：若确认出现资金重复扣款、影响扩散或无法及时识别，应升级为 S0；若加上幂等控制后风险被有效限制，则可重新评估。

3. 处置顺序：先阻止损害，再追求根因修复

这类问题的首要动作不是立刻改页面提示，而是确认后台是否存在重复写入、资金是否重复处理、受影响订单如何识别。接着可以临时限制重试、增加幂等校验、给客服提供核查清单，并由研发补充日志和监控。根因修复需要覆盖前端重试、接口幂等与数据对账。

1. 在一小时内核对重复订单数量、涉及版本和客户范围，确认是否涉及扣款或履约。
2. 若仍有新增，先关闭高风险重试路径或启用经过验证的临时限制。
3. 由业务人员确认受影响记录的识别和补偿方式，研发负责自动化核查工具。
4. 修复后使用历史样本、并发请求和网络超时场景做回归，不能只验证正常网络下单。
5. 观察一个完整业务周期，确认重复率回落且没有新增隐性损害，再关闭事件跟踪。

4. 一个小型样本推演，展示分母对判断的影响

假设两个产品都报告“重复订单率 0.8%”。产品甲一周有 250 次有效提交，对应约 2 笔重复订单；产品乙一周有 50,000 次提交，对应约 400 笔。比例相同，但核查和补偿成本、业务影响范围完全不同。该例为样本推演，目的是说明绝对量和业务后果必须一起看。

也不能因此把绝对数量当作唯一标准。假如产品甲的两笔订单涉及高价值合同或不可逆履约，风险可能更高；产品乙的订单若能可靠自动合并，实际损害可能较低。定级应从“比例、绝对量、后果、控制能力”共同推导，而不是挑一个最醒目的数字。

5. 用结果数据验证处置是否有效

缺陷修复完成，不等于问题真正解决。团队应观察与故障机制相关的指标，例如重复写入次数、受影响记录数、人工对账工时、补偿完成率和再次发生率。不同缺陷需要不同指标，不能所有问题都只看“关闭数量”。

在上述情景中，如果接口幂等修复上线后重复订单降为零，但客服仍需手工处理存量订单，事件就还没有完全收尾。可以把“技术修复完成”和“业务影响清理完成”设为两个状态，避免缺陷单关闭过早、影响却留在一线团队。

六、从 0 到 1 的落地步骤：把规则变成团队每天能用的流程

1. 第一步：盘点当前缺陷，找出最常见的争议

不要先开会设计一套宏大制度。先抽取最近 4 到 8 周的缺陷，看看哪些问题最常引发升级、重复讨论、延期或错误关闭。样本不必很大，但应覆盖正常迭代、线上故障和客户反馈。

可以选取 30 到 50 条具有代表性的缺陷，由产品、研发、测试和支持角色分别独立定级，再比较分歧。这里的数字只是工作坊建议样本量，不是统计学硬门槛。若团队规模较小，抽取全部近期缺陷反而更有价值。

2. 第二步：写清等级定义与升级条件

每个等级最多写三类内容：影响特征、典型例子、必须动作。定义应尽量短，方便提单时阅读；复杂边界放在升级规则和案例库里。团队还要明确哪些情况可直接触发高等级评估，例如越权访问、关键数据不可恢复、核心交易无法完成。

不要用“影响严重”“用户很多”“无法接受”这类没有边界的表达。可以改成“多个客户无法完成关键流程”“没有经过验证的绕行方案”“数据完整性无法确认”等可核查描述，并允许评审人记录证据不足。

3. 第三步：建立提单模板，降低缺失信息造成的误判

缺陷模板不应只要求标题、描述和截图。至少应包含环境与版本、发生时间、复现步骤、预期结果、实际结果、受影响对象、影响流程、数据风险、绕行方式和证据链接。字段太多会降低填写质量，因此可以按等级逐步显示补充字段。

例如，所有缺陷都要求说明受影响对象；当提单人选择可能涉及数据、安全或资金风险时，再出现对应核查项。这样既能提醒提单者，也避免低风险视觉问题被迫填写一长串无关信息。

4. 第四步：设定分流时段与响应责任

严重程度规则要进入日常节奏。团队可以每天安排一个短时段处理新缺陷分流，S0、S1 则设置即时升级渠道和明确值班责任。分流负责人不一定是最终定级者，但必须能拉齐业务、研发和测试判断，并确保问题不留在“待确认”状态里。

待确认状态必须有负责人和下次更新时间。一个缺陷如果连续多天停留在“信息不足”，它本身就是流程问题。系统可以提醒逾期，但团队还要区分提单人补充信息、研发调查和业务确认分别由谁负责。

5. 第五步：用案例校准，而不是只靠文档培训

规则发布后，挑选历史缺陷做一次匿名复盘，让团队独立判断，再对比分歧原因。重点不是追求所有人给出完全一样的答案，而是看分歧是否来自事实不同、定义不清，还是角色关注点不同。

如果分歧集中在“影响范围如何算”，就补充范围示例；如果争议集中在“有无绕行”，就明确什么叫可靠绕行；若大家都同意严重程度，却对是否阻断发布意见不同，应修订发布决策机制，不要错误地往严重程度定义里塞更多内容。

6. 第六步：每月检查分布与偏差，避免等级膨胀

每月可以看缺陷等级分布、从提单到分流的耗时、等级变更比例、逾期率、重复打开率和线上逃逸情况。单看 S0、S1 的数量没有意义，必须结合产品规模、用户量、发布频率和业务阶段解释。

如果某个团队几乎所有问题都是 S1，可能是定义过宽，也可能是核心功能确实处于高风险状态；如果 S0 多年为零，也不能直接证明治理优秀，可能是团队没有及时升级或缺少事件识别机制。数据用于提出问题，不应直接用于排名和问责。

七、不同情况下的行动建议与取舍

1. 小团队：优先追求判断一致，不要过度流程化

十几人的研发团队通常可以用四级定义、一个分流负责人和一个短评审机制起步。每个缺陷要求过多审批，会让流程成本高于问题本身。重点是高影响问题能被及时看见，普通问题有稳定的排期入口。

取舍上，可以接受部分中低等级缺陷由负责人快速判断，但 S0、S1 必须有第二角色复核。若团队没有专职测试或支持岗位，可以轮值补足信息采集责任，避免“没人负责定级”成为默认状态。

2. 多团队组织：增加共同语言和跨团队升级机制

在 100 人以上、多个产品线或多个交付团队并行的组织中，等级定义应统一到足以横向沟通，但具体响应时限可以按服务类型设定。核心平台、内部工具和低频试验项目的响应能力并不相同，不能要求同一 SLA，却应使用共同的影响词汇。

这类组织可以通过某项目管理平台或缺陷跟踪系统维护统一字段、权限、通知和变更记录。以 PingCode 这样的研发协作平台为例，价值在于承载跨团队工作流和缺陷上下文，而不是替团队自动判断哪个问题更严重。没有明确分级规则时，工具只会更快地传递混乱。

3. 面向消费者的在线服务：把影响范围和扩散速度放在前面

用户规模大、发布频繁的在线服务，应重点关注影响扩散速度、受影响比例、关键转化路径和恢复能力。用户投诉数量可能滞后于真实故障，监控告警和业务漏斗异常有时会更早出现。

取舍上，早期可以对不确定但可能扩大的问题采取保护性措施，例如暂停灰度、关闭高风险功能或回滚。代价是可能牺牲短期可用功能；收益是避免损害继续扩大。是否回滚应结合变更风险、数据一致性和恢复成本，而不是机械规定所有 S1 一律回滚。

4. 涉及安全、隐私或资金：宁可先止损，再快速校准

这类问题的下行损失可能远高于临时处置的成本。遇到可信的越权、敏感数据暴露、错误扣款或不可逆数据变更，应优先限制风险路径、保全证据并通知相应负责人。等级可以在事实更清晰后调整，但止损不能等到所有调查结束。

取舍上，临时关闭功能可能影响正常用户，快速修补也可能引入新故障。团队应把“风险消减措施”和“永久修复”分开评审，先选择可撤销、影响可控的方案，并明确恢复条件、验证负责人和回退方案。

5. 版本临近发布：不要为了守住日期篡改等级

临近发布时，团队容易把“会不会延期”偷偷塞进严重程度判断。正确做法是先按影响定级，再把发布窗口、修复风险、临时规避和客户承诺用于发布决策。若缺陷影响有限且绕行可靠，可以决定带风险发布，但需要明确接受风险的人和补救计划。

取舍不应是“上线或不上线”两个按钮。可考虑分批放量、关闭单一功能、限制受影响人群、增加监控阈值或延后特定能力。方案越复杂，越需要验证实际回退路径，而不是只在会议上假设它可行。

6. 试点期与成熟期：流程重点并不相同

试点期的主要目标是快速暴露分歧、验证定义是否有用。因此应记录争议案例和改判原因，允许规则小步调整。成熟期则更需要稳定口径、跨团队可比性、数据审计和定期复核，避免每个项目都长出一套自己的等级解释。

无论哪个阶段，都要保留人工判断空间。自动化适合做缺字段提醒、超时通知、相似缺陷关联和升级建议；不适合仅根据关键词或投诉数自动下结论。缺陷描述往往不完整，错误自动定级可能让团队过度响应，也可能把真正的高风险问题埋进队列。

八、复盘与长期治理：让严重程度成为学习机制，而非问责标签

1. 关注等级改判背后的原因

等级从 S2 升到 S1，不必然表示有人判断失误。可能是新的日志证明影响面扩大，也可能是数据核查发现损害不可逆。复盘时应区分“事实发生变化”和“规则执行偏差”，避免团队为了不被批评而不愿调整等级。

有价值的问题包括：提单时缺少什么信息？哪个监控信号本可以更早发现？绕行方案是否真的可执行？业务和研发是否对“核心流程”有共同定义？这类问题能帮助团队改善系统，而不是只追问最初是谁填错了字段。

2. 用复发率和逃逸情况检验分级质量

如果低严重缺陷反复引发线上事故，说明影响判断或场景覆盖可能不足；如果大量高严重缺陷最终都无需紧急动作，说明定义可能过宽，或高等级没有对应处置能力。两类现象都值得调查，但不能仅凭单月数据下结论。

可按季度观察高等级缺陷的响应时间、线上逃逸率、重复打开率、影响用户时长和临时处置有效率。比较时要说明样本口径和版本范围，也要留意发布规模变化。指标是治理的传感器，不是简单的绩效排名。

3. 预防“等级通胀”和“等级压低”

等级通胀通常来自所有人都希望自己的问题优先处理，结果高等级变成普通标签；等级压低则常由延期压力、对外承诺或害怕触发升级引起。两者都会让等级失去区分能力。

应对方法不是禁止调整，而是要求每次升级或降级都记录依据：影响对象变化、绕行验证、数据确认、风险解除或发布条件改变。定期抽样复核变更记录，比单纯规定“不许改等级”更能提高可信度。

4. 把业务恢复和技术修复分别验收

技术团队可能已经部署补丁，但受影响数据还未修复；服务已经恢复，用户仍不知道如何继续；根因修复完成，监控规则却没有补上。把这些结果统称为“已解决”，会让缺陷状态过早关闭。

对高影响问题，建议至少分别确认：故障是否停止、业务数据是否恢复或补偿、用户影响是否沟通、监控是否完善、复发风险是否可接受。不同事项可以由不同角色签字确认，避免研发独自承担业务恢复的全部判断。

5. 最终行动：先用十条缺陷验证规则

如果团队现在没有成熟的严重程度体系，不必等待完整制度写完再开始。挑十条近期缺陷，按“影响面、业务后果、绕行能力、风险敏感性”共同复评，记录最难判断的三类情况，再据此修订等级定义和提单模板。

接下来运行两周：观察分流是否更快、争议是否减少、信息缺失是否下降、等级是否真的改变了响应动作。若指标没有改善，先检查流程与责任，不要急着增加等级。一套好的严重程度体系，最终应减少反复争论，让团队更早看见损害、更快控制风险，并对为什么这样判断说得清楚。

6. 最重要的取舍：一致性比表面精确更有价值

团队很容易把精力花在争论 S1 和 S2 的边界，仿佛一个数字就能解决所有排期冲突。我的判断是，早期最值得追求的不是绝对精确，而是相似影响得到相似处理、等级变化有证据、重大风险不会被平均数掩盖。

当团队能够稳定回答“谁受影响、损害是什么、有没有可靠绕行、风险是否仍在扩大、下一步谁负责”，严重程度体系就已经从 0 走到了 1。下一步不是继续增加标签，而是用真实缺陷校准判断，用结果数据验证处置，再把被证明有效的规则沉淀进团队工作流。