3. SLO 设定方法论：三种核心路径
SLO（Service Level Objective）是 Error Budget 策略的起点。设定一个“既不过松导致无意义、也不过紧导致频繁告警”的 SLO，需要系统化的方法论。本章围绕三种主流设定路径展开：用户旅程驱动、历史数据驱动、业务目标驱动。三种方法并非互斥，实际生产中通常组合使用。
核心原则：SLO 不是“系统能跑多快”的宣言，而是“用户能接受多差”的共识。先定义“不可用”，再定义“可用”。
3.1 基于用户旅程的 SLO 设定
用户旅程（User Journey）是从用户视角出发，将一次完整交互拆解为多个关键步骤。SLO 应直接绑定到这些步骤的成败上，而非底层基础设施指标。
设定步骤：
- 绘制核心旅程：识别用户完成一次业务目标所经过的系统节点（如：登录 → 搜索 → 查看详情 → 加入购物车 → 支付 → 订单确认）。
- 定义每个步骤的 SLI：为每个步骤选择最能反映用户体验的指标（如：登录成功率、搜索响应时间、支付成功率）。
- 分配权重与目标：根据步骤对业务的影响程度，分配不同的 SLO 目标（支付步骤的 SLO 通常高于浏览步骤）。
- 计算复合 SLO：通过串联或并联模型，计算整体旅程的可用性。
案例：电商下单旅程 SLO 分解
| 旅程步骤 | SLI 口径 | 权重 | 单步 SLO |
|---|---|---|---|
| 用户登录 | 登录成功率 (5xx + 超时) | 20% | 99.9% |
| 商品搜索 | 搜索结果返回时间 P95 < 2s | 15% | 99.5% |
| 商品详情加载 | 详情页渲染成功率 | 15% | 99.5% |
| 加入购物车 | 加购接口成功率 | 10% | 99.9% |
| 提交支付 | 支付成功率 (含回调) | 30% | 99.99% |
| 订单确认 | 订单状态最终一致性延迟 < 5s | 10% | 99.9% |
复合 SLO 计算（串联模型）： 0.999 × 0.995 × 0.995 × 0.999 × 0.9999 × 0.999 ≈ 98.8%。这意味着即使每个步骤都很高，整体旅程仍可能只有 2 个 9。
3.2 基于历史数据的 SLO 设定
当系统已经运行一段时间，积累了足够的监控数据时，可以通过分析历史表现来设定 SLO。这种方法的核心是“以过去的行为为锚点”，避免设定不切实际的目标。
实施流程：
- 数据采集窗口：至少取过去 30~90 天的 SLI 数据，覆盖业务高峰、低谷、以及已知的故障时段。
- 分位数分析：计算 SLI 的 P50、P90、P95、P99 值，观察分布形态。SLO 通常设定在 P95 或 P99 附近。
- 排除异常点：剔除已知的重大故障窗口（如机房断电、代码回滚），避免“被故障拉低”的 SLO 成为常态目标。
- 设定缓冲区间：在历史 P99 基础上，增加 0.1%~0.5% 的缓冲，为未来增长留出空间。
常见陷阱：直接使用历史数据的“平均值”作为 SLO。平均值会掩盖长尾问题。例如：平均延迟 200ms，但 P99 延迟可能高达 5s。SLO 应基于分位数，而非均值。
历史数据 SLO 设定示例（以 API 成功率为例）：
| 指标 | 过去 30 天 P50 | 过去 30 天 P95 | 过去 30 天 P99 | 建议 SLO |
|---|---|---|---|---|
| API 成功率 | 99.99% | 99.95% | 99.80% | 99.90% |
| API 延迟 (ms) | 120 | 350 | 1200 | P95 < 400ms |
| 数据库查询成功率 | 99.99% | 99.97% | 99.85% | 99.95% |
3.3 基于业务目标的 SLO 设定
这是最高层级的设定方法：SLO 直接服务于业务 KPI。例如：“支付成功率 SLO 必须保证季度营收损失不超过 10 万元”。这种方法将技术指标与财务影响挂钩，便于向管理层解释 SLO 的价值。
转化公式：
业务损失 = 总请求量 × (1 - SLO) × 单次失败平均损失金额
示例：
- 每日支付请求：100 万笔
- 目标 SLO：99.99%
- 单笔失败平均损失：50 元（含客诉、补偿、流失）
- 每日预期损失：1,000,000 × 0.01% × 50 = 5,000 元
- 月度损失：15 万元
若业务要求月度损失 < 5 万元，则 SLO 需提升至 99.997%
业务目标驱动 SLO 设定矩阵
| 业务目标 | 关联 SLI | 可接受损失/影响 | 反推 SLO |
|---|---|---|---|
| 季度营收损失 < 50 万 | 支付成功率 | 单笔损失 50 元 | 99.99% |
| 核心用户流失率 < 0.5% | 登录成功率 | 每次失败流失率 2% | 99.95% |
| 客服工单量 < 1000/月 | 订单最终一致性延迟 | 每延迟 1 分钟产生 0.5 个工单 | P99 < 30s |
| 合规审计通过率 100% | 数据持久化成功率 | 单次失败导致合规扣分 | 99.999% |
3.4 三种方法对比与选择策略
| 维度 | 用户旅程驱动 | 历史数据驱动 | 业务目标驱动 |
|---|---|---|---|
| 适用阶段 | 新系统设计、重构 | 已运行 3 个月以上的系统 | 有明确财务/业务指标 |
| 数据依赖 | 低（依赖业务理解） | 高（依赖监控数据质量） | 中（依赖业务财务模型） |
| 管理层认可度 | 中 | 低（技术视角） | 高（直接关联损益） |
| 调整频率 | 随业务迭代调整 | 季度/半年度重新校准 | 随业务目标变化调整 |
| 风险 | 可能忽略非关键路径 | 可能固化历史低水平 | 可能过于激进导致频繁告警 |
推荐组合策略：
- 新系统上线：以用户旅程驱动为主，快速建立初始 SLO。
- 运行 1 个季度后：引入历史数据驱动，校准 SLO 的合理性。
- 与业务对齐：使用业务目标驱动，将 SLO 转化为财务语言，获取管理层支持。
- 持续迭代：每季度回顾三种方法的结果，取交集或加权平均作为最终 SLO。