2. SLO 目标设定：如何为不同服务设定合理的 SLO 目标，错误预算的概念与计算
2.1 从 SLI 到 SLO：定义可靠性基线
SLO（Service Level Objective，服务等级目标）是围绕 SLI（Service Level Indicator，服务等级指标）设定的具体目标值。它不是“尽可能高”，而是“足够好”——在用户满意与运维成本之间找到平衡点。
核心公式：
SLO = SLI 的阈值 + 时间窗口
例：过去 30 天内，99.9% 的请求延迟 ≤ 200ms。
SLO = SLI 的阈值 + 时间窗口
例：过去 30 天内，99.9% 的请求延迟 ≤ 200ms。
设定 SLO 时，必须明确三个要素：
- 指标（What）：选择哪个 SLI（延迟、错误率、吞吐量、饱和度）。
- 阈值（How good）：具体数值（如 99.9%、200ms）。
- 窗口（When）：评估周期（滚动 30 天、28 天、7 天）。
2.2 错误预算：可靠性的“货币”
错误预算（Error Budget）是 SLO 的衍生概念，它将抽象的可靠性目标转化为可量化的“失败额度”。
错误预算 = 100% - SLO
例如：SLO = 99.9%，则错误预算 = 0.1%。这意味着在评估窗口内，服务最多允许 0.1% 的请求失败。
例如：SLO = 99.9%，则错误预算 = 0.1%。这意味着在评估窗口内，服务最多允许 0.1% 的请求失败。
错误预算的核心价值在于：
- 决策依据：预算充足时，可以放心发布新功能；预算耗尽时，必须冻结变更、优先修复稳定性。
- 量化风险：将“系统是否稳定”的模糊判断，转化为“还剩多少失败额度”的精确数字。
- 对齐团队：开发团队与 SRE 团队基于同一份预算进行协作，避免“开发追求速度，SRE 追求稳定”的对立。
2.3 错误预算计算与消耗模型
错误预算的计算基于滚动时间窗口，常见窗口为 30 天。以下为计算示例：
| 参数 | 值 | 说明 |
|---|---|---|
| SLO 目标 | 99.9% | 可用性目标 |
| 错误预算 | 0.1% | 允许失败的比例 |
| 窗口总请求数 | 10,000,000 | 30 天内总请求量 |
| 总错误预算 | 10,000 | 10,000,000 × 0.1% |
| 已消耗错误 | 6,000 | 当前窗口内实际失败数 |
| 剩余错误预算 | 4,000 | 10,000 - 6,000 |
| 预算消耗率 | 60% | 6,000 / 10,000 |
常见误区：错误预算不是“每天重置”，而是滚动窗口。今天的失败会影响未来 30 天的预算余额，直到该请求滑出窗口。
2.4 不同服务的 SLO 设定策略
并非所有服务都需要 99.99% 的可用性。SLO 应与服务的业务价值、用户容忍度、成本成正比。以下为典型服务的 SLO 建议：
| 服务类型 | 推荐 SLO | 错误预算（30天） | 用户容忍度 | 典型场景 |
|---|---|---|---|---|
| 核心支付/交易 | 99.99% | 0.01%（约 4.3 分钟） | 极低 | 银行转账、订单扣款 |
| 用户认证/登录 | 99.95% | 0.05%（约 21.6 分钟） | 低 | SSO、OAuth 服务 |
| 核心 API/微服务 | 99.9% | 0.1%（约 43.2 分钟） | 中等 | 商品查询、订单列表 |
| 推荐/搜索 | 99.5% | 0.5%（约 3.6 小时） | 较高 | 首页推荐、搜索结果 |
| 日志/监控/非关键 | 99.0% | 1.0%（约 7.2 小时） | 高 | 内部审计、调试日志 |
2.5 SLO 设定流程：四步法
- 识别关键用户旅程：找出对用户影响最大的核心链路（如“登录→搜索→下单→支付”）。
- 选择关键 SLI：为每个旅程选择 1-2 个最能反映用户体验的指标（如“下单接口的 P99 延迟”）。
- 设定初始 SLO：基于历史数据（过去 1-3 个月）的 P99/P95 值，取略高于当前表现的目标。
- 迭代调整：运行 1-2 个窗口后，根据错误预算消耗速度、用户反馈、业务需求进行微调。
经验法则：初始 SLO 不要定得太高。从 99.9% 开始，逐步向 99.95%、99.99% 演进。过高的 SLO 会导致频繁告警和无效的运维投入。
2.6 SLO 与错误预算的关系图
以下 SVG 展示了 SLO、错误预算、时间窗口之间的核心关系：
2.7 多层级 SLO 架构
在微服务架构中，单一 SLO 往往不够。建议采用分层 SLO 体系，从用户视角逐层分解：
2.8 设定 SLO 的常见陷阱
| 陷阱 | 表现 | 后果 | 正确做法 |
|---|---|---|---|
| 追求完美 | 所有服务 SLO 设为 99.999% | 成本爆炸，频繁误告警 | 按业务重要性分级设定 |
| 忽略长尾 | 只关注平均延迟，忽略 P99 | 用户体验差，但指标好看 | 使用 P95/P99 作为 SLI |
| 窗口过短 | 使用 1 小时或 1 天窗口 | 预算波动剧烈，难以决策 | 使用 28-30 天滚动窗口 |
| 静态不变 | SLO 设定后从不调整 | 脱离实际业务需求 | 每季度复盘并微调 |
| 忽略依赖 | 只设定自身 SLO，不考虑下游 | 上游达标，下游拖垮整体 | 建立依赖链 SLO 级联 |
2.9 实践建议：从零开始设定 SLO
快速启动清单：
1. 选择 1 个核心用户旅程（如“用户下单”）。
2. 提取 2 个 SLI（成功率 + P99 延迟）。
3. 基于过去 30 天数据，取 P95 值作为初始 SLO。
4. 计算错误预算，设置 80% 消耗告警阈值。
5. 运行 2 周后，根据告警频率和用户反馈调整。
1. 选择 1 个核心用户旅程（如“用户下单”）。
2. 提取 2 个 SLI（成功率 + P99 延迟）。
3. 基于过去 30 天数据，取 P95 值作为初始 SLO。
4. 计算错误预算，设置 80% 消耗告警阈值。
5. 运行 2 周后，根据告警频率和用户反馈调整。
记住：SLO 不是合同，而是沟通工具。它的目的是让团队在“多快发布”和“多稳运行”之间做出有数据支撑的决策。错误预算则是这个决策的量化仪表盘。