MTBF、MTTR、MTTA、MTTF

了解一些最常见的事件指标

在当今永不停机的世界中，中断和技术事件比以往任何时候都更为关键。故障和停机会带来切实后果，错过截止时间、延迟付款和项目延期，这些都是停机产生的成本。

这就是为什么公司必须量化和跟踪有关正常运行时间、停机期间以及团队解决问题的速度和有效性的指标。

行业中一些最常跟踪的指标包括：

• MTBF（平均故障间隔时间）用于衡量系统两次故障之间的平均正常运行时间。

  • 公式：MTBF = 总运行时间 ÷ 故障次数

• MTTR（平均修复/恢复/解决/响应时间）用于衡量系统或服务在出现故障后恢复的速度。

  • 公式：MTTR = 总停机时间 ÷ 事件数

• MTTF（平均实效时间）关注不可修复系统在发生故障前的预期使用周期。

  • 公式：MTTF = 总运行时间 ÷ 故障次数（适用于不可修复系统）

• MTTA（平均确认时间）用于衡量团队识别或响应事件所需的时间。

  • 公式：MTTA = 确认时间 ÷ 事件数

许多专家认为，这些指标本身其实没有那么有用，因为它们不会问一些更难的问题，比如如何解决事件、哪些有效、哪些无效，以及问题升级或降级的方式、时间和原因。

另一方面，MTTR、MTBF 和 MTTF 可以作为良好的基线或基准，启动对话，引发更深层次的重要问题。

关于 MTTR 的免责声明

提到 MTTR 时，人们很容易误以为它是含义单一的指标。但事实是，它可能代表了四种不同的衡量标准。R 可以代表修复、恢复、响应或解决，虽然这四个指标确实存在交叉，但存在各自的含义与细微差别。

因此，如果您的团队正在谈论跟踪 MTTR，最好弄清楚他们在说哪个 MTTR 以及他们是如何定义的。在您开始跟踪成功和失败之前，您的团队需要同步了解您正在跟踪的内容，并确保每个人都知道他们在说同样的事情。

MTBF：平均故障间隔时间

平均故障间隔时间是多少？

MTBF（平均故障间隔时间）是技术产品两次可修复故障之间的平均时间。该指标用于跟踪产品的可用性和可靠性。两次故障之间的时间越长，系统就越可靠。

大多数公司的目标是尽可能保持较高的 MTBF，两次问题之间间隔数十万小时（甚至数百万小时）。

MTBF 公式

MTBF 公式很简单：

• MTBF = 总运行时间/故障次数

总运行时间通常以小时为单位统计，对于高频使用的设备尤其如此。计算方式为：每日运行时间 × 使用天数。

对于使用频率不高的设备，可以用运行天数替代小时来统计；而对于预期使用寿命极长的设备，甚至可以按周进行统计。

MTBF 示例

通过查看一个使用 MTBF 公式的示例，有助于理解 MTBF 的计算方法及其在事件管理中的作用。在本例中，我们以一台每日 24 小时不间断运行、运行时长为 1 个月的服务器为例。

• 24 小时 * 30 天 = 720 小时

• MBTF = 720 小时/2 次故障 = 360 小时

在此示例中，平均故障间隔时间为 360 小时。

何时使用 MTBF（以及何时不宜使用）

MTBF 在规划与预防性维护方面是一项实用指标。借助 MTBF，您可以更清晰地掌握故障与停机的发生频率，从而主动部署事件管理工具与应对策略。

但 MTBF 并非适用于所有场景。对于不可修复系统，应改用平均失效时间 (MTTF)，而非 MTBF。

MTBF、MTTR 与可用性之间有什么关系？

同时计算 MTBF 和 MTTR，可以确定系统可用性。以下是系统可用性的公式：

• 可用性 = MTBF/(MTBF + MTTR)

MTBF 数值越高、MTTR 数值越低，系统正常运行时间就越长，故障带来的成本也会随之降低。但需要注意可靠性与可用性的区别：可用性衡量系统可正常运行的时长，而可靠性衡量系统性能是否达到性能标准。

MTTR：平均修复时间

平均修复时间是多少？

MTTR（平均修复时间）是指修复系统（通常是技术或机械系统）所需的平均时间。这包括修复时间和任何测试时间。直到系统恢复完全正常运行，此指标才会停止计时。

如何计算平均修复时间

您可以通过将任何给定时间段内的总修复时间相加，然后将该时间除以修复次数来计算 MTTR。

因此，假设我们正在考虑一周内的修复。在这段时间里，发生了十次中断，系统修复花了四个小时。四小时等于 240 分钟。240 除以 10 等于 24。这意味着在这种情况下，平均修复时间为 24 分钟。

平均修复时间的限制

平均修复时间并不总是与系统中断本身的时间相同。某些情况下，修复会在产品故障或系统中断后的几分钟内开始。在其他情况下，在问题出现、检测到问题和开始修复之间会有一段时间间隔。

此指标在跟踪维护人员修复问题的速度时最有用。它并不是要识别系统警报问题或修复前延迟，这两者也是评估事件管理计划成败的重要因素。

如何以及何时使用平均修复时间

MTTR（平均恢复时间）是支持和维护团队用来保持维修按计划进行的一项指标。目标是通过提高维修流程和团队的效率来尽可能降低这个数字。

MTTR：平均恢复时间

平均恢复时间是多少？

MTTR（平均恢复时间或平均还原时间）是指从产品或系统故障中恢复所需的平均时间。这包括整个中断时间—从系统或产品发生故障起，到其完全恢复正常运行为止。

正如 DevOps 研究与评估 (DORA) 指出的那样，这是一项关键的 DevOps 指标，可用于衡量 DevOps 团队的稳定性。

如何计算平均恢复时间

平均恢复时间是通过将特定时间段内的所有停机期间相加并除以事件数来计算的。因此，假设我们的系统 24 小时内在两次不同的事件中停机了 30 分钟。30 除以二等于 15，所以我们的 MTTR 是 15 分钟。

平均恢复时间的限制

此 MTTR 用于衡量您的完整恢复流程的速度。它有您想要的那么快吗？它与您的竞争对手相比如何？

这是一个高层级指标，有助于您确定是否存在问题。但是，如果您想诊断问题具体出在流程中的哪个环节（是警报系统的问题？团队修复耗时过长？还是人员响应修复请求的时间太久？），则需要更多的数据支撑。因为从故障发生到系统恢复，中间涉及多个环节。

问题可能出在您的警报系统上。故障和警报之间有延迟吗？警报发送给正确人员所需的时间是否超过了应有的时间？

问题可能出在诊断上。您能很快弄清楚问题出在哪里吗？有没有可以改进的流程？

或者问题可能出在修复上。您的维护团队是否尽其所能？如果他们占用了大部分时间，是什么难住了他们？

您需要比 MTTR 更深入地研究才能回答这些问题，但平均恢复时间可以为诊断恢复流程是否存在需要您更深入研究的问题提供一个出发点。

如何以及何时使用平均恢复时间

MTTR 指标非常适合评估整体恢复流程的速度。

MTTR：平均解决时间

平均解决时间是多少？

MTTR（平均解决时间）是指完全解决故障所需的平均时间。这不仅包括检测故障、诊断问题和修复问题所花费的时间，还包括确保故障不会再次发生所花费的时间。

该指标将处理修复的团队的责任扩展到长期提高绩效。这是灭火与灭火然后对房屋进行采取防火措施之间的区别。

这个 MTTR 与客户满意度之间有很强的相关性，因此需要重点注意。

如何计算平均解决时间

要计算此 MTTR，请将要跟踪的时间段内的完整解决时间相加，然后除以事件数。

因此，如果您的系统 24 小时内在单个事件中共停机了两个小时，而团队又花了两个小时进行修复以确保系统中断不会再次发生，那么解决问题总共花了四个小时。这意味着您的 MTTR 是四个小时。

关于跟踪平均解决时间的说明

请记住，MTTR 通常是使用工作时间计算的（因此，如果您有一天在工作时间结束时从问题中恢复过来，第二天早上第一时间花时间修复潜在问题，那么您的 MTTR 将不包括离开办公室的 16 个小时）。如果您有多个地点的团队全天候工作，或者您的待命员工在下班后工作，那么定义如何跟踪这个指标的时间很重要。

如何以及何时使用平均解决时间

MTTR 通常用于讨论计划外事件，而不是服务请求（通常是计划内的）。

MTTR：平均响应时间

平均响应时间是多少？

MTTR（平均响应时间）是指从首次收到产品或系统故障警报开始，到从产品或系统故障中恢复所需的平均时间。这不包括警报系统中的任何延迟时间。

如何计算平均响应时间

要计算此 MTTR，请将从警报到产品或服务完全恢复正常运行时的全部响应时间相加。然后除以事件数。

例如：如果您在一周 40 个小时的工作时间内发生了四起事件，并且在这些事件上总共花费了一个小时（从警报到修复），则该周的 MTTR 为 15 分钟。

如何以及何时使用平均响应时间

在衡量团队在抵御系统攻击方面的成功时，通常将此 MTTR 用于网络安全。

MTTA：平均确认时间

平均确认间隔时间是多少？

MTTA（平均确认时间）是从触发警报到开始处理问题所花费的平均时间。此指标可用于跟踪团队的响应能力和警报系统的有效性。

如何计算平均确认时间

要计算您的 MTTA，请将警报和确认之间的时间相加，然后除以事件数。

例如：如果您有 10 个事件，而所有 10 个事件的警报和确认之间总共有 40 分钟，则将 40 除以 10 得出平均值 4 分钟。

如何以及何时使用平均确认时间

MTTA 在跟踪响应速度方面很有用。您的团队是否受警报疲劳困扰并且响应时间过长？此指标将帮助您标记问题。

MTTF：平均故障时间

平均故障时间是多少？

MTTF（平均失效时间）是指技术产品两次不可修复故障的平均间隔时间。例如，若 X 品牌汽车发动机平均运行 500000 小时后彻底失效、必须更换，则 500000 小时就是该发动机的 MTTF。

该计算用于了解系统通常会持续多长时间，确定新版本的系统性能是否优于旧版本，并向客户提供有关预期使用寿命以及何时安排系统检查的信息。

如何计算平均故障时间

平均故障时间是算术平均值，因此您可以通过将正在评估的产品的总运行时间相加，然后将该总运行时间除以设备数量来计算。

例如：假设您在计算灯泡的 MTTF。Y 品牌的灯泡在烧坏之前平均能持续多长时间？假设您有四个灯泡的样本需要测试（如果您想要具有统计学意义的数据，那您需要的远不止于此，但为了简单的数学目的，我们保持这个小值）。

灯泡 A 持续 20 个小时。灯泡 B 持续 18 个小时。灯泡 C 持续 21 个小时。灯泡 D 持续 21 个小时。总共 80 个小时。除以四，MTTF 为 20 个小时。

平均故障时间问题

通过灯泡这种例子可以看出，MTTF 是一个很有意义的指标。我们可以运行灯泡直到最后一个灯泡出现故障，然后利用这些信息得出关于灯泡弹性的结论。

但是，当我们测量那些不会很快出现故障的东西时会发生什么？那些本来可以使用很多年的东西。对于这些情况，尽管经常使用 MTTF，但它并不是一个很好的指标。因为在大多数情况下，我们不是在产品出现故障之前一直运行产品，而是要在规定的时间长度内运行产品，并测量有多少产品出现故障。

例如：假设我们正在尝试获取 Z 品牌平板电脑上的 MTTF 统计数据。希望平板电脑能用很多年。但是 Z 品牌可能只有六个月时间来收集数据。因此，他们对 100 台平板电脑进行了六个月的测试。假设一台平板电脑恰好在六个月期限出现故障。

因此，我们计算总使用时间（六个月乘以 100台平板电脑），得出 600 个月。只有一台平板电脑出现故障，所以我们将其除以一，那么我们的 MTTR 将为 600 个月，也就是 50 年。

Z 品牌的平板电脑每台能平均使用 50 年吗？不太可能。因此，在这样的情况下，指标会被分解。

如何以及何时使用平均故障时间

当您尝试评估寿命较短的产品和系统（例如灯泡）的平均寿命时，MTTF 很好用。它也仅适用于评估全部产品故障的情况。如果您要计算需要修复的事件之间的间隔时间，可以使用 MTBF（平均故障间隔时间）。

MTBF vs. MTTR vs. MTTF vs. MTTA

那么，在跟踪和改善事件管理方面，哪个衡量标准更合适？

答案是全部。

虽然它们有时可以互换使用，但每个指标都提供了不同的见解。组合使用时，它们可以更完整地讲述您的团队在事件管理方面的成功程度以及团队可以改进的地方。

平均恢复时间能反映系统恢复正常运行的速度。

结合平均响应时间，可区分恢复时间中，哪些是团队处理耗时、哪些是警报系统延迟耗时。

再结合平均修复时间，就能了解团队在修复和诊断上的耗时。

纳入平均解决时间，就能全面掌握故障修复与问题解决的整体情况，而不只是实际停机时间。

纳入平均故障间隔时间，视角会进一步拓宽，可衡量团队预防、减少后续问题的成效。

再纳入平均失效时间，就能掌握产品或系统的全生命周期状况。

Jira Service Management 提供报告功能，因此您的团队可以跟踪 KPI 并监控和优化您的事件管理实践。

常见问题

MTBF 数值为多少才算理想？

理想的 MTBF 数值取决于所使用的系统类型。SSD 这类高可靠性组件的 MTBF 可达200 万小时；服务器的 MTBF 约为 15000 小时；而传送带电机等实体制造组件的 MTBF 达到 4000 小时即视为性能可靠。

MTTR 数值为多少才算理想？

平均修复时间 (MTTR) 数值越低，修复速度越快，可减少代价高昂的停机时间。对于制造系统，MTTR 低于 5 小时最为理想，能够最大限度提升产能。IT 和安全团队通常追求趋近于零的 MTTR，因此 1 小时以内就属于优秀水平。MTTR 同时也取决于故障的严重等级。

MTTF 应该高还是低？

对于不可修复系统，平均失效时间 (MTTF) 越高越好，因为失效就代表该系统寿命终结。MTTF 与 MTBF 不同，前者衡量的是不可修复组件发生故障前的平均时长，而非多次故障之间的平均间隔。