📚 课程目录第1章 MTTR基础概念

1. MTTR 基础概念：定义、区别与核心地位

在 SRE 与平台工程实践中，MTTR（Mean Time to Repair，平均修复时间）是衡量故障恢复速度的核心指标。它直接决定了服务中断对用户的影响时长，也是值班台（On-Call）性能调优的首要优化对象。

1.1 MTTR 定义

MTTR 指从系统发生故障到完全恢复服务所花费的平均时间。在平台工程语境下，MTTR 覆盖从告警触发、故障确认、根因定位、修复实施到验证恢复的完整闭环。

  MTTR 计算公式：

  MTTR = 总修复时间 ÷ 故障次数

  其中“修复时间”通常从告警确认时刻开始计算，至服务恢复正常为止。

阶段	说明	典型耗时占比
告警确认	值班人员收到告警并确认故障	5% – 10%
故障定位	分析日志、指标、链路追踪，确定根因	40% – 60%
修复实施	执行回滚、扩容、配置变更或代码修复	20% – 30%
验证恢复	确认服务指标恢复正常，告警消除	5% – 10%

平台工程视角：MTTR 优化的最大杠杆在于缩短“故障定位”阶段。通过标准化可观测性数据、构建自动化诊断流水线，可将定位时间从小时级压缩到分钟级。

1.2 MTTR 与 MTBF / MTTF 的区别

这三个指标常被混淆，但分别衡量可靠性的不同维度。下表清晰对比三者的定义与关注点：

指标	全称	定义	关注点	优化方向
MTTR	Mean Time to Repair	平均修复时间	恢复速度	缩短故障处理流程
MTBF	Mean Time Between Failures	平均故障间隔时间	系统稳定性	提升代码质量与架构韧性
MTTF	Mean Time to Failure	平均无故障时间（不可修复系统）	组件寿命	硬件选型与冗余设计

常见误区：部分团队将 MTBF 与 MTTF 混用。对于可修复系统（如微服务实例），应使用 MTBF；对于不可修复组件（如一次性传感器），才使用 MTTF。SRE 场景下绝大多数系统为可修复系统，MTBF 是更常用的稳定性指标。

三者关系可通过以下公式理解：

系统可用性 = MTBF / (MTBF + MTTR)

示例：
- 若 MTBF = 720 小时（30天），MTTR = 1 小时
  可用性 = 720 / (720 + 1) ≈ 99.86%
- 若 MTTR 缩短至 0.5 小时
  可用性 = 720 / (720 + 0.5) ≈ 99.93%

可见，即使 MTBF 不变，降低 MTTR 也能直接提升系统可用性。

1.3 MTTR 在 SRE 中的核心地位

在 SRE 的四大黄金信号（延迟、流量、错误、饱和度）之外，MTTR 是衡量故障响应效率的关键运营指标。其核心地位体现在以下三个层面：

直接影响用户体验：MTTR 越长，用户受影响时间越长，直接导致流失与品牌声誉损失。
决定 SLA/SLO 达成率：可用性计算公式中 MTTR 是分母项，缩短 MTTR 是提升可用性最直接的手段。
衡量平台工程效能：值班台的自动化程度、可观测性建设水平、变更管理成熟度，最终都体现在 MTTR 上。

  平台工程核心主张：通过构建内部开发者平台（IDP），将故障诊断与修复能力产品化、自助化，使值班人员从“救火队员”转变为“流程管理者”，系统性降低 MTTR。

1.4 平台工程对 MTTR 的重新定义

传统 SRE 将 MTTR 视为值班人员的个人技能指标。平台工程视角下，MTTR 被重新定义为平台能力指标：

自动化修复率：平台能否自动执行常见故障的修复操作？
诊断链路完整性：从告警到根因的链路是否被平台工具链覆盖？
变更回滚速度：平台是否提供一键回滚或灰度发布能力？

实践建议：在值班台仪表盘中，将 MTTR 拆解为“定位时间”和“修复时间”两个子指标，分别设定 SLO。通常定位时间应占 MTTR 的 60% 以内，若超过则优先优化可观测性建设。