乐于分享
好东西不私藏

软件可靠性失效严重程度分类与深度解析

软件可靠性失效严重程度分类与深度解析

一、为什么要分级(What & Why)

失效严重程度(Severity)描述的是:一旦发生失效,其后果有多严重(与发生概率无关)。
用途:

  • 统一"多严重"的语言,指导测试力度、发布闸口、应急响应级别;
  • 驱动工程资源分配(高 S 缺陷优先修复),并与可靠性指标、SLA/SLO 对齐;
  • 为风险评估矩阵(Severity × Likelihood)和 FMEA/RPN 提供输入。

切记:Severity ≠ Priority。Priority(处理优先级)还会考虑发生概率、客户关系、可替代方案等要素。

二、分级维度(看什么)

核心两维:

  • 成本影响(Cost Impact):直/间接损失(营收、赔付、罚款、人工/机会成本、品牌舆情)。
  • 系统能力影响(Capability Impact):系统是否还能提供核心能力、是否退化、受影响范围与持续时间。

常见补充维度(建议纳入判定卡):

  • 安全与合规:人身/财产安全、隐私泄露、监管处罚风险;
  • 数据层面:数据损坏/丢失/不可逆一致性破坏;
  • 可用性与性能:停机、明显降级、SLO 违约;
  • 影响范围:所有用户/区域/单租户/小范围;
  • 持续时间:瞬时/分钟/小时/天;
  • 可替代性:是否有应急绕行或降级方案。

三、通用 5 级严重度分级表

可直接用于需求、缺陷、事件分级;阈值请结合你的业务标定。

级别名称系统能力影响成本/合规数据与安全典型阈值(示例,可调整)
S1
灾难级 Catastrophic
核心能力全面不可用;影响全体/大多数用户;无法自愈
高额收入损失;重大违约/合规风险;品牌重大负面
不可逆的数据丢失/泄露;人身/财产安全风险
受影响用户 ≥ 30% 或关键交易成功率 < 50% 持续 ≥ 30 min
S2
严重级 Critical
核心路径严重退化或关键区域不可用;影响大范围
显著收入损失;潜在合规风险;客户大量投诉
可能数据不一致,但可修复;无明确安全事件
受影响用户 10-30% 或关键交易成功率 < 90% 持续 ≥ 30 min
S3
重要级 Major
非核心/部分核心功能不可用或明显降级;中等范围
间接损失;支持成本上升
低概率数据不一致,可回滚/校正
受影响用户 1-10% 或性能退化(P95 延时↑>50%)持续 ≥ 1 h
S4
次要级 Minor
局部功能异常,有替代路径;小范围
轻微影响;少量投诉
无数据破坏;无安全风险
受影响用户 <1%,体验缺陷/边角问题
S5
提示级 Trivial
仅 UI/文案/日志噪声,不影响功能
可忽略
开发/测试阶段发现的小瑕疵

调参建议:把"受影响用户占比、关键交易成功率、延时/错误率阈值、持续时间、成本区间"量化为你们组织的基线(如 MRR、关键转化漏斗、SLO、法务红线),定期复盘校准。

四、与成本影响的量化对齐(怎么"数")

给出一套易操作的成本画像方法:

  • 直接损失:单位时间 GMV/收入 × 停机/降级时长。
  • 间接损失:流失率上升 × LTV,补偿金/券/客服工时 × 单价。
  • 合规成本:潜在罚款、事后审计/改造费用。
  • 品牌/舆情:以"公关预估 × 概率"近似计入。

可定义成本档位(如 ≥Y-X 万/小时 → S2),与上表联动。

五、与系统能力的对齐

为避免"口水战",先做能力清单分级

  • L0(生命线能力):认证/支付/解锁/报警/视频推流等;
  • L1(核心能力):告警通知、订单/工单闭环;
  • L2(支持能力):报表、历史检索、偏好设置;
  • L3(装饰能力):皮肤、引导、非关键推荐。

规则:影响 L0 → 至少 S2,广泛影响 L0 → S1;影响 L3 通常 ≤ S4。

六、风险矩阵与优先级(Severity×Likelihood)

  • Severity(后果):用上面的 S1-S5。
  • Likelihood(发生概率):用事件基线/仿真/历史频率标定(如 年/季度 发生≥N次)。
  • Risk Priority:可采用 RPN 或 5×5 风险矩阵将风险分为 High/Medium/Low,用于测试强度、发布闸口与缓解计划。

FMEA 简式:RPN = S × O × D(严重度×发生度×探测度)。高 RPN 必须有预防+检测+缓解三件套。

七、测试与发布策略联动(按严重度差异化投入)

S1/S2 缺陷

  • 预防:关键路径形式化/模型检查、高覆盖率单测+契约测试、金丝雀+自动回滚、混沌/故障注入演练;
  • 检测:实时 SLO 监控(错误率、延时、可用性)、端到端合成探针;
  • 闸口:必须修复或提供等价缓解(Feature Flag、KillSwitch);高风险改动需灰度/双写/影子流量;
  • 恢复:RTO/RPO 明确,演练切主、只读/降级模式、数据回滚脚本。

S3

  • 预防:覆盖主流场景与边界值、回归自动化;
  • 闸口:版本可入,但需在下个迭代修复并评审。

S4/S5

  • 批量处理,合入常规迭代;注意避免视觉/文案瑕疵堆积。

八、度量与看板

  • 按严重度的缺陷密度:Defect Density_s = Count_s / KLOC 或 Story Points
  • 加权缺陷指数(WDI):WDI = Σ(w_s × Count_s)(示例权重:S1=100, S2=30, S3=10, S4=3, S5=1)
  • 缺陷外泄率(DRE):DRE = 缺陷在发布前捕获数 / 总缺陷数(按严重度分桶)
  • 可靠性增长图:随时间跟踪 S1/S2 缺陷的累计关闭与回归率。

九、面向物联网/智能安防实例

以"智能锁/安防摄像头"为例:

  • S1:远程解锁失效导致大范围用户无法进入;报警触发失败;直播/录像与告警全断;云端密钥泄露。
  • S2:某地区固件升级后大量设备离线;录像延迟>30s 且丢片;告警推送大面积延迟。
  • S3:历史回放间歇性卡顿;个别型号低电量阈值计算错误导致误报。
  • S4:设备列表排序错误、图标错位;日志噪声。
  • S5:中英混排文案问题。

量化阈值示例

  • 设备离线率 ≥ 20% 且 ≥ 30 分钟 → S1
  • 告警延迟 P95 ≥ 15s 且影响 ≥ 10% 设备 → S2
  • 回放卡顿率 ≥ 5% 用户且 P95 延时↑>50% → S3

十、落地流程

  • 定义卡:把上面的分级表+阈值固化成 1 页速查卡;
  • 标注与复核:提缺陷/事件时必须填 Severity,发布经理或 SRE 复核;
  • 发布闸口:带 S1/S2 的版本一律拦截或必须有等价缓解;
  • 复盘机制:S1/S2 事件 48h 内完成 RCA(根因、检测盲点、缓解、长期防御);
  • 季度校准:用真实事件/损失校准阈值与能力清单;
  • 训练:让一线/研发/测试对同一案例分级打分,做一致性训练(Inter-Rater Reliability)。