6.1 服务水平指标、目标与错误预算

概述与动机

站点可靠性工程（SRE），这门由Google开创、并记录在Site Reliability Engineering一书中的学科，贡献了本主题直接建立于其上的一套词汇：一项服务水平指标（SLI）是对一项服务健康状况的直接测量信号，请求延迟、错误率、可用性。一项服务水平目标（SLO）是那项指标的目标范围，例如99.9%的请求在200毫秒内成功。而一份错误预算则是被允许的差额，被允许失败的那0.1%的请求，它不被当作一个需要消除的缺陷，而是被当作一种可花费的资源，可以被刻意用来承担风险：发布一项有风险的变更，运行一次实验，或者干脆接受完美的可靠性既不可实现、过了某个点之后也不值得为之付出代价这一事实。

最后这个理念，把错误预算当作一种可花费的资源、而不是一个要向零最小化的数字，是本主题、也可以说是整个这一部分中最重要的单一概念。它解决了一种困扰许多组织的张力：工程想要发布功能、承担合理的风险；运营想要最大限度的稳定性。没有一份共享的、量化的错误预算，这会变成一场无休止的、充满政治色彩的协商。有了它，这就变成了一条简单、客观的规则：只要预算还有余量就自由花费，一旦预算耗尽就自动放慢速度、优先处理稳定性工作。这把一场哲学分歧变成了一道算术题。

对大团队而言，服务水平目标和错误预算，正是让可靠性变得可测量、可协商，而不是一个每个团队都悄悄未能达到、却又对此隐隐感到愧疚的、无法企及的、未被言明的绝对值的东西。企业组织用服务水平目标，在团队之间以及与客户之间设定清晰的、具有合同约束力的预期；运营关键公共基础设施的政府组织，用它们来设定站得住脚的、可以向公众交代的可靠性目标，而不是一个没有任何真实系统能够维持的、不可能实现的完美标准。

核心原则

100%的可靠性，对几乎任何系统而言都是错误的目标。 它通常无法实现，超过某个点之后追求它，会积极地用速度换取没有任何有意义用户收益的东西。
一项服务水平目标应当反映用户真正会注意到、并在意的东西， 而不是一个仅仅因为听起来令人安心而被选中的任意整数。
错误预算把可靠性变成一种可花费的资源， 给工程和运营双方都提供了一条共享的、客观的规则，用以判断何时该快速发布、何时该放慢速度。
服务水平指标必须在可能的情况下从用户的真实体验中测量， 而不只是从一个内部系统自我报告的健康状况中测量。
错误预算耗尽会触发一个预先确定、已经商定好的应对方案， 而不是每次发生时都临时争论一番。

建议

选择反映真实用户体验的服务水平指标

选择尽可能贴近真实用户体验测量出来的指标：在边缘或负载均衡器处测量的请求成功率和延迟，而不仅仅是内部服务健康检查，那种检查可能在用户遭遇真实问题时仍然报告”健康”。一项衡量用户实际上从未注意到的东西的服务水平指标，比如一个内部组件在技术上是启动的，而整体请求依然失败，无论它埋点起来多么容易，衡量的都是错误的东西。

根据用户真正需要什么、而不是一个任意的整数来设定服务水平目标

抵制仅仅因为”99.99%正常运行时间”这样的目标听起来令人印象深刻地严谨，就反射性地设定它的冲动。相反，研究用户真正注意到、并在意的可靠性水平，依据历史事件数据、用户研究，以及实现每一个额外可靠性增量所展现出的成本，因为从99.9%提升到99.99%所需的工程努力，往往远多于从99%提升到99.9%所需的努力，而用户能感知到的收益却在递减，最终变得微不足道。

把错误预算当作一种可花费的资源，配上一个预先确定的耗尽应对方案

直接从服务水平目标计算错误预算（一个持续30天、99.9%的可用性目标，允许大约43分钟的停机时间），并持续跟踪对照它的花费。提前、并且在任何具体事件发生之前，就商定好当预算耗尽时会发生什么：一项常见、有效的政策是，功能工作暂停，团队的优先级自动转向可靠性工作，直到预算恢复。这条预先确定的规则，消除了在每一次具体事件中都在压力下重新争论这项权衡的必要。

用错误预算做出刻意的、有依据的风险决策

一份健康的、未被花费的错误预算，不是一件应当被囤积的东西；它是承担合理风险的许可，发布一项风险有所提高但可接受的变更，运行一次混沌工程实验（姊妹书籍software-engineering-guide的混沌工程主题直接涵盖了这一点），或接受一次风险更高的架构变更，因为这份预算的存在，正是为了被刻意花费，而不是被原封不动地保留下来。一份从未被花费的错误预算，暗示的要么是一个过度保守的团队，要么是一项相对于实际已达成可靠性而言设得过于宽松的服务水平目标，两者都值得调查。

定期审阅并修订服务水平目标，依据证据，而不是惯性

一项多年前设定的服务水平目标，可能已经不再反映当前的用户预期、系统架构或业务优先级。以一个固定的节奏审阅服务水平目标，检查历史上已达成的可靠性、用户反馈，以及这个目标是否依然代表着一个有意义的权衡点，而不是一个容易达成、本可以收紧以便在别处释放更多速度的目标，或一个团队实际上已经放弃去达成的不切实际的目标。

权衡取舍：利与弊

方案	优点	缺点
没有正式的服务水平目标（隐含的”尽可能可靠”）	没有设置开销	速度与稳定性之间无休止、缺乏依据的协商；没有共享的规则
抱负性的、非常高的服务水平目标（99.99%以上）	传递出对可靠性的重视	往往是不必要的成本；超过用户真正注意到的部分之后回报递减
基于证据、扎根于用户体验的服务水平目标	反映真实价值；站得住脚且可实现	需要真实的数据和分析才能正确设定
配有预先确定耗尽应对方案的错误预算	消除了临时协商；决策客观、迅速	需要组织层面的认同和纪律，才能真正兑现这条预先确定的规则

核心张力是抱负与可实现性之间的张力。一个高企、有抱负的服务水平目标，感觉上传递出对质量的重视，但追求超出用户真正能注意到的可靠性，会用真实的速度换取没有真正收益的东西，而一个团队实际上从未达成过的不切实际的目标，会教会所有人从此不再认真对待这项服务水平目标。解决这种张力的办法，是把服务水平目标建立在真实证据之上，用户注意到了什么，系统历史上达成过什么，每一个额外增量花费了什么，而不是建立在抱负或想在记分卡上显得严谨的愿望之上。

与团队讨论的问题

我们当前的服务水平目标是建立在关于用户真正注意到什么的证据之上，还是因为一个高数字感觉上足够严肃而抱负性地设定的？ 如果可以的话，追溯你当前目标的来源，诚实地评估它反映的是真实的用户研究，还是单纯的工程直觉。
我们是否有一个预先确定、已经商定好的错误预算耗尽应对方案，还是这项权衡每次发生时都要重新争论？ 如果诚实的答案是后者，那这个缺口值得在下一次事件迫使这场争论在压力下发生之前弥补。
我们的错误预算是否曾经真正被刻意地花费在一项经过计算的风险变更或一次实验上，还是它只会通过事件被意外消耗？ 一份从未被刻意花费的预算，可能意味着一个过度谨慎的团队，错过了这份预算本应促成的合理机会。
我们的服务水平指标是从真实的用户体验中测量的，还是从可能无法反映用户实际遭遇情况的内部系统健康状况中测量的？ 对照这个具体的区分检查你当前的埋点；即使在其他方面成熟的可靠性项目中，这也是一个常见的缺口。
我们上一次对照当前证据审阅服务水平目标是什么时候，有没有什么变化，用户预期、系统架构、业务优先级，值得据此修订它？ 如果你想不起最近的一次审阅，这种缺失本身就值得讨论。
把我们当前的服务水平目标提升一个额外的”9”，在工程努力上会花费我们什么代价，这份代价会被任何真实的用户收益证明是合理的吗？ 这种具体的成本收益框架，有助于把抱负与可实现性之间的张力，建立在真实数字之上，而不是抽象的偏好之上。

行业视角

初创公司。 在非常早期，正式的服务水平目标往往没有必要，当时团队能够直接、非正式地应对可靠性问题。一旦你有了真正依赖正常运行时间的付费客户，就采用至少一个粗略、非正式的服务水平目标，因为一个明确目标的纪律，哪怕只是被松散地跟踪，也能比大多数年轻公司所想的更早地帮助在功能压力下确定可靠性工作的优先级。

小型企业。 大多数现代托管和可观测性平台以最低的设置成本报告基本的正常运行时间和延迟数据；用它来设定一个简单、可实现的服务水平目标，而不是一个你在有限的运营能力下无法现实地跟踪或据以行动的抱负性目标。

企业。 在这个规模上，服务水平目标常常是具有真实经济后果的合同性服务水平协议的基础，这让基于证据的目标设定和有纪律的错误预算管理尤为重要。投资于真正扎根于用户体验的服务水平指标，而不是图方便的内部健康检查，并在压力出现之前，就正式地、在高管认同下建立起预先确定的耗尽应对政策。

政府。 关键基础设施的公共部门可靠性目标，有时带有法律或监管方面的分量，一个在审计或一次公开事件中被发现不切实际、未能达成的目标，会显著损害机构的可信度。基于真实的、有文档记录的用户和使命需求来设定目标，并公开透明地说明错误预算所代表的那种刻意权衡，而不是暗示一个无法企及的完美标准。

案例

企业。 一家云存储公司多年来一直以”最大限度的正常运行时间”为目标，没有正式的服务水平目标，这导致产品团队（想要快速发布功能）与基础设施团队（想要最大限度的谨慎）之间长期存在、未被解决的张力，在每一次发布规划会议上都重新争论一遍。采用一项正式的99.95%可用性服务水平目标，配以一份明确的错误预算和一项预先确定的政策，预算耗尽时功能工作自动暂停，完全解决了这种反复出现的协商：两个团队能够看到同一个数字，认同同一条规则，该公司报告称，在预算健康的时期，发布的功能数量出现了可衡量的增长，与此同时，在随后一年中预算真正耗尽的两个时期，也出现了可衡量的、刻意的放缓，完全符合这项政策的初衷。

政府。 一家国家气象局的公共预警系统，多年来一直在”始终可用”这种非正式的预期下运作，没有有文档记录的目标，也给尝试满足一个未被言明、实际上不可能达成的标准的待命团队带来了巨大、未被解决的运营压力。一份新采用的正式服务水平目标，99.9%的可用性，配以一份清晰传达给公众的错误预算解释，让运营团队获得了明确的、站得住脚的许可，在预算范围内安排计划内的维护窗口，而此前那种未被言明的”始终可用”预期，即使在真正为了系统长期健康而必要时，也让这样做在政治上变得困难。直接解释错误预算概念的公开沟通，而不是把它隐藏起来，被公众视为诚实、成熟运营实践的一个标志，而不是对服务质量承诺的削弱，因而受到好评。

商业理由：动机、投资回报与总拥有成本

正式采用服务水平目标和错误预算的回报，是用一条单一、共享、客观的规则，解决一场原本会无休止、且在政治上代价高昂的速度与稳定性之间的协商。上面的云存储案例具体展示了这一点：两个团队之间多年反复出现、未被解决的张力，被一个单一的正式目标和一项预先确定的政策所解决，释放出了此前一直花在反复重新争论同一项权衡上的大量组织精力。

总拥有成本包括正确设定一个基于证据的目标所需的分析工作，以及即使在有压力要不顾一切发布一项特别想要的功能时，依然兑现预先确定的耗尽应对方案的纪律。这份纪律的成本是真实的，但它远低于一场无休止地在每一个规划周期中消耗组织精力的、未被解决的持续协商所带来的成本。

反模式与陷阱

设定一个没有任何证据支撑的抱负性服务水平目标： 产生一个团队不再认真对待的不切实际目标，或一个追逐用户根本注意不到的收益的、不必要地昂贵的目标。
没有预先确定的错误预算耗尽应对方案： 迫使同样那场艰难的权衡争论每次发生时都要在压力下重来一遍。
从内部系统健康状况而不是真实的用户体验中测量服务水平指标： 可能在用户遭遇真实问题时仍然报告”健康”。
从不真正刻意地花费一份健康的错误预算： 可能意味着过度的谨慎和被错过的合理机会。
设定一次目标之后从不重新审视它： 随着用户预期、架构和优先级的变化，一项服务水平目标会变得过时。
在压力下把错误预算政策当作可有可无的东西对待： 一条只要不方便就被推翻的预先确定规则，不提供任何真实的决策价值。

成熟度模型

第一级，启动： 可靠性目标是隐含的或抱负性的，没有定义正式的服务水平目标、服务水平指标或错误预算。
第二级，发展： 一些服务拥有一个非正式的服务水平目标，但服务水平指标可能不反映真实的用户体验，也没有预先确定的耗尽政策。
第三级，标准化： 基于证据的服务水平目标，配以真实的用户体验服务水平指标和一项预先确定的错误预算耗尽政策，在关键服务上被一致地建立起来。
第四级，管理： 错误预算被主动、刻意地花费在经过计算的风险承担上，服务水平目标按一个固定的、基于证据的节奏被审阅和修订。
第五级，协奏： 服务水平目标和错误预算在全组织范围内被整合，成为平衡速度与稳定性的共享、客观机制，组织能够指出这个框架所促成的、一场缺乏依据的协商本不会同样有效地解决的具体决策。

讨论思路

我们当前的服务水平目标是建立在证据之上，还是建立在抱负之上？
我们是否有一个在压力之下也会真正兑现的、预先确定的错误预算耗尽应对方案？
我们上一次刻意地把一份健康的错误预算花费在一项经过计算的风险上，是什么时候？
我们的服务水平指标衡量的是真实的用户体验，还是图方便的内部健康检查？
把我们的服务水平目标提高一个额外的”9”，会花费我们什么代价，这份代价会是合理的吗？

要点回顾

一项服务水平指标（SLI）衡量的是真实的用户体验；一项服务水平目标（SLO）是它基于证据的目标；一份错误预算是被刻意允许花费的差额。
100%的可靠性通常是错误的目标；把你的服务水平目标建立在用户真正注意到的东西，以及每一个额外增量真正花费了什么之上。
把错误预算当作一种配有预先确定耗尽应对方案的可花费资源，消除每次都要在压力下重新争论速度与稳定性的必要。
从真实的用户体验中测量服务水平指标，而不仅仅是图方便的内部健康检查。
定期审阅并修订服务水平目标，依据证据，因为随着系统及其用户的变化，一个过时的目标会失去它的用处。

参考文献与延伸阅读

Site Reliability Engineering: How Google Runs Production Systems，Betsy Beyer、Chris Jones、Jennifer Petoff、Niall Richard Murphy编（定义服务水平指标、服务水平目标和错误预算的奠基性著作）。
The Site Reliability Workbook，Betsy Beyer、Niall Richard Murphy、David K. Rensin、Kent Kawahara、Stephen Thorne编（实施服务水平目标和错误预算的实用指导）。
Implementing Service Level Objectives，Alex Hidalgo著（一份全面的、面向从业者的服务水平目标设计与操作化指南）。
Accelerate: The Science of Lean Software and DevOps，Nicole Forsgren、Jez Humble、Gene Kim著（可靠性实践与交付绩效之间的关系）。