第 1 章 · 02 SRE 与可靠性工程
文档摘要
第 1 章 · 02 SRE 与可靠性工程 本节摘要:SRE(Site Reliability Engineering,站点可靠性工程)是 Google 提出的"让软件工程师做运维"的实践体系。本节讲清 SRE 与 DevOps 的关系、SRE 团队的职责,重点掌握SLI/SLO/SLA 三级指标体系与错误预算的计算,再理解 Toil、监控、事后复盘等核心机制。学完本节,你能把一个服务的可靠性从"玄学"变成"可计算的预算"。 学习目标 说出 SRE 与 DevOps 的关系,以及 SRE 团队的六大职责。 区分 SLI、SLO、SLA 并各举一例。 计算给定 SLO 下的错误预算,并说明错误预算的意义。 说出 Toil 的五个特征与消除原则。
第 1 章 · 02 SRE 与可靠性工程
本节摘要:SRE(Site Reliability Engineering,站点可靠性工程)是 Google 提出的"让软件工程师做运维"的实践体系。本节讲清 SRE 与 DevOps 的关系、SRE 团队的职责,重点掌握SLI/SLO/SLA 三级指标体系与错误预算的计算,再理解 Toil、监控、事后复盘等核心机制。学完本节,你能把一个服务的可靠性从"玄学"变成"可计算的预算"。
学习目标
- 说出 SRE 与 DevOps 的关系,以及 SRE 团队的六大职责。
- 区分 SLI、SLO、SLA 并各举一例。
- 计算给定 SLO 下的错误预算,并说明错误预算的意义。
- 说出 Toil 的五个特征与消除原则。
- 解释为什么 100% 可用性不是正确目标,并说出 MTTF/MTTR/MTBF 的含义。
一、SRE 与 DevOps 的关系
Google 的定义:"可以把 DevOps 看作是若干核心 SRE 原则在更广泛的组织、管理结构与人员中的泛化。"
简单说:SRE 是 DevOps 的一种具体工程实现——DevOps 是文化运动,SRE 是把它落到可靠性度量与工程实践上。
SRE 团队负责(Google):可用性、延迟、性能、效率、变更管理、监控、应急响应、容量规划。
二、SLI / SLO / SLA 三级指标
这是 SRE 最重要的概念三件套,顺序从"测什么"到"承诺什么":
| 概念 | 全称 | 定义 | 示例 |
|---|---|---|---|
| SLI | Service-Level Indicator | 服务性能/可靠性的实际测量值 | 请求延迟、处理吞吐、单位时间失败请求数 |
| SLO | Service-Level Objective | SLI 的目标值或范围 | "30 天窗口内 99% 请求延迟 < 300ms" |
| SLA | Service-Level Agreement | 与客户签的正式协议及未达成的后果 | "低于 99.9% 可用性赔款 X" |
三个要点:
- SLO 同时是下限:没有义务做得比 SLO 更可靠——过度可靠反而会拖延新功能发布(可靠性有成本)。
- SRE 一般不参与 SLA 制定:SLA 与业务、产品决策强相关,属于商业范畴;SRE 负责把它翻译成技术目标(SLO)。
- 顺序:先有 SLI 测量,再定 SLO 目标,最后才谈 SLA 承诺。
三、错误预算(Error Budget)
定义:服务在仍满足 SLO 的前提下,可以承受的故障/错误总量。
计算:错误预算 = 1 - SLO。
举例:99.9% 可用性 SLO → 0.1% 错误预算。若四周内服务收到 1,000,000 个请求,则预算 = 1,000 个错误。
机制意义:错误预算是平衡创新与稳定的机制——
- 预算充足:可以放心发布新功能(创新);
- 预算耗尽:停止发布,全力修复稳定性(稳定)。
- 关键:如果 SRE 无法执行错误预算(该拦的时候拦不住),整个机制就失效。
四、为什么 100% 可用性不是目标
- 没有任何系统能保证零停机,"100%"是伪目标;
- 大多数系统应该在 99%~100% 之间取一个成本与体验平衡的值;
- 追求 99.99% 比 99.9% 的工程成本高一个数量级,但用户几乎感知不到差异;
- 可用性越高,允许发布新功能的空间(错误预算)越小,创新反而被拖慢。
小知识:常见可用性换算——99.9% = 全年停机约 8.76 小时;99.99% ≈ 52.6 分钟;99.999% ≈ 5.26 分钟。
五、可靠性度量:MTTF / MTTR / MTBF
| 指标 | 全称 | 含义 |
|---|---|---|
| MTTF | Mean Time To Failure | 系统运行到故障的平均时长(即"uptime") |
| MTTR | Mean Time To Repair | 修复故障所需的平均时间 |
| MTBF | Mean Time Between Failures | 两次故障之间的平均时长 |
它们帮助团队评估:系统有多"长寿"(MTTF)、出事后恢复多快(MTTR)、故障多频繁(MTBF)。MTTR 是运维最可优化的指标——降 MTTR = 更好的监控、预案与自动化。
六、Toil(苦差事)
定义(Google):与运行生产服务相关的工作,具有以下特征——
- 手动:人肉执行;
- 重复:做了一遍又一遍;
- 可自动化:有规律可循;
- 战术性:应急式,不产生持久价值;
- 随服务规模线性增长:服务越大,苦差越多。
原则:能自动化就应该自动化。自动化投资产生持久价值,且具备规模化的杠杆——系统扩张时几乎无需额外调整。
七、监控与事后复盘
监控:服务所有者跟踪系统健康与可用性的主要手段(Google)。没有监控就没有 SLI,没有 SLI 就没有 SLO——监控是一切可靠性的起点。
Postmortem(事后复盘):事故发生后必须进行的过程,目的是找出根因,并确定避免再次发生的行动项。
核心价值:Blamelessness(无指责)。复盘开场就要重申"不追责"——这是确保大家敢说真话、专注找根因而非藏过错的最好方式。事故归因要落在流程与系统设计上,而不是个人。
小结
- 关系:DevOps 是文化, SRE 是工程化落地。
- 三件套:SLI 测量 → SLO 目标 → SLA 合同,SLO 也是"不必更可靠"的下限。
- 错误预算:1 - SLO;预算耗尽即冻结发布,平衡创新与稳定。
- 100% 是伪目标:可靠性有成本,过度追求拖慢交付。
- Toil 五特征:手动/重复/可自动化/战术性/线性增长——能自动化就自动化。
- 复盘铁律:无指责,找根因,落行动项。
下一节预告:带上"安全眼镜"看全流程——DevSecOps、零信任、认证授权与常见攻击。