📚 课程目录第4章 SLO目标设定与阈值设计

4. SLO 目标设定与阈值设计：为蓝绿发布设定合理的 SLO 阈值

蓝绿发布的核心风险在于流量切换瞬间的负载冲击与版本兼容性问题。若 SLO 阈值设置过松，会掩盖真实故障；设置过严，则会导致频繁误告警与不必要的回滚。本章将系统讲解如何为蓝绿发布设计分层的 SLO 阈值体系，包括硬性阈值、软性阈值与多窗口策略。

4.1 SLO 目标设定的核心原则

在设定阈值前，需明确 SLO 的 三个层级：

层级	定义	蓝绿发布场景示例
SLI（服务等级指标）	可量化的测量指标	请求延迟 P99、错误率、吞吐量
SLO（服务等级目标）	SLI 的目标值	P99 延迟 ≤ 200ms，错误率 ≤ 0.1%
SLA（服务等级协议）	对外承诺的底线	月度可用性 ≥ 99.95%

实战建议：蓝绿发布的 SLO 应比 SLA 严格 2-5 倍。例如 SLA 要求 99.9% 可用性，则发布期间的 SLO 应设为 99.95% 以上，为故障响应预留缓冲时间。

4.2 硬性阈值与软性阈值设计

阈值设计需区分 硬性阈值（Hard Threshold） 与 软性阈值（Soft Threshold），二者在蓝绿发布中承担不同角色：

类型	触发行为	蓝绿发布中的用途	示例值
硬性阈值	立即触发回滚或阻断流量	保护用户免受严重故障影响	错误率 > 1%，P99 延迟 > 500ms
软性阈值	触发告警、观察窗口、渐进式降级	提前发现异常趋势，避免误回滚	错误率 > 0.3%，P99 延迟 > 300ms

避坑提示：不要将硬性阈值设得过于接近正常波动范围。建议基于历史基线数据，取 均值 + 3σ 作为硬性阈值，均值 + 1.5σ 作为软性阈值。

4.3 多窗口阈值策略

单一时间窗口的阈值容易受瞬时抖动影响。多窗口策略通过组合不同粒度的窗口，提升检测的鲁棒性。以下是蓝绿发布中推荐的 三窗口模型：

4.4 蓝绿发布 SLO 阈值配置示例

以下是一个生产环境可用的阈值配置模板（基于 Prometheus + Alertmanager）：

# 蓝绿发布 SLO 阈值配置
groups:
  - name: blue_green_slo
    rules:
      # 软性阈值：短窗口 10s，错误率 > 0.3%
      - alert: BlueGreenErrorRateSoft
        expr: |
          rate(http_requests_total{status=~"5..",deploy="green"}[10s])
          / rate(http_requests_total{deploy="green"}[10s]) > 0.003
        for: 10s
        labels:
          severity: warning
          threshold_type: soft
        annotations:
          summary: "Green 环境错误率软性阈值触发"

      # 硬性阈值：长窗口 5min，错误率 > 1%
      - alert: BlueGreenErrorRateHard
        expr: |
          rate(http_requests_total{status=~"5..",deploy="green"}[5m])
          / rate(http_requests_total{deploy="green"}[5m]) > 0.01
        for: 1m
        labels:
          severity: critical
          threshold_type: hard
        annotations:
          summary: "Green 环境错误率硬性阈值触发，执行回滚"

      # P99 延迟软性阈值
      - alert: BlueGreenLatencySoft
        expr: |
          histogram_quantile(0.99,
            rate(http_request_duration_seconds_bucket{deploy="green"}[1m])
          ) > 0.3
        for: 1m
        labels:
          severity: warning
          threshold_type: soft

      # P99 延迟硬性阈值
      - alert: BlueGreenLatencyHard
        expr: |
          histogram_quantile(0.99,
            rate(http_request_duration_seconds_bucket{deploy="green"}[5m])
          ) > 0.5
        for: 30s
        labels:
          severity: critical
          threshold_type: hard

4.5 阈值调优的基线方法

阈值不能凭空设定，必须基于历史数据。推荐以下 三步调优法：

采集基线：在蓝绿发布前，持续采集 Green 环境空载/低负载时的 SLI 数据至少 24 小时。
计算统计值：计算 P50、P95、P99、均值、标准差（σ）。
设定阈值：
- 软性阈值 = P99 或均值 + 1.5σ
- 硬性阈值 = 均值 + 3σ 或 P99.9

案例：某电商平台在蓝绿发布前采集到 Green 环境错误率基线为 0.02%（均值），σ=0.05%。则：
软性阈值 = 0.02% + 1.5×0.05% = 0.095% → 取整 0.1%
硬性阈值 = 0.02% + 3×0.05% = 0.17% → 取整 0.2%

实际配置时，考虑到发布期间的负载波动，可再增加 50% 的缓冲，即软性 0.15%，硬性 0.3%。

4.6 阈值设计的常见误区

误区	后果	正确做法
硬性阈值设得过于宽松	故障扩散到全部用户	基于基线 + 3σ 设定，定期复审
软性阈值与硬性阈值差距过小	频繁误回滚	软硬阈值至少相差 2-3 倍
只使用单一时间窗口	无法区分瞬时抖动与持续故障	采用多窗口策略（10s/1min/5min）
忽略发布期间的流量变化	阈值在高峰期失效	按时间段（峰/谷）设置不同阈值

4.7 多窗口阈值与自动恢复的联动

阈值设计最终要服务于自动恢复。以下是蓝绿发布中阈值与恢复动作的 联动矩阵：

4.8 总结：阈值设计检查清单

区分软硬阈值：软性用于告警，硬性用于回滚。
多窗口覆盖：至少使用 3 个时间窗口（10s/1min/5min）。
基线驱动：阈值基于历史数据统计，而非拍脑袋。
联动恢复：阈值触发后必须有明确的自动恢复动作。
定期复审：每次发布后复盘阈值合理性，持续调优。