---
tags: [microservice, sre, slo, error-budget, postmortem]
create time: 2026-05-05
---

# SRE 实践

## 概述

站点可靠性工程 (SRE) 把运维问题看作**软件工程问题**。它的核心理念是用 SLI/SLO/SLA 来量化服务质量，避免"我觉得系统很慢"这类模糊描述。

```mermaid
flowchart LR
    User["用户体验"] --> SLI{"实际测量"}
    SLI -->|"达标"| SLO_OK["✅ SLO 达成"]
    SLI -->|"不达标"| Budget["消耗错误预算"]
    
    Budget --> Left{"预算剩余?"}
    Left -- "> 50%" --> Ship["快速迭代 🚀"]
    Left -- "< 10%" --> Stabilize["稳定优先 ❄️"]
    
    style User fill:#e3f2fd
    style SLO_OK fill:#e8f5e9
    style Ship fill:#fff3e0
    style Stabilize fill:#ffebee
```

## SLI / SLO / SLA 详解

### 三层模型

| 术语 | 全称 | 定义 | 谁制定 | 变更频率 |
|------|------|------|--------|---------|
| **SLI** | Service Level Indicator | 实际度量：用户请求的成功率是多少？ | 观测系统自动产出 | 持续更新 |
| **SLO** | Service Level Objective | 内部目标：我们承诺达到 99.9% 可用性 | SRE + 研发 | 季度回顾 |
| **SLA** | Service Level Agreement | 对外契约：达不到就赔钱 | 法务 + 商务 | 按合同约定 |

### 实用性比例对照表

| SLO | 每年停机时间 | 每月停机时间 | 适用级别 |
|-----|-------------|-------------|---------|
| **99%** | ~87.6 小时 | ~7.2 小时 | 内部工具（几乎无意义） |
| **99.9% ("三个九")** | ~8.76 小时 | ~43 分钟 | 大多数后端服务 ✅ |
| **99.95%** | ~4.38 小时 | ~21 分钟 | 核心交易链路 |
| **99.99% ("四个九")** | ~52.6 分钟 | ~4.3 分钟 | 金融级 / 支付系统 |
| **99.999%** | ~5.26 分钟 | ~26 秒 | 电信级，极难实现 |

> [!warning] "三个九"是底线
> 
> 如果团队宣称 SLO = 99%，这意味着每月可以容忍近 **7 小时的不可用**——这在生产环境中基本等于没有可用性目标。

## Error Budget (错误预算) 深度解析

### 计算方式

```
可用率 = (总时间 - 故障时间) / 总时间 × 100%
错误预算 = 1 - SLO

SLO = 99.9% → 错误预算 = 0.001
      每月可容忍故障 = 30 × 24 × 60 × 0.001 = 43.2 分钟
      每周可容忍故障 = 7 × 24 × 60 × 0.001 = 10.1 分钟
      
SLO = 99.99% → 错误预算 = 0.0001
      每月可容忍故障 ≈ 4.3 分钟
```

### 基于错误预算的决策矩阵

```mermaid
flowchart TD
    Ratio["错误预算使用率 = 已消耗 / 总预算"]
    
    Ratio -- "< 50%" --> Green["🟢 绿灯阶段<br/>预算充足: 可以大胆发布<br/>新功能、尝试激进方案<br/>常规发布节奏"]
    Ratio -- "50~90%" --> Yellow["🟡 黄灯阶段<br/>预算紧张: 收紧发布频率<br/>增加人工审查<br/>暂停非关键功能开发"]
    Ratio -- "\> 90%" --> Orange["🟠 橙灯阶段<br/>严重不足: 冻结发布<br/>专注稳定性修复<br/>全员 On-Call"]
    Ratio -- "\> 100%" --> Red["🔴 红灯阶段<br/>预算耗尽: 禁止所有<br/>功能性变更<br/>SLO 事故复盘"]
    
    style Green fill:#c8e6c9
    style Yellow fill:#fff9c4
    style Orange fill:#ffe0b2
    style Red fill:#ffcdd2
```

### 错误预算告警联动

```yaml
# Prometheus 告警规则示例
groups:
  - name: error-budget
    rules:
      - alert: ErrorBudgetBurnRateHigh
        expr: |
          sum(rate(http_requests_total{status=~"5.."}[1h])) /
          sum(rate(http_requests_total[1h])) > 0.001
        for: 1h
        labels:
          severity: warning
          budget_phase: yellow
        annotations:
          summary: "错误预算消耗加速"
          message: "当前错误率 {{ $value }}% > SLO 阈值 0.1%"
      
      - alert: ErrorBudgetExhausted
        expr: |
          (sum(rate(http_requests_total{status=~"5.."}[24h])) /
           sum(rate(http_requests_total[24h]))) >= 0.001
        labels:
          severity: critical
          budget_phase: red
        annotations:
          summary: "错误预算已耗尽！"
          message: "本月 SLO 已破线，冻结非紧急变更"
```

## SRE 心法

1. **用户视角定义 SLO** — 不是"API P99 < 200ms"，而是"用户在正常网络下加载页面 < 2s"
2. **错误预算用完 = 停止功能开发** — 全力修 bug、加稳定性
3. **Blameless Postmortem** — 不问"谁干的"，问"流程哪里可以改进"
4. **自动化一切重复劳动** — 手动操作一定会出错
5. **接受一定程度的失败** — 在可控范围内快速迭代，比追求完美更重要

## Blameless Postmortem 模板

| 字段 | 填写内容 |
|------|---------|
| **事件名称** | `2026-05-05 支付服务超时事故` |
| **影响范围** | 约 15% 的支付请求失败，持续 23 分钟 |
| **发现时间** | 14:32 (On-Call 接到告警) |
| **恢复时间** | 14:55 (回滚后确认恢复) |
| **根本原因** | 某次变更后支付网关的连接池大小从 50 降到 10 |
| **时间线** | 14:00 发布 v1.2.3 → 14:30 错误率开始升高 → 14:32 收到告警 → 14:35 开始排查 → 14:45 定位根因 → 14:50 回滚 → 14:55 完全恢复 |
| **改进行动** | ① 连接池参数变动必须经过压测验证；② 监控中补充连接池活跃数指标 |
| **跟进人** | @zhangsan (行动 ①)、@lisi (行动 ②) |

## SRE Metrics 看板

除了 SLO，SRE 还需要关注以下运营指标：

| 指标 | 说明 | 目标 |
|------|------|------|
| **MTTR** | Mean Time To Recovery | 核心服务 < 30min |
| **Change Failure Rate** | 变更导致故障的比例 | < 5% |
| **Lead Time for Changes** | 代码提交到上线的时间 | < 2h |
| **Deployment Frequency** | 日均部署次数 | > 5 (大规模团队) |

> [!tip] DORA Metrics
> 
> Google 提出的四大 DevOps 指标，广泛用于评估工程效能：
> - **部署频率** — 交付速度
> - **变更前置时间** — 从代码提交到生产部署需要多久
> - **变更失败率** — 多少部署导致了故障或回滚
> - **MTTR** — 恢复服务的平均时间

## 关联笔记

- [[04-可观测性/04-告警管理]] — SLO/Error Budget 与告警体系的联动
- [[05-部署运维/02-Kubernetes]] — K8s HPA 弹性伸缩支撑 SLO 保障
- [[05-部署运维/03-CICD与GitOps]] — GitOps 支持安全的持续交付