4. SLO 目标定义：为 Kubernetes 工作负载定义合理的 SLO 目标

为 Kubernetes 工作负载定义 SLO（Service Level Objective）是 SRE 实践的核心环节。合理的 SLO 不是凭空设定的数字，而是基于用户旅程、系统容量、业务成本与错误预算共同推导出的可量化承诺。本章将系统讲解如何为 K8s 工作负载定义如 99.9% 可用性这类 SLO 目标。

4.1 SLO 定义的三层模型

在 Kubernetes 环境中，SLO 定义需要从用户视角出发，逐层分解。我们推荐使用“用户旅程 → 黄金信号 → 聚合指标”的三层模型：

4.2 定义 SLO 的六步流程

以下是为 Kubernetes 工作负载定义合理 SLO 的标准化步骤：

1. 识别关键用户旅程 — 列出工作负载对外提供的核心 API 或功能入口。
2. 选择 SLI 指标 — 从黄金信号中选取可测量的指标（如请求成功率、P95 延迟）。
3. 设定初始目标值 — 基于历史数据或行业基准（如 99.9%、99.99%）。
4. 计算错误预算 — 确定可接受的故障时间窗口（如 99.9% 对应每月 43.2 分钟）。
5. 对齐业务与成本 — 评估达到该 SLO 所需的冗余、监控、运维投入。
6. 迭代优化 — 通过定期 SLO 回顾会议调整目标值。

4.3 常见 K8s 工作负载的 SLO 参考值

不同工作负载类型对可用性的敏感度不同。以下表格给出了典型场景的 SLO 参考范围：

4.4 SLO 与错误预算的关系

定义 SLO 的同时必须配套错误预算（Error Budget）机制。错误预算 = 1 - SLO，代表在给定时间窗口内允许的故障总量。当错误预算耗尽时，应触发“冻结新功能发布，优先修复稳定性”的流程。

4.5 SLO 定义决策流程

下图展示了从业务需求到最终 SLO 数值的完整决策流程：

4.6 定义 SLO 的代码示例

以下是一个使用 Prometheus 记录 SLI 并计算 SLO 的典型配置片段：

# Prometheus recording rule: 计算 5 分钟窗口内的请求成功率
- record: job:slo_request_success_rate:ratio_rate5m
  expr: |
    sum(rate(http_requests_total{status=~"2..|3.."}[5m]))
    /
    sum(rate(http_requests_total[5m]))
    * 100

# 告警规则：当 SLO 接近边界时触发警告
- alert: SLOViolation
  expr: |
    job:slo_request_success_rate:ratio_rate5m < 99.9
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "SLO 违规：请求成功率低于 99.9%"

4.7 定义 SLO 的常见陷阱

• 陷阱一： 使用基础设施指标代替用户指标。例如用“节点 CPU 使用率”而非“API 响应延迟”。
• 陷阱二： 对所有工作负载使用统一 SLO。不同重要性的服务应有差异化目标。
• 陷阱三： 忽略错误预算的消耗速率。即使总预算未耗尽，短时间内大量消耗也应触发告警。
• 陷阱四： SLO 定义后从不回顾。业务变化后，SLO 应随之调整。