严重程度流程与规范：研发团队Bug / 缺陷制度设计关键指标

严重程度流程与规范如果只剩下“致命、严重、一般、建议”四个选项，缺陷制度通常会在最忙的时候失效：同一个线上问题，研发标成“普通”，业务认为“致命”，测试则因为影响范围不清不敢关闭。我的判断是，严重程度不是给缺陷贴标签，而是把用户损失、系统风险和响应资源连接起来的一套决策规则；标签若不能导出明确的处理动作，就只是多填了一个字段。

一、先讲核心结论：严重程度必须对应行动，不应只对应形容词

1. 严重程度回答“影响有多大”，优先级回答“现在先做什么”

制度设计首先要分开两个常被混用的概念。严重程度描述缺陷造成的影响，包括功能损坏范围、数据风险、安全影响和业务损失；优先级则决定团队在当前计划中何时处理。前者相对稳定，后者会随着版本窗口、客户承诺、绕行方案和资源情况变化。

例如，某个报表导出功能在少数内部用户中偶发失败，可能属于中等严重程度；但如果它是月末审计的唯一出口，距离审计截止只剩一天，处理优先级就可能很高。反过来，某个低频视觉错位虽然影响面广，若不妨碍操作且有简单替代方式，也未必需要中断当前发布。

我建议制度中至少保留“严重程度”和“处理优先级”两个独立字段。如果团队把两者合并成一个“紧急程度”，每次排期都会变成争夺标签：提单人用更严重的词争取资源，开发用更低的词保护计划，数据最终失去分析价值。

2. 每个等级必须绑定响应时限、升级条件和验证要求

一个可执行的等级定义，不是“影响很大”“比较严重”这类主观描述，而是由三个部分组成：影响边界、必做动作、升级或降级条件。缺少其中任何一项，成员都需要临场猜测，制度就会退化成个人经验。

以最高等级为例，定义不能只写“系统不可用”。还要写清：是否涉及核心交易中断、数据丢失或安全风险；谁负责确认影响面；是否需要暂停发布、启动回滚或切换方案；多长时间内必须有人响应；关闭前要提供什么验证证据。

响应时限应当按团队实际值班能力制定，而不是照抄行业模板。一个没有夜间值守的团队，不应在制度里承诺“全天候五分钟响应”；这种承诺只会制造名义上的服务水平，不能真实降低用户风险。

3. 先把边界和流程跑通，再追求复杂评分模型

不少团队一开始就设计五级严重度、四级优先级、影响面权重、客户等级系数和风险评分公式，表格看起来精密，实际填写率却很低。我更倾向于先设定四级严重程度、明确证据要求，并用一到两个版本观察分布，再判断是否需要细分。

制度是否有效，不以字段数量或流程图复杂度衡量，而看三个结果：相同问题是否得到相近判断；高风险缺陷是否在规定时间内被确认和处置；团队能否通过数据发现反复发生的系统性问题。

二、背景和真实场景：为什么同一个缺陷会被判成三个等级

1. 描述不完整，导致每个角色都在补自己的假设

提单写“支付按钮点不了”，开发可能理解为某个浏览器的样式问题，测试可能理解为主流程阻断，业务则可能担心所有用户都无法付款。缺陷描述只要缺少发生时间、影响对象、复现条件和实际损失，严重程度就会被不同角色按各自最熟悉的风险放大或缩小。

我会要求提单至少回答五个问题：谁遇到问题、在哪个环境、什么条件下发生、实际结果是什么、影响多少用户或业务流程。无法立即量化时，可以写“影响范围待确认”，但必须安排确认责任人和回报时间，不能把未知默认为低风险。

2. “功能坏了”不等于“业务损失大”，但数据与安全风险不能按频率折价

一个后台配置页面每天只有两名管理员使用，出现错误的频率很低；如果错误会把客户数据覆盖成不可恢复的值，它依然可能是最高风险。另一个首页动画每次加载都略有偏移，触达用户很多，却不妨碍使用，也不必自动列为最高严重程度。

因此，我不会用“发生频率”单独决定严重程度。频率可以帮助判断受影响范围和优先级，但数据完整性、权限越界、安全暴露、不可逆操作等风险需要单独审视。对这些风险，缺少已发生损失的证据，不等于风险不存在。

3. 团队的服务边界不同，等级定义也不能机械复制

面向内部研发工具的团队，严重等级可能以开发流程中断、关键数据丢失、权限错误为主；面向在线交易的团队，支付、下单和资金对账的可用性更重要；面向设备控制或医疗场景的团队，则要把人身安全和合规风险作为单独的升级条件。

通用框架可以提供起点，不能替代业务风险分析。制度设计前，我通常会先列出团队的关键用户旅程、关键数据对象、不可逆操作和外部承诺，再据此写判级边界。否则，等级名称看似统一，实际无法表达各业务线的损失结构。

4. 流程失灵通常发生在交接点，而不是缺少一个新字段

高等级缺陷的处置至少经过发现、初判、复核、止损、修复、验证和复盘。每个交接点如果都没有明确接手人，就容易出现“大家都看到了，但没人确认”“开发已修复，但没人验证”“临时绕行了，却没有人记录风险”的情况。

很多团队把问题归因于工具不够强，随后增加一组字段或自动化规则。但工具只能承载规则，不能替代“谁有权最终判级”“谁在超时后升级”“谁确认业务恢复”等责任设计。先定角色与时限，再配置流程，往往更省力。

三、拆解常见误区：看起来统一，实际会让判断更混乱

1. 误区一：所有团队都应该使用同一套等级名称和定义

统一词汇有助于跨团队沟通，但统一到同一套影响阈值未必合理。一个业务线的核心交易可能是另一个业务线的边缘功能；如果只要求名称一致，却不允许各团队补充关键业务边界，汇总报表会得到表面可比、实质不可比的数据。

更稳妥的做法是统一等级骨架和判定方法，同时为业务域保留少量明确的补充条款。比如所有团队都使用四级影响框架，但交易域补充“账务不平”升级条件，数据域补充“不可逆覆盖”条件，权限域补充“越权访问”条件。

2. 误区二：严重程度越高，修复就必须排在最前面

严重程度是风险描述，不是自动排期命令。某个高风险问题已经通过关闭入口、回滚版本或禁用功能完成止损，下一步修复可能仍然重要，但和另一个正在造成真实损失的问题相比，优先级排序需要结合当前状态。

优先级至少应考虑业务时间窗口、受影响对象、缓解措施、修复成本和发布风险。高严重度通常触发快速评估和管理关注；是否立即开发修复，要基于“继续不修的损失”与“仓促修复引入的新风险”比较。

3. 误区三：一个缺陷只允许一个团队修改严重等级

完全开放修改会导致标签反复变化，完全锁死又会让错误判断无法纠正。我建议允许提单人提出初判，由指定责任角色确认；等级发生变化时保留变更记录，说明修改人、时间、理由和新证据。

高等级缺陷可采用双人复核，普通缺陷则不必增加审批层。制度追求的不是让所有人都签字，而是让高风险判断有足够透明度，并让低风险判断保持轻量。

4. 误区四：用缺陷数量、关闭率直接评价个人或团队

缺陷数量受测试覆盖、用户规模、版本复杂度和报告习惯影响。单纯以“谁提得多”“谁关得快”做绩效判断，容易诱发少报、拆单、提前关闭或把问题归到其他团队等行为。

指标应该帮助团队找系统性改进点，而不是制造标签博弈。更有解释力的组合包括：严重缺陷响应达成率、重新打开率、逃逸缺陷率、重复缺陷率、根因措施完成率，并按业务域、发布批次和问题类型分层观察。

5. 误区五：所有缺陷都必须填完全部字段才能进入处理

高风险问题发生时，强制填写一长串字段会延迟止损。提单信息应根据风险等级分阶段补齐：先收集最小必要信息并开始响应，再在规定时间内补足影响范围、日志、复现步骤和根因线索。

这不意味着可以随意提交。入口可以要求标题、环境、现象、发生时间和联系人；影响范围暂时未知时标记“待确认”，并生成一项明确的确认任务。信息不完整可以接受，责任和下一步不明确不能接受。

四、专业判断逻辑：把严重程度变成可复核的决策

1. 先定义影响维度，再定义等级阈值

我通常从六个维度建立判级卡：核心功能可用性、受影响用户或业务范围、数据完整性、安全与权限、业务连续性、外部承诺或合规要求。不同业务不一定每个维度权重相同，但至少要显式讨论，避免只凭“看起来很严重”做结论。

等级定义应描述可观察结果，而不是主观感受。比如“关键流程无法完成且没有可接受替代路径”，比“影响很大”更容易被复核；“存在未经授权访问敏感数据的可能”比“安全问题严重”更能指导升级。

这张表是制度起点，不是所有行业的标准答案。团队应把“核心业务”“大范围”“显著损失”“可接受替代方式”进一步写成自己的例子。否则，词看起来比原来规范，实际争论仍会发生在定义边界。

2. 对高风险设置覆盖规则，不要让平均分掩盖极端风险

简单加权评分适合辅助排序，不适合替代风险红线。假设某缺陷影响用户很少、发生概率不高，但可能造成敏感数据泄露，普通加权模型可能因为其他维度得分低而把它算成中等风险。这正是平均分不适用于所有缺陷的地方。

我建议设置“覆盖规则”：一旦命中数据不可逆丢失、权限越界、资金或关键账目异常、人身安全或监管报告义务等条件，至少触发特定等级的复核。覆盖规则不一定直接把缺陷判为最高级，但必须阻止它被普通排队流程静默降级。

3. 将“未知”作为状态管理，而不是自动归为低等级

发生范围暂时不清楚时，制度应允许“初判待确认”，并配上调查时限、责任人和升级条件。比如一小时内无法判断是否涉及敏感数据，就由安全或数据责任角色介入；如果监控显示影响扩大，自动进入更高等级复核。

“未知”不是一个可以长期停留的严重程度，而是一个需要被消除的信息状态。高风险未知应先采取保守的临时控制，再补充证据；低风险未知则可以按既定时间收集信息，不必立即动用最高级别响应资源。

4. 把严重程度和优先级组合成两步判断

实际执行时，我会先回答“这件事造成什么风险”，再回答“当前先做什么”。优先级判断可以参考业务时间窗口、受影响对象、是否存在绕行、修复风险和投入规模，但不要把这些因素偷偷塞回严重程度字段。

5. 让判级证据可追溯，而不是只保留最终结果

制度应保留初判等级、复核等级、变更理由和关键证据。记录不需要写成长篇报告，但要能够回答：依据哪些事实定级，后来有什么新事实导致调整，谁确认了调整，采取了什么止损动作。

这类记录的价值不止在审计。季度复盘时，如果某个团队频繁把S3升到S1，可能是初判标准不清；如果高等级大量降级，可能是提单人的风险理解偏差；如果等级正确但响应仍迟缓，问题就不在判级，而在值班和资源配置。

6. 时限按风险与服务能力协商，不照搬单一数字

可把响应时限拆成“确认时限、缓解决策时限、修复计划更新时间、验证时限”。确认问题和完成修复并不是一回事。对复杂缺陷，团队可能无法承诺短时间内彻底修好，但应该能够承诺何时确认影响、何时说明临时方案、何时更新计划。

制定时限前要核对工作时间、值守安排、跨团队依赖和版本发布机制。对没有全天候支持的团队，可以规定非工作时间由值班角色先执行预案，次日由业务责任人复核；不要通过制度文字制造不存在的即时响应能力。

五、案例与数据观察：用一个版本周期检验制度是否真的有效

1. 情景案例：月末导出异常，争论焦点不是按钮坏没坏

下面的案例是用于说明判级方法的情景模拟，不代表某家企业的真实事故记录。某企业的月末结算报表偶发导出失败，研发初步认为只影响少数浏览器，给出S3；财务团队认为报表是对账凭证，要求当天修复；测试又发现失败集中在数据量较大的账户。

如果只看“受影响用户少”，S3似乎合理；但继续核查后发现，当天是结算截止日，失败账户无法通过其他入口取得完整明细，且手工补录需要逐项核对。此时应至少把优先级提高，并确认是否存在数据缺失。若只是导出组件失败而源数据完整、后台可生成替代文件，严重程度可能仍为S2；若源数据本身被错误覆盖，风险就可能触发S1复核。

这个案例说明，业务压力可以改变处理优先级，却不一定改变缺陷严重程度；真正推动严重程度变化的是影响事实，比如数据是否完整、是否有替代路径、影响范围是否扩大。把这几项事实补齐，团队才有机会形成稳定判断。

2. 不要只看等级分布，还要看等级流转和处置结果

假设一个团队连续两个版本的缺陷等级分布变化如下。数字是情景模拟数据，仅用于演示如何读数。若S1数量减少，但S1响应达成率也明显下降，不能直接得出风险变小的结论；可能只是提单人不再愿意选择最高等级，或者复核过程把缺陷压低了。

3. 用“等级校准会”发现定义漏洞，而不是审判提单人

我建议在制度试运行的前四到六周，每周抽取少量样本做等级校准。不要只挑最高等级，也要抽取被降级、被重新打开、超过响应时限和造成线上影响的缺陷。每个样本回答三个问题：当时掌握了什么证据，按规则应该做什么，哪条定义让人产生了分歧。

会议的产出不是“某同事判断错了”，而是可复用的边界案例。例如“关键业务时间窗口内不可导出的报表属于S2；若源数据完整且存在人工替代方案，优先级视截止时间调整”；这样的规则能减少下一次相同争论。

4. 用分层数据避免被平均数误导

全公司平均响应时长可能看起来不错，但安全问题、线上交易问题和内部体验问题的风险完全不同。至少要按严重等级、产品或业务域、线上与非线上、是否产生用户损失分层；样本量不足时标出数量，不要只报百分比。

例如，某季度只有两件S1缺陷，其中一件超时，达成率就是50%。这个百分比看起来很差，但样本很小；与其据此追责，不如检查那一次为何超时，以及值班覆盖是否存在结构性缺口。对管理层而言，分母和案例背景与百分比同样重要。

六、制度流程设计：从发现到关闭，明确每个交接点

1. 发现与提报：先收集足以采取下一步行动的信息

缺陷入口应支持快速提交，但不能让“问题描述”只剩一句模糊判断。提单人至少提供标题、环境和版本、实际结果、预期结果、发生时间、复现步骤、影响对象、相关日志或截图；无法提供的字段说明原因，并标记待确认事项。

若问题疑似涉及安全、数据完整性、资金或人身风险，入口应允许直接触发专门升级，不必先经过普通缺陷队列。是否需要独立通道取决于团队架构，但关键是高风险信号不能被普通排队规则吞掉。

2. 初步分级：由提单人给建议，责任角色确认

提单人可以提交初判等级，帮助后续快速分流，但不应把最终判级责任全部压给测试或业务人员。技术负责人确认技术影响，业务责任人补充业务损失，安全或数据角色在命中风险条件时参与复核。

团队规模较小时，一个人可能承担多个角色；制度仍应把职责写清楚。角色可合并，责任边界不应消失。高等级缺陷还要指定唯一的处置负责人，避免“相关人很多、决策人没有”。

3. 影响确认与止损：修复前先判断是否需要减少损失

对正在产生损失的问题，第一目标通常是控制影响，而不是立刻写代码。可考虑回滚、关闭入口、限制流量、撤销权限、暂停批处理、切换备用路径或通知用户。采取何种动作需要根据系统风险判断，不能把回滚当成无条件正确的标准答案。

止损动作要留下时间、负责人、影响范围和副作用。比如关闭某功能缓解了错误写入，却让用户无法继续关键流程；记录这些代价，才能判断临时措施能维持多久、是否需要替代方案。

4. 修复与验证：技术通过不等于业务恢复

修复验证至少应区分代码或配置是否按预期变更、原始复现路径是否恢复、相关回归范围是否受影响、业务用户是否恢复关键操作。不同缺陷需要不同验证深度；高风险问题不应仅凭开发者口头确认就关闭。

对线上问题，修复后还可以设置观察窗口，检查错误率、失败请求、告警和用户反馈是否回落。观察窗口长短应与问题影响周期相匹配：即时交易系统可能观察较短但密集，月结或批处理问题则需要覆盖实际业务周期。

5. 关闭与复盘：关闭缺陷不等于关闭风险

缺陷可以在修复完成后关闭，但如果根因措施、数据修复、用户通知或长期监控仍未完成，就应建立关联任务，而不是把所有工作塞进同一张缺陷单后标记完成。关闭条件要区分“问题已恢复”和“防止再次发生的工作已完成”。

不是每件缺陷都需要长篇复盘。可以按严重度和系统性设门槛：S1必须复盘；同类问题在短期内重复出现时复盘；涉及跨团队交接、自动化测试遗漏或重大数据修复时复盘。低等级偶发问题记录根因与验证即可。

1. 发现问题后，记录现象、环境、时间、影响对象和证据。
2. 提单人给出初判，责任角色在约定窗口内确认严重程度与优先级。
3. 高风险问题先评估止损、回滚、隔离或业务绕行，再制定修复计划。
4. 修复后由适当角色完成技术验证、关键路径验证和必要的线上观察。
5. 按关闭条件归档证据，并为遗留风险、根因措施和用户沟通建立后续责任项。
6. 按周期复查样本，修订有歧义的定义、时限和升级规则。

七、关键指标设计：测流程是否有效，不拿数字制造表演

1. 响应指标：把确认、止损和修复拆开统计

响应时长至少拆为发现到确认、确认到止损决策、确认到修复完成。只统计“从创建到关闭”的总时长，会把等待排期、等待复现、等待外部依赖和实际开发时间混成一个数字，管理者很难知道该改哪里。

报告时建议展示中位数、较高分位数和超时数量，并按严重等级分层。平均值适合看总体消耗，却容易被极端长尾影响；中位数体现典型体验，高分位数能暴露最差一批案例。任何一个数字都不应脱离样本数解释。

2. 质量指标：关注逃逸、重开、复发和风险闭环

逃逸缺陷率用于观察问题是否流入更晚阶段或生产环境。口径必须明确分母，例如按生产缺陷数除以测试阶段发现总量，或按发布后缺陷数除以某一发布周期全部确认缺陷数；不同口径不能直接横向比较。

重新打开率可提醒团队检查验证质量，但高重开率不必然等于开发质量差，也可能是需求预期不一致、提单描述有误或用户验收标准变化。重复缺陷率更适合帮助识别根因措施无效、回归覆盖不足或同类代码路径缺少治理。

3. 判级质量指标：看一致性和调整理由，不追求等级越低越好

等级变更率可以反映初判与复核之间的差距，但不是越低越好。若团队把等级修改权限收得过紧，数字会变得漂亮，实际高风险却可能被压低。建议把等级变更率与变更方向、变更原因、复核时长一起看。

还可以定期抽取匿名案例，让不同角色依据同一份材料独立判级，比较结果是否接近。若同一案例在开发、测试和业务角色之间出现两级以上差异，通常说明边界描述不够可操作，或者输入信息不足。

4. 流程负担指标：制度本身也要接受检验

一套制度可能提高控制能力，也可能制造过多等待。可以记录高等级复核耗时、平均补充字段次数、重复通知数量、每件缺陷的行政处理时间、超时但无责任人变更的次数。若字段越填越多、响应反而变慢，就应删掉低价值环节。

这类指标能帮助团队在风险控制和交付速度之间做取舍。对高风险缺陷，多一次复核可能值得；对轻微文案问题，重复审批通常只是摩擦。流程复杂度应与风险相称，而不是所有缺陷一律套用最高控制强度。

八、不同团队与不同风险下的行动建议和取舍

1. 小团队：先用轻流程换一致性，别提前建设审批委员会

小团队通常没有专职值班、质量运营或安全复核角色。此时可以由提单人初判、当周技术负责人确认；命中数据、安全或核心业务风险时，再拉业务责任人共同复核。响应规则可以先采用工作时间窗口，并明确非工作时间的例外处理方式。

取舍是把少量判断集中到关键角色，避免所有人都参与审批。风险在于负责人缺席时容易卡住，所以要指定替补人，并规定超时升级对象。不要先设计复杂评分表，先观察团队最常发生的三类分歧，再补充判级例子。

2. 多业务线或中大型组织：统一框架，保留业务域覆盖规则

中大型组织需要跨团队汇总，但不应强迫所有业务共用完全相同的影响案例。适合统一严重度命名、最小字段、变更记录和统计口径，同时允许各业务域维护一页补充规则，明确关键链路、合规义务和不可逆风险。

在这类组织中，工具配置的价值是让规则可执行、记录可追踪，而不是替团队做风险判断。以 PingCode 这类项目管理平台为例，可以把缺陷字段、状态流转、责任人和通知规则映射到制度流程；具体字段、自动化能力及权限配置应以实际版本和组织设置核验。不要因为平台支持某个字段，就把它写进制度；先确认这个字段会改变谁的行动。

取舍在于跨团队一致性与业务灵活性之间。若完全统一，特殊风险容易被稀释；若各团队各自定义，管理层又无法解释整体数据。较好的方式是统一“判定框架与数据口径”，把例外限定为少数经过业务负责人确认的补充条款。

3. 高可靠或强监管场景：宁可多一道风险确认，也不要用平均评分降级

涉及安全、资金、个人敏感信息、设备控制或监管义务的系统，应建立独立升级条件和可审计记录。发现不确定风险时，允许先采取临时限制措施，同时由对应专业角色确认；不得因为影响用户数量暂时较少，就自动认定为低严重度。

取舍是更高的响应成本和更严格的证据要求。过度升级会消耗专家资源，过度谨慎也可能造成业务中断，因此应设置清晰的解除条件：何时可以确认风险不存在，谁可以撤销临时限制，撤销后要保留什么依据。

4. 发布密集或线上变化频繁的团队：先保证止损和回滚路径

频繁发布的团队应把缺陷等级与发布决策连接起来，但不要让所有S1、S2都自动阻断发布。要问清当前版本是否可能扩大影响、修复是否经过充分验证、是否有可逆回滚、发布后监控能否及时发现异常。

取舍是发布速度与变更风险之间的平衡。回滚容易且影响可控时，快速恢复可能比现场热修更安全；回滚会丢失关键数据或影响其他依赖时，应先制定数据补偿和分阶段发布方案。制度需要规定决策角色和证据，而不是只写“严重缺陷禁止发布”。

5. 测试成熟度较低的团队：先补输入质量和回归能力

如果缺陷经常无法复现、环境信息缺失、关闭后反复出现，问题可能不在严重程度等级，而在测试环境、日志和验证机制不足。团队应优先改善复现模板、版本标记、自动化回归和线上监控，让判级建立在更可靠的信息之上。

取舍是把短期开发时间投入到基础设施和质量能力。短期看似少修了几个低等级问题，长期可能减少重复调查和线上逃逸。可以先从高频、高损失、容易自动化的关键路径开始，不需要一次覆盖所有边界场景。

6. 正在选管理工具：把制度流程带去试跑，不要只看功能清单

选工具时，我会拿一组真实但脱敏的缺陷样本做流程演练：能否记录初判和复核差异；高等级是否能通知正确角色；超时能否暴露；修复与验证是否能区分；关闭后能否关联复盘或防复发任务；报表是否支持按等级、业务域和发布批次筛选。

还要测试权限边界、历史记录、字段必填策略和移动端响应方式。工具若让高风险提报多出十几步，成员可能改用聊天消息，正式记录就会缺失。若工具没有自动化能力，也可以先用清晰的责任约定和轻量提醒试运行，不能把制度成败全归因于软件。

九、落地路线与最终判断：先验证规则，再扩大管理半径

1. 用四周完成最小可行制度，而不是一次写出百科全书

第一周盘点关键业务链路、数据风险和常见争议案例，形成四级严重程度草案。第二周邀请研发、测试、业务及必要的安全或数据角色，用过去的缺陷记录独立判级，找出定义模糊的位置。

第三周在一个产品或团队中试运行，记录初判、复核、响应、等级变化和关闭证据。第四周复盘样本，删掉没人使用的字段，补充导致分歧的案例，并确定下一轮需要验证的指标。试点不必等到工具改造完成，先用轻量流程跑通更容易发现真实问题。

2. 先设三条红线，再逐步细化普通缺陷

如果团队资源有限，我建议先明确三类不能被普通队列稀释的风险：数据丢失或不可逆损坏；权限、安全或隐私暴露；核心业务无法继续且没有可接受替代路径。三条红线不是全部严重度制度，但能优先覆盖最难补救的损失。

普通功能异常可以在样本积累后再拆分。团队不需要为了表面完整，提前讨论大量极少发生的边界。制度应该从真实争议和真实损失中长出来，而不是从等级名称中长出来。

3. 用案例复盘更新规则，避免制度成为静态文档

每次复盘都问：当时的等级定义是否能让不同角色做出相近判断；哪项信息最晚才被确认；哪次交接造成了等待；修复后是否验证了真实用户路径；是否有某个长期风险被“关闭”掩盖。答案应反馈到模板、升级规则、测试覆盖或责任分工中。

一年不变的制度未必稳定，也可能早已不适合业务。产品边界、用户规模、合规要求、发布方式和团队值班能力都会变化。至少在重大架构调整、业务扩张或严重事故后，重新核对等级条件和响应承诺。

4. 最终判断：好制度不是让每个缺陷都被准确命名，而是让风险及时改变行动

严重程度流程的价值，不在于所有人都能背出S1到S4，而在于遇到不完整信息时知道先确认什么；发现高风险时知道谁来接手；需要降级时知道依据是什么；修复完成后知道还要验证什么。

下一步可以从最近三个月的二十件缺陷开始：挑出等级争议最大、响应超时、重新打开或造成线上影响的样本，按“影响事实，等级依据，处置动作，验证证据”重新走一遍。如果同一条规则仍然让不同角色做出截然不同的判断，就改写规则；如果规则已清楚但行动仍延迟，就调整责任、时限或工具配置。制度应服务于风险决策，而不是让团队为填表而填表。