话说可靠性中5个“9”的疑惑
2019/06/28 23:18:54
前段时间，用WQS（WindchillQuality Solutions ）软件基于SR332可靠性(Reliability)预计给出了我们一个产品的MTBF预计值到客户。结果被前端告知：客户反应我们里面的一个主板达不到5个9的可靠性(Reliability)要求。当时就困惑了...什么是5个9？客户是不是说99.999%的可靠性(Reliability)呢？如果是指可靠性(Reliability)，通常电子产品如果基于指数分布R=e(-λt),λ=1/MTBF,现在MTBF已知，但时间t是未知的，怎么就说达不到要求的5个9的可靠性(Reliability)呢？
后来找到了客户的原始邮件，里面提到的是Availability(可用性),并非之前自己理解的指数分布的可靠性(Reliability)的概率值,搞清方向,问题就好办了,运用固有可用性计算公式:A=MTBF/(MTBF+MTTR)（这里A指可用性Availability);
MTBF已知为2，000，000小时（这里数字为参考，与实际值在一个数量级），MTTR的取值定义为1小时（因为MTTR指平均修复时间，这产品按照我的实际经验，正常拆装重组到恢复运行要1个小时，这意味着即使不修坏了的主板，直接更换性维修也至少1小时，所以这里MTTR先去最小值1小时）。算出来A=2000000/(2000000+1)=0.99999950000025=99.999950000025%;
这一看，6个9了....想想，怎么客户还说不符合呢？难道客户的MTTR时间很长，考虑了实际的现场维护可能出现的维修延迟？例如更换板卡和协调人员维修等耽误的时间等...利用反推法，假设刚好满足5个9的可用性，算出MTTR=20小时，意味着维修时间若超过20小时，则达不到5个9的要求；因为现场维护时间对于不同场景均有不同，后来有 询问客户他们的通常售后维护MTTR时间，并告知客户我们目前的MTBF为预计值且指定了SR332里面的Issue 3,Method 1, Case 1的预计算法，不同预计算法得出的值都有差异。可能由于商业或者其他原因，客户不愿透露他们的预计方法及MTTR取值参数，且也未再提我们的产品不能达到5个9的要求....
注意：不建议直接将可靠性(Reliability)预计值直接代入计算可用性，有条件的情况下，为了更接近现场，通常使用加速测试方案卡方分布单侧置信得出的MTBF值进行计算。
说来也巧，在解答了上面的疑问后，第二天便看到了关注的“可靠性(Reliability)知识”公众号出了一篇文章：可靠性(Reliability)几个“9”什么意思，把人搞疯了。很及时的一篇文章，里面提到了企业经常宣传的几个9的定义级别，提到了一般电信级设备要求5个9的要求。对于里面的提及的一年允许中断时间的计算方法，引用“可靠性(Reliability)知识”公众号文章里1个9和5个9各自对应的一年允许中断时间如下：
*1个9：
（1-90%）*365=36.5天；
*5个9：
（1-99.999%）*365*24*60=5.26分钟；
这里有人可能会有疑惑怎么直接算出上面的值，下面我运用可用度公式分别验证了这两个计算方法如下：
先说1个9；A=MTBF/(MTBF+MTTR)；这里A=0.9，MTBF+MTTR=1年（因为描述里写了一年内允许的中断时间，假设时间长度为1年，则无故障时间+故障维修时间总和为一年，即MTBF+MTTR=1年），代入得如下等式：
0.9=（365-MTTR）/365；继而推导出MTTR=（1-0.9）*365=36.5天，吻合；
再说5个9；同样的道理，代入得出0.99999=(365-MTTR)/365，MTTR=（1-0.99999）*365*24*60=5.256分钟，吻合。
后来找到了客户的原始邮件，里面提到的是Availability(可用性),并非之前自己理解的指数分布的可靠性(Reliability)的概率值,搞清方向,问题就好办了,运用固有可用性计算公式:A=MTBF/(MTBF+MTTR)（这里A指可用性Availability);
MTBF已知为2，000，000小时（这里数字为参考，与实际值在一个数量级），MTTR的取值定义为1小时（因为MTTR指平均修复时间，这产品按照我的实际经验，正常拆装重组到恢复运行要1个小时，这意味着即使不修坏了的主板，直接更换性维修也至少1小时，所以这里MTTR先去最小值1小时）。算出来A=2000000/(2000000+1)=0.99999950000025=99.999950000025%;
这一看，6个9了....想想，怎么客户还说不符合呢？难道客户的MTTR时间很长，考虑了实际的现场维护可能出现的维修延迟？例如更换板卡和协调人员维修等耽误的时间等...利用反推法，假设刚好满足5个9的可用性，算出MTTR=20小时，意味着维修时间若超过20小时，则达不到5个9的要求；因为现场维护时间对于不同场景均有不同，后来有 询问客户他们的通常售后维护MTTR时间，并告知客户我们目前的MTBF为预计值且指定了SR332里面的Issue 3,Method 1, Case 1的预计算法，不同预计算法得出的值都有差异。可能由于商业或者其他原因，客户不愿透露他们的预计方法及MTTR取值参数，且也未再提我们的产品不能达到5个9的要求....
注意：不建议直接将可靠性(Reliability)预计值直接代入计算可用性，有条件的情况下，为了更接近现场，通常使用加速测试方案卡方分布单侧置信得出的MTBF值进行计算。
说来也巧，在解答了上面的疑问后，第二天便看到了关注的“可靠性(Reliability)知识”公众号出了一篇文章：可靠性(Reliability)几个“9”什么意思，把人搞疯了。很及时的一篇文章，里面提到了企业经常宣传的几个9的定义级别，提到了一般电信级设备要求5个9的要求。对于里面的提及的一年允许中断时间的计算方法，引用“可靠性(Reliability)知识”公众号文章里1个9和5个9各自对应的一年允许中断时间如下：
*1个9：
（1-90%）*365=36.5天；
*5个9：
（1-99.999%）*365*24*60=5.26分钟；
这里有人可能会有疑惑怎么直接算出上面的值，下面我运用可用度公式分别验证了这两个计算方法如下：
先说1个9；A=MTBF/(MTBF+MTTR)；这里A=0.9，MTBF+MTTR=1年（因为描述里写了一年内允许的中断时间，假设时间长度为1年，则无故障时间+故障维修时间总和为一年，即MTBF+MTTR=1年），代入得如下等式：
0.9=（365-MTTR）/365；继而推导出MTTR=（1-0.9）*365=36.5天，吻合；
再说5个9；同样的道理，代入得出0.99999=(365-MTTR)/365，MTTR=（1-0.99999）*365*24*60=5.256分钟，吻合。