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

1. MTTR 基础概念：定义、重要性及与 MTBF/MTTF 的区别

MTTR（Mean Time To Repair，平均修复时间） 是衡量系统从故障发生到完全恢复所消耗平均时间的核心指标。在 Kubernetes 语境下，MTTR 覆盖从节点或 Pod 进入异常状态开始，到集群调度器、自动化恢复机制或人工操作将其修复并重新提供服务的完整时间窗口。

  MTTR 计算公式：

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

  其中“修复时间” = 故障发现时间 + 故障定位时间 + 故障恢复时间 + 验证时间

Kubernetes 集群的节点异常直接影响工作负载可用性。MTTR 直接决定了 SLO（Service Level Objective）的达成率，也是 SRE 团队核心考核指标之一。在 Kubernetes 环境中，MTTR 的重要性体现在以下四个维度：

维度	说明	典型影响
可用性	节点异常导致 Pod 驱逐，MTTR 越长，服务中断时间越长	直接影响 99.9%/99.99% SLO
成本	异常节点持续占用云资源但无法承载业务负载	云资源浪费、额外人工介入成本
稳定性	长 MTTR 可能引发级联故障（如 etcd 过载、控制平面压力）	集群雪崩风险增加
运维效率	MTTR 反映自动化恢复能力和排障流程成熟度	团队 On-Call 压力、故障复盘质量

SRE 最佳实践： 在 Kubernetes 集群中，MTTR 应拆解为“检测时间”、“决策时间”、“执行时间”和“验证时间”四个子阶段分别度量，才能精准定位瓶颈。

这三个指标共同构成系统可靠性评估的“铁三角”，但各自关注不同阶段：

指标	全称	定义	Kubernetes 场景示例	关注点
MTBF	Mean Time Between Failures	两次故障之间的平均正常运行时间	节点从上次恢复后到再次进入 NotReady 状态的时间间隔	系统稳定性、故障频率
MTTF	Mean Time To Failure	系统首次发生故障前的平均运行时间（不可修复系统）	一次性节点（如 Spot 实例）从启动到被回收的时间	系统寿命、不可逆故障
MTTR	Mean Time To Repair	从故障发生到完全恢复的平均时间	节点 NotReady → 自动 cordon → 驱逐 Pod → 修复 → 重新调度完成	恢复速度、自动化程度

三者之间的关系可以通过以下公式表达：

可用性 = MTBF / (MTBF + MTTR)

其中：
- MTBF 越高 → 系统越稳定
- MTTR 越低 → 恢复越快
- 两者共同决定最终可用性

常见误区： 部分团队将 MTBF 和 MTTF 混用。在 Kubernetes 中，节点通常属于“可修复系统”，应使用 MTBF 而非 MTTF。MTTF 仅适用于不可修复组件（如一次性 Spot 实例、临时存储卷等）。

为了精确复盘节点异常 MTTR，需要将其拆解为四个子阶段。每个阶段都有独立的优化策略：

检测时间（Detection Time）：从节点实际异常到监控系统发出告警的时间。受监控周期、Node Problem Detector 配置、Prometheus 采集间隔影响。
定位时间（Diagnosis Time）：从告警触发到确定根因的时间。依赖日志聚合、事件分析、节点健康检查脚本。
恢复时间（Recovery Time）：从确定根因到节点恢复正常状态的时间。包括自动修复脚本执行、kubelet 重启、节点排水与重新加入集群。
验证时间（Verification Time）：从节点恢复完成到确认业务流量正常的时间。依赖就绪探针、自定义健康检查、流量灰度验证。

  复盘口径建议： 在 Kubernetes 节点异常复盘时，应分别记录上述四个子阶段的耗时，并计算各自占比。通常“定位时间”占比最高（40%~60%），是 MTTR 优化的首要目标。

在 Kubernetes 节点异常复盘时，三个指标需要联合分析才能完整评估集群健康度：

复盘建议： 在 Kubernetes 节点异常复盘报告中，应同时展示 MTBF 趋势和 MTTR 趋势曲线。如果 MTBF 持续下降但 MTTR 保持不变，说明故障频率在增加，需要排查基础设施层；如果 MTBF 稳定但 MTTR 上升，说明恢复流程出现退化。