MTTR、MTBF、MTTA是什么意思：公式与算例

先说结论： MTTR 是故障发生后平均要多久修好或恢复；MTBF 是系统两次故障之间平均能稳定运行多久；MTTA 是事件出现后平均要多久有人接手。MTTR 和 MTTA 衡量的是支持团队行动快不快，MTBF 衡量的是系统本身牢不牢靠。写进合同之前，务必先写清楚你说的 MTTR 里的"R"到底是哪一个。

只要看过月度 IT 支持报告，多半见过这三个缩写排在一起。它们长得像，常被一起引用，也常被用错。这篇文章逐个说明含义和公式，每个指标配一个小算例，最后讲哪些指标适合写进服务等级协议（SLA），哪些只适合放在报告里。

定义和公式参考了 Atlassian 的常用事件指标指南，该文给出了各指标的公式，并指出 MTTR 有四种不同含义。我们于 2026 年 10 月 28 日阅读该文（查证日期：2026-10-28）。下文算例中的数字均为虚构，仅用于说明，并非博迅的实际数据。

MTTR、MTBF、MTTA 分别代表什么？

三者都是"平均时间"：总时长除以次数，回答的都是"平均下来要多久"，只是各自量的是一次故障生命周期中的不同一段。

MTTA（平均确认时间）： 从告警或工单产生，到有人开始处理为止。
MTTR（平均修复、恢复、响应或解决时间）： 从故障开始（或工单创建）到服务恢复正常为止。问题出在这个"R"上，下一节展开说。
MTBF（平均无故障间隔时间）： 可修复的系统，平均每隔多久出一次故障。

把一次故障想成一条时间线：故障发生、告警触发、有人确认、有人修复，然后系统一直正常运行到下一次故障。MTTA 量第一段空档，MTTR 量从故障到修好，MTBF 量两次故障之间那一长段稳定期。

MTTR 到底是什么意思？为什么有四种说法？

MTTR 是三个指标里被引用最多、定义却最不统一的一个。Atlassian 指出，这个 R 可以是 repair（修理）、recovery（恢复）、respond（响应）或 resolve（解决），四者互有重叠，但并不是同一种测量。我们的理解如下。

平均修理时间（repair）： 动手修故障花的时间，一般从开始修到修完，包括测试直到系统完全恢复正常，不含发现故障和排队等待的时间。
平均恢复时间（recovery）： 从故障开始，到用户重新能用服务为止的整段时间，包含发现、确认、诊断、修复和测试。老板关心的就是这个版本，因为它等于停机时长。
平均响应时间（respond）： 从第一次告警到系统完全恢复的平均时间，不含告警系统本身的延迟。这是 Atlassian 的定义。
平均解决时间（resolve）： 从工单创建到工单被标记为已解决，含永久性修复和后续跟进。服务台系统里报表上的 MTTR 通常指这个。

这四种都不算错，错在把含义不同的数字拿来比较。服务商报告"平均 40 分钟修好"，客户却经历了三小时停机，两边说的可能都是真的，只是量的东西不一样。

实用做法是：数字旁边一定写上定义，即从哪个时间点开始计时、到哪个时间点停止，等待客户回复的时间算不算。

MTTR 怎么算？一个算例

公式很简单：

MTTR = 所有事件耗时之和 ÷ 事件数量

假设一个支持团队本月处理了五起事件，从工单创建到服务恢复的耗时分别为：

事件 A：45 分钟
事件 B：90 分钟
事件 C：30 分钟
事件 D：240 分钟
事件 E：15 分钟

总耗时为 45 + 90 + 30 + 240 + 15 = 420 分钟，除以 5 起事件，MTTR 为 84 分钟。

换个角度看同一组数据。按从小到大排序：15、30、45、90、240，中位数是 45 分钟。五起事件中有四起在 90 分钟内解决，只是事件 D 拖得特别久，把平均值拉到了 84 分钟。这个平均值算得没错，但容易让人误解，因为实际上没有任何一起事件恰好花了 84 分钟。

所以我们建议在平均值旁边同时报告中位数和耗时最长的那起事件。只报平均值的话，一个糟糕的夜晚就能让整个月看起来很差，一批很快搞定的密码重置也可能掩盖一台服务器的严重故障。

MTBF 是什么意思？怎么计算？

MTBF 用来衡量可以修复并重新投入使用的设备或系统的可靠性，比如服务器、防火墙、专线、业务应用。公式：

MTBF = 总运行时间 ÷ 故障次数

算例：监控一台文件服务器 30 天，即 720 小时，期间故障三次，累计停机 6 小时。

运行时间 = 720 − 6 = 714 小时
故障次数 = 3
MTBF = 714 ÷ 3 = 238 小时

也就是说，这台服务器平均每运行 238 小时（不到十天）出一次故障。

有两点要注意。第一，MTBF 需要足够长的历史数据，一个月三次故障说明不了未来一年的情况。第二，MTBF 适用于可修复的系统；对更换而不修理的部件，对应的指标是 MTTF（平均失效前时间），Atlassian 也说明了非可修复对象应该用 MTTF。

另外，MTBF 是对一批设备或一段时期的平均，不能预测某一台具体设备何时出故障。别把"238 小时"当成这台服务器一定能撑 238 小时的承诺。

MTTA 是什么意思？怎么计算？

MTTA 衡量响应是否及时。公式：

MTTA = 从告警到确认的总时间 ÷ 事件数量

算例：产生五起事件，工程师接手所用的时间分别是 4、6、10、3、12 分钟，总计 35 分钟，MTTA = 35 ÷ 5 = 7 分钟。

MTTA 低，说明告警能很快送到人手上，而且这个人确实会行动。MTTA 逐渐升高，则是预警信号：队列过载、告警被忽略，或者值班路由设置有问题。但它不能说明修好要多久。

MTTA 和 SLA 里的"首次响应时间"很接近，但不完全相同。首次响应是针对每张工单的承诺（例如"每张紧急工单 15 分钟内响应"），MTTA 则是实际耗时的平均数。团队可以平均数很漂亮，同时个别工单仍然超时。关于各优先级的首次响应目标是怎么定的，可以看我们的P1 至 P4 优先级说明。

MTTR 和 MTBF 的区别，以及两者的关系

两者是同一枚硬币的两面，放在一起可以算出可用性。

MTBF 说明多久坏一次。
MTTR（取"恢复"的含义）说明每次坏多久。

可用性是服务处于正常状态的时间占比：

可用性 = MTBF ÷ （MTBF + MTTR）

沿用前面的文件服务器：MTBF 为 238 小时；3 次故障共停机 6 小时，所以 MTTR = 6 ÷ 3 = 2 小时。可用性 = 238 ÷ （238 + 2）= 238 ÷ 240 ≈ 0.9917，约 99.2%。反过来验证：720 小时里正常运行 714 小时，同样是 99.2%。

由此可以看出两条改进路径：让故障变少，即提高 MTBF，通常靠更好的硬件、补丁、监控和变更管控；或者让恢复变快，即降低 MTTR，靠更完善的运维手册、备件、升级路径和自动化。对中小企业来说，第二条路往往更便宜，也更容易马上动手。

哪些指标适合写进 SLA，哪些只放在报告里？

合同条款和管理报告的用途不同。我们的看法：

逐张工单的响应和解决目标适合写进 SLA。 它们可以按工单逐一核对，例如每个优先级的首次响应时间和解决时间。博迅在 SLA 页面公开了这些数字：紧急（P1）工单首次响应 15 分钟，解决目标 8 个工作小时，尊享服务窗口另提供 24×7 覆盖。SLA 是什么一文讲了怎么读这类数字。
MTTA 和 MTTR 适合放在月报里。 它们反映趋势。它们是平均数，只靠一个平均数去设违约条款并不合适。
MTBF 适合放在可靠性或容量评审里。 它用于基础设施：哪台防火墙、哪条线路、哪台服务器总出问题，该不该换。

如果合同确实要用平均数，例如"平均解决时间低于四小时"，就要写清四件事：计时起点、计时终点、暂停规则（例如等待客户回复），以及重大事件是否剔除。缺了这四条，这个数字就无法审计。

开始统计之前，如何先统一定义？

与任何服务商或内部团队建立报告时，可以按下面的清单来。

说明你所指的 MTTR 是修理、恢复、响应还是解决。
写明起点时间戳（告警产生、工单创建或故障开始）和终点时间戳（服务恢复、工单解决或工单关闭）。
约定等待客户、等待供应商或等待已批准变更窗口的时间怎么处理。
约定按事件还是按工单统计，重复工单和误报是否剔除。
按优先级分别报告，不要只给一个混合数字，免得 P4 的小请求稀释 P1 的重大故障。
在平均值旁边同时给出中位数和最慢的一例。
把定义和数字放在同一份文档里。

想把这些报告和背后的优先级定义对应起来，可读严重程度与优先级的区别。当故障大到需要单独流程时，请看重大事件管理流程。关于可用性规划中的恢复环节，可参考RTO 与 RPO。

在哪里可以看到博迅公开的服务等级？

我们对各优先级承诺的响应目标在 SLA 页面公开，页面上也说明了 8×5 和 24×7 两种服务窗口。管理型IT外包服务方案与按人头定价展示了管理型IT外包服务的公开价目，并标明合同约定的服务时段内紧急事件 15 分钟首次响应，方便你在联系我们之前先做比较。如果想了解哪种服务等级和报告方式适合你的业务，欢迎联系我们。