跳至主要内容

什么是平均修复时间(MTTR)?

什么是平均修复时间(MTTR)?

平均修复时间(MTTR)是一项指标,用于衡量 IT 团队响应和修复中断的 IT 服务、系统或软件组件所花费的平均时间。任何 IT 系统都可能由于网络中断、软件错误、系统过载、自然灾害和其他未知原因而出现故障。MTTR 是指从故障发生到系统恢复完全运行之间的时间。其中包括检测故障、诊断原因和解决问题所花费的时间。

为什么 MTTR 很重要?

该图在时间轴上显示了 MTTR 以及 MTTD 和 MTBF 等相关指标。

平均修复时间是用于评估软件和系统的可靠性和可用性的标准性能指标。计划外停机时间的每一秒都可能影响生产力、成本并影响客户满意度。

组织可以通过缩短在修复过程中花费的平均时间来帮助避免这些不良的副作用。MTTR 越长表示可靠性和可用性越高,这是能够按用户预期运行的高性能软件和系统的必备品质。

通常为反映可靠性和可用性而跟踪的其他指标包括平均故障间隔时间(MTBF)、平均检测时间(MTTD)和正常运行时间(时间百分比)。这些指标与 MTTR 一起,在内部用作绩效指标,在外部用来向客户提供质量保证。

如何使用 MTTR?

MTTR 指标源自机械领域,用于衡量一件机械或一个部件通常需要多长时间才能修复。从这个意义上讲,它仍在使用,但现在扩展到基于软件的系统。

定义软件性能

在软件中,平均修复时间与正常运行时间、稳健性以及错误检测和恢复有关。该指标与其他指标相结合,可以衡量基于质量的两个关键性能指标:可靠性和可用性。这些指标量化了软件提供商和客户之间的服务交付质量。

服务水平指标(SLI)是衡量理想系统值的定量指标。

服务水平目标(SLO)为衡量的 SLI 设定目标值。

服务水平协议(SLA)是法律合同,概述了 SLO 以及未满足时的补偿条款。

MTTR 通常是 SLA 中的关键 SLI。例如,给定服务的 SLO 可能为 48 小时 MTTR,而可观测的 MTTR 可能为 24 小时,这意味着 SLA 已明显得到满足。如果未满足 SLO,则客户有权获得赔偿。

MTTR 是如何计算的?

平均修复时间表明修复程序可以使系统正常运行。计算 MTTR 的常用公式是修复时间/修复次数。停机时间是必不可少的,但不用于 MTTR 计算,因为系统恢复时失效转移系统可能已就位。在计算 MTTR 时,时间间隔也很重要。如果给定时间段太短,跟踪 MTTR 将无法准确反映实际情况。

MTTR 不是一项标准化衡量标准;提供商决定如何定义“修复”窗口。MTTR 时钟通常从修复准备工作开始时开始,在系统完全恢复时停止。但是,无论系统的上线日期如何,一些组织都只会跟踪从修复开始到测试完成的时间。

其他计算

在事件管理中,缩写 MTTR 也可以指平均恢复时间、平均响应时间或平均解决时间。

平均响应时间从检测到事件时开始,一直持续到系统完全运行为止。

平均解决时间从故障发生之时(检测之前)开始,直到问题完全解决,以后再也不会出现问题。

这些指标都可以在事件跟踪和报告中报告。确保在正确的位置报告正确的指标对于避免混乱至关重要。

优化 MTTR 的策略有哪些?

构建质量更高的软件,侧重于以预防作为缩短 MTTR 的一种方法。重构代码、更新旧组件以及根据性能选择新架构都可以提高软件质量。高质量的软件性能良好,不需要修复。

但是,即使在实施了最佳实践之后,由于团队无法控制的因素,也可能会出现产品或系统故障。要优化 MTTR,请实施以下措施。

降低系统复杂性

随着系统的增长和扩展,部件之间的复杂性和互连性也会增加。不幸的是,当出现问题时,这会导致修复时间延长。

维护团队需要在故障排除、研究根本原因和遵循漫长而复杂的逆向工程过程方面花费更多修复时间。重构系统和提供微服务式架构可以缩短平均修复时间。

可重复的恢复程序

通过遵循事件管理行动手册进行响应和恢复,并恢复以前的运营,组织可以节省手动确定行动方针的时间。这种方法需要在每次发生故障时进行预先规划,并将吸取的新经验教训纳入行动手册中。

更多资源

技术人员、运营成员、开发人员或维护团队修复系统组件的速度越快,平均修复时间就越短。这可以通过多种方式实现,包括:

  • 提升技能
  • 提供更强大的工具
  • 雇用更多团队成员。

通过为团队提供正确的资源,帮助他们提高效率,进而缩短 MTTR。

正确的报告

绩效指标只有在准确、及时、用于适当环境并与最佳配对指标一起使用时,才会发挥更大作用。确定平均修复期的不同起点和终点至关重要。您应该在内部准确地报告 MTTR,并通过实时控制面板和定期报告向客户报告。

缩短 MTTR 面临哪些挑战?

下文列出了团队在缩短 MTTR 时面临的一些常见挑战。

流程和工具

不成熟的事件管理流程会对 MTTR 产生不利影响。团队需要响应计划和行动手册,需要自动化来启动失效转移系统,以及帮助确定问题根本原因的工具。组织可以通过完善故障、修复流程和工具开始修复问题。现在,借助机器学习能力,组织可以更轻松地根据过去的类似事件创建文档和响应行动手册。

预算

当产品或系统出现故障时修复问题是一回事。但是,从一开始就将质量纳入系统和服务需要人才、战略、精心架构的系统、即代码方法、衡量标准和明确的管理。为了取得积极的结果,组织必须投入必要的时间和金钱。即使是熟练的团队也需要资源投资,从而进一步缩短 MTTR 并持续改进。

遗留代码和系统

由于感觉构建新系统的成本太高,旧系统通常在应有的使用时间之后很久还在继续使用。但是,修复问题所花费的成本和时间可能会超过构建新系统的成本。组织在使用遗留代码和系统时应慎重考虑成本风险比。

不可靠的服务提供商

系统需要可靠的基础设施才能正常运行。从长远来看,投资于 SLA 不佳的不可靠第三方会增加您的 MTTR。选择像 AWS 云服务这样的可靠服务提供商来满足您的 IT 基础设施要求对于 MTTR 来说更好。

AWS 如何帮助满足您的 MTTR 要求?

使用 AWS 上的监控和可观测性服务,您能够随时了解您的技术堆栈中正在发生的事情。您可以在云、混合或本地环境中的网络、基础设施和应用程序中收集、关联、聚合和分析遥测数据。

深入了解您的系统,更快地发现问题并缩短 MTTR。使用人工智能和机器学习来主动反应、预测和预防问题。例如,您可以使用:

立即创建免费账户,开始在 AWS 上进行 MTTR 跟踪和优化。

Browse all cloud computing concepts

Browse all cloud computing concepts content here:

正在加载
正在加载
正在加载
正在加载
正在加载

Did you find what you were looking for today?

Let us know so we can improve the quality of the content on our pages