平均服务恢复时间

通常认为，平均服务恢复时间（MTTR）来源于服务等级协议（Service Level Agreements，SLAs）中的关键指标之一。

最早始于1980年代后期，由宽带服务运营商在其提供的服务等级水平中使用。

如今，随着SLAs在其他行业中的广泛使用，MTTR的应用范围也扩展到金融，工商业，服务业以及IT界的物联网，云计算等各个不同领域。

平均服务恢复时间（MTTR）会对企业的业务服务水平产生重大影响。

大型企业的IT团队需要在提高服务水平的同时降低成本，而事件响应时间变得极为重要。MTTR不是一个单纯的数字，它是一个强有力的指标，表明企业在响应和解决潜在的并可能导致高昂代价的问题时，能有多迅速。

系统停服时间长短对企业的生产力、盈利能力和客户信誉有着直接的影响。

系统或组件服务发生故障时。

MTTR计算方法

MTTR的计算方法是，以月为单位，将故障导致的总停服时间除以故障总数。

例如，如果一个系统每月发生3次故障并且这些故障导致总共6小时的停服时间，则MTTR为2小时。

MTTR = 6小时/3次故障 = 2小时

根据故障的严重程度，修复可能需要几分钟甚至几天的时间，但IT系统的MTTR通常以小时表示。

计算MTTR时需要记住的两个假设：

1. 通常，每个故障实例的严重程度都不同，因此虽然有些故障需要几天才能修复，但其他故障可能只需要几分钟。因此，MTTR为您提供了预期的平均值。

2. 重要的是，每个故障实例都应由合格且经过适当培训的维护人员按照标准化流程进行处理。这确保了结果的可靠性。

MTTR计算考虑了从事件开始到系统或组件恢复服务之间的时间段。一般包括如下内容：

1. 通知运维人员

2. 诊断问题

3. 解决问题

4. 重新组装、校准和验证服务

5. 重置、测试和启动系统或组件

MTTR 的四个阶段

1. 识别 - 从发生故障到技术人员意识到问题的时间段。自动探测和警报系统之类的东西是缩短MTTR识别时间的好方法。

2. 探明 - 确定故障后但开始维修之前的时间段。找出或诊断问题通常是MTTR中最耗时的部分。

3. 修复 - 实际修复问题所需的时间。通过标准化流程来指导负责解决问题的训练有素的技术人员，可以减少解决问题所需的时间。

4. 验证 - 确保应用的修复确实有效所需的时间。实时监控系统是一种有用的工具，可以快速收集数据和报告以显示修复工作正常。

诊断故障原因是MTTR最耗时的工作。事实上，据统计，80%的MTTR用于找出导致系统或组件失败的原因。记录、管理和拥有系统设备分类账目，包括维护计划、维修/更换组件以及设备监控系统的历史记录，这对于快速缩小可能的故障原因至关重要。在发生故障的情况下，在拨打电话、召开会议和发生错误诊断时会浪费关键时间，从而导致修复失败。

在相同的故障场景中，拥有适当的文档和资产历史记录可以让您快速检查可能导致故障的所有因果因素。管理人员可以查看维护日历以了解设备是否一直得到维护，查看设备上次维修或更换部件的时间，并查看该特定设备过去在哪里出现问题。

1. 如何缩短MTTR？

如果MTTR很长，导致原因会因组织而异（需要对实际IT流程和程序进行详细评估），但是通过以下6个步骤，去缩短MTTR似乎对任何企业都有用。

1. 了解真实事件：
   为了缩短MTTR，您应该做的第一件事是对真实事件和故障有一个很好的了解。借助现代企业软件，您可以自动聚合孤立的数据以计算可靠的MTTR，并获得针对这一重要指标的原因分析和宝贵见解。

2. 彻底监控：
   要解决问题，您必须及时识别它，越早发现，越有效。使用合适的监控解决方案，有关系统性能的实时数据始终可以无缝获取，并且在易于理解的仪表盘界面中一揽子显示。通常情况下，如果问题持续存在，您将收到警报通知。

3. 制定行动计划：
   资源不足的小型组织通常需要灵活，但大公司应遵循更严谨的程序和惯例。因此，通常需要使用传统的ITSM技术明确定义角色和响应。经历过全面数字化转型的公司可能具有更大的灵活性，例如使用跨部门协作工具为每个事件构建个性化响应。无论您的预案是什么，都应明确在事件发生时通知谁、如何记录事件以及您的IT团队在着手解决问题时将采取哪些步骤措施等等，必须要确定。

4. 自动化事件管理机制：
   为了缩短MTTR，快速响应的第一步是确保正确的人员快速获得有关问题的准确信息。如果在营业时间内发生低优先级事件，您可以致电负责人。但是如果网站在周五晚上8点钟宕机了怎么办？定位相关负责人并手动逐个联系他们太耗时了。这时候自动化事件管理系统可以通过多种渠道（包括电话、微短信和电子邮件等等）一次向所有指定收件人发送警报，从而为您节省大量时间。

5. 指定响应团队和角色：
   明确定义角色和职责对于有效的事件管理和缩短MTTR至关重要。组织类型取决于不同企业的业务需求，但ITIL提供了一个具有以下角色的框架。

   • 事故经理：推动事件管理流程并根据需要进行调整和改进的角色。ITIL表示，中小型组织基本上可以将此角色分配给服务经理兼任，而大公司则可以将其设置为单独的角色。事故经理主要负责管理事故管理系统和实施事故管理流程。此外，他还是响应团队的负责人，向管理层报告KPI（关键绩效指标），并管理初级和次级支持。

   • 主要（1级）支持：此角色负责给最终用户提供点到点联络从而报告服务中断。负责对事件进行分类并努力尽快恢复失败的服务。主要支持角色无法解决的事件，必须从主要支持小组转发给适当的二级支持人员，并跟踪监控补救活动，实时向用户通知事件的进展状态。

   • 二级（2级）支持：二级支持技术人员通常比一级支持更有临场经验。因此，他们将要处理主要支持们无法解决的事件。二级支持响应人员还负责与第三方软件和硬件供应商进行交互，以快速恢复正常的服务。

   • 在更为庞大、复杂跟敏感的系统环境中，可能还需要一个具有更高级技能和知识的三级（3级）支持小组。

   没有必要严格按照以上框架建立事件响应团队。但是，无论如何组织这个团队，指名一名负责监督事件响应并与团队内外干系人密切沟通的领导，并且所有团队成员都清楚自己的职责，是必需的。

6. 对多个角色的团队成员进行交叉培训：
   专业专家的存在对事件团队至关重要。然而，大材小用般的依靠这些专家来解决相对琐碎的问题可能会让人不知所措，专家将因其而导致主要职责表现不佳，最终会精疲力尽。更为严重的是，事件发生时如果没有专家，可能会伤害响应团队。

结合使用上述方法可以缓解这些问题，从而缩短MTTR。这意味着所有团队成员都对系统有深入的了解，并接受过培训，可以承担多种职责和事件响应角色。这样，无论出现问题时谁接电话，都会比以往更有效率。

2. 还有哪些其他常用的故障指标？

• 平均检测时间(Mean Time To Detect，MTTD)：从发生问题到检测到问题的平均时间。MTTD指示的时间段是直到IT团队收到故障单，MTTR的测量从这一时间点开始。

• 平均调查时间(Mean Time To Investigate，MTTI)：从发现IT事件到组织开始调查原因和解决方案之间的平均时间。从MTTD到MTTR开始的时间段。

• 平均修复时间(Mean Time To Repair，MTTR)：修复和恢复故障系统所需的平均时间。MTTR是衡量可修复组件和服务的可维护性的指标。根据目标设备和问题的复杂性，MTTR可以是分钟、小时或天的值。

• 平均服务恢复时间(Mean Time to Restore Service，MTRS；Mean Time To Recovery 或者 Mean Time To Restore，MTTR)：从检测到事件到目标系统或组件再次可供用户使用的平均经过时间。(本文阐述对象)

• 平均故障间隔时间(Mean Time Between Failures，MTBF)：一个设备或系统从发生故障到发生下一个故障的平均正常运行时间。它用于预测系统和组件的可靠性和可用性。通过跟踪系统和组件故障之间的正常运行时间来计算该指标，以便及时维修或者更换系统组件。

• 平均无故障时间(Mean Time To Failure，MTTF)： MTTF是设备或系统出现故障之前的平均预期正常运行时间。IT团队通常会花费数天或数周的时间观察系统组件以收集这些数据。与MTBF类似，但MTTF通常用于可更换项目，例如磁带阵列备份驱动器；而MTBF常用于可修复&可更换的项目，例如。

• 系统事件间隔平均时间(Mean Time Between System Incidents，MTBSI)：两次连续事件之间的平均经过时间。一般通过将MTBF和MTRS(MTBSI=MTBF+MTRS)相加来计算。

故障指标示意图：

1. https://cio-wiki.org/wiki/Mean_Time_to_Repair_(MTTR)

2. https://en.wikipedia.org/wiki/Mean_time_to_repair

3. https://www.fiixsoftware.com/maintenance-metrics/mean-time-to-repair-maintenance/

4. https://www.atlassian.com/incident-management/kpis/common-metrics

5. https://www.reliableplant.com/mttr-31713

欢迎补充