1. SLO 与 MTTR 基础概念
在 SRE 实践中，SLO（Service Level Objective，服务等级目标）与 MTTR（Mean Time to Repair，平均修复时间）是衡量系统可靠性与故障响应效率的两大核心支柱。SLO 定义了用户可接受的服务质量边界，而 MTTR 则决定了当边界被突破后，系统恢复的速度。两者共同构成了 SRE 运维的闭环：设定目标 → 度量偏差 → 快速修复 → 复盘优化。
1.1 SLO 定义：可靠性的量化契约
SLO 是 SRE 团队与产品、业务方共同协商后，为服务设定的一个具体、可量化的可靠性目标。它不是“99.999%”这样的数字，而是基于用户体验和业务成本权衡后的承诺。SLO 通常以“在某个时间窗口内，SLI 达到某个阈值”的形式表达。
SLO = 目标阈值（如 99.9%） + 时间窗口（如 30 天滚动）
示例：过去 30 天内，请求延迟 P99 ≤ 200ms 的占比 ≥ 99.9%。
1.2 SLI 与错误预算：SLO 的度量与弹性
SLI（Service Level Indicator，服务等级指标）是 SLO 的原始数据来源。常见的 SLI 包括：
- 延迟（Latency）：请求响应时间，通常关注 P50、P95、P99。
- 流量（Traffic）：系统每秒处理的请求数（RPS）或吞吐量。
- 错误（Errors）：请求失败率，如 HTTP 5xx 占比。
- 饱和度（Saturation）：资源使用程度，如 CPU、内存、连接池占用率。
错误预算（Error Budget）是 SLO 的衍生概念，定义为 1 - SLO。例如，SLO 为 99.9%，则错误预算为 0.1%。这个预算代表了服务在时间窗口内允许“犯错”的总量。当错误消耗接近预算上限时，团队应停止发布新功能，优先投入稳定性建设。
| 概念 | 定义 | 示例 |
|---|---|---|
| SLO | 服务可靠性目标，是承诺 | 99.9% 可用性（30 天滚动） |
| SLI | 实际测量的指标，是数据 | 请求成功率 99.95% |
| 错误预算 | 允许失败的总量，是弹性空间 | 0.1% × 总请求数 |
1.3 MTTR 在 SRE 中的核心地位
MTTR（Mean Time to Repair）是衡量从故障发生到服务完全恢复所需平均时间的指标。在 SRE 体系中，MTTR 直接决定了故障对用户的影响时长，是 SLO 违约后最关键的恢复指标。MTTR 通常包含以下阶段：
- 检测时间（MTTD）：从故障发生到被监控系统或人工发现的时间。
- 响应时间：从告警触发到 SRE 开始介入的时间。
- 定位时间：从介入到确定根因的时间。
- 修复时间：从确定根因到服务完全恢复的时间。
MTTR 的优化直接关系到 SLO 违约的严重程度。一次 SLO 违约的持续时间越长，消耗的错误预算越多，对用户信任和业务收入的冲击也越大。
1.4 SLO 与 MTTR 的关系：违约与恢复的闭环
下图展示了 SLO 违约发生后，MTTR 各阶段如何影响错误预算的消耗，以及如何通过复盘口径优化形成正向循环。
1.5 MTTR 复盘口径：从数据到洞察
MTTR 复盘口径是指在对 SLO 违约事件进行事后分析时，所采用的统一数据查询与计算标准。一个规范的复盘口径应包含：
- 时间边界：违约开始时间、结束时间、告警触发时间、人工确认时间。
- 指标对齐：复盘时使用的 SLI 数据源必须与 SLO 监控面板一致。
- Trace 采样：在违约窗口内，选取具有代表性的 Trace 样本用于根因分析。
- 维度标签：按服务、集群、版本、地域等维度拆解 MTTR 各阶段耗时。
# 查询违约窗口内 P99 延迟异常的 Trace
{ resource.service.name = "checkout-service" }
|> latency > 200ms
|> status = error
|> span.db.system = "redis"
|> by(service.version, k8s.cluster.name)
|> count() > 100通过建立标准化的复盘口径，SRE 团队可以确保每次故障复盘的结论可对比、可复现，从而持续优化 MTTR，守住 SLO 底线。