3. SLO 目标设定：如何根据业务需求设定合理的 SLO 阈值
服务等级目标（Service Level Objective, SLO）是衡量系统可靠性的核心量化指标。设定合理的 SLO 阈值，本质是在用户体验与运维成本之间寻找平衡点。本章将深入讲解如何根据业务需求确定 SLO 数值，并引入“错误预算”这一关键管理工具。
3.1 业务需求驱动的 SLO 阈值选择
SLO 阈值并非越高越好。99.999%（“五个九”）的可用性意味着全年不可用时间不超过 5.26 分钟，其背后需要投入巨大的冗余架构、多活部署和 7×24 小时值班成本。对于大多数非关键业务，过高的 SLO 反而会造成资源浪费。
以下表格展示了不同 SLO 阈值对应的年度/月度不可用时间，以及典型的适用业务场景：
| SLO 阈值 | 年度不可用时间 | 月度不可用时间 | 典型适用场景 |
|---|---|---|---|
| 99% （两个九） | 3.65 天 | 7.20 小时 | 内部工具、开发环境、非关键报表系统 |
| 99.9% （三个九） | 8.76 小时 | 43.20 分钟 | SaaS 应用、电商平台、企业级 Web 服务 |
| 99.99% （四个九） | 52.56 分钟 | 4.32 分钟 | 金融交易、支付网关、实时通信 |
| 99.999% （五个九） | 5.26 分钟 | 25.90 秒 | 电信核心网、航空管制、医疗生命支持 |
设定建议：从用户可感知的维度出发，而非基础设施维度。例如，对于 API 网关，SLO 应定义为“99.9% 的请求在 200ms 内成功返回”，而不是“服务器 CPU 使用率低于 80%”。
3.2 错误预算（Error Budget）概念
错误预算 = 1 - SLO。它定义了在给定时间窗口内，系统允许出现故障或性能降级的最大“额度”。例如，如果 SLO 设定为 99.9%，那么错误预算就是 0.1%。在一个 30 天的月度窗口内，允许的不可用时间为 43.2 分钟。
错误预算的核心价值在于：
- 量化风险容忍度：将抽象的“可靠性”转化为具体的分钟数或请求数。
- 驱动运维决策：当错误预算充足时，可以更积极地发布新功能或进行架构升级；当错误预算即将耗尽时，应冻结变更，优先恢复稳定性。
- 促进跨团队协作：为开发团队和运维团队提供统一的“预算”语言，避免因发布与稳定之间的冲突。
关键公式：
错误预算 = 1 - SLO
允许的不可用时间 = 时间窗口总时长 × (1 - SLO)3.3 SLO 与错误预算的联动关系
下图展示了 SLO 阈值、错误预算消耗速率与告警触发之间的逻辑关系：
3.4 设定 SLO 阈值的实践步骤
- 识别关键用户旅程：列出用户最常使用的 3-5 个核心流程（如登录、搜索、下单、支付）。
- 定义 SLI（服务等级指标）：为每个旅程选择可测量的指标，例如：
- 可用性：请求成功率 ≥ 99.9%
- 延迟：95% 的请求响应时间 ≤ 200ms
- 吞吐量：每分钟处理订单数 ≥ 1000
- 收集历史基线数据：分析过去 1-3 个月的实际 SLI 表现，了解当前系统的真实可靠性水平。
- 设定初始 SLO：在历史基线基础上，设定一个略高于当前水平但可实现的 SLO。例如，当前可用性为 99.85%，可设定 SLO 为 99.9%。
- 计算错误预算：根据 SLO 计算月度或周度错误预算，并配置告警规则。
- 定期复盘与调整：每季度或每半年根据业务变化和系统演进，重新评估 SLO 的合理性。
常见陷阱：避免设定“完美”的 SLO（如 100%）。100% 的可用性意味着零错误预算，任何变更都可能导致违规，这在实际工程中既不现实也无必要。始终为系统留出合理的容错空间。
3.5 错误预算消耗与告警阈值示例
假设我们为一个支付接口设定了 99.95% 的月度 SLO（30 天），错误预算为 0.05%。以下表格展示了不同消耗速率下的告警策略：
| 错误预算消耗率 | 剩余预算（分钟） | 告警级别 | 建议响应动作 |
|---|---|---|---|
| < 50% | > 10.8 | Info（信息） | 记录日志，无需立即处理 |
| 50% - 80% | 4.3 - 10.8 | Warning（警告） | 排查异常来源，准备回滚方案 |
| 80% - 100% | 0 - 4.3 | Critical（严重） | 立即介入，必要时冻结所有非关键变更 |
| > 100% | 已超支 | P0（最高优先级） | 启动应急响应，SLO 已违反 |
通过将 SLO 与错误预算结合，SRE 团队可以从“被动救火”转变为“主动管理风险”，用数据驱动的方式平衡系统稳定性与业务迭代速度。