MTTR 基础概念：构成要素、关联指标与降低支柱
MTTR（Mean Time to Repair，平均修复时间）是衡量系统从故障发生到完全恢复服务所需平均时间的核心指标。在 SRE 与可观测性实践中，MTTR 直接决定了故障对业务的影响时长，是发布准入与日志检索体系设计的首要优化目标。
2.1 MTTR 的构成要素
MTTR 并非单一时间点，而是由三个连续阶段的时间总和构成：
| 阶段 | 定义 | 典型活动 | 占比（经验值） |
|---|---|---|---|
| 检测时间（Detection） | 从故障发生到被监控系统或人工发现的时间 | 告警触发、日志异常检测、指标阈值突破 | 30% – 50% |
| 诊断时间（Diagnosis） | 从发现故障到定位根因的时间 | 日志检索、链路追踪、指标关联分析 | 30% – 40% |
| 修复时间（Repair） | 从定位根因到服务完全恢复的时间 | 回滚、配置变更、重启、代码热修复 | 10% – 30% |
关键公式： MTTR = Detection Time + Diagnosis Time + Repair Time
在发布准入场景中，检测与诊断时间往往占据 MTTR 的 70% 以上。日志检索体系的优化重点在于压缩这两个阶段，而非仅关注修复动作本身。
2.2 MTTR 与 MTBF / MTTF 的关系
三个指标共同构成系统可靠性的完整评估模型，但关注维度不同：
| 指标 | 全称 | 定义 | 关注点 | 与 MTTR 的关系 |
|---|---|---|---|---|
| MTBF | Mean Time Between Failures | 两次故障之间的平均正常运行时间 | 系统稳定性 | MTBF 越长，系统越稳定；MTTR 越短，恢复越快 |
| MTTF | Mean Time To Failure | 系统从启动到首次故障的平均时间 | 不可修复系统的寿命 | MTTF 适用于不可修复组件；MTTR 适用于可修复系统 |
| MTTR | Mean Time To Repair | 从故障发生到恢复的平均时间 | 故障恢复效率 | MTTR 越短，业务连续性越高 |
实践要点： 在发布准入场景中，MTBF 衡量发布间隔的稳定性，MTTR 衡量故障后的恢复速度。降低 MTTR 可以直接提升系统可用性（Availability = MTBF / (MTBF + MTTR)）。
2.3 降低 MTTR 的三大支柱
在日志检索与发布准入场景中，降低 MTTR 需要围绕三个核心支柱构建能力：
- 快速检测（Detection） — 缩短故障发现时间
- 精准诊断（Diagnosis） — 缩短根因定位时间
- 高效修复（Repair） — 缩短服务恢复时间
支柱一：快速检测
- 建立多维度告警体系（日志错误率、延迟 P99、错误码分布）
- 日志采集延迟控制在 10 秒以内，避免检测盲区
- 发布期间自动触发基线对比检测，发现异常立即告警
支柱二：精准诊断
- 日志结构化与索引优化，支持秒级检索
- 建立故障模式库，通过日志关键词自动关联已知根因
- 链路追踪与日志关联，快速定位故障服务与代码行
支柱三：高效修复
- 发布准入机制：自动阻断异常发布，触发回滚
- 标准化修复剧本（Runbook），一键执行
- 灰度发布与流量切换，最小化修复影响范围
常见误区： 许多团队将 80% 的精力放在修复工具建设上，却忽略了检测与诊断环节。实际上，检测与诊断时间通常占 MTTR 的 70% 以上。日志检索体系的优化应优先压缩检测与诊断时间。
2.4 三大支柱在发布准入中的落地映射
| 支柱 | 发布准入场景能力 | 日志检索支撑 | MTTR 压缩效果 |
|---|---|---|---|
| 快速检测 | 发布后自动对比基线，异常秒级告警 | 实时日志流分析、错误率监控 | 检测时间从分钟级降至秒级 |
| 精准诊断 | 告警自动关联日志与链路，定位根因 | 结构化日志索引、故障模式匹配 | 诊断时间从小时级降至分钟级 |
| 高效修复 | 自动阻断发布、触发回滚或流量切换 | 日志驱动的自动化决策 | 修复时间从分钟级降至秒级 |