1. SLO 基础概念：服务等级目标

在可靠性工程中，服务等级目标（Service Level Objective, SLO） 是衡量服务健康度的核心量化指标。它不是一个简单的“可用性”百分比，而是定义了在特定时间窗口内，服务应达到的、可测量的性能或可用性阈值。SLO 是连接用户期望与工程投入的桥梁，也是后续误差预算计算与复盘策略调整的基石。

1.1 SLO 与 SLA、SLI 的关系

要理解 SLO，必须先厘清它与 服务等级协议（SLA） 和 服务等级指标（SLI） 的层级关系。这三者构成了可靠性度量的金字塔结构：

1.2 SLO 在可靠性工程中的核心地位

SLO 不是简单的数字，而是整个可靠性工程的决策锚点。它决定了团队如何分配精力、何时触发应急响应、以及如何评估变更风险。以下是 SLO 在可靠性工程中的四大核心作用：

• 量化用户满意度： 将模糊的“系统稳定”转化为具体的、可追踪的指标，如“99.5% 的请求在 1 秒内完成”。
• 驱动误差预算机制： SLO 定义了“好”与“坏”的边界，从而计算出误差预算（Error Budget），即服务允许“不达标”的时间或比例。这是本课程后续所有动态调整策略的基础。
• 指导运维优先级： 当误差预算充足时，团队可以更积极地发布新功能；当预算紧张时，应优先投入稳定性工作，暂停高风险变更。
• 统一团队语言： 开发、运维、产品、管理层围绕 SLO 进行沟通，避免因“系统是否稳定”这类主观判断产生分歧。

1.3 SLO 定义的三要素

定义一个有效的 SLO 需要明确以下三个要素：

1. 指标（What）： 选择哪个 SLI？例如：请求成功率、延迟 P95、吞吐量。
2. 目标（How Good）： 阈值是多少？例如：≥ 99.9%、≤ 200ms。
3. 时间窗口（When）： 在什么周期内衡量？例如：滚动 30 天、日历月、季度。

一个完整的 SLO 定义示例：
“在滚动 30 天的时间窗口内，99.5% 的 HTTP GET 请求的响应时间不超过 300 毫秒。”

1.4 SLO 与 MTTR 复盘的内在联系

本课程的核心命题是“利用 SLO 误差预算驱动 MTTR 复盘口径的动态调整”。理解 SLO 是理解这一策略的前提：

• SLO 定义了“严重性”： 只有消耗了误差预算的故障才需要被纳入复盘范围。未消耗预算的轻微抖动，可能不需要触发完整的复盘流程。
• 误差预算消耗速率决定了复盘优先级： 如果一次故障消耗了 50% 的月度预算，其复盘优先级远高于消耗 1% 预算的事件。
• 复盘口径随预算状态动态变化： 当预算充足时，复盘可以更宽松、更关注长期改进；当预算紧张时，复盘必须更严格、更聚焦于立即止血。