📚 课程目录第2章 SLO制定原则

2. SLO 制定原则：如何选择关键服务指标，定义合理的 SLO 目标值，避免常见陷阱

SLO 是可靠性运营的锚点。选错指标或定错目标，会导致团队精力浪费、误报频发，甚至让 SLO 沦为数字游戏。本章从指标选择、目标值定义和常见陷阱三个层面，给出可落地的操作原则。

2.1 关键服务指标的选择原则

不是所有指标都适合作为 SLO 的 SLI。选择 SLI 时，应遵循以下四个原则：

原则	说明	反例
用户可见性	指标必须直接反映最终用户的真实体验	服务器 CPU 使用率（用户不感知）
可测量性	指标必须能被精确、持续地采集和计算	“用户满意度”这种主观评分
可区分性	好与坏的边界必须清晰，不能模棱两可	“响应时间较慢”这种模糊描述
业务关联性	指标变化能直接对应业务结果（收入、留存、转化）	数据库连接数（与业务结果弱相关）

实践建议： 优先从用户请求的生命周期中提取 SLI。例如：

可用性： 请求成功返回非 5xx 状态码的比例。
延迟： 请求在特定阈值内完成的比例（如 p99 < 500ms）。
吞吐量： 每秒成功处理的请求数。
完整性： 数据写入后能被正确读取的比例。

2.2 定义合理的 SLO 目标值

目标值不是拍脑袋定的“理想值”，而是基于历史数据和业务容忍度的平衡结果。定义过程分为三步：

收集基线数据： 至少回溯 30-90 天的 SLI 数据，了解当前的真实表现。
确定误差预算： 用 100% - SLO 目标值 计算出允许的不可用时间。
对齐业务容忍度： 与产品、业务方确认“多慢算慢”“多错算错”。

以下是一个典型的 SLO 目标值定义示例：

# 示例：API 服务的 SLO 定义
service: "用户订单 API"
sli:
  - name: "请求可用性"
    measurement: "成功请求数 / 总请求数"
    window: "28 天滚动窗口"
    target: 99.9%  # 允许 0.1% 的失败，约 43 分钟/月
  - name: "请求延迟 (p99)"
    measurement: "p99 延迟 <= 500ms 的请求比例"
    window: "28 天滚动窗口"
    target: 99.0%  # 允许 1% 的慢请求

2.3 常见陷阱与规避策略

即使选对了指标，定义了目标，团队仍可能掉入以下陷阱：

陷阱	表现	后果	规避策略
完美主义陷阱	将 SLO 目标设为 99.999% 甚至 100%	误差预算为零，任何故障都算违规，团队持续高压	根据业务重要性分层：核心链路 99.9%，非核心 99.0%
指标堆砌陷阱	一个服务定义 10+ 个 SLI	监控成本高，告警风暴，团队无法聚焦	每个服务最多 3 个 SLI，优先选择用户最敏感的指标
静态目标陷阱	SLO 目标值一年不变	系统演进后目标不再合理，或过于宽松或过于严格	每季度评审一次，结合业务增长和技术升级调整
平均主义陷阱	使用平均值（如平均延迟）作为 SLI	掩盖长尾问题，用户体验差的请求被平均掉	使用百分位指标（p95、p99）而非平均值
窗口选择陷阱	使用过短（如 1 小时）或过长（如 1 年）的评估窗口	短窗口噪音大，长窗口反应迟钝	推荐 28 天或 30 天滚动窗口，兼顾敏感性和稳定性

关键提醒： SLO 不是 SLA。SLO 是团队内部承诺的目标，用于指导运维决策；SLA 是对外的合同承诺。SLO 可以比 SLA 更严格，但绝不能更宽松。例如：对外 SLA 是 99.9%，对内 SLO 应设为 99.95% 或更高，留出缓冲空间。

2.4 实战案例：电商购物车服务的 SLO 定义

假设我们负责一个电商平台的购物车服务，以下是按照上述原则制定的 SLO：

# 购物车服务 SLO 定义
service: "cart-service"
version: "v2.3"
effective_date: "2025-04-01"

sli_list:
  - name: "添加商品可用性"
    measurement: "HTTP 2xx 响应数 / 总请求数"
    window: "28 天滚动"
    target: 99.95%  # 误差预算：约 20 分钟/月

  - name: "查询购物车延迟 (p95)"
    measurement: "p95 延迟 <= 300ms 的请求比例"
    window: "28 天滚动"
    target: 99.5%   # 误差预算：约 3.4 小时/月

  - name: "数据一致性"
    measurement: "添加后 5 秒内查询一致的比例"
    window: "28 天滚动"
    target: 99.99%  # 误差预算：约 4 分钟/月

  选择理由：

  添加商品可用性： 用户核心操作，直接影响下单转化率。
查询购物车延迟： 用户频繁操作，慢查询会导致用户流失。
数据一致性： 购物车数据必须准确，否则用户会看到错误商品或数量。

  三个指标覆盖了可用性、性能和正确性三个维度，且每个指标都有明确的业务关联。

2.5 小结

选指标： 用户可见、可测量、可区分、业务关联。
定目标： 基于历史基线，计算误差预算，对齐业务容忍度。
避陷阱： 拒绝完美主义、指标堆砌、静态目标、平均主义、窗口选择不当。
持续迭代： SLO 是活的，需要定期评审和调整。