5个“9”的疑惑

前段时间，用WQS（WindchillQuality Solutions ）软件基于SR332可靠性预计给出了我们一个产品的MTBF预计值到客户。结果被前端告知：客户反应我们里面的一个主板达不到5个9的可靠性要求。当时就困惑了…什么是5个9？客户是不是说99.999%的可靠性呢？如果是指可靠性，通常电子产品如果基于指数分布R=e(-λt),λ=1/MTBF,现在MTBF已知，但时间t是未知的，怎么就说达不到要求的5个9的可靠性呢？
后来找到了客户的原始邮件，里面提到的是Availability(可用性),并非之前自己理解的指数分布的可靠性的概率值,搞清方向,问题就好办了,运用固有可用性计算公式: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的要求….
注意：不建议直接将可靠性预计值直接代入计算可用性，有条件的情况下，为了更接近现场，通常使用加速测试方案卡方分布单侧置信得出的MTBF值进行计算。

说来也巧，在解答了上面的疑问后，第二天便看到了关注的“可靠性知识”公众号出了一篇文章：可靠性几个“9”什么意思，把人搞疯了。很及时的一篇文章，里面提到了企业经常宣传的几个9的定义级别，提到了一般电信级设备要求5个9的要求。对于里面的提及的一年允许中断时间的计算方法，引用“可靠性知识”公众号文章里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分钟，吻合。

写这篇文章的时候在想，要提高可用性，有两个方向：1）提高平均无故障工作时间MTBF；2）缩短平均修复时间MTTR；

不过通常这两个方向都会增加成本，这里就涉及到了全寿命周期花费LCC（Life Cycling Cost),如何平衡取舍，将总体成本最优化？这应该是可靠性的一个重要工作内容，不过暂无LCC相关案例，欢迎补充，留待后续讨论~~