使用错误预算的目的[1]

作者：Mark Roth

编辑：Carmela Quinito

本书的其他章节讨论了紧张局势之所以在产品研发小组和SRE 小组中产生，是因为他们基于不同的指标进行自己的绩效评估。产品研发的绩效是如何很大程度通过产品研发速度体现的，这会激励员工尽可能快地创建新的代码。同时，SRE 的绩效表现取决于该服务的可靠性，这意味着SRE 会对高频率的更改提出抗议。两个团队之间的信息不对称进一步加剧了这种内在的紧张局势。产品开发者更了解编写和发布他们的代码所需的时间，而SRE则更关注服务可靠性程度（以及生产环境中的其他相关事项）。

这些紧张关系往往反映出他们自己对于应该投入到工程实践中的努力程度的不同意见。下面列举一些典型的紧张局势。

软件对故障的容忍度

对意外事件的容忍程度有多高？做得太少，我们就只能设计出一个脆弱无用的产品。

做得太多，我们的产品可能没有人会使用（但运行非常稳定）。

测试

同时，没有足够的测试，可能会有令人尴尬的故障发生，泄露隐私数据，或发生其他会上报纸的故障事件。而过于强调测试可能会失去市场先机。

发布频率

每一次发布都是有风险的。我们应该花多少时间在减少风险上？

金丝雀测试（Canary）的持续时间和大小

测试新发布的代码的最好做法就是在一个典型工作负载的服务子集中进行测试，这种做法通常被称为金丝雀测试。我们要等多久，而且测试范围有多大？

通常，现有团队已经找到了某种非正式的风险与成本的平衡点。不幸的是，人们很少能证明这种平衡是最佳的，而不是单单由参与谈判的工程师的谈判能力决定的。这些决定也不应该受办公室政治、不理智的恐惧或一厢情愿的希望所驱使（事实上，Google SRE的非官方座右铭就是“希望不是一种策略”）。

相反，我们的目标是定义一个双方都同意的客观指标，该指标可以用来指导谈判的方向。一项决策越是基于数据做出的，常常就越好。

错误预算的构建过程

为了基于客观数据做出决策，两个团队需要共同定义一个基于服务水平目标（SLO）的季度错误预算（参考第4章）。错误预算提供了一个明确的、客观的指标来决定服务在一个单独的季度中能接受多少不可靠性。这个指标在SRE与产品研发部门的谈判中将政治因素排除。

我们的实际做法如下：

● 产品管理层定义一个SLO，确定一项服务在每个季度预计的正常运行时间。

● 实际在线时间是通过一个中立的第三方来测算的：我们的监控系统。

● 这两个数字的差值就是这个季度中剩余的不可靠性预算。

● 只要测算出的正常在线时间高于SLO，也就是说，只要仍然有剩余的错误预算，就可以发布新的版本。

例如，假设一项服务的SLO是每季度99.999%的查询成功率。这就意味着，这项服务在给定季度的错误预算是0.001%。如果某个问题导致我们这个季度产生了0.0002%的故障，就相当于占用了这项服务20% 的季度错误预算。

好处

错误预算的主要好处就是它能够激励产品研发和SRE一起找出创新和可靠性之间合理的平衡点。

许多产品使用这个控制回路来调节发布的速度：只要系统符合SLO，就可以继续发行新版本。如果频繁地违反SLO 导致错误预算被耗尽，那么发布就会暂停，同时需要在系统测试和开发环节投入更多资源使得系统更有弹性，以使性能得到提升。

有比这种简单的开/关技术更巧妙和有效的方法：[2]例如，当SLO 违规导致错误预算接近耗尽时，将发布的速度减慢，或者回退到上一版本。

例如，如果产品研发人员想要在测试上节约时间或者想要提高发布速度并且SRE 表示反对时，那么就可以通过错误预算指导决策。当预算剩余很多时，产品研发人员就可以承担更多的风险。如果预算接近耗尽，产品研发人员自身将会推动更多的测试或者放慢发布的速度，因为他们不想冒着用尽预算的风险和拖延他们的程序上线。实际上，产品开发团队这样就开始进行自我监管。他们知道预算还剩多少，并且可以控制自己的风险。（当然，这要求SRE在SLO达不到的时候有权停止程序的发布。）

如果网络中断或者数据中心发生故障影响了SLO，怎么办？这样的事件也会给错误预算带来不良的影响，会使本季度剩余部分的发布将会减少。整个团队会支持这种发布频率的降低，因为每个人都有义务保障服务正常运行。

利用错误预算可以同时找到制定得过高的可用性目标，显示出它们所导致的灵活性和创新速度方面的问题。如果团队无法发布新的功能，他们可以选择降低SLO（从而增加错误预算）来提高创新速度。

关键点

● 管理服务的可靠性主要在于管理风险，而且管理风险的成本可能很高。

● 100%可能永远都不是一个正确的可靠性目标：不仅是不可能实现的，而且它通常比一项服务的用户期望的可靠性大得多。我们要将服务风险和愿意承担的业务风险相匹配。

● 错误预算在SRE和产品研发团队之间调整激励，同时强调共同责任。错误预算使得讨论发布速率更容易，同时可有效地减少任何关于事故的讨论。这样，多个团队可以毫无怨言地对生产环境风险度达成一致。