数据中心MTBF和AFR如何计算与应用？(1)(3)

二、影响AFR的可变因素

大多数情况下，用户是从供应商处获取MTBF值，不带有任何用于证实这些数值的相关数据。如上所述，当查看多个系统的MTBF值或AFR值）时，了解分析所用的隐含假设和可变因素特别是定义故障的方式）非常重要。比较时若忽视了这一点，比较结果出现偏差的可能性就会变大，可能会出现500%或更高的偏差。最终可能导致不必要的业务支出甚至意外停机。

一般来说，必须有明确的可变因素定义、假设定义以及故障定义，才可以比较两个或更多系统间的MTBF值。即使两个MTBF值看起来很相似，仍然有比较结果出现偏差的可能。因此，必须弄清MTBF结果后面隐含的内容，并仔细研究和领会这些数值所包含的含义。

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

产品功能、应用和边界

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

更重要的是，MTBF比较中所用系统的边界必须等同。如果各个系统的定义方式不同，那么不可避免地会出现比较偏差。我们以使用外部电池的UPS系统为例。某些供应商可能选择不包括由这些电池导致的故障，因为他们位于系统“外部”，不是系统的一部分。其他供应商可能选择包括电池故障，因为这些电池是系统运转的必要组件。图2说明此示例。其他可能导致不一致边界的组件包括输入和输出电路断路器、旁路系统、保险丝和控制系统。用户应该向供应商咨询MTBF计算中应包括哪些组件或子系统，不应认为所有供应商定义系统的方式都相同。

图2   比较UPS系统的“边界”

稳定故障率假设

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

抽样总体大小

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

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

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

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

样本数据采集期

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

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

故障定义

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

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

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

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

如果耗材例如电池）的使用期比预期的时间要短，是否属于故障？

运输造成的损坏是否属于故障？这可能表明包装的设计不当。是否将重复出现的故障统计在内？也就是说，对于同一用户使用的同一系统内诊断结果相同的故障，是重复计数还是仅计数一次？

安装过程导致的故障是否统计在内？此故障可能是供应商技术人员引起的。如果用户没有购买推荐的维护合同或监视系统，是否将故障统计在内？如果地震导致建筑物损害，使得系统出现故障，是否将故障统计在内或将其视为“天灾”？

是否将系统外某些组件的故障统计在内？对于UPS系统，系统外组件可能是电池或旁路开关。如果出现连锁故障，导致后续系统停机，是将每个系统的故障都统计在内还是仅统计第一个系统的故障？

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

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

有三个直观定义：
类型0 该产品有一个妨碍其运转的缺陷或故障。
类型I 产品整体失效，无法实现其所应实现的功能。
类型II个别组件失效，无法实现其应实现的功能，但不是产品整体失效，无法实现该产品应实现的功能。

除了了解每个供应商选择的定义，还必须明确是否包括人为故障。在MTBF计算要包括人为失误的情况下，比较MTBF值可能更困难。这是因为有多种可能导致故障的人为失误，使得供应商需要筛选出与人为失误相关的故障。如果所有供应商都没有筛选出相同类型的故障，那么系统比较结果就很值得怀疑。

要说明这一点，我们仍然以上面的“X”牌产品为例。表1比较当存在不同的故障定义时的MTBF值。

系统“A”是“X”牌产品，其故障被定义为严重类型I）故障，包括所有人为失误和耗材故障类型。系统“B”是同一“X”牌产品。其故障同样为仅有类型I故障，但不包括人为失误导致的故障、连锁故障以及耗材故障。根据MTBF公式的性质，在样本期间即使一个故障差额也可能对MTBF结果产生很大影响。在此示例中，有5个系统故障差额系统A有9个，系统B有4个），MTBF按125%变化。故障定义很容易且常常被误解，就象此示例中所示，可以看出有效比较和无效比较的差别。

 

 

为了减少这种不一致性，APC为您建议了一种最佳方案，用于定义MTBF值所包括的内容。此最佳方案是基于向用户展示所有合理故障这一目标而建立的。这些故障应该代表供应商控制的所有故障情况。例如，如果故障是由供应商的维修技术人员引起的，MTBF应该反映这个情况，因为此故障属于供应商的责任。另一方面，如果用户选择雇佣第三方维修人员，是维修人员引发了故障，MTBF不应该反映此情况，因为它已经超出了供应商的控制范围。附录中的对照表指明哪些定义是此最佳方案的组成部分。

只要有可能，此故障最佳方案定义应该用于比较供应商间的产品。如果供应商只能够提供此定义的子集，那么从其他被比较的供应商获取同一子集是很必要的。再次说明，此一致性对于公平比较是非常必要的。不过，尽管这可以促成“公平”比较，但并不能很好地反映现实。供应商包括的故障子集越小，MTBF值与实际情况距离越远。

样本期间结束日期和AFR计算日期之间的时间间隔

如果某个供应商可以接收、诊断和修理样本期间内报告的所有产品故障，则可以立即计算AFR。事实上，对于在客户处进行诊断和修理的少量产品，这是可行的。但是，如果是运回制造商处的大量产品，就不能这样。对于相似产品类型的MTBF比较，样本期间结束日期和AFR计算日期之间的延迟应该相似。例如，假设供应商“A”在样本期间结束的一个月后计算AFR，供应商“B”在样本期间结束的四个月后计算AFR。如果被比较的产品是大批量产品，供应商“A”报告一个令人满意的AFR的可能性更大。这是因为某些“故障”产品尚未接收、诊断和修理）不计入AFR计算之内。

在某种条件下，系统之间的时间范围差异未必会导致无效比较其他所有情况都等同）。这个条件就是，当所有供应商都假设未修理的产品与以前修理过的产品的故障率相同并且已经接收、诊断和修理了大部分返回产品。