cs-note/hhs/MS/05-部署运维/04-SRE实践.md

tags, create time

tags	create time
microservice sre slo error-budget postmortem	2026-05-05

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 详解	基础：三层模型、比例对照表、设定方法	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 支持安全的持续交付