---
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 详解 | **基础**：三层模型、比例对照表、设定方法 | [[04-SRE实践/01-SLI-SLO-SLA详解]] |
| Error Budget 深度解析 | **进阶**：计算方式、决策矩阵、告警联动 | [[04-SRE实践/02-错误预算深度解析]] |
| SRE 心法与事故复盘 | **文化**：五条心法、Postmortem 模板、DORA Metrics | [[04-SRE实践/03-SRE心法与事故复盘]] |

## SRE 五条心法

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

## Error Budget 计算速查

| SLO | 月预算 | 周预算 | 日预算 |
|-----|--------|--------|--------|
| 99% | ~5h | ~72min | ~14min |
| 99.9% | ~43min | ~10min | ~1.4min |
| 99.95% | ~21min | ~5min | ~43s |
| 99.99% | ~4.3min | ~1min | ~8.6s |
| 99.999% | ~26s | ~6s | <1s |

## SRE Metrics 看板

| 指标 | 说明 | 精英级目标 |
|------|------|-----------|
| **MTTR** | Mean Time To Recovery | < 1h |
| **Change Failure Rate** | 变更导致故障的比例 | < 5% |
| **Lead Time for Changes** | 代码提交到上线的时间 | < 1h |
| **Deployment Frequency** | 部署频率 | 每日多次 |

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

## 关联笔记

- [[04-SRE实践/01-SLI-SLO-SLA详解]] — SLI/SLO/SLA 三层模型基础
- [[04-SRE实践/02-错误预算深度解析]] — Error Budget 告警规则示例
- [[hhs/MS/05-部署运维/02-Kubernetes]] — K8s HPA 弹性伸缩支撑 SLO 保障
- [[hhs/MS/05-部署运维/03-CICD与GitOps]] — GitOps 支持安全的持续交付