2、SLO基础：服务等级目标定义、SLI与SLO的关系、常见的Kubernetes SLO指标

2.1 从SLI到SLO：可观测性驱动的承诺模型

在Kubernetes自愈场景中，SLO（Service Level Objective，服务等级目标）是衡量系统是否“健康”的黄金标尺。它不是一个孤立的数字，而是建立在SLI（Service Level Indicator，服务等级指标）之上的量化承诺。理解SLI与SLO的关系，是设计自愈触发策略的前提。

2.2 SLI与SLO的关系：四象限决策矩阵

SLI是“测量什么”，SLO是“承诺多少”。两者通过燃烧速率（Burn Rate）和错误预算（Error Budget）形成闭环。下表清晰展示了SLI与SLO在自愈场景中的角色差异：

2.3 常见的Kubernetes SLO指标分类

Kubernetes环境的SLO指标可归纳为可用性、性能、可靠性和资源饱和度四大类。以下是生产环境中常用的指标清单：

• 可用性类：
  • API Server 请求成功率（2xx/5xx比例）
  • Pod Ready 状态比例（Ready / Desired）
  • Endpoint 可用性（Endpointslices 健康比例）
• 性能类：
  • 请求延迟（P50/P90/P99，单位ms）
  • Pod 启动时间（从Pending到Running）
  • Service 响应时间（通过Ingress或Service Mesh测量）
• 可靠性类：
  • Pod 重启频率（CrashLoopBackOff次数/小时）
  • 节点NotReady持续时间
  • 持久卷挂载失败率
• 资源饱和度类：
  • CPU 使用率（Request/Limit比例）
  • 内存使用率（OOM Killer事件频率）
  • 磁盘IO等待时间（PVC性能）

2.4 SLO指标与自愈触发的关系图

下图展示了SLI采集、SLO评估与自愈动作之间的典型流程。该图适用于理解“基于SLO的事件触发验证”的完整链路：

2.5 SLO定义的最佳实践：从指标到阈值

定义有效的SLO需要遵循“可测量、可达成、有意义”三原则。以下是一个面向Kubernetes工作负载的SLO定义模板：

# SLO 定义示例：关键业务API
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: api-slo-rules
  namespace: production
spec:
  groups:
  - name: slo-rules
    rules:
    # SLI: 请求延迟P99
    - record: job:request_latency_seconds:p99
      expr: histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))
    # SLO: P99 ≤ 0.2秒，30天窗口内达标率99.9%
    - alert: HighLatencySLO
      expr: job:request_latency_seconds:p99 > 0.2
      for: 5m
      labels:
        severity: critical
        slo: "99.9"
      annotations:
        summary: "API P99延迟超过SLO阈值"

2.6 燃烧速率与错误预算：SLO的动态守护者

在自愈场景中，仅靠静态阈值触发往往不够灵敏。燃烧速率（Burn Rate）和错误预算（Error Budget）提供了动态视角：

• 错误预算 = 1 - SLO：例如99.9% SLO对应0.1%的错误预算（30天内允许约43分钟故障）。
• 燃烧速率 = 实际错误率 / 允许错误率：当燃烧速率超过1时，表示错误消耗速度超过预期。
• 多窗口燃烧速率告警：通常设置1小时（高燃烧）和6小时（低燃烧）两个窗口，避免瞬时抖动导致误触发。

下表展示了不同燃烧速率下的自愈响应策略：

2.7 自愈场景中的SLO指标选择矩阵

不同的自愈场景需要关注不同的SLO指标。以下矩阵帮助你在测试设计时快速定位：