1. MTTR 复盘口径概述
在分布式系统故障管理中，MTTR（Mean Time to Repair，平均修复时间）是衡量团队故障响应与恢复效率的核心指标。当系统架构从单体演进为微服务，一次用户请求可能穿越数十个服务实例、数百个网络调用，传统基于日志或单机指标的排查方式已无法满足快速定位根因的需求。分布式链路追踪技术——以 Jaeger 为代表——正是为填补这一空白而生。
1.1 MTTR 在分布式链路追踪中的核心价值
MTTR 的经典计算公式为：
MTTR = (故障发现时间 + 故障定位时间 + 故障修复时间 + 故障验证时间) / 故障次数在分布式环境下，故障定位时间往往占据 MTTR 的 60%–80%。链路追踪通过以下三个维度直接压缩定位时间：
| 维度 | 传统方式痛点 | 链路追踪价值 |
|---|---|---|
| 调用拓扑可视化 | 依赖人工梳理服务依赖关系，容易遗漏或过时 | 自动生成实时服务调用拓扑，一眼识别故障传播路径 |
| 请求级根因定位 | 日志分散在多个服务，需要跨系统关联时间戳 | 通过 TraceID 串联完整请求链路，精准定位异常 Span |
| 性能瓶颈量化 | 只能看到服务级平均延迟，无法区分慢调用来源 | 每个 Span 记录耗时，快速识别慢服务、慢数据库或慢外部调用 |
关键认知： MTTR 复盘不是事后追责，而是通过链路数据还原故障现场，找到系统薄弱环节，从而驱动架构改进与运维自动化。Jaeger 提供的 Trace 数据是 MTTR 复盘中最客观、最完整的证据链。
1.2 Jaeger 在故障排查中的角色定位
Jaeger 是 CNCF 毕业的分布式追踪系统，在故障排查场景中承担以下四个核心角色：
- 数据采集器： 通过 Jaeger Agent 或 OpenTelemetry Collector 接收来自各服务的 Span 数据，完成采样与上报。
- 存储与索引引擎： 支持 Cassandra、Elasticsearch、Kafka 等后端，提供海量 Trace 数据的持久化与快速检索。
- 可视化分析平台： Jaeger UI 提供 Trace 详情、服务拓扑、延迟分布、火焰图等视图，支持按服务、操作、标签、时间范围过滤。
- 故障复盘数据源： 通过 Jaeger Query API 或 gRPC 接口，可被外部复盘系统（如告警平台、AIOps 平台）集成，形成自动化复盘流水线。
1.3 MTTR 复盘口径的构成要素
基于 Jaeger 的 MTTR 复盘，需要从以下五个维度采集数据并形成复盘报告：
- 故障发现时间： 从故障发生到第一个告警触发的时间差。Jaeger 可结合 Service Graph 的异常检测或自定义告警规则。
- 故障定位时间： 从告警触发到确定根因 Span 的时间。这是 Jaeger 的核心价值区间，通过 Trace 详情、错误 Span 高亮、标签过滤等手段加速。
- 故障修复时间： 从确定根因到执行修复操作的时间。Jaeger 可提供受影响的服务列表与调用链，辅助评估修复范围。
- 故障验证时间： 从修复完成到确认系统恢复正常的时间。Jaeger 的实时 Trace 流可用于验证修复效果。
- 复盘改进项： 基于 Trace 数据识别出的代码缺陷、配置错误、资源瓶颈、依赖故障等，形成可落地的改进清单。
实践建议： 在 Jaeger 中为关键业务接口配置 自定义采样策略（如基于错误率或延迟阈值的头采样），确保故障期间的 Trace 数据完整保留，避免因采样丢失关键证据链。
1.4 Jaeger 数据模型与 MTTR 的映射关系
Jaeger 的核心数据模型包括 Trace、Span、SpanContext、Baggage 等。下表展示了这些模型如何支撑 MTTR 复盘中的具体问题：
| Jaeger 数据模型 | MTTR 复盘问题 | 使用方式 |
|---|---|---|
| Trace | 故障影响范围有多大？涉及哪些服务？ | 按 TraceID 检索完整调用链，统计受影响的服务数与请求数 |
| Span | 哪个服务/哪个操作耗时异常？错误码是什么？ | 按延迟降序或错误标记排序 Span，定位根因 Span |
| SpanContext | 故障是否跨进程传播？上下游依赖是否正常？ | 通过 ParentSpanID 构建调用树，分析故障传播路径 |
| Tags / Logs | 故障时的上下文信息（如请求参数、数据库语句、异常堆栈） | 在根因 Span 中查看 Tags 和 Logs，获取详细错误上下文 |
| Service Graph | 服务间的依赖关系是否发生变化？是否存在单点依赖？ | 对比故障前后的 Service Graph，识别新增或异常的依赖边 |