SRE 实践

概述

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

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 分钟

基于错误预算的决策矩阵

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

错误预算告警联动

# 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 心法

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

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 支持安全的持续交付

6.1 KiB Raw Blame History Unescape Escape

SRE 实践

概述

SLI / SLO / SLA 详解

三层模型

实用性比例对照表

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

计算方式

基于错误预算的决策矩阵

错误预算告警联动

SRE 心法

Blameless Postmortem 模板

SRE Metrics 看板

关联笔记

6.1 KiB

Raw Blame History