专业书籍精读 · SRE · 第 1 章
Site Reliability Engineering · Ch 1 · Google（Benjamin Treynor Sloss）· 2016
你刷淘宝、点外卖、发微信，从来没想过「它今天会不会打不开」。这份「从来没想过」的背后，有一群人专门守着机器。《SRE：Google 运维解密》第 1 章讲的就是：Google 发现「守机器」这件事，用老办法越守越贵、越守越吵，于是干脆换了一批人、换了一套规矩去守。
想象一家越开越大的餐厅。老办法是：客人多一倍，就多招一倍洗碗工。生意翻十倍，洗碗工也翻十倍——而洗碗工永远在洗碗，永远腾不出手干别的。
Google 的办法是：招进来的不是洗碗工，是会造机器的工程师，并立一条硬规矩——你每天最多只许花一半时间洗碗，另一半必须拿去造洗碗机。这些人受不了重复劳动，又刚好有本事把它做成机器。于是生意翻十倍，人却不用翻十倍。
更难的其实不是人手，是两拨人天生吵架。写新功能的人，绩效来自「上线了多少东西」，所以想天天发版；守机器的人，绩效来自「今年没出事」，所以想什么都别动。而线上事故绝大多数恰恰是「刚改了点什么」引起的——两边的目标从根上就对着干。
于是就有了那种熟悉的拉锯：发布要走一堆评审，工程师则学会给改动换个名字绕过去（「我这不是发版，只是改了个开关」）。谁也没错，但事情越来越慢。
这章最漂亮的一招，是把这场吵架变成看同一个数。做法是：事先大大方方承认「我们不追求永远不坏」，然后写死一个额度——这个服务一年允许出问题多久。这就是它的「预算」。
然后规矩很简单：额度有富余，就尽管上新功能，出了小问题算花预算，没人拦你；额度花光，新功能一律停，全员回头修稳定性，等下一期预算回来。想快，就得先把系统弄稳——不看谁嗓门大、职级高，只看账本上还剩多少。而追求「永远不坏」反而是错的：用户手里的手机、路上的 Wi-Fi、家里的宽带本身就没那么可靠，你再往上磨，用户根本感觉不到，钱却烧得飞快。
规模涨十倍，守机器的人不用涨十倍；发布不再是审批拉锯，而是查一下额度；出了事只追系统不追人，因为追人只会换来下次没人敢说实话。还有个朴素得可爱的发现：把救火步骤提前写成一本手册，真出事时的恢复速度比现场临时发挥快好几倍。
代价也得说清楚：这套要请会写代码的人来做运维，人贵也难招——服务不够大、活得不够久，硬照搬未必划算。
与其不停招人洗碗，不如请工程师来造洗碗机，并且用两条硬规矩逼他造：一半时间必须用来造工具，以及一年只准坏这么久，坏超了就停止上新。可靠性从一场立场之争，变成了一本大家都看得懂的账。
想进到具体机制、数字和示意图？ → 切到精读版
你以为 SRE 是「运维改了个洋气的名字」，其实它是一次组织设计：把运维当成软件问题，请软件工程师来干，再用两个数字化装置把它钉住——50% 的工程时间下限（防止人力随规模线性膨胀）和错误预算（error budget）（把「多发版 vs 少出事」的立场之争，换算成一个双方共享、可仲裁的数）。这一章不给任何工具，它给的是一套激励结构。
99.9%、99.99% 这类「几个 9」。作者 Benjamin Treynor Sloss——2003 年被要求去带一支 7 人生产团队，SRE 这个词和这个职能就是从那儿长出来的。本章是全书 Part I「引论」的开篇，也是整本书的宪法：后面每一章都是它某一条的展开——Ch3「拥抱风险」与 Ch4「SLO」把错误预算拆细，Ch5「消除琐务」把 50% 上限拆细，Ch6「监控」把「不许人肉读告警」拆细。对应现实里的场景：任何需要长期在线、且还在增长的服务。
业界的默认做法很自然：研发把系统写出来，交给 sysadmin 团队去跑。好处实实在在——技能满大街能招到、现成工具与惯例一大堆、门槛低。作者要算的是它的两笔账。
第一笔是直接成本：人力随规模线性增长。因为变更与事件都靠人工介入，流量涨 10 倍，机器涨 10 倍，工单、呼叫、手工操作也跟着涨 10 倍——团队只能跟着涨。这条曲线小规模看不出问题，大规模就是灾难：你雇的不是解决问题的人，是吸收问题的人。
第二笔是间接成本，更致命：研发与运维的目标从结构上就对立。研发的产出是「上线了多少功能」，所以想尽快发；运维的产出是「今年没出事」，所以想尽量少动。而大部分线上事故恰恰源于变更——新配置、新功能、新流量类型。两个团队被同一个事实拉向相反方向：冲突不是谁人品有问题，是激励设计出来的必然结果。
于是就有了那场熟悉的军备竞赛：运维方架起发布评审与变更冻结，研发方则学会绕过闸门——「改个开关不算发布」。不解决会怎样？规模越大越贵、发布越来越慢，而可靠性并没变好——闸门只是把变更藏起来了，没让它变安全。
Treynor Sloss 给 SRE 的定义就是这么一句话：SRE is what happens when you ask a software engineer to design an operations team.——SRE 就是「让软件工程师去设计一支运维团队」的结果。它不是一套工具，而是一次人员构成上的替换：招软件工程师来跑产品，让他们去写软件替掉本该由 sysadmin 手工完成的活。
这句定义决定了后面所有事。Google 的招法很具体：约 50–60% 走标准的 Google 软件工程师招聘流程；另外 40–50% 是「差一点点就达到 SWE 标准」（书中说约具备 85–99% 的技能）、但额外掌握一类稀缺技能的人——最常见的两类是 UNIX 系统内核内部机制 与 网络（第一到第三层）。
这样组队有一个可预测的副作用，而这正是设计意图：这批人做重复手工活会烦、会走人，于是团队会本能地把手工活做成系统。人力曲线因此从线性被压成次线性——服务翻十倍，SRE 团队不用翻十倍。
光招对人不够——真出了事，人还是会被工单淹没。所以本章给出全书最有名的一条硬约束：SRE 花在运维类工作（工单、on-call、手工操作）上的时间总量不得超过 50%，剩下至少一半必须用于工程项目——去写那些能消灭未来运维工作的软件。
关键不在于「定个目标」，而在于它带执行机制：当运维负担长期超过 50%，多出来的部分回流给产品研发团队——溢出的工单和呼叫转给研发经理、研发工程师排进 on-call 轮值，必要时 SRE 整体撤出、服务交回研发自运维。
精妙之处在于谁制造运维负担，谁就承受它：研发若写出一个难伺候的系统，痛苦会精确地反噬回自己身上，「把系统写得好运维」第一次成了研发自己的利益。同一逻辑落在 on-call 的量级上：平均每个 8–12 小时班次最多应收到 2 起事件——多了说明系统或告警该修了，而不是该加人。每起重大事故还要写无指责（blameless）复盘：只追系统与流程、不追人，因为追人换来的只是下次没人肯讲实话。
这是本章最具原创性的一招，起点是一句反直觉的断言：100% 对几乎所有系统都是错误的可靠性目标（书里给的例外是心脏起搏器和防抱死刹车）。理由不是「做不到」，而是用户根本区分不出来：用户和你的服务之间还隔着手机、Wi-Fi、家宽、运营商骨干网，这条链路本身的可靠性就远低于你的服务。从 99.99% 磨到 99.999%，成本陡增，用户感知却几乎为零。
既然如此，就明确定一个低于 100% 的目标，把差额当预算花掉：可用性目标 99.99% 的服务有 0.01% 的不可用额度，这 0.01% 就是它的错误预算，可以拿去买发布、买实验。
真正改变组织的是它的后果：有余额，研发就放手发布，出点小问题算花预算，不必逐次求批准；烧光了，新功能发布自动冻结，全员转去修可靠性，等下期回补。「该不该发这个版本」于是从一场靠嗓门和职级决定的辩论，变成查一下账本余额——研发和 SRE 第一次共享同一个目标函数：想发得快，就得先让系统稳。这是自我约束，不需要裁判坐在中间。
本章对监控有一条毫不含糊的铁律：不该有人类去例行「读」告警——人的职责是在软件判定出问题后行动，而不是盯着屏幕自己判断。据此监控只有三种合法输出：告警（page）「必须现在有人处理」、工单（ticket）「需要人处理但不急」、日志（logging）「没人需要看，出事时用来诊断」。书中特别点名：靠人去读邮件告警基本无效——既叫不醒人，又制造「我们有监控」的错觉。
应急响应被拆成 MTTF 与 MTTR，而重点明确压在后者：比起「多久坏一次」，更值钱的是「坏了多快能好」。这里有本章最容易被低估的量级：把处置步骤事先想清楚、写成 playbook（应急手册），相比临场发挥，MTTR 大约能改善 3 倍。成本只是写文档，却是整章性价比最高的一条——所以 Google 才配套做「厄运之轮」演练与 DiRT 灾难演习：手册要在无压力时练熟，真出事才用得上。
这是全书引用率最高的数字之一：SRE 的经验是，约 70% 的线上事故源于对运行中系统的变更——新配置、新功能发布、新类型的用户流量。既然如此，主战场就不在「加固」，而在让变更本身变安全。三板斧非常朴素：渐进式发布（先小流量再放大）、快速且准确地检测问题、出事能安全回滚——共同思路仍是把人从执行回路里挪走，人只做决策，同时减少人为失误和 toil。
其余几条职责统一在同一逻辑下：需求预测与容量规划（有机增长如自然用量上涨、无机增长如一次营销活动或新功能上线，必须分开预测，再用压测把「原始资源」换算成「服务容量」）；资源供给（加容量既贵又风险高，要快、且只在真需要时做）；效率与性能（管供给就得管利用率——服务随负载升高而变慢，容量目标必须和延迟目标绑在一起谈）。
表 1 · 两种运维模式的结构性差别
| sysadmin 模式 | SRE 模式 | |
|---|---|---|
| 谁来做 | 与研发技能栈不同的独立运维团队 | 软件工程师（约 50–60% 走标准 SWE 招聘，其余近 SWE 水平 + UNIX 内部机制 / 网络 L1–L3 专长） |
| 人力曲线 | 随负载近似线性——流量 ×10，团队也要 ×10 | 次线性——增量被自动化吃掉 |
| 冲突结构 | 研发要发、运维要冻，靠评审与闸门拉锯 | 错误预算做仲裁，双方共享一个目标函数 |
| 招聘难度 | 低，技能常见、供给充足 | 高且贵——与产品研发抢同一批人 |
| 前期投入 | 低，几乎即插即用 | 高——先写一大堆自动化才见效 |
| 适用 | 规模有限、生命周期不长的服务 | 规模大且还在涨、要长期在线的服务 |
表 2 · 可用性目标 ↔ 错误预算 ↔ 每年允许的不可用时长（按 365 天换算）
| 可用性目标 | 错误预算 | 每年允许不可用 | 代价与适用 |
|---|---|---|---|
99% | 1% | 约 3.65 天 | 内部工具、非关键批处理；几乎不额外花钱 |
99.9% | 0.1% | 约 8.8 小时 | 多数业务后台的现实起点；需基本冗余与值班 |
99.95% | 0.05% | 约 4.4 小时 | 需多副本、自动切换与像样的监控 |
99.99% | 0.01% | 约 52 分钟 | 要跨机房容灾、秒级检测与自动回滚，成本上台阶 |
99.999% | 0.001% | 约 5.3 分钟 | 常常不划算——用户侧链路本身更不可靠，多出的可靠性感知不到 |
表 3 · 监控系统的三种合法输出：选错等级的代价
| 输出 | 含义 | 该用在 | 用错的代价 |
|---|---|---|---|
| 告警 page | 必须立刻有人处理 | 用户已受影响、或马上要受影响 | 滥用 → 告警疲劳，真事故被淹没，班次事件数轻易破「≤ 2 起」 |
| 工单 ticket | 需要人处理，但不必现在 | 容量将满、证书临期、掉了一个副本 | 该发告警的降成工单 → 小问题拖成大事故 |
| 日志 logging | 无需任何人查看，出事时用于诊断 | 常规状态、调试信息 | 指望人去「读」日志或邮件告警 → 制造「我们有监控」的错觉 |
那么该不该照搬 SRE？诚实的答案是：整套照搬要拿规模作前提——你得用产品研发的价码去招人做运维，还要先垫一大笔自动化的前期投入，它才开始省钱；服务不够大、活得不够久，这笔投入回不了本。但本章里几乎零成本、任何团队今天就能拿走的三样是：写 playbook（约 3 倍 MTTR 改善，成本只是文档）、无指责复盘、以及显式定一个低于 100% 的可靠性目标——这三样都不需要你有一支 SRE 团队。
这一章的影响力可以用一个简单事实衡量：今天几乎所有互联网公司的可靠性对话，都在用它发明的词汇——SLI / SLO、错误预算、toil、无指责复盘、告警分级。云厂商把 SLO 做成了托管产品，可观测性平台标配「错误预算燃尽」面板；「可靠性不是越高越好，而是定一个目标、再把差额花掉」这个观念，已从 Google 内部的组织设计变成行业默认心智。面试里问「你们服务的 SLO 是多少、错误预算怎么用」，本质上就是在问你有没有读懂这一章。
① 一句话：SRE 不是运维的新名字，是一次组织设计——「让软件工程师去设计一支运维团队会发生什么」。
② 旧模式的两笔账：直接成本是人力随负载线性增长；间接成本是研发（想发）与运维（想冻）结构性对立，闸门只把变更藏起来、没让它变安全。
③ 人员构成决定一切：约 50–60% 按标准软件工程师招，其余为近 SWE 水平 + UNIX 内部机制 / 网络 L1–L3 专长——这批人受不了手工重复，自动化于是成了必然。
④ 制度装置一：运维工作 ≤ 50%，带溢出阀门（工单与呼叫回流研发、研发进 on-call、必要时 SRE 撤出）——谁制造运维负担，谁承受它。
⑤ 制度装置二：错误预算。100% 是错误的目标；99.99% 意味着 0.01% 额度可拿去买发布速度，烧光则自动冻结。争论变成查账。
⑥ 监控铁律：不该有人例行读告警；只有三种合法输出——告警（立刻处理）、工单（需处理但不急）、日志（无人需看）；邮件告警基本无效。
⑦ 应急重点在 MTTR 而非 MTTF：写好 playbook 约带来 3 倍 MTTR 改善，全章性价比最高的一条；配合演练与无指责复盘。
⑧ 变更管理是主战场：约 70% 的事故源于对运行中系统的变更；对策是渐进式发布 + 快速准确检测 + 安全回滚。
⑨ 容量与效率也归 SRE：有机 / 无机增长分开预测，压测把原始资源换算成服务容量；管供给就得管利用率与延迟目标。
⑩ 选型诚实说：整套 SRE 要规模才回本；但 playbook、无指责复盘、显式定一个低于 100% 的目标几乎零成本，任何团队今天就能拿走。