简介严重度发生度探测度评价准则的PDF文档聚焦FMEA中的核心风险评价参数面向质量、研发及制造工程人员。内容围绕严重度、发生度、探测度评价准则展开结合DFMEA与PFMEA表格给出分级标准与风险优先数RPN计算方法帮助读者判断失效模式的影响程度、发生概率及探测能力便于在设计和制造阶段优先改进高风险项。压缩包仅含1个PDF文件大小为475KB适合作为FMEA分析和质量风险评估的速查手册。文档将各评价尺度按10至1明确量化例如无警告的安全影响评为10无明显后果评为1频度依据失效概率划分探测度按设计控制强弱排序。此外还包含“为何新版不再关注RPN”的说明与DFMEA/PFMEA填写模板可帮助理解从传统RPN到基于行动优先级的变化。目前已有76人浏览学习可直接参考其表格填写FMEA辅助风险分级与改进决策。1. 严重度发生度探测度评价准则把“风险高不高”拆成三个能吵架的问题一份变更单到了评审会最常见的争吵是“这功能到底能不能上”。赞成的人说概率低反对的人说后果严重两方都在谈风险但用的标尺不一样。严重度、发生度和探测度是FMEA这套质量方法里三个独立维度严重度描述失效的后果有多重发生度描述失效出现的频率有多高探测度描述失效在被用户看到之前能否被拦住。三个维度的评分一旦统一风险就不再是一句“看起来有风险”而是一张可排序、可复盘、可跟踪的表格。下面把三把尺子分别讲清楚给出IT场景可以引用的等级表也说明怎么把评价准则编成团队自己的一份文档放在评审入口处当标准用。2. 严重度评价准则用“最坏结果”而不是“会不会发生”来打分2.1 只判断后果大小避免把概率混进来严重度的主语是失效模式不是失效概率。一个失效模式一旦发生会对用户、数据、系统可用性造成什么影响这个影响用1到10打分1表示没有影响10表示不可接受。评分时最常犯的错是把“这个情况很少发生”当成降低严重度的理由。很少发生属于发生度的范围严重度只看那一次真发生时世界有多糟。把边界划清后严重度评价准则其实不需要谈概率。失效模式可能是磁盘满、接口超时、缓存击穿、发布错误但评严重度的人只回答一个问题当它真的出现时用户业务是否中断、数据是否丢失、资金是否损失、合规是否被触碰。这也是为什么严重度表必须由产品、研发、运维一起定而不是SRE单方面给分。2.2 一张适合IT系统的严重度等级参考表下面这张表把10个等级映射到IT系统常见结果。等级描述尽量用可观察结果避免用“非常严重”这类递进形容词。等级等级名称IT场景锚点10灾难核心数据永久丢失或触发资安通报9重大核心服务不可用超过RTO目标自动恢复失效8很高核心功能大面积失败但可在数分钟内回滚恢复7高主要功能严重降级大量请求报错需人工介入6中等次要功能完全不可用主流程未中断5中低次要功能降级响应时间翻倍且持续存在4低少量用户反馈异常影响面可控3轻微用户可感知但能自行绕过的界面问题2很轻微内部可见日志报错用户无感知1无无用户影响只留下技术债记录表里的锚点不是标准答案。每家公司应该把自己最近一年的三到五个真实故障填进去让团队对“9级是什么样子”有共同记忆。与其争论“这个算7还是8”不如先问“历史上哪个故障跟它最接近”。评价准则的价值就是把这种对照物固定下来避免每次评审都重新发明形容词。2.3 定标时必须明确的三个边界第一数据可恢复性要单独说清楚。同样是数据库故障最坏情况是没有备份、备份不可用、还是能恢复到五分钟前对应的严重度差别很大。准则里建议写一句“数据不可恢复时最低按8分起评”这样后续评价才有约束力。第二恢复时间目标要和评分绑定。IT系统大量失效可以通过自动恢复或回滚结束因此严重度不是“永久损坏”的后果而是在规定时间内无法恢复的后果。用RTO作为9分和7分的分界比用“几分钟”这种描述更可执行。第三涉及法律法规或外部合同要求的失效直接拉高评分。银行卡信息泄露、医疗数据未授权访问这类场景不按人数或时长评估只要触碰红线就进入9到10区间。边界写清楚后严重度评价准则就不会在跨部门讨论中被反复推翻。3. 发生度评价准则让发生度等级从小道消息变成监控数据3.1 发生度的评分单位是频率发生度回答“这个失效模式在生命周期里出现的概率或对应的平均发生频率”。由于现实中的失效频率可能从一天多次到十年一次跨度极大发生度等级不能按线性递进通常用对数刻度每升一级频率大约提高十倍。这样做的效果是评测时不必精确到百分位只要判断它落在哪个数量级区间。对IT系统来说发生度最直接的数据来源是监控告警、工单系统、发布失败统计和容量事件。一个接口每天报错一万次发生度显然不会低于8。一个只在每年证书轮换时出现的配置错误则通常在3到4之间。评价准则要给出频率对照表目的是让评分人在同一个时间尺度上说话。3.2 适合IT系统的发生度等级参考表下面这张表用“平均每天发生次数”作为参照具体边界可以按团队的历史数据调整。等级平均每天发生次数IT场景参考10100次以上每次定时任务都失败或常态性绕过逻辑910到100次每天都会出现的边缘请求错误81到10次每天若干次能够稳定复现70.1到1次每几天一次与某个变更节奏强相关60.01到0.1次每月一次的量级往往由容量因素触发50.001到0.01次每季度一次依赖外部条件组合40.0001到0.001次一年一次通常与证书、依赖方有关30.00001到0.0001次几年一次发生在特定架构场景2更低几乎未在现网出现过1无记录在所有已知系统上都没有触发过这张表的好处是口径统一所有人都知道8分意味着“每天都会出”。实际填写时可以按照系统和模块分别建表因为核心链路和边缘模块的同类失效频率基线往往也不同。3.3 用告警数据和工单计算发生度等级让“大概发生”变成“按数据评级”的最小做法是把过去90天的告警去重后统计事件数再除以天数。下面的Python函数演示这个换算过程它把平均每天事件量映射到上一节的10级刻度。def occurrence_from_daily(daily_rate: float) - int: 根据平均每天发生次数返回发生度等级。 边界用不同数量级切分等级越高发生越频繁。 if daily_rate 100: return 10 if daily_rate 10: return 9 if daily_rate 1: return 8 if daily_rate 0.1: return 7 if daily_rate 0.01: return 6 if daily_rate 0.001: return 5 if daily_rate 0.0001: return 4 if daily_rate 0.00001: return 3 if daily_rate 0.000001: return 2 return 1这个函数的参数只有一个daily_rate表示平均每天发生多少次。你可以从监控平台导出事件去重后来计算也可以用Python直接查Prometheus或工单API再传入。评级的核心在于不要在评审现场临时估一个数字而是拿着这个函数的结果当作讨论起点。提示这段换算适合评级前快速对齐口径不是对真实故障概率的统计推断。发生度评价准则需要在文档里写明数据来源和时间窗口避免下次有人换一个监控范围得到完全不同的结果。3.4 没有历史数据时怎么估发生度新系统、新模块基本没有历史数据常见的做法是找同构系统的缺陷率做参照。比如上线一个与旧网关同构的新网关先沿用旧网关最近三个月的事故频次再乘以架构差异的修正系数。另一个办法是找团队里最资深的三个人分别打分分数出来后公开讨论差异点而不是直接取平均。无论用哪种方式发生度评价准则里都应写一条凡是用估计值打的分必须备注依据来源比如“参考相似模块的历史告警”。这一条看起来繁琐但对后期复盘极有价值。三个月后真实数据出来能否看出当初低估还是高估全靠这些备注。4. 探测度评价准则探测度要按“拦截手段”来打分4.1 探测度不是质量感觉是控制措施的有效性探测度描述的是在失效模式对用户造成影响之前现有检测手段能拦住它的概率。评分同样是1到101表示几乎必定能被发现10表示无法发现。这里最容易混淆的是把“团队里有测试”当成探测度低的理由测试存在但覆盖不到这个失效模式拦截概率依然是零。探测度与严重度、发生度的最大区别在于它的主体不是失效模式本身而是围绕这个失效模式的控制措施。同一个失效模式在没有监控、有日志告警、有自动回滚三种状态下探测度分别可能是10、5、2。因此探测度评价准则要写成“按手段打分”而不是“按感觉打分”。4.2 不同控制手段对应的探测度等级参考表下面是一张IT常用的探测度参考表。手段描述越具体跨团队打分越容易一致。等级探测能力对应的IT控制手段10无法探测无监控、无测试、无评审只能等用户投诉9极弱有人工巡检但巡检周期远大于故障时长8弱发布前人工点测核心路径漏检率高7一般完整测试用例人工执行覆盖失效主要触发条件6工具辅助有静态检查或配置校验但无自动阻断5部分自动自动化测试覆盖部分分支覆盖率低于50%4主要自动主流程自动化回归覆盖异常分支未覆盖3自动且可定位金丝雀发布告警能在一分钟内定位到变更2双自动防线自动化测试监控自动回滚人工介入少1几乎必中历史上该模式从未逃逸有多重校验与演练4.3 探测度最容易高估的三种情况第一种高估是“有告警就等于能拦住”。监控的欺骗性在于告警触发路径可能和失效触发路径不一致磁盘写入失败报了告警但业务在更早的缓存层已经返回错误用户早于告警发现。评价探测度时要看告警到人工响应之间的时间差是否短于故障影响了用户的时间。第二种高估是“测试全绿所以探测度高”。一个失效模式如果测试用例根本没覆盖全绿的结果不提供任何保护。评估时应该反向检查如果现在把这个失效故意注入系统哪条测试或监控会发现它。能回答出“哪一条”才能给3分以下。第三种高估是把评审发现当成常规探测。代码评审偶尔拦住过问题但它不是持续可复现的控制手段。同一段代码三个评审人和两个评审人的效果差异很大。准则里一般要求把人工评审探测度定在6到8之间除非有历史逃逸率数据证明它能回回拦住。4.4 探测度评级要写的动作建议探测度评级不应只留分数还应该留下“升级举措”。这是探测度与其他维度不同的地方严重度和发生度的改进往往涉及架构调整周期长探测度改进却可以在一到两个迭代内完成例如补充一条监控、增加一个断言、接入一把自动化回归。在评价准则里建议在每个失效模式旁边留一列“探测手段短板”。探测度数值为7及以上的强制写一行要补的检测动作。这样探测度不止是数字而是能被跟踪的改进任务。很多团队的低风险项最后没有整改往往是因为只记录了分数没有记录短板。5. 严重度发生度探测度联合使用RPN排序与处理优先级5.1 RPN不是概率只是排序数值把严重度、发生度、探测度的分数相乘得到风险优先数RPN。RPN通常在1到1000之间它不表示真实的概率也不表示损失金额它只解决一个问题当系统里有多个失效模式时先处理哪一个。RPN的数学形式决定了它天然偏袒“最大值”的影响有时候某个维度特别高会把乘积推得很大这未必是坏事但要看清楚排序背后的主导因素。RPN单独不好用的地方在于三个维度的分数含义不同10×10×1和1×10×10都是100治理动作差异却很大。前者是高频高危但探测强后者是低频低危但探测弱。因此现在更常见的做法是先按RPN排序再在排序结果上叠加行动优先级规则避免纯数字掩盖结构差异。5.2 用Python对一组FMEA项目排序并建议优先级下面用一个可执行的小脚本示例把一个失效模式列表按S、O、D计算RPN并输出一段建议。脚本里的action_priority是实现规则的地方团队按自己的阈值调整。# 失效模式名称, 严重度S, 发生度O, 探测度D items [ (订单支付响应超时, 9, 7, 6), (缓存热点打穿数据库, 7, 8, 4), (证书过期未刷新, 4, 2, 9), ] def action_priority(s: int, o: int, d: int) - str: # 高严重度不依赖其他维度先处理 if s 9: return 立即行动 # 高频且高后果排在前面 if s 7 and o 6: return 近期行动 # 探测度很高且后果有限跟踪即可 if s 5 and o 4 and d 7: return 持续跟踪 return 常规改进 for name, s, o, d in items: rpn s * o * d print(f{name}: RPN{rpn} 优先级{action_priority(s, o, d)})参数s、o、d对应三个维度的1到10分。action_priority函数把高严重度列为第一优先级因为严重度是用户和业务代价的直接来源s大于等于7且o大于等于6的组合代表已经出现过的、影响不小的故障需要近期排期s低、o低、d高的组合基本是“很难发生且发生前会被发现”跟踪提醒即可。实际使用时应把“立即行动”的RPN阈值或优先级阈值固化在准则文档里而不是临时在会议里拍板。5.3 高S低O、高O低D、低S高D三类组合的处置这里区分三类典型组合。高严重度低发生度的失效模式例如核销计算逻辑写反虽然触发要满足多个条件但一旦触发后果不可承受。这类组合RPN不一定最高却必须通过设计与评审手段降低S或者增加补偿逻辑不能只靠监控。高发生度低探测度的失效模式例如某个定时任务每天失败但无人发现说明它在真实环境里频繁发生而当前手段拦不住。这类组合的优先动作不是改架构而是先把探测度拉上去加监控、加报警、加失败重试。低严重度低发生度但高探测度的失效模式在列表中可能分值偏高但它本质是“会被检测到且影响不大”的问题RPN高属于误伤。这时不应占用稀缺整改资源只要持续跟踪即可。评价准则里把这类组合提前标注出来能少很多不必要的整改会议。6. 把严重度发生度探测度评价准则落地成PDF的最后100米6.1 开局放决策树而不是等级总表一份能用的评价准则PDF先不要放10级大表。读者看到不会用的。应在第一页放一个决策树数据是否可能丢失是跳到9分以上否再问是否违反合规要求再问用户是否可见。这样评分人两三分钟就能进入正确区间然后再回表里要精确分级。等级表放第二页之后。6.2 每个等级写一个“反例”反例和正例要同时存在。正例说明这个等级该给什么场景反例说明什么场景看起来很像但不应给这个等级。例如严重度7的正例是主要功能降级需人工恢复反例是数据库误操作但五分钟内恢复成功后者应按8到9而不是7。反例的价值在于暴露边界让团队知道两档之间的灰色地带左右选择哪个。6.3 用历史事件回测评级尺文档定稿前找出最近一年的三个故障按新准则重新打分再对照当时的处置顺序。如果新准则把当时认为最重要的故障排到了后面说明准则阈值需要改。回测的结论直接写进准则的版本记录里下一轮评审引用这个节作为依据。6.4 在评审模板里引用版本号评价准则最后落地不是发邮件的瞬间而是它成为评审模板必填项的时刻。代码审查、变更评审、架构评审模板中凡是涉及风险评估都应该有一格填写“依据评价准则版本号”。版本号的意义是让两个月的会议使用同一版评分表。准则正文本身不需要常更新但回测数据和锚点案例应每个季度补充一轮补充后版本号随之增加这样“为什么上次评7这次评6”的争议永远有据可查。本文还有配套的精品资源点击获取
` 替代只读场景下的 `Arraysplice()`)
