2. 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 是活的，需要定期评审和调整。