平均故障间隔时间的说明和标准

运维 服务器运维
本文说明应如何使用MTBF以及将MTBF用作规格和选择依据时的限制。本文还提供一个核对表,作为确保公平有效地进行跨系统比较的指导性原则。

避免关键数据中心出现故障始终是头等重要的任务。如果短时间的停机可能会对业务的市场价值产生负面影响,那么,支持这个网络环境的物理基础设施就一定要可靠。如何才能确信自己实施的解决方案是可靠的?MTBF是比较可靠性最常用的方式。不过,如果没有透彻地了解MTBF,可能就无法实现业务可靠性目标。“平均故障间隔时间:说明和标准”介绍了MTBF的基本原则。如果故障定义不明确或者假设不现实或被曲解,MTBF就毫无意义。

本文说明应如何使用MTBF以及将MTBF用作规格和选择依据时的限制。本文还提供一个核对表,作为确保公平有效地进行跨系统比较的指导性原则。

MTBF的比较性分析的现实方式和步骤

本文介绍了几种预测MTBF的方法。由于有如此多种可用方法,似乎不可能找到使用同一方法的两个系统。不过,还是有一种方法可以适用于大多数组织的各种不同过程。现场数据评估方法使用实际的现场故障数据,因此能够提供比模拟情况更准确的故障率评估。对于小批量生产的产品或新产品,此数据可能找不到;不过,对那些已在现场获得广泛应用的产品,应该始终采用此数据。因此,对于跨系统比较,从现场数据评估开始比较是最合理也是最现实的。请注意,此方法与其他许多方法一样,都是基于稳定故障率假设。

本文介绍完成此方法的步骤,列举并说明各个步骤中可能影响结果的可变因素。如果要进行比较的系统间的关键假设或可变因素发生变化,那么评估这些变化对MTBF估计结果的可能影响就非常重要。

第1步:定义并估计抽样总体的大小确定年故障率(AFR)并最终确定产品的MTBF的过程中,第一步是确定要分析的特定产品抽样总体。是基于特定产品型号还是整个产品系列进行计算?此抽样总体中产品的生产时间跨度应该多大(以天或月计)?生产日期何时开始何时结束?为抽样总体选择的产品应该在设计方面非常相似,并具有足够多的数量以保证所采集数据的统计有效性,这非常重要。

第2步:确定采集数据的样本时间范围过程的第二步是确定从抽样总体中采集故障数据的样本时间范围。通常在产品的用户给供应商报告故障时采集数据。抽样总体中产品的最晚生产日期和样本期间开始日期之间的适合时间间隔,因产品、地理位置、分销过程和库存地点不同而有所差异。例如,如果产品在工厂仓库中储存两个月,在分销渠道中历时两个月,那么最早只能在抽样总体中最晚产品生产日期的四个月后开始进行抽样。对于需要通过批发商、经销商和零售商这些环节的产品,四个月被视为是考虑上述可变因素的合理时间范围。

下面说明两个重要的可变因素:(1)抽样总体中产品的最晚生产日期和样本期间开始日期之间要有足够的时间间隔(2)数据采集窗口要足够大,以确保结果的可信度。

如果抽样总体中产品的最晚生产日期和样本期间开始日期之间没有足够的时间间隔,那么在抽样总体中的产品得到完全部署之前可能就已经开始进行抽样了。这种情况可能会造成两种结果。第一,由于尚未部署的产品不可能出现故障,所以有低估故障率的倾向。第二种结果就是样本期间很可能包括大量的安装故障或设置故障。因为新产品的故障率可能会显示为一个标准的“浴缸”型,所以包括大量安装故障可能会导致高估故障率。尽管我们知道这两种相反的效果都很明显,但也不能指望他们能互相抵消。

在抽样时间方面,另一个需要考虑的重要问题是窗口的持续时间。需要多少天才能充分采集故障数据?采样时间窗口必须选得足够宽,以便可以从样本中移除统计“干扰”。获得合理准确度所需的持续时间取决于抽样总体的大小。例如,大批量产品可能需要一个月时间,小批量产品可能需要几个月时间。

第3步:定义故障必须准确定义故障,确保评估过程的一致性后,才能开始统计故障。

现在假设在“故障”产品返回工厂时,是由每个技术人员单独定义故障。某位技术人员可能只统计那些出现重大故障的产品,而另一位技术人员可能统计所有出现了故障(包括重大故障)的产品。这两种极端的做法使得准确评估特定产品故障率的可能性几乎为零,当然更不能准确评估对该产品的过程控制所产生的影响。因此,在诊断任意产品之前,供应商必须对故障有一个明确的定义。在计算特定事件的MTBF时,供应商可能有多种不同的故障定义。例如,供应商会试图评估导致关键负载停用的故障的MTBF以及负载能够继续运转的不很严重的故障的MTBF。

第4步:接收、诊断和修理产品样本期间结束时间和AFR计算时间之间必须有足够的时间间隔,以允许一定的时间来接收、诊断和修理报告为有故障的产品。诊断结果确定故障类型,而修理将会验证诊断结果。体积较小的产品通常会发回供应商处,这会导致出现接收延迟或需要一定的产品递送时间。产品到达供应商处后,必须对其进行诊断和修理,这会导致另一个称为诊断延迟的延迟。大型产品通常在客户处进行诊断和修理,因此基本没有延迟。在上述任一情况下,都需要在计算AFR前诊断和修理产品。如果是大批量产品,很可能在诊断延迟结束时仍然有需要修理的产品。在这些情况下,有时会做出未修理产品和以前修理过的产品出现故障的机率相等这样的假设。取决于待评估产品的生产量和产品类型,接收延迟和诊断延迟可以在样本期间结束时间后加上几个星期,您可以在此时间点计算AFR。

第5步:计算年故障率计算年故障率是用来说明某个特定产品在一个日历年度内的预期故障数。

计算此数值的第一步是“按年计算”故障数据。将样本期间中的故障数乘以每年的样本期间数,可以得出此值。第二步就是确定整个抽样总体的故障率。将计算出来的每年故障数除以抽样总体期间安装的产品数,可以得出此值。

此公式有如下两个假设:(1)产品一年365天、每天24小时连续运转(2)抽样总体中的所有产品都在同一时间开始运转。因此尽管此公式可以用于任意产品,但更适用于连续运转的产品。

本抽样总体有10,000辆汽车。在2个月(样本期间)内,要采集此抽样总体的故障数据。平均而言,一辆汽车每年运转400个小时。在这2个月内,有10辆汽车出现故障。

使用公式1:故障率为10个故障x(每年52个星期/样本期间为8个星期)/抽样总体中有10,000台装置=0.0065或0.65%。

使用公式2:假设这些产品同时*开始运转,抽样总体的运转时间为每年10,000x400小时=每年累计4百万小时或4,000,000/8760小时=累计457年。

故障率为10个故障x(每年52个星期/样本期间为8个星期)/累计457年=0.14或14%*请注意,此假设是为了简化这个示例。现实情况是产品在整个期间内都有销售,因此实际运转时间将比上面的数字小。导致AFR值变大。

如果上面的示例是以连续运转产品为例,那么两个AFR值将相等。即使取消所有产品同时开始运转这个假设,AFR值仍然非常接近。因此,了解产品是连续运转还是非连续运转对于进行正确地分析至关重要。

第6步:将AFR转换为MTBF将AFR转换为MTBF(以小时计)是所有步骤中最容易的,不过可能也是最常被误解的。只有在故障率稳定这一假设下,将AFR转换为MTBF才有效。

#p#

使用AFR评估过程对MTBF计算结果抽样

下面的假想示例有助于说明整个过程。

第1步:确定抽样总体全部为“X”牌15kVA**系统,是在2003年的第36周到第47周(9月1日至11月21日)生产的,生产窗口时长共12周。抽样总体共2000台装置。

第2步:确定采样窗口从2004年2月2日开始,至2004年7月16日结束。选择这一采样窗口时,考虑了在产品库存和分销过程中会有10周的延迟。

第3步:将故障定义为由任何原因(包括人为错误)引起的关键负载停用。

第4步:在样本期间,总共报告了二十起故障。其中,九起故障被划分为关键负载停用故障,其他故障为非关键故障。因此,根据第3步中确定的故障定义,下面计算中使用的故障数为九。已经在计算AFR之前接收、诊断和修理了出现故障的产品。

影响AFR的可变因素大多数情况下,用户是从供应商处获取MTBF值,不带有任何用于证实这些数值的相关数据。如上所述,当查看多个系统的MTBF值(或AFR值)时,了解分析所用的隐含假设和可变因素(特别是定义故障的方式)非常重要。比较时若忽视了这一点,比较结果出现偏差的可能性就会变大,可能会出现500%或更高的偏差。最终可能导致不必要的业务支出甚至意外停机。一般来说,必须有明确的可变因素定义、假设定义以及故障定义,才可以比较两个或更多系统间的MTBF值。即使两个MTBF值看起来很相似,仍然有比较结果出现偏差的可能。因此,必须弄清MTBF结果后面隐含的内容,并仔细研究和领会这些数值所包含的含义。

下面将介绍每个可变因素,并说明他们可能对结果产生的影响。附录中提供一个核对表,可以用于比较两个或多个系统间的可变因素。完成比较后,必须再检查一下核对表,以确定系统间有哪些不同的可变因素。通过逐一严格分析这些不同的可变因素及其对MTBF的影响,可以确定比较是否公正并可以作为产品规格或购买决策的关键标准。

产品功能、应用和边界在比较两个或更多MTBF值之前,验证被比较的两个产品是否同类非常重要。被比较的产品必须在功能、性能及应用方面相似。如果被比较的产品是**,则产品功能就是为连接的负载提供备用电源。此产品的用途可能是用来支持数据中心环境中的关键IT负载。如果没有相似的应用,就不可能进行公正的MTBF比较。例如,对工业用途和IT用途的比较是不切合实际的。

稳定故障率假设要使计算AFR和MTBF的现场数据评估方法有效,必须假设被分析产品具有稳定的故障率。很重要的一点就是要判明此假设对于被比较产品的类型是否合理。对于电子系统或组件,这个假设通常可以成立。该产品是否属于这一类?如果不属于,计算出来的值可能不会是预期故障的代表性值,进行公正比较的可能性就很小。

抽样总体大小在明确产品及其应用非常相似后,很重要的一项工作就是审查现场数据采集过程。在这里,定义抽样总体大小(生产的产品数量)是第一个关键的可变因素。如果抽样总体中定义的产品数量太少,那么得出的MTBF估计值就很可能没用。因此,比较MTBF值时,确保每个值都是基于足够大的抽样总体大小,这是非常重要的。

尽管被比较产品的生产率可能不同,但需要着重考虑的是抽样总体中的产品数量。如果某个产品的生产率较低,那么此产品的生产时间范围应该比较大,以便能够达到一个合适的产品数量。例如,供应商“A”在一个月内生产1000台产品,而供应商“B”在一个月内生产50台“同类”产品。对于供应商“B”,抽样总体中应包括若干个月生产的产品,以确保结果的统计有效性;对于供应商“A”,一个月内生产的产品就够了。

抽样总体中产品的最晚生产日期和样本期间开始日期之间的时间间隔如果抽样总体范围的结束时间和样本采集期的开始时间之间没有足够的时间间隔,那么AFR和MTBF值可能是不准确的。被比较的每个系统的供应商必须为其抽样总体提供足够时间,以便在开始采集故障数据之前系统可以完成库存及分销过程。

例如,如果某个特定产品通常在库房中存放一个月后,进入分销过程(历时一个月),那么评估故障前设定的最短时间应该是两个月。总“等待”时间因产品类型而异。由于要进行比较的产品类型应该相似,所以总体期间和样本期间之间的时间应该相似。如果某个供应商明显没有足够的等待时间或根本没有等待时间,那么他们的系统AFR可能会低于实际值,在比较这些值时要特别注意。

样本数据采集期正如在此过程第2步中所指出的那样,选择合适的样本数据采集期非常重要。如果被比较的系统具有相同长度的采样窗口,并且具有相似的生产量和/或销售量,就可以进行公平比较。不过,情况并不总是这样。如果各个系统的数据采集期时间不同,那么单独地评估每个系统,确定其是否能够反映准确的故障率就很重要。

产品数量越少,窗口应该越长。例如,如果某个供应商每个月的产品产量为10台,用一个月时间来采集故障数据,时间就不充分。因为产品数量少,所以用这个月内报告的故障(如果有)来推断前几个月的故障率,可信度很低。

故障定义如果两个可比较产品间的故障定义不同,那么进行故障分析就象比较苹果和橙子一样毫无意义。因此,要进行有效的MTBF比较,一项基本任务就是准确分析每个被比较产品的故障组成。因此,对于MTBF计算,供应商应该将哪些故障统计在内?

将用户误用导致的故障统计在内是否有用?设计者可能忽视了许多人为因素,这将导致用户很容易误用产品。

在电源保护行业中,**故障的最常见“定义”是“负载停用”故障。这表示向负载供电超出了可接受范围,导致了负载停止运转。不过,将由供应商维修技术人员导致的负载停用统计在内是否有用?产品设计本身是否会提高风险程序出现故障的可能性?

如果计算机上的LED(发光二级管)出现故障,是否属于故障(虽然它没有影响计算机的运行)?

如果耗材(例如电池)的使用期比预期的时间要短,是否属于故障?

运输造成的损坏是否属于故障?这可能表明包装的设计不当。是否将重复出现的故障统计在内?也就是说,对于同一用户使用的同一系统内诊断结果相同的故障,是重复计数还是仅计数一次?安装过程导致的故障是否统计在内?此故障可能是供应商技术人员引起的。如果用户没有购买推荐的维护合同或监视系统,是否将故障统计在内?如果地震导致建筑物损害,使得系统出现故障,是否将故障统计在内或将其视为“天灾”?是否将系统外某些组件的故障统计在内?对于**系统,系统外组件可能是电池或旁路开关。如果出现连锁故障,导致后续系统停机,是将每个系统的故障都统计在内还是仅统计第一个系统的故障?

如果某个系统进行了“自定义”设置,是否将该系统的故障从抽样总体中排除?

工业中用来计算MTBF的实际故障定义可能会有一些衍生情况。上面列出的只是一小部分。因为将许多异常情况统计为故障,所以MTBF值所反映的系统性能比实际使用情况更可靠。要为合作伙伴和用户提供AFR和MTBF值,比较MTBF值时需要一个明确的故障定义。

有三个直观定义:

类型0该产品有一个妨碍其运转的缺陷或故障。

类型I产品整体失效,无法实现其所应实现的功能。

类型II个别组件失效,无法实现其应实现的功能,但不是产品整体失效,无法实现该产品应实现的功能。2除了了解每个供应商选择的定义,还必须明确是否包括人为故障。在MTBF计算要包括人为失误的情况下,比较MTBF值可能更困难。这是因为有多种可能导致故障的人为失误,使得供应商需要筛选出与人为失误相关的故障。如果所有供应商都没有筛选出相同类型的故障,那么系统比较结果就很值得怀疑。

责任编辑:景琦 来源: 机房360
相关推荐

2010-04-07 11:56:58

Oracle JOB

2020-07-27 09:37:31

Intel系统更新

2018-11-21 09:27:45

机房监控系统故障

2023-05-16 07:32:33

业务指数级故障

2009-12-16 10:40:03

2010-03-01 18:07:53

Python语言

2019-11-12 13:30:07

开源技术 软件

2009-08-19 22:29:12

VMWare系统时间故

2010-07-14 17:51:53

Telnet协议标准

2009-11-24 18:34:23

网络故障诊断路由器

2009-09-03 14:55:34

C#计算时间间隔

2010-01-05 16:41:48

JSON 标准

2023-10-19 13:42:00

数据集MEG数据

2016-09-30 08:56:45

Windows 10间隔时间

2009-11-03 14:33:46

无线接入技术

2023-09-11 17:39:35

SSH服务TCP

2010-03-12 17:20:03

交换机故障现象

2009-11-12 16:58:14

路由器死机

2009-12-29 16:49:52

ADSL2和ADSL2

2009-12-16 09:26:56

边缘路由器
点赞
收藏

51CTO技术栈公众号