专业书籍精读 · SRE · 第 3 章
Site Reliability Engineering · Ch 3 · Google（Marc Alvidrez）· 2016
没有一个 App 敢跟你保证「我永远不会出问题」。但一家公司内部总得回答一个很具体的问题：我们到底允许自己一年出多久问题？《SRE：Google 运维解密》第 3 章讲的就是——Google 不但不回避这个问题，还把答案做成了一笔可以花的预算。
你想让家里更安全。装把好锁几百块；加道防盗门几千块；装一圈摄像头上万；雇个 24 小时轮班的保安，一年几十万。每往上加一档，花的钱翻着番涨，安全感却只多一点点。到某一档你会发现：为了「更安全」多花的钱，已经超过家里全部值钱东西了。再往上加就不是谨慎，是亏本。
就算你舍得花钱，用户也未必感觉得到。用户和你的服务之间还隔着一部手机、一个 Wi-Fi、一根宽带、一段运营商网络——这一整条路本身就没那么可靠。书里那句话很扎心：一个用着「偶尔抽风」的手机的人，分不出你的服务是「几乎不坏」还是「更几乎不坏」。
既然「永不出事」既贵又没人察觉，那就大大方方定一个会出事的额度：先说清「这个服务一年允许出问题多久」，那点差额就是它的预算。
然后像管家庭旅游预算一样管它：钱还在就尽管出门玩——放手上线、大胆做实验，出点小问题算花预算；钱花光了就老实在家待着——新功能一律停，全员回头修稳定性，等下期额度回来。于是「这版该不该发」这种以前靠嗓门和职级决定的争论，变成了低头看一眼账本还剩多少。
还有个容易忽略的细节：「坏了多久」怎么数？直觉是看钟表——今天躺了几分钟。但铺在全球的服务几乎从不整个躺平，只会「这里坏一点、那里坏一点」。所以更实用的数法是数人头：今天来了这么多次请求，有多少次没被伺候好。这样「半死不活」也能记进账。
额度不是全公司一个数。内部报表工具和支付系统本来就不该定一样的目标；同一套存储，给「点一下就要出结果」的业务和给「半夜跑一批账」的业务，也该是两个档位、明码标价，让用的人自己挑——想要更稳，就多付点钱。
代价也得说清楚：这套规矩只有在「真敢停」的时候才成立——只要每次额度见底都能靠一句「可这个功能特别重要」网开一面，它就只是仪表盘上一个好看的装饰。
可靠性不是越高越好，它是一样有价格的东西。与其发誓「绝不出事」，不如先承认「一年就允许坏这么久」，把这点额度当预算：有余额就大胆往前跑，花光了就停下来修路。吵架于是变成了查账。
想进到具体机制、数字和示意图？ → 切到精读版
你以为可靠性是「越高越好、能做多高做多高」，其实过了某个点，再高一分对用户不可见、对业务是净亏。这一章把可靠性从道德问题改造成会计问题：明确定一个低于 100% 的目标，把「1 减去目标」的那截当成一笔可以花的钱——错误预算（error budget）。有余额就放手发布，花光了就停下来修。SRE 管的从来不是「不出事」，而是风险的度量、定价与分配。
99.9%、99.99% 这类「几个 9」。1 − SLO。目标 99.99% 就有 0.01% 的「允许坏」额度，可以拿去买发布速度和实验。p99）：把所有请求耗时排队，第 99% 慢的那个值——衡量「最难受的那批用户有多难受」。本章是全书 Part II「原则（Principles）」的开篇。Ch1 引论抛出了「错误预算」这个词，本章负责把它量出来、定出价、给出使用规则；紧接着的 Ch4「服务质量目标」把 SLI / SLO / SLA 的定义方法讲细，Ch5「消除琐务」与 Ch6「监控」是预算被消耗后的日常执行面。对应现实里的场景：任何需要回答「这次到底能不能发」「我们该定几个 9」「再多花一笔钱做冗余值不值」的团队。
行业里的默认心智几乎是本能：可靠性越高越好。这章要拆的正是这一条，而且拆得毫不含糊——书里的原话是：过了某个点，提高可靠性对服务（以及它的用户）来说是更糟而不是更好。
第一笔账：成本不是线性的。经验是，可靠性的下一个增量可能比上一个贵 100 倍。钱花在两处：冗余资源——多买的机器、多存的副本、为随时下线维护留出的余量；机会成本——工程师被调去加固，就意味着一批用户看得见的功能没做出来。第二项才致命，因为它不出现在任何一张账单上。
第二笔账：用户根本感知不到。用户和你之间隔着手机、Wi-Fi、家宽和运营商骨干网，这条链路本身就远不如你的服务可靠。书里说得很直接：一个用着 99% 可靠手机的用户，分不出 99.99% 和 99.999% 的服务可靠性。你在小数点后第五位花的钱，掉进了用户侧的背景噪音里。
第三笔账：没有共同标准，可靠性就只能靠吵。研发按「上线了多少东西」考核，SRE 按「今年没出事」考核，两边履行各自的 KPI，却被同一件事拉向相反方向；缺的不是善意，是一个双方都认的裁判量。不解决会怎样？要么过度加固——钱烧了、功能出不来、还没有一个用户会因此感谢你；要么每次发布都靠拍桌子，谁级别高谁赢。
横轴可靠性、纵轴成本，得到的不是斜线，而是一条越往右越陡的曲线。从 99% 到 99.9%，可能只是加个副本、补个健康检查；从 99.99% 到 99.999%，往往意味着跨地域多活、秒级自动切换、专门的容量冗余和一整支人常年守着——换算成时间，是把一年允许的不可用从约 52 分钟压到约 5 分钟。而曲线右段还横着一条用户侧地板：用户体验到的可靠性 ≈ 你的服务 × 他的设备 × 他的网络，你那一项磨得再细，差别也被后两项的抖动淹没。成本陡增、感知归零——两条线一交叉，就有了本章的核心判断：可靠性存在一个「过了就亏」的点。SRE 的工作因此被重新定义：让服务承担的风险，与业务愿意承担的风险显式对齐。
要预算，先要有度量。最直觉的是时间可用性：可用性 = 正常时间 ÷ (正常时间 + 停机时间)——99.99% 约对应一年 52 分钟不可用。这在「单机房、要么活要么死」的世界里够用。但 Google 明确说它在自己身上基本没意义：服务铺在全球又做了故障隔离，任何时刻几乎总在为世界某处的一部分流量服务，从不整个躺平，也就量不出干净的「停机时长」。真实的坏法是「这个地区坏一点、那类请求失败一批」。
所以本章换了口径：用请求成功率定义可用性，即 聚合可用性 = 成功请求数 ÷ 总请求数。书里的算例很具体：每天服务 250 万次请求、日目标 99.99% 的系统，一天最多失败 250 次仍然达标。预算第一次成了当天就能查、能盯着往下烧的整数。离线同理——批处理管线按「成功处理的记录数 ÷ 总记录数」照算；目标通常按季度定、按周或按天跟踪，好让偏离在还来得及时被发现。
目标该定几个 9，不是 SRE 拍脑袋，而是和产品负责人一起，把业务目标翻译成可工程化的指标。本章给了四个具体问题：
（a）需要什么样的可用性水平？用户期待什么？是否直接绑着收入？免费还是付费？竞品做到什么水平？面向消费者还是企业？答案差异极大——书中以 Google Apps for Work（面向企业的办公套件）为例：它有对外承诺、带赔付责任的 SLA，内部目标还要定得比对外承诺更高；而当年收购 YouTube 时，Google 反而刻意定了比企业级产品更低的目标——2006 年的 YouTube 还在高速演进，快速迭代的价值大于多出来的那点可靠性。
（b）不同类型的故障，伤害一样吗？差得很远。同样是「一年错 5000 次请求」，均匀摊在每天几乎无人察觉，集中成一次全站宕机就会上新闻。故障的「形状」和总量同样重要。
（c）用成本把它钉在风险光谱上。本章最实用的一招：把「几个 9」换算成钱。算例干净利落——服务年收入 100 万美元、当前 99.9%，提到 99.99% 多出 0.09% 在线时间，收入增量 $1M × 0.0009 = $900。判据于是毫无争议：这一个 9 的改造花不到 900 美元就做，超过就别做。数字不重要，重要的是这个动作把一场关于「我们该更负责任」的辩论，压成一次两边都能验算的比较。没有直接收入的内部服务同理：把停机折成被堵住的工程师小时数再乘人力成本。
（d）还有别的关键指标吗？可用性常常不是最重要的那个。书中举 AdSense（挂在第三方网页上的广告）：异步加载，少显示一次影响有限，但拖慢宿主页面就是实打实的伤害——它真正要守的是延迟，且延迟目标按不同地区页面本身的加载速度设定。指标定错，后面所有预算管理都在管一个错的东西。
基础设施服务（存储、消息、计算这类内部底座）有一个消费级服务没有的难题：它天然有很多客户，需求彼此冲突。书里的例子是 Bigtable（Google 的分布式表格存储）：一类客户在实时伺候用户请求，最在意延迟——要么很快回来，要么不如报错；另一类在跑离线分析，只关心单位时间处理多少数据。用一个 SLO 同时满足两类必然双输：按低延迟标准建全部集群，离线那批人为用不上的东西付钱；按吞吐标准建，在线那批人的体验垮掉。
解法不是找折中值，而是分层供给、明码标价、让客户自选：一批低延迟、低利用率、单位成本高的集群，一批高吞吐、高利用率、单位成本低的集群，各挂不同 SLO、按不同价格计费。精妙之处是把选择权和成本绑死——当「更可靠」明码标价，内部客户才会诚实说出自己需要多可靠；在「大家都免费」的世界里，每个人都宣称自己需要最高等级。
前四节是「怎么定风险」，这一节是「定完怎么用」。本章先把研发与 SRE 的结构性冲突摊开——它集中在四件都没有客观答案的事上：软件容错做到多深（少了产品脆弱得没法用，多了稳是稳了、功能却少得没人想用）、测试做到多厚（不够就是线上事故，过头就错过市场窗口）、发布频率多高（每次发布都是风险，该花多少精力降它）、金丝雀放多久放多大（窗口越长越安全，也越慢）。
四个问题，两边各有立场，谁也说服不了谁。错误预算不回答它们，而是给它们一个共同的计价单位。构造极简：产品管理层定 SLO；实际可用性由中立第三方——监控系统——测出；两者的差额就是本季度剩余的「可以不可靠」额度。规则只有一条：只要还有余额，新版本就可以发。
它真正改变的是激励结构。其一，它给「目标定太高」也标了价：团队若老是发不动版本，可以选择放宽 SLO 换回创新空间——预算是双向的，不只是一根打人的棍子。其二，天灾也照扣：机房故障或网络抖动同样吃预算，看着「不公平」，但正因如此两边都有动力去减少它，而不是甩锅给不可抗力。其三，事故的性质变了：出事不再是「坏事」，而是创新过程中预期之内、由双方共同管理的开销——这才是「拥抱风险」的真正含义。
表 1 · 两种可用性度量：什么时候用哪个
| 时间可用性（钟表法） | 请求成功率（聚合可用性） | |
|---|---|---|
| 算法 | 正常时间 ÷ (正常时间 + 停机时间) | 成功请求数 ÷ 总请求数 |
| 适合 | 单机房、单实例，故障接近「要么活要么死」 | 全球分布、做了故障隔离的服务；批处理管线（按记录数） |
| 能量「半死不活」吗 | 不能——只要还有部分流量在服务，就算不出停机时长 | 能——局部失败如实计入分子分母 |
| 可执行性 | 弱：「今年还剩 30 分钟」难以指导今天的决策 | 强：250 万 × 99.99% → 今天还能失败 250 次 |
| 代价 | 与 SLA 合同口径一致，对外好解释 | 请求并不等价（心跳 ≠ 结账），是个已知的近似 |
表 2 · 该定几个 9：按服务类型反推，并写清定高了的代价
| 服务类型 | 典型量级 | 为什么是这个量级 | 定得更高的代价 |
|---|---|---|---|
| 内部工具 / 离线分析 | 99%（年约 3.65 天） | 用户是同事，坏了能等；吞吐比延迟重要 | 几乎纯浪费——多买的冗余没人受益 |
| 高速演进的消费级产品 | 刻意低于企业级 | YouTube 例：此刻迭代速度的价值大于多出的可靠性 | 换来的稳定，抵不上错失的产品机会 |
| 面向企业、带 SLA | 99.9% 起（年约 8.8 小时） | 有合同与赔付；内部目标须高于对外承诺留缓冲 | 需值班、冗余与像样的监控，成本上台阶 |
| 直接绑收入的交易链路 | 99.99%（年约 52 分钟） | 停机可直接换算成钱，用 $900 式算术定 | 要跨地域容灾、秒级检测与自动回滚 |
| 被很多服务依赖的底座 | 分层供给，不设单一值 | Bigtable 例：低延迟档与高吞吐档分开建、分开计费 | 一刀切必然双输：一批人多付钱，另一批人体验垮 |
| 几乎任何服务 | 99.999% 通常不划算 | 用户侧链路更不可靠，增量掉进背景噪音 | 下一个增量可能比上一个贵 100 倍 |
表 3 · 预算烧光时的四种反应：哪个是制度，哪个是装饰
| 反应 | 做法 | 后果 |
|---|---|---|
| 冻结发布 | 停掉新功能，只放紧急修复与安全补丁，直到回到 SLO 之上 | 制度生效——本章设计的默认路径 |
| 放宽 SLO | 与产品方重新谈：这个服务确实不需要这么稳 | 合法且被鼓励——前提是显式改目标并公开记录 |
| 加大投入 | 把工程资源转向可靠性，压低消耗速率 | 合法，但要认账：这段时间功能产出会掉 |
| 逐次豁免 | 「可这个功能特别重要」，本次照发 | 装饰品——豁免一旦成惯例，预算就退化成一个数字 |
本章教你给自己的服务定目标，但目标能不能兑现取决于你脚下那一层。Google 后来在《服务可用性的演算》里补上了这条：你的可用性不可能高于所有关键依赖之和。背后是纯粹的乘法——5 个关键依赖各做到 99.99%，仅这一项就把上限压到约 99.95%（0.9999⁵ ≈ 0.9995），你一行 bug 还没写就已不达标。由此得出的法则很硬：关键依赖的目标要比你自己的高一个 9——定目标前先数一遍依赖，比事后加冗余便宜得多。
「错误预算」已经从 Google 的内部机制变成行业标配：主流可观测性平台把「预算燃尽率」做成默认面板，云厂商把 SLO 做成托管产品，发布系统直接读预算余额决定放不放行。更深的影响在心智上——「我们的目标是 100% 可用」这句话，今天在稍微专业的技术评审里已经会被追问「凭什么、你算过成本吗」。面试与架构评审里对应几个高频问题：你们的 SLO 是多少、怎么定出来的？可用性用时间算还是用请求成功率算？预算烧光会发生什么？关键依赖各是多少个 9、乘起来还够不够？答不上最后一问的人，通常也没真读懂这一章。
99.99% 的系统，一天失败 250 次仍然达标；以及那个把「一个 9」折成 $900 的成本收益算式。《Site Reliability Engineering》Ch3 Embracing Risk（Google 官方全文）↗99.99% 而非 100%，且关键依赖要比你自己的目标再多一个 9。The Calculus of Service Availability, ACM Queue 2017（Google Research 官方页）↗ · 官方 PDF ↗99.9 百分位——论文写道，SLA 形如「在每秒 500 个请求的峰值负载下，99.9% 的请求要在 300 毫秒内完成」，因为按平均值定目标会系统性忽略最难受的那批用户。Dynamo: Amazon's Highly Available Key-value Store, SOSP 2007（Amazon CTO 官网 PDF）↗99.9% 和 99% 差不了几次错误，统计上几乎不可区分）；不少关键依赖是外部 SaaS，你既管不了也看不清它的真实可用性。这也是后来《SRE Workbook》补一整章讲「非 Google 环境怎么实施 SLO」的原因。① 核心命题：过了某个点，提高可靠性对服务反而更糟。SRE 要做的是让服务承担的风险与业务愿意承担的风险显式对齐，而非无限追求不出事。
② 成本非线性：下一个增量可能比上一个贵 100 倍；花在冗余资源与机会成本（没做成的功能）两处，后者不出现在任何账单上。
③ 用户感知有地板：手机、Wi-Fi、宽带本身更不可靠——用一部 99% 可靠手机的用户，分不出 99.99% 和 99.999%。
④ 度量换口径：时间可用性对全球分布式服务基本没意义（几乎从不整个躺平），改用聚合可用性 = 成功请求数 ÷ 总请求数。能盯的整数长这样：每天 250 万请求 × 日目标 99.99% → 当天可失败 250 次。
⑤ 消费级服务四问：要什么可用性水平 / 故障形状是否同等伤害 / 用成本把它钉住 / 有没有更关键的别的指标（AdSense 真正要守的是延迟）。
⑥ 成本算式最实用：年收入 $1M、99.9% → 99.99% 多出 0.09% 在线时间，值 $900——改造成本低于它就做，高于就别做。
⑦ 基础设施要分层：Bigtable 的低延迟与高吞吐客户需求冲突，正解是分档建集群、挂不同 SLO、按不同价格计费——免费时人人都要最高等级。
⑧ 错误预算：产品定 SLO、监控做中立第三方、差额即额度；有余额就发，烧光就冻结。它也给「目标定太高」标了价（可反向放宽 SLO），且天灾照扣，逼双方一起减少它。
⑨ 别忘了脚下：你不可能比关键依赖之和更可用——5 个 99.99% 的依赖已把上限压到约 99.95%；法则是关键依赖要比你的目标高一个 9。