企业官网建设流程全解析

简介：严重度发生度探测度评价准则的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系统常见结果。等级描述尽量用可观察结果，避免用“非常严重”这类递进形容词。

表里的锚点不是标准答案。每家公司应该把自己最近一年的三到五个真实故障填进去，让团队对“9级是什么样子”有共同记忆。与其争论“这个算7还是8”，不如先问“历史上哪个故障跟它最接近”。评价准则的价值就是把这种对照物固定下来，避免每次评审都重新发明形容词。

2.3 定标时必须明确的三个边界

第一，数据可恢复性要单独说清楚。同样是数据库故障，最坏情况是没有备份、备份不可用、还是能恢复到五分钟前，对应的严重度差别很大。准则里建议写一句“数据不可恢复时，最低按8分起评”，这样后续评价才有约束力。

第二，恢复时间目标要和评分绑定。IT系统大量失效可以通过自动恢复或回滚结束，因此严重度不是“永久损坏”的后果，而是在规定时间内无法恢复的后果。用RTO作为9分和7分的分界，比用“几分钟”这种描述更可执行。

第三，涉及法律法规或外部合同要求的失效，直接拉高评分。银行卡信息泄露、医疗数据未授权访问，这类场景不按人数或时长评估，只要触碰红线就进入9到10区间。边界写清楚后，严重度评价准则就不会在跨部门讨论中被反复推翻。

3. 发生度评价准则：让发生度等级从小道消息变成监控数据

3.1 发生度的评分单位是频率

发生度回答“这个失效模式在生命周期里出现的概率，或对应的平均发生频率”。由于现实中的失效频率可能从一天多次到十年一次，跨度极大，发生度等级不能按线性递进，通常用对数刻度：每升一级，频率大约提高十倍。这样做的效果是，评测时不必精确到百分位，只要判断它落在哪个数量级区间。

对IT系统来说，发生度最直接的数据来源是监控告警、工单系统、发布失败统计和容量事件。一个接口每天报错一万次，发生度显然不会低于8。一个只在每年证书轮换时出现的配置错误，则通常在3到4之间。评价准则要给出频率对照表，目的是让评分人在同一个时间尺度上说话。

3.2 适合IT系统的发生度等级参考表

下面这张表用“平均每天发生次数”作为参照，具体边界可以按团队的历史数据调整。

这张表的好处是口径统一：所有人都知道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到10，1表示几乎必定能被发现，10表示无法发现。这里最容易混淆的是把“团队里有测试”当成探测度低的理由；测试存在但覆盖不到这个失效模式，拦截概率依然是零。

探测度与严重度、发生度的最大区别在于它的主体不是失效模式本身，而是围绕这个失效模式的控制措施。同一个失效模式，在没有监控、有日志告警、有自动回滚三种状态下，探测度分别可能是10、5、2。因此，探测度评价准则要写成“按手段打分”，而不是“按感觉打分”。

4.2 不同控制手段对应的探测度等级参考表

下面是一张IT常用的探测度参考表。手段描述越具体，跨团队打分越容易一致。

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”的争议，永远有据可查。

本文还有配套的精品资源，点击获取