定义
MTTR（Mean Time To Repair）即平均修复时间，衡量从故障发生到恢复的平均时长，是运维核心指标。设备管理平台通过 Work Order、Remote Diagnosis、Fault Knowledge Base 等能力降低 MTTR。
计算与统计
MTTR = 总修复时间 / 故障次数。修复时间通常从告警产生或工单创建起，至设备恢复、工单关闭止。设备管理平台可从 Event Stream 事件流、Work Order 工单系统自动统计；支持按产品、区域、故障类型等维度聚合。与 MTTD（平均检测时间）、MTBF（平均故障间隔）等指标配合，可全面评估运维效率。MTTR 是 SLA 服务等级协议的核心承诺指标之一。
与 DMP 的优化手段
降低 MTTR 的关键在于快速发现、快速定位、快速修复。平台通过实时告警、Remote Diagnosis 远程诊断、Log Collection 日志采集缩短定位时间；通过 Fault Knowledge Base 故障知识库、RCA 根因分析提升处理效率；通过 Remote Maintenance 远程维护减少现场出差。工单自动创建、智能派单、升级策略可进一步压缩响应与修复时长。
应用场景
适用于运维 KPI 考核、SLA 达成评估、持续改进分析。MTTR 是衡量设备管理平台运维能力的重要指标，缩短 MTTR 可提升客户满意度与业务可用性。
修复时长从哪一个时刻起算
平均修复时间是一段累计的修复耗时除以故障次数。它是统计结果，不是某一台设备的实时状态。关键在于分子和分母怎么取。起点可以是故障发生、告警产生、工单创建或人员到场，终点可以是设备恢复上报、业务确认可用或工单关闭。这几个时刻之间往往隔着等待、派工和复核，选哪一段，数字的含义就完全不同。计算前必须把起点和终点写成同一条规则，并在图表上注明。次数也应有定义：抖动的同一告警算一次还是多次，并入同一工单的多台设备算一台还是多台。没有这些约定，两个班组的数字不能相减，也不能拿来说明谁更快。它描述的是已经发生的修复，不描述尚未关闭的积压；把未完成的单按“到现在为止”算进平均，会让数字每天变长，失去比较意义。运维中心看板上的这个数，应和工单系统使用同一套关闭规则。
哪些数字可以放在一起比
可以比较的前提，是产品范围、故障定义和起止规则都相同。远程能恢复的通信闪断，和必须到场更换部件的故障，时长分布差得很远，混在一个平均数里会互相掩盖。计划内维护引起的离线不应算进故障次数，否则窗口越严格执行，数字越难看，形成错误激励。等待备件、等待许可和实际动手的时间若业务上要分开管理，就应分成几段耗时，而不是只留一个总和。样本太少的周期不宜和全年数字比高低。跨时区的工单要用同一时间基准计算间隔。告警自动复归但工单未关时，要规定以哪一个为准，避免同一事件在故障诊断统计和工单统计里各算各的。公开或考核这个数字之前，应能抽查几张单，手工复核起止时刻是否符合规则。
把等待和未关闭都算进或都不算
规则没写清时，有人从告警算到恢复上报，有人从开单算到关单，两套数同时出现在相邻报表里。关单动作拖延，会把已经恢复的设备继续算在修复时间里；相反，告警一复归就自动关单，会把尚未确认的抖动算成极短的修复。重复打开的同一故障若每次都计入分母，次数被放大，平均值被拉低，看起来“更快”了。把计划停机、升级重启和真实故障放进同一个分母，比较失去对象。未填写恢复时间的单被当成零时长或被直接丢弃，两种处理会把平均值推向相反方向。用日历时间减去夜间无人值守，却不说明，和全时钟表放在一起时会被说成效率差异。只公布平均值、不看少数极长的单，个别长时间停机在数字上几乎看不见。