4. 多场景 SLO 识别：延迟型、错误率型、吞吐量型、饱和度型

SLO（Service Level Objective）是服务等级目标，是自愈触发策略的核心输入。不同业务场景关注的服务质量维度不同，对应的 SLO 类型也截然不同。本章将四种最常见的 SLO 类型进行结构化拆解，帮助你在 Runbook 参数化设计中准确识别并适配触发条件。

4.1 四种 SLO 类型总览

下表从定义、典型指标、适用场景、触发敏感度四个维度对比四种 SLO 类型，便于快速建立全局认知。

4.2 延迟型 SLO：响应时间的承诺边界

延迟型 SLO 定义的是“在多少毫秒内完成请求的比例”。常见的表述为：“99% 的请求在 200ms 内完成”。

• 分位数选择： p50 反映典型体验，p95 反映长尾用户，p99 反映极端异常。Runbook 参数化时，建议将分位数作为可配置参数。
• 窗口聚合： 延迟指标通常按 1 分钟 / 5 分钟窗口滑动计算，避免瞬时毛刺误触发。
• 自愈触发条件： 当 p99 延迟连续 3 个窗口超过阈值，且错误率未同步上升时，优先触发扩容或缓存预热。

# 延迟型 SLO 参数化示例（YAML 片段）
slo_type: latency
metric: http_request_duration_seconds
aggregation: p99
window: 5m
threshold: 0.2  # 200ms
consecutive_buckets: 3
action: scale_up

4.3 错误率型 SLO：故障的快速探测器

错误率型 SLO 衡量的是失败请求占总请求的百分比。它是自愈系统响应最快的触发信号，因为错误率上升通常意味着服务已经不可用或部分不可用。

• 错误分类： 需要区分客户端错误（4xx）和服务端错误（5xx）。Runbook 通常只对 5xx 或业务自定义错误码触发自愈。
• 基线对比： 错误率阈值应基于历史基线动态设定，而非固定值。例如“当前错误率超过基线 3 倍”作为触发条件。
• 熔断联动： 错误率型 SLO 常与熔断器（Circuit Breaker）配合，在触发自愈前先隔离故障节点。

# 错误率型 SLO 参数化示例
slo_type: error_rate
metric: http_requests_total{status=~"5.."}
aggregation: rate_1m
window: 1m
threshold: 0.05  # 5% 错误率
baseline_mode: dynamic_3x
action: circuit_break

4.4 吞吐量型 SLO：容量与压力的平衡点

吞吐量型 SLO 关注的是服务在单位时间内能处理多少请求或数据。它不直接反映服务质量，但能揭示容量瓶颈和限流需求。

• 指标类型： QPS（每秒查询数）、TPS（每秒事务数）、BPS（每秒字节数）。
• 触发逻辑： 吞吐量下降通常意味着上游限流或下游阻塞；吞吐量突增则可能触发限流自愈。
• 参数化要点： 吞吐量阈值必须与部署规模挂钩。例如“单实例 QPS 超过 5000”作为扩容触发条件，而非全局固定值。

# 吞吐量型 SLO 参数化示例
slo_type: throughput
metric: nginx_requests_per_second
aggregation: avg_1m
threshold: 5000
per_instance: true
action: scale_out

4.5 饱和度型 SLO：资源耗尽的前兆

饱和度型 SLO 衡量的是资源使用接近上限的程度。它是四种 SLO 中唯一不直接反映请求质量的类型，但却是基础设施自愈的核心依据。

• 资源维度： CPU 使用率、内存使用率、磁盘 IO 等待、连接池使用率、文件描述符使用率。
• 预留缓冲： 饱和度阈值通常设定在 70%~80%，预留 20%~30% 的缓冲空间应对突发流量。
• 自愈动作： 资源饱和度触发后，自愈动作通常是垂直扩容、水平扩容或资源回收（如清理临时文件）。

# 饱和度型 SLO 参数化示例
slo_type: saturation
metric: node_cpu_utilization
aggregation: avg_5m
threshold: 0.8  # 80%
resource_type: cpu
action: scale_up_or_evict

4.6 四种 SLO 的识别与选择矩阵

在实际 Runbook 设计中，你需要根据服务类型和故障模式选择 SLO 组合。下表给出了常见服务类型的推荐 SLO 组合。

4.7 四种 SLO 的触发关系图

下图展示了四种 SLO 类型在自愈系统中的触发关系与典型流转路径。理解这个关系图有助于你在 Runbook 中设计正确的触发优先级和联动逻辑。

4.8 多场景 SLO 参数化设计要点

在 Runbook 中实现多场景 SLO 自愈触发，需要将上述四种 SLO 类型抽象为可配置的参数模板。以下是参数化设计的核心要点：

1. 指标源抽象： 将 Prometheus、Datadog、CloudWatch 等指标源封装为统一接口，Runbook 只关心 metric 名称和聚合方式。
2. 阈值动态化： 支持固定阈值、基线倍数、百分位数三种阈值模式，通过参数 threshold_mode 切换。
3. 窗口与连续性： 每个 SLO 类型独立配置 window 和 consecutive_buckets，避免误触发。
4. 动作映射： 定义 SLO 类型到自愈动作的映射表，支持“一类型多动作”和“多类型一动作”两种模式。
5. 优先级与抑制： 当多个 SLO 同时触发时，按错误率 > 延迟 > 饱和度 > 吞吐量的优先级执行，并支持抑制规则。

# 多场景 SLO 参数化模板（完整示例）
slo_definitions:
  - name: api_latency
    type: latency
    metric: http_request_duration_seconds
    aggregation: p99
    window: 5m
    consecutive: 3
    threshold_mode: fixed
    fixed_threshold: 0.2
    actions: [scale_up, cache_warm]

  - name: api_error_rate
    type: error_rate
    metric: http_requests_total{status=~"5.."}
    aggregation: rate_1m
    window: 1m
    consecutive: 2
    threshold_mode: baseline
    baseline_multiplier: 3
    actions: [circuit_break, alert]

  - name: db_saturation
    type: saturation
    metric: node_cpu_utilization
    aggregation: avg_5m
    window: 10m
    consecutive: 2
    threshold_mode: fixed
    fixed_threshold: 0.8
    actions: [scale_up, evict_pods]