02 SRE 是什么

概述#

SRE（Site Reliability Engineering，站点可靠性工程）是 Google 于 2003 年创立的一套工程实践体系，核心主张：用软件工程的方法解决运维问题。它不是传统运维的"换一个名字"，而是一次根本性的范式转移——把可靠性当作一个可以量化、可以工程化、可以用软件自动化来解决的问题。

本章回答四个基本问题：SRE 从哪来、SRE 的本质是什么、SRE 与 DevOps 的关系、SRE 在不同规模团队里如何落地。

一、起源：Google 的运维危机#

2003 年前后，Google 面临一个矛盾：服务规模指数级增长，但运维团队如果按传统方式线性扩人，成本不可承受。Ben Treynor Sloss（Google SRE 创始人）给出的定义至今是 SRE 最经典的表述：

SRE is what happens when you ask a software engineer to design an operations team.

关键不在"design"这个词，而在 software engineer——不是 sysadmin，不是 operator，而是用写代码的思维来设计运维工作。传统运维靠经验、靠手册、靠手动操作；SRE 靠代码、靠自动化、靠数据驱动决策。

这套体系后来通过两本免费书籍（Google SRE Book 和 SRE Workbook）向全行业开放，成为现代互联网公司可靠性工程的事实标准。Google 内部 SRE 团队规模已超过 3000 人，覆盖 Search、Ads、Cloud、YouTube 等所有核心产品线，其方法论经过 20 年实战验证。

二、核心定义：软件工程做运维#

SRE 的日常工作可以概括为三件事：

运维工作：SRE 承担 on-call 值班、事件响应、故障处理等传统运维职责。但有一个硬性约束——运维工作（toil）不能超过总时间的 50%。超过这个比例，其余的时间必须投入到自动化工程上，把重复工作逐步消除。

自动化工程：SRE 写代码来替代手动操作。不是写一次性脚本，而是构建可复用的自动化平台，让系统自己完成部署、扩缩容、故障恢复。最终目标是让运维工作量与系统规模解耦——系统扩大 10 倍，运维工作不随之 10 倍增长。

可靠性工程：SRE 用 SLI/SLO/错误预算这套量化框架来管理可靠性。不是拍脑袋说"可用性要高"，而是精确度量"当前成功率是 99.95%，目标是 99.9%，我们还有 X 分钟的不可用预算"。

这三件事的比例不是固定不变的。Google SRE Book 给出的参考是：运维 50%、工程 50%；但落地到不同公司会有差异——早期 SRE 团队可能 70% 运维 30% 工程，成熟期可以做到 30% 运维 70% 工程。关键不是比例数字，而是有明确的工程时间预算，并且这个预算被团队和管理层共同尊重。

三、SRE 的四个核心原则#

1. 可用性目标（SLO）#

SRE 不给所有服务设同一个可用性目标。一个内部管理后台和支付 API 的可靠性要求不可能一样。SRE 的工作从**定义 SLO（Service Level Objective）**开始：和业务方协商出一个比用户期望略高一点的目标——既不是 100%（太贵、不现实），也不能太低（用户会不满意）。

SLO 是一切后续决策的锚：触发什么级别的告警、能不能发版、要不要停下新功能先修稳定性，都看 SLO。没有 SLO 的"可靠性工作"本质上都是在凭感觉——这也是为什么 Google SRE Book 把"SLO 是 SRE 的根基"放在第一章。

为什么不能 100%？因为 100% 可用性意味着：每一笔硬件投入、每一行代码、每一次发布都要为"绝对不出错"付出代价。99.9% 到 99.99% 的成本通常是 2-3 倍，99.99% 到 99.999% 又是 2-3 倍——指数级增长的成本，换来的边际用户感知极小（用户感受不到 99.9% 和 99.95% 的差别，但能感受到功能慢了三个月上线）。

2. 错误预算（Error Budget）#

Error Budget = 1 - SLO。如果 SLO 是 99.9%（月度），那允许的"错误时间"就是 0.1% × 30 天 ≈ 43 分钟。

错误预算的本质是把可靠性变成可量化的决策依据：

• 预算充足 → 正常发布新功能，可以接受一定风险
• 预算耗尽 → 冻结发布，全员投入稳定性修复
• 预算超支 → 必须有明确的恢复路径，不能假装没发生

这让"SRE 拦着不让发版"变成有数据的理性讨论，而不是立场之争。开发说"这个功能必须这周上"，SRE 不再回"不行太冒险"，而是回"这个月还剩 8 分钟错误预算，你的发布风险评估是会消耗 15 分钟，建议下周预算刷新后再上"。

错误预算还隐含一个反直觉的洞察：完全不犯错的服务是不可演进的。如果一个团队从不出事故，要么是流量太小、要么是发布太慢、要么是没人敢动核心系统——这些都是更危险的状态。错误预算的存在就是承认"系统会出错"，并把这个出错量管控在用户可接受的范围内。

3. 消除琐事（Toil）#

Toil 是 SRE 体系中一个精确的定义：手动、重复、可自动化、无持久价值、操作型的工作。它不等于"不喜欢的工作"——紧急响应不是 toil（有价值），写运维文档也不是 toil（有持久价值）。

Google SRE Book 给出 toil 的六个典型特征（命中越多越可能是 toil，Google 原文是"具备其中部分或全部"，并非缺一不可）：

1. 手动：需要人去点按钮、敲命令、填表单
2. 重复：不止做一次，而是周期性或事件触发型地反复出现
3. 可自动化：逻辑明确、规则稳定，理论上可以用代码描述
4. 战术性（被动响应）：由系统当前状态触发、疲于应付，而非主动改进系统设计
5. 无持久价值：做完之后系统状态和做之前没有结构性改善
6. 与服务规模成正比（O(n)）：流量翻倍，toil 也翻倍——这种工作是规模陷阱

50% 上限原则：每个 SRE 的 toil 工作时间不能超过 50%。超过就必须把 toil 减下来或转交给研发团队。这不是福利，是结构性约束——如果 SRE 每天疲于救火，就没时间做自动化，toil 永远减不掉，形成恶性循环。

实际操作中如何衡量 50%？Google 的做法：每个 SRE 周报里填 toil 时间占比，季度汇总。超过 50% 的团队需要向 SRE Director 解释原因并给出削减计划。这套机制看起来繁琐，但没有度量的约束等于没有约束——只喊口号"少做琐事多写代码"是没用的。

4. 可观测性（Observability）#

SRE 不满足于"有监控"。监控只能回答你提前想好的问题（"CPU 是不是高了"），可观测性要求系统能回答你没提前想到的问题（"为什么这个用户下单失败"）。

可观测性的本质源自控制论：能否从外部输出反推系统内部状态。三支柱（指标/日志/链路）只是手段，不是定义。判断一个系统是否"可观测"，标准是：线上出了你从没预想过的故障，你能不能靠现有信号一路问到根因。

这意味着：告警必须是症状型（用户感受到了什么）而非原因型（某个组件怎么了）；排障需要从指标→链路→日志的完整下钻闭环；三种信号必须共享关联键（trace_id），能从一条慢链路一键拉出它的所有日志。可观测性工具栈的具体部署见 DevOps 路线 Ch25-28，本路线重点讲怎么用这些工具做可靠性决策。

四、SRE vs DevOps：本质区别#

很多人以为 SRE 是 DevOps 的一种实现方式。这个理解部分正确但不完整。

一句话总结：DevOps 是理念和文化，SRE 是具体工程实践。一个团队可以既有 DevOps 文化又做 SRE 实践——事实上最好的团队就是这样。DevOps 提供了"如何搭工具链"，SRE 提供了"如何用工具做决策"。

在本书体系里，DevOps 路线（前置课程）已经覆盖了工具层：Prometheus 部署、Alertmanager 配置、GitOps 流水线。SRE 路线在此基础上回答"怎么用这些工具做出可靠性决策"。

五、SRE 不是运维的重命名#

一个常见的误解是把 SRE 等同于"改了个名的运维"。两者的关键区别：

判断一个团队是不是"真 SRE"的几个实操标准：

1. 有没有公开的 SLO 仪表盘，团队任何人都能看到当前错误预算消耗
2. Postmortem 文档是否对所有员工开放，有没有"无指责"文化
3. Toil 时间占比是否被定期度量并作为团队 KPI 之一
4. On-call 告警数量是否被主动治理（不是被动接受越多越好）
5. SRE 工程师有没有真正写代码的时间——还是天天在救火

如果以上五条大部分是"没有"或"否"，那即使团队名字叫 SRE，本质还是运维。

六、SRE 在不同规模团队的落地#

Google SRE 是"教科书版本"，规模、资源、文化都到顶配。绝大多数公司没有 Google 的条件，需要做适配。下面按团队规模给落地建议：

< 10 人团队#

不需要专职 SRE，但需要 SRE 思维。开发轮流 on-call，每人每周一轮。重点：

• 引入 SLO 概念，哪怕只是简单的"可用性 = 成功请求/总请求"
• On-call 告警必须有 runbook
• 每次事故写一份简短 Postmortem（不追求完整模板，但要写根因 + 改进项）

10-50 人团队#

可以有 1-2 名专职 SRE，作为"可靠性教练"角色。重点：

• 建立完整 SLO 体系（3-5 个核心服务）
• Postmortem 模板固化，所有 P0/P1 事故必须写
• 开始引入自动化：自动扩缩容、自动回滚、自动告警分组
• SRE 不直接负责所有服务的可靠性，而是赋能开发团队

50-200 人团队#

SRE 团队 3-8 人，可以做平台化投入。重点：

• 嵌入式 SRE 模式（每个业务线配 1 名 SRE 顾问）
• 自研可靠性平台（SLO 配置即代码、自动 Postmortem 流程）
• 混沌工程、容量规划等主动可靠性工程
• SRE 工程师和开发工程师同等薪酬、同等晋升路径

200+ 人团队#

Google 式 SRE 可以完整落地：BU 级 SRE 团队、可靠性平台团队、SRE 文化培训体系。这时候需要思考的是组织架构问题，而不是技术问题。

SRE 失败的常见模式#

不是所有引入 SRE 的团队都成功。常见失败模式：

1. SRE 当高级运维用：组织给 SRE 配了团队，但不给工程时间，全用在救火上，半年后核心成员离职
2. SLO 形式化：定了一堆 SLO 但不参与发布决策，错误预算耗尽也没人管，SLO 变成 dashboard 装饰
3. Postmortem 走过场：开了复盘会但 Action Items 没人跟进，同样的故障反复发生
4. SRE 和开发对立：SRE 变成"拦着不让发版"的角色，开发绕着走，组织政治消耗巨大
5. 没有 blameless 文化：复盘开成追责会，工程师不敢说真话，根因永远是"操作失误"

实战要点#

1. SRE 落地不靠堆人。如果团队承受不住 on-call 压力，不是加班一个人能解决的，需要先做告警治理、toil 消除。Google SRE Book 明确：on-call 工作量不超过总时间 25%，超了就是组织问题不是个人问题。
2. 先建 SLO 体系再谈 SRE。没有 SLO 的 SRE 只是换了名字的运维——因为没有客观数据来驱动决策。SLO 体系的最小可行版本：3 个核心服务、每月 1 次回顾、有发布冻结机制。
3. 50% toil 上限是硬指标，不是建议，是 SRE 存在的前提。做不到就说明组织还没有真正实施 SRE。Google 内部这条是写到 SRE 绩效考核里的。
4. 与 DevOps 路线的关系：DevOps Ch17-Ch28 覆盖了工具部署层（Prometheus/Grafana/Alertmanager/CI/CD），本路线在工具基础上讲可靠性方法论。建议先完成 DevOps 路线再学 SRE，否则容易陷入"知道要做什么但不知道怎么做"的尴尬。
5. SRE 是工程角色不是运维角色。招聘时看代码能力，不只是看运维经验。一个不会写代码的 SRE 注定只能做 toil 消除的低级版本。
6. 可靠性是业务问题不是技术问题。SLO 必须由业务方和 SRE 共同制定，不能 SRE 自己拍。错误预算的消耗也必须让业务方看到——这是让业务方理解"稳定性有成本"的最有效方式。

小结#

SRE 不是玄学，是一套经过 Google 二十年验证的工程方法论。三个核心概念贯穿全书：SLO（衡量标准）、错误预算（决策工具）、消除 Toil（工作方式）。后续章节逐一展开。

读完本章，记住一个等式：SRE = 软件工程 × 运维 + 可靠性量化。

判断一个组织是否真正在做 SRE，看三件事：有没有公开的 SLO、有没有 blameless 的 Postmortem、有没有度量并治理 toil 占比。三件事都做到，就是真 SRE；只做到其中一两件，是"在路上"；一件都没做，那就是换了名字的运维。

下一章我们进入 SRE 的根基——SLI/SLO/SLA 体系，看可靠性如何被精确量化和决策。