📚 课程目录第3章 MTTR复盘口径定义

3、MTTR复盘口径定义：故障发现时间(TTD)、故障确认时间(TTI)、故障定位时间(TTF)、故障修复时间(TTR)

在 Kubernetes 节点异常场景下，MTTR（Mean Time To Repair，平均修复时间）是衡量运维效率与集群稳定性的核心指标。然而，若不对 MTTR 进行精细化的阶段拆解，复盘时往往陷入“修了多久”的笼统结论，无法定位瓶颈环节。本节目的是将 MTTR 拆解为四个标准时间口径：TTD、TTI、TTF、TTR，并给出每个阶段的起止定义、典型场景与复盘数据来源。

3.1 四阶段时间轴定义

下图展示了从节点异常发生到完全恢复的完整时间轴，以及四个关键时间点的位置关系：

3.2 各阶段详细定义与复盘口径

阶段	全称	起止定义	复盘数据来源	典型瓶颈
TTD	Time To Detect 故障发现时间	T0（异常发生）→ T1（告警触发）	监控系统告警记录、Prometheus Alertmanager 日志	监控缺失、告警阈值过高、采集周期过长
TTI	Time To Identify 故障确认时间	T1（告警触发）→ T2（人工确认异常）	值班交接记录、IM/工单系统响应时间戳	告警风暴、误报率高、值班响应延迟
TTF	Time To Find 故障定位时间	T2（确认异常）→ T3（定位根因）	排查操作日志、kubectl describe / logs 时间线	缺乏关联分析、日志分散、知识沉淀不足
TTR	Time To Repair 故障修复时间	T3（定位根因）→ T4（修复完成）	变更记录、kubectl apply / cordon/uncordon 时间戳	修复步骤复杂、依赖人工操作、回滚流程缺失

复盘计算公式：

MTTR = TTD + TTI + TTF + TTR

其中：
  TTD = T1 - T0
  TTI = T2 - T1
  TTF = T3 - T2
  TTR = T4 - T3

注意：T0 通常为估计值，复盘时建议以 T1 作为 MTTR 计算的基准起点，避免因 T0 不可知导致指标失真。

3.3 各阶段在 Kubernetes 节点异常中的典型场景

以下通过一个真实的节点 NotReady 故障案例，展示四个阶段的具体表现：

TTD 场景：kubelet 心跳超时 3 分钟后，Prometheus 触发 NodeNotReady 告警。若监控采集间隔为 30 秒，则 TTD 约 3.5 分钟。
TTI 场景：值班人员收到告警后，登录 Grafana 确认节点状态为 NotReady，并排除是计划内维护。此过程耗时 2 分钟。
TTF 场景：通过 kubectl describe node 查看 kubelet 状态，发现 kubelet 服务异常；进一步 journalctl -u kubelet 定位到磁盘空间不足导致 kubelet 停止。定位耗时 8 分钟。
TTR 场景：执行 kubectl cordon 驱逐 Pod，清理磁盘日志后重启 kubelet，再 kubectl uncordon 恢复调度。修复耗时 5 分钟。

复盘建议：在 Kubernetes 场景下，建议将 TTF 和 TTR 进一步拆解为“人工操作时间”与“系统恢复时间”，以便区分是人的决策慢还是系统恢复慢。例如：TTF_人工 = 排查命令执行时间，TTF_系统 = 日志检索/监控查询延迟。

3.4 四阶段口径在自动恢复策略中的映射

理解 MTTR 拆解口径后，可以针对每个阶段设计对应的自动恢复策略，从而系统性降低 MTTR。下图展示了各阶段与自动恢复动作的映射关系：

3.5 复盘数据采集清单

为了在复盘时准确计算各阶段时间，建议在集群中提前部署以下数据采集点：

阶段	数据采集项	推荐工具/方法
TTD	告警触发时间、告警级别、告警源	Prometheus Alertmanager + Alertmanager 日志
TTI	值班确认时间、告警认领记录	PagerDuty / 飞书/钉钉机器人回调时间戳
TTF	排查命令执行时间、日志检索耗时	kubectl audit log、Loki 查询日志时间戳
TTR	修复操作开始/结束时间、变更审批记录	kubectl events、ArgoCD 部署记录、Operator 日志

常见复盘误区：

将 TTD 与 TTI 合并计算，导致无法区分“监控延迟”与“响应延迟”。
忽略 T0 的估计误差，直接使用告警时间作为异常开始时间，导致 TTD 被低估。
将 TTR 仅计算为“修复命令执行时间”，忽略了 Pod 重新调度、健康检查通过等系统恢复时间。