服务质量目标：先挑对该量的东西，再谈几个 9

一句话

你以为定 SLO 就是挑「几个 9」，其实那是最后一步、也是最不值钱的一步。功课全在前面：先弄清用户在乎什么，翻译成一个能测的量（SLI），写死在哪测、按多长窗口聚合，再挑一个刚好够用、且你敢在优先级争论里当裁判用的数（SLO）。SLA 是把它写进合同并附上赔付条款——SRE 深度参与前两步，第三步交给业务与法务。指标选错，后面几个 9 都是自欺。

Glossary · 术语表

坐标

本章紧接 Ch3「拥抱风险」，同属 Part II「原则」。Ch3 论证了可靠性目标必须低于 100% 并给出错误预算，却留下一个空白：那个具体的数怎么定、拿什么量。本章填这个空白。往下，Ch6「监控」讲告警如何由 SLO 驱动。对应现实：任何需要回答「我们的服务算不算好」「这次能不能发」「对外该承诺什么」的团队。

这章要解决什么

病一：三个词混着用。工程师嘴里的「SLA」多半指内部目标，销售嘴里的是合同条款，面板上写的其实是一条 SLI 曲线——词都对不上，讨论收不了尾。书给的判据只有一句：问「达不到会怎样」——没有明确后果的，几乎肯定是 SLO 而不是 SLA。病二：量错了东西。你量「服务端有没有返回 200」，用户在乎「有没有在能忍的时间内拿到结果」——这两件事平时重合，故障时剧烈分叉。

病三：没有共同裁判量，优先级只能靠嗓门。研发按上线量考核、SRE 按不出事考核，同一件事把两边往反方向拽。书因此立了一条锋利的自检：如果你从来没法靠引用某条 SLO 赢下一次优先级讨论，那条 SLO 大概不值得存在。

不解决会怎样？一个日均 2000 万次调用的结算接口，成功率 SLO 定 99.9% 意味着每天允许失败约 2 万次；定 99.99% 只剩 2000 次，一次三分钟的批量报错就能吃光。只因小数点后多写一位，「这版该不该发」的答案就完全相反——而这个数若没被认真定过，答案就由会议室里级别最高的人给出。

核心内容，讲透

1. 三个词：用「违约有没有后果」一刀切开

SLI 是量——注意「精心定义」四个字，第 3 小节整节都在解释它。SLO 是线，结构无非 SLI ≤ 目标 或 下界 ≤ SLI ≤ 上界。SLA 是合同：SLO 加上「达不到会怎样」，后果通常是退款或罚金。书还明确了分工：SRE 通常不写 SLA（它紧贴业务与产品决策），但要评估这些 SLO 有多难达到，并负责别让赔付条款被触发。对照：Google 搜索对公众没有 SLA、只有内部 SLO，面向企业售卖的产品线才有。

表 1 · 三个词一刀切开：问「达不到会怎样」

2. 挑指标：先问用户在乎什么

全章最常被跳过的一句忠告：从「容易测的东西」开始，你只会得到一堆没用的 SLO。正确顺序是先弄清用户在乎什么、再想办法逼近它——用户在乎的往往难测，只能找代理量，但「找一个逼近用户感受的代理量」和「在现成指标里挑一个」是两件事。数量上也有讲究：太多没有一条真被盯，太少留下大片盲区，答案是少数几个（表 2）。其中一条边界值得单拎：正确性人人在乎，但它是数据的属性、不是基础设施的属性，通常不由 SRE 兜底。

表 2 · 不同类型的系统，默认该盯哪几个 SLI

3. 在哪测、按什么窗口聚合——魔鬼全在这里

先说在哪测。多数指标最自然的采集点在服务端，但书里警告：只在服务端测，会漏掉一整类「伤到用户却不体现在服务端指标上」的问题——页面 JavaScript 卡顿时，后端每个请求都是干净的 200、耗时也漂亮，用户却盯着白屏。这时「页面多久变得可用」才是更好的代理量。

再说聚合，两个陷阱。一是窗口：一个系统偶数秒服务 200 请求/秒、奇数秒服务 0，另一个稳定 100 请求/秒，分钟平均一模一样，但前者的瞬时负载是后者的两倍——窗口一拉长，尖峰就被抹平。二是平均：它掩盖了「绝大多数请求很快、同时有一条长尾慢得多得多」的真相。所以书立了一条原则：大多数指标应当被当成「分布」而不是「平均值」来想。高位百分位（p99、p99.9）给一个可信的最坏值，中位数刻画典型情况；方差越大，典型体验越被长尾左右。书还引了一条结论：人们通常宁要稍慢但稳定的系统，也不要平均更快、抖动却大的。

最后是标准化。书建议把 SLI 定义做成模板：聚合区间（按 1 分钟平均）、聚合范围（一个集群的所有任务）、测量频率（每 10 秒）、算哪些请求（黑盒探针的 HTTP GET）、在哪取数、延迟怎么算（到最后一个字节）。这些琐碎约定决定两个部门能不能对上账——「到第一个字节」和「到最后一个字节」在流式响应里能差一个数量级。

4. 一条合格的 SLO 长什么样

合格的写法把百分位、聚合窗口、测量点一并写死（书里的样板见表 3 末行）。在乎曲线形状就写多条（90% / 1 ms、99% / 10 ms、99.9% / 100 ms）；负载分几类就按类分开定：批量客户端看吞吐（95% 的 Set 在 1 s 内），交互客户端看延迟（99% 的小负载 Set 在 10 ms 内）——把不同人群塞进一条 SLO，通常两头都不满意。另有来自 Ch3 的硬约束：要求 SLO 被 100% 满足既不现实也不可取，正确做法是给出错误预算并按天跟踪消耗。

5. SLO 怎么变成行动：四步控制回路

SLO 驱动一个闭环：① 测量 SLI → ② 与 SLO 比、判断要不要动 → ③ 想清楚做什么才能达标 → ④ 去做。书给的例子：发现延迟在涨、按趋势几小时后破线，于是验证「是不是 CPU 打满了」，然后加机器摊负载。没有 SLO，你既不知道该不该动手，也不知道什么时候动手。这正是 Ch6 那条原则的上游——告警该由「SLO 快破了」触发，而不是「某台机器 CPU 到 80%」。

6. 期望管理：留安全边际，并且别做得太好

公开 SLO 本身就是在设定预期。第一招留安全边际：内部用一个比对外宣称更严的 SLO，慢性问题在外部可见之前就有空间处理。第二招极其反直觉：别超额交付——用户依赖的是你实际的表现，而不是你宣称的承诺。于是有了本章最有名的故事：Google 的分布式锁服务 Chubby 长年可用性远高于 SLO，好到所有服务方都默认它「永远在」、谁都不写降级路径，它一旦真抖一下就引发一大批不相干的服务同时故障。SRE 的对策是计划内停机：季度实际可用性超出目标时主动停一会儿、把实际表现拉回目标线，逼不合理的依赖尽早暴露，而不是攒到某次真故障时一起爆发。

关键权衡与选型

这章的权衡不在「用哪个技术」，而在线画在哪、写多细、由谁守。

表 3 · 同一条延迟 SLO 的四种写法：从没用到能用

表 4 · 选目标的五条纪律（书中给出），以及违反它的代价

定紧还是定松？定紧了：错误预算天天见底，发布冻结从例外变成常态，告警疲劳随之而来，团队最终学会无视告警——比没有 SLO 更糟。定松了：用户已经在打一星，面板还是全绿。折中是先按用户可感知的阈值定一条守得住的线，再把「什么时候收紧、收到多少」写进计划。

在哪测、要不要给 SLA？服务端便宜、全量、定位快但离用户最远；客户端最贴近真实体验，代价是埋点成本与更大噪声——多数团队的答案是混合：主线放在服务端以保证可稳定计量，另设一小组客户端指标校准，两者长期背离就说明主线量错了东西。至于 SLA，受众越广，日后想改动或撤销一条不明智的 SLA 就越难，所以对外务必保守，并把「怎么数」抠死：Google Compute Engine 的 SLA 就把 Downtime 定义为连续一分钟以上的中断，不满一分钟一概不计。

为什么重要 / 落到真实系统

这一章把「可靠性」从形容词变成了一套可交接的工程契约。今天 Prometheus、Grafana、Cloud Monitoring 里的 SLO 对象与错误预算消耗率（burn rate）告警，本质上都是它的产品化——「这次能不能发」的答案，从一场会议变成了一次查询。它也改写了面试的正确答法：被问「你们的 SLO 是多少」，只报一个 99.9% 不及格，合格的回答是一串——指标是什么、在哪层测、按什么窗口聚合、为什么是这个数、破了之后会发生什么。最后一问最见功底：说不出后果，那就还是一条装饰。

易错点与争议

• 把 SLA 当 SLO 说。最常见的口误，也最误事——对外多承诺一位小数，可能是一份要赔钱的合同。
• 只报平均值。平均对长尾不敏感，几乎总是错的度量。但只盯 p99.9 也有代价：高位百分位统计噪声大，请求量小的服务上会剧烈抖动、容易假告警。
• SLO 太多太细。几十条谁也守不住的目标等价于一条都没有。自检：过去半年有哪条 SLO 真的改变过一次排期？
• 「别照现状定」与「从历史趋势起步」的分歧（见上）。书怕被现状锁死，后来 Google 自己的实操指南怕定出一个没人信的数。折中：用历史定起点、用用户诉求定终点，并把收紧的时间表写进去。
• 「别超额交付」不能无脑照抄。Chubby 是内部基础设施、依赖方是同事，主动停机才行得通；对付费外部客户这么干基本是自杀，等价手段是把依赖治理放进架构评审与故障演练。
• 时代局限：2016 年成书时 SLO 多半还活在电子表格里，此后 burn-rate 多窗口告警、SLO-as-code、托管 SLO 面板才成标配（《The Site Reliability Workbook》2018 专门补了实施细节）。本章给的是方法论骨架，不是工具指南。

要点