SLO 设计实战：从业务目标到技术指标

            ┌─────────────┐
            │  业务目标    │  "我们的服务需要做到什么程度？"
            └──────┬──────┘
                   │
            ┌──────▼──────┐
            │  用户体验    │  "用户关心什么？"
            └──────┬──────┘
                   │
            ┌──────▼──────┐
            │   SLI 定义   │  "我们怎么衡量用户体验？"
            └──────┬──────┘
                   │
            ┌──────▼──────┐
            │  SLO 目标值  │  "这个指标要做到多少？"
            └──────┬──────┘
                   │
            ┌──────▼──────┐
            │  告警与行动  │  "不达标时怎么办？"
            └─────────────┘

用户旅程：电商下单

  浏览商品 → 加入购物车 → 提交订单 → 支付 → 确认

  每一步都映射到一个或多个 SLI：
  
  浏览商品：
    - SLI: 商品页面加载成功率 > 99.95%
    - SLI: 商品页面 P95 加载时间 < 500ms

  加入购物车：
    - SLI: 购物车操作成功率 > 99.9%
    - SLI: 购物车操作 P99 延迟 < 200ms

  提交订单：
    - SLI: 订单提交成功率 > 99.99%
    - SLI: 订单提交 P99 延迟 < 1s

  支付：
    - SLI: 支付成功率 > 99.99%
    - SLI: 支付 P99 延迟 < 2s

# CUJ 优先级矩阵
user_journeys:
  - name: "用户登录"
    business_value: "high"       # 登录失败 → 用户直接流失
    user_sensitivity: "high"     # 用户对登录失败零容忍
    priority: P0
    needs_slo: true

  - name: "商品搜索"
    business_value: "high"       # 搜索影响转化率
    user_sensitivity: "medium"   # 搜索稍慢可以接受
    priority: P1
    needs_slo: true

  - name: "查看订单历史"
    business_value: "medium"
    user_sensitivity: "low"
    priority: P2
    needs_slo: false             # 可用默认 SLO 覆盖

# SLI 规范定义模板
sli_spec:
  name: "支付请求成功率"
  
  # 1. 测量对象
  subject: "payment-service"
  
  # 2. 测量维度
  metric: "成功率"
  
  # 3. 计算方式
  formula: |
    成功请求数 / 总请求数
    成功定义: HTTP 状态码不在 [500, 599] 区间
    排除: 客户端错误 (4xx)、健康检查请求 (/healthz)    
  
  # 4. 测量窗口
  window: "30d"
  
  # 5. 数据来源
  source: "Prometheus http_requests_total metric"

# ❌ 错误：CPU 使用率不是 SLI
sli:
  metric: "CPU 使用率 < 80%"
  why_wrong: "CPU 80% 时用户可能完全无感知，也可能已经严重影响延迟"

# ✅ 正确：从用户视角定义
sli:
  metric: "请求 P99 延迟 < 200ms"
  why_right: "直接反映用户感受到的体验"

# ❌ 错误：全局成功率
sli:
  metric: "所有 HTTP 请求成功率 > 99.9%"
  why_wrong: "健康检查请求和支付请求混在一起，掩盖了关键路径的问题"

# ✅ 正确：按关键路径分别定义
sli:
  metric: "支付 API 成功率 > 99.99%"
sli:
  metric: "商品 API 成功率 > 99.9%"

# ❌ 错误：平均延迟
sli:
  metric: "平均延迟 < 100ms"
  why_wrong: "平均延迟掩盖了长尾——1% 的用户可能等了 5 秒"

# ✅ 正确：使用百分位
sli:
  metric: "P99 延迟 < 200ms"
sli:
  metric: "P95 延迟 < 100ms"

# SLO 校准分析
def calibrate_slo(historical_sli_data, user_satisfaction_threshold):
    """
    historical_sli_data: 过去 90 天的 SLI 数据
    user_satisfaction_threshold: 用户满意度阈值
    """
    # 1. 计算历史 SLI 分布
    p50 = percentile(historical_sli_data, 50)
    p90 = percentile(historical_sli_data, 90)
    p99 = percentile(historical_sli_data, 99)
    p999 = percentile(historical_sli_data, 99.9)
    
    # 2. 找到用户满意度的拐点
    # 用户满意度突然下降的 SLI 值就是 SLO 的下限
    satisfaction_inflection = find_inflection_point(
        historical_sli_data, 
        user_satisfaction_threshold
    )
    
    # 3. SLO 设定在拐点之上，留出安全余量
    suggested_slo = satisfaction_inflection * 1.1  # 10% 安全余量
    
    return {
        "historical_p50": p50,
        "historical_p99": p99,
        "satisfaction_inflection": satisfaction_inflection,
        "suggested_slo": suggested_slo,
        "error_budget": 1 - suggested_slo
    }

Step 1: 确定服务的业务等级
  → L1 核心 / L2 重要 / L3 一般 / L4 辅助

Step 2: 分析历史数据
  → 过去 90 天的 SLI 表现如何？
  → P50 / P95 / P99 分布如何？

Step 3: 识别用户容忍度
  → 用户在什么 SLI 水平下开始投诉？
  → 历史上 SLI 降到多少时业务指标受影响？

Step 4: 选择初始 SLO
  → 基于历史 P99 或 P99.9 表现，设定略高于当前水平的目标
  → 留出足够的错误预算用于发布和创新

Step 5: 试运行验证
  → 设定 4-6 周的试运行期
  → 观察是否可行、是否反映真实用户体验

Step 6: 正式发布与定期评审
  → 试运行通过后正式生效
  → 每月/每季度评审 SLO 合理性

# 新服务 SLO 初始设定策略
new_service_slo_strategy:
  phase_1: "试运行期（前 4 周）"
    action: "只监控不设 SLO，收集基线数据"
    goal: "了解 SLI 的自然分布"
    
  phase_2: "初始 SLO（第 5-8 周）"
    action: "基于基线数据设定保守的 SLO"
    strategy: |
      可用性 SLO = 历史最低可用性 + 0.5%
      延迟 SLO = 历史 P99 × 1.2      
    goal: "验证 SLO 的可行性"
    
  phase_3: "正式 SLO（第 9 周起）"
    action: "根据试运行数据调整并正式发布"
    review_cycle: "每月评审"

# SLO 季度评审模板

## 评审范围
- 服务名称：payment-service
- 评审周期：2026 Q2
- 参与者：SRE 负责人、服务负责人、产品经理

## 当前 SLO
| SLI | SLO 目标 | 实际表现 | 错误预算消耗 |
|-----|---------|---------|-------------|
| 可用性 | 99.95% | 99.97% | 40% |
| 延迟(P99) | <200ms | 185ms | 25% |
| 延迟(P95) | <100ms | 92ms | 10% |

## 评审问题

### 1. SLO 是否反映了用户体验？
- [ ] 用户投诉量是否与 SLO 违规相关？
- [ ] 是否有用户感知到的问题未被 SLI 覆盖？
- 分析：3 月的一次延迟劣化未被 P99 SLO 捕获，但用户有投诉
  → 需要增加 P95 延迟 SLI ✅

### 2. SLO 是否过于宽松或严格？
- [ ] 错误预算是否总是用完？→ 否，消耗 40%
- [ ] 错误预算是否总是剩余很多？→ 可用性预算消耗 40%，延迟预算消耗 25%
- 分析：延迟 SLO 消耗较低，可以考虑收紧
  → 延迟 P99 SLO 从 200ms 收紧到 180ms ⚠️

### 3. 是否需要新增或删除 SLI？
- [ ] 是否有新的关键用户旅程需要覆盖？
- [ ] 是否有不再相关的 SLI？
- 分析：新增了"支付回调延迟"SLI，覆盖支付链路的异步部分
  → 新增 SLI: 支付回调 P99 < 5s ✅

### 4. SLO 的成本是否合理？
- [ ] 维持当前 SLO 的基础设施成本是多少？
- [ ] 提升 SLO 到下一级的成本是多少？
- 分析：从 99.95% 提升到 99.99% 需要多活架构，成本增加 200%
  → 暂不提升，当前 SLO 已满足业务需求 ✅

## 评审结论
- 可用性 SLO：维持 99.95%
- 延迟 P99 SLO：从 200ms 收紧到 180ms
- 新增延迟 P95 SLO：<100ms
- 新增支付回调 SLO：P99 < 5s
- 下次评审：2026 Q3

错误预算消耗率
  │
  ├─ < 25%（长期）
  │   → SLO 可能过于宽松
  │   → 评估是否收紧 SLO
  │   → 或利用富裕预算做创新
  │
  ├─ 25-75%
  │   → SLO 合理
  │   → 维持当前 SLO
  │
  └─ > 75%（长期）
      → SLO 可能过于严格
      → 评估是否放松 SLO
      → 或投入资源提升系统能力

┌──────────────────────────────────────────────────┐
│  用户体验级 SLO（User Experience SLO）              │
│  "用户能不能顺畅地完成关键操作？"                    │
│  → 从用户视角定义，面向业务                         │
└───────────────────────┬──────────────────────────┘
                        │ 分解
┌───────────────────────▼──────────────────────────┐
│  服务级 SLO（Service SLO）                         │
│  "每个服务是否满足其接口契约？"                     │
│  → 从服务间调用视角定义，面向开发                   │
└───────────────────────┬──────────────────────────┘
                        │ 分解
┌───────────────────────▼──────────────────────────┐
│  资源级 SLO（Resource SLO）                        │
│  "底层资源是否健康？"                              │
│  → 从基础设施视角定义，面向 SRE/运维               │
└──────────────────────────────────────────────────┘

# 用户体验级 SLO 示例：电商下单
user_experience_slo:
  journey: "用户下单"
  
  sli_1:
    name: "下单成功率"
    formula: "成功下单数 / 下单请求数"
    target: 99.99%
    window: 30d
    user_impact: "下单失败直接导致交易损失"
    
  sli_2:
    name: "下单端到端延迟"
    formula: "从点击'提交订单'到看到'下单成功'页面的时间"
    target: "P95 < 2s, P99 < 5s"
    window: 30d
    user_impact: "延迟超过 5s 用户可能放弃"
    
  sli_3:
    name: "下单页面可用性"
    formula: "商品页面成功加载次数 / 总访问次数"
    target: 99.95%
    window: 30d
    user_impact: "页面打不开用户直接流失"

# 服务级 SLO 示例：订单服务
service_slo:
  service: "order-service"
  
  sli_1:
    name: "API 可用性"
    formula: |
      非 5xx 响应数 / 总请求数
      排除: /healthz, /metrics      
    target: 99.95%
    window: 30d
    
  sli_2:
    name: "API 延迟"
    formula: "P99 响应时间"
    target: "< 500ms"
    window: 30d
    breakdown:
      - endpoint: "POST /api/orders"
        target: "P99 < 1s"
      - endpoint: "GET /api/orders/{id}"
        target: "P99 < 200ms"
      - endpoint: "GET /api/orders"
        target: "P99 < 500ms"
        
  sli_3:
    name: "消息处理延迟"
    formula: "消息从入队到处理完成的时间"
    target: "P99 < 10s"
    window: 30d

# 资源级 SLO 示例：数据库
resource_slo:
  resource: "order-db (PostgreSQL)"
  
  sli_1:
    name: "数据库可用性"
    formula: "可成功执行 SELECT 1 的时间 / 总时间"
    target: 99.99%
    window: 30d
    
  sli_2:
    name: "查询延迟"
    formula: "P99 查询执行时间"
    target: "< 50ms"
    window: 30d
    
  sli_3:
    name: "复制延迟"
    formula: "从库 lag"
    target: "< 1s"
    window: 30d
    
  sli_4:
    name: "连接池健康"
    formula: "可用连接数 / 总连接数"
    target: "> 30%"
    window: 5m   # 资源级 SLO 通常用更短的窗口

用户体验级：下单成功率 99.99%
    ↑ 依赖
服务级：订单 API 成功率 99.95% + 支付 API 成功率 99.99%
    ↑ 依赖
资源级：数据库可用性 99.99% + 缓存可用性 99.95%

# SLO 级联告签示例
cascade_alerting:
  # 资源级告警：提前预警
  - level: resource
    condition: "数据库连接池使用率 > 80%"
    action: "通知 SRE，不通知业务团队"
    purpose: "在影响服务级 SLO 之前介入"
    
  # 服务级告警：影响正在发生
  - level: service
    condition: "订单 API 错误率 > 0.1%"
    action: "通知 SRE + 服务负责人"
    purpose: "防止影响用户体验级 SLO"
    
  # 用户体验级告警：用户已受影响
  - level: user_experience
    condition: "下单成功率 < 99.99%"
    action: "立即 page，通知全团队 + 管理层"
    purpose: "用户已感知到问题，必须立即恢复"

# Service SLO: payment-service

## 服务概述
- 服务名称：payment-service
- 业务等级：L1（核心）
- 负责团队：支付团队 + SRE 平台团队
- SLO 评审周期：每季度

## 关键用户旅程
1. 用户发起支付 → 支付处理 → 返回结果
2. 支付回调 → 订单状态更新 → 通知用户

## SLI 与 SLO

### SLI-1: 支付 API 可用性
- 定义：非 5xx 响应 / 总请求（排除 /healthz）
- SLO：99.99%（30天窗口）
- 错误预算：4.3 分钟/月
- 数据来源：Prometheus http_requests_total

### SLI-2: 支付 API 延迟
- 定义：P99 响应时间
- SLO：< 2s（30天窗口）
- 数据来源：Prometheus http_request_duration_seconds

### SLI-3: 支付成功率
- 定义：支付成功数 / 支付发起数
- SLO：99.95%（30天窗口）
- 数据来源：业务日志 + 数据库统计

## 告警策略
- 快速消耗：1h 窗口消耗速率 > 14x → 立即 page
- 慢速消耗：6h 窗口消耗速率 > 6x → 工单跟踪
- 预算耗尽：月度预算 100% → 冻结发布

## 依赖关系
- 上游依赖：order-service, user-service
- 下游依赖：payment-db, redis-cluster, 第三方支付网关
- 共享基础设施：API Gateway, Load Balancer

## 历史记录
| 日期 | 变更 | 原因 |
|------|------|------|
| 2026-04-01 | 可用性 SLO 从 99.95% 提升到 99.99% | 业务要求 |
| 2026-05-15 | 新增支付回调延迟 SLI | 覆盖异步链路 |
| 2026-07-01 | 延迟 SLO 从 2.5s 收紧到 2s | 历史表现优于 SLO |

搜索是用户进入商品详情页的前置环节
  → 搜索慢 → 用户放弃浏览 → 交易损失
  → 搜索无结果 → 用户流失
业务目标：搜索体验直接影响 GMV

用户输入关键词 → 搜索请求 → 返回结果 → 用户点击商品

关键体验维度：
  1. 搜索是否可用（可用性）
  2. 搜索是否够快（延迟）
  3. 搜索结果是否相关（正确性/相关性）
  4. 搜索是否有结果（覆盖率）

search_service_sli:
  sli_1:
    name: "搜索 API 可用性"
    formula: "非 5xx 搜索响应 / 总搜索请求"
    target: 99.95%
    
  sli_2:
    name: "搜索 P99 延迟"
    formula: "P99(搜索响应时间)"
    target: "< 300ms"
    
  sli_3:
    name: "搜索 P95 延迟"
    formula: "P95(搜索响应时间)"
    target: "< 100ms"
    
  sli_4:
    name: "零结果率"
    formula: "返回 0 条结果的搜索 / 总搜索"
    target: "< 5%"
    note: "零结果率反映搜索质量，不是技术指标但影响用户体验"

# 基于历史数据校准
historical_data = {
    "availability_p50": 99.98,
    "availability_p99": 99.93,
    "latency_p99_avg": 250,  # ms
    "latency_p99_max": 450,  # ms
    "zero_result_rate_avg": 3.2,  # %
}

# SLO 设定
slo = {
    "availability": 99.95,       # 略低于 P50，留出预算
    "latency_p99": 300,          # 略高于平均，可达成
    "latency_p95": 100,          # 较严格，驱动优化
    "zero_result_rate": 5,       # 允许一定比例的零结果
}

平台级 SLO（面向用户）
  ├── 下单成功率 > 99.9%
  ├── 搜索可用性 > 99.95%
  └── 支付成功率 > 99.95%
      │
      ├── order-service SLO
      │   ├── API 可用性 > 99.95%
      │   └── API P99 < 500ms
      │       │
      │       ├── order-db SLO
      │       │   ├── 可用性 > 99.99%
      │       │   └── 查询 P99 < 50ms
      │       │
      │       └── redis SLO
      │           ├── 可用性 > 99.95%
      │           └── 命中率 > 90%
      │
      ├── payment-service SLO
      │   └── ...
      └── inventory-service SLO
          └── ...

平台级：下单成功率 99.9%
  = order-service(99.95%) × payment-service(99.95%) × inventory-service(99.95%)
  = 0.9995^3 = 0.9985 = 99.85%
  → 不满足 99.9% 的平台级 SLO！
  
  需要：每个服务至少 99.97% → 0.9997^3 = 0.9991 = 99.91% ✅

# Prometheus + Grafana SLO 监控
slo_monitoring:
  prometheus_rules:
    # SLO 达成率
    - record: slo:availability:rate30d
      expr: |
        sum(rate(http_requests_total{status!~"5.."}[30d]))
        /
        sum(rate(http_requests_total[30d]))        
    
    # 错误预算消耗
    - record: slo:error_budget:consumed:rate30d
      expr: |
        1 - (slo:availability:rate30d / 0.9999)        
    
    # 剩余错误预算
    - record: slo:error_budget:remaining:ratio
      expr: |
        1 - (slo:error_budget:consumed:rate30d / (1 - 0.9999))        
  
  grafana_dashboards:
    - "SLO 概览看板"
      panels:
        - "当前 SLI 值 vs SLO 目标"
        - "错误预算消耗趋势"
        - "SLO 达成历史"
        - "按服务分组的 SLO 状态"

# slo-spec.yaml - SLO 规范即代码
apiVersion: sre/v1
kind: ServiceSLO
metadata:
  name: payment-service-slo
  service: payment-service
spec:
  window: 30d
  targets:
    - name: availability
      sli:
        source: prometheus
        query: |
          sum(rate(http_requests_total{service="payment",status!~"5.."}[{{.window}}]))
          /
          sum(rate(http_requests_total{service="payment"}[{{.window}}]))          
      slo: 0.9999
      alerts:
        - burn_rate: 14
          window: 1h
          severity: page
        - burn_rate: 6
          window: 6h
          severity: ticket
          
    - name: latency_p99
      sli:
        source: prometheus
        query: |
          histogram_quantile(0.99,
            sum(rate(http_request_duration_seconds_bucket{service="payment"}[{{.window}}])) by (le)
          )          
      slo: 2.0
      comparison: less_than