📚 课程目录第1章课程导论

1. 课程导论：什么是 MTTR、为什么 Tempo 查询延迟是影响 MTTR 的关键因素、课程目标与受众

在 SRE 与可观测性实践中，MTTR（Mean Time to Resolve，平均恢复时间） 是衡量系统从故障发生到完全恢复所需时间的黄金指标。它直接决定了故障对业务的影响时长，也是团队响应效率与系统韧性的综合体现。

MTTR 通常被拆解为三个子阶段，每个阶段都有独立的优化空间：

  关键认知： 大多数团队 60% 以上的 MTTR 消耗在 MTTI（定位阶段）。Tempo 查询延迟直接影响的就是这个阶段——查询越慢，工程师定位根因的时间越长，MTTR 越差。

Grafana Tempo 作为分布式追踪后端，其核心价值是让工程师通过 TraceID、服务名、标签等维度快速检索请求链路。当系统出现性能劣化或错误时，工程师的第一反应往往是：“查一下这条请求的完整链路”。此时，Tempo 的查询延迟直接决定了定位速度。

以下对比表展示了不同 Tempo 查询延迟场景下对 MTTR 的实际影响：

场景	Tempo 查询延迟（P99）	MTTI 典型耗时	MTTR 估算	影响等级
理想	< 1s	2 – 5 min	5 – 10 min	低
可接受	1 – 5s	5 – 15 min	10 – 25 min	中
劣化	5 – 30s	15 – 45 min	25 – 60 min	高
不可用	> 30s 或超时	> 60 min	> 90 min	严重

常见误区： 很多团队只关注 Tempo 的存储容量和采样率，却忽略了查询延迟。实际上，查询延迟每增加 1 秒，在故障场景下可能导致 MTTR 增加 3 – 5 分钟（因为工程师会反复执行查询、调整过滤条件、对比多个 Trace）。

下面这张流程图展示了 Tempo 查询延迟在故障响应流程中的位置与放大效应：

本课程旨在帮助 SRE、平台工程师与可观测性负责人系统性地评估并优化 Tempo 查询延迟，从而显著降低 MTTR。课程不局限于理论，而是提供可落地的诊断方法、压测工具链与调优策略。