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

我们的实际做法如下∶
●产品管理层定义一个 SLO，确定一项服务在每个季度预计的正常运行时间。
● 实际在线时间是通过一个中立的第三方来测算的∶我们的监控系统。
● 这两个数字的差值就是这个季度中剩余的不可靠性预算。
● 只要测算出的正常在线时间高于SLO，也就是说，只要仍然有剩余的错误预算，就可以发布新的版本。

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

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

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

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

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

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

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

关键点

● 管理服务的可靠性主要在于管理风险，而且管理风险的成本可能很高。
● 100%可能永远都不是一个正确的可靠性目标∶ 不仅是不可能实现的，而且它通常比一项服务的用户期望的可靠性大得多。我们要将服务风险和愿意承担的业务风险相匹配。
● 错误预算在 SRE和产品研发团队之间调整激励，同时强调共同责任。错误预算使得讨论发布速率更容易，同时可有效地减少任何关于事故的讨论。这样，多个团队可以毫无怨言地对生产环境风险度达成一致。

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

我们的实际做法如下∶
●产品管理层定义一个 SLO，确定一项服务在每个季度预计的正常运行时间。
● 实际在线时间是通过一个中立的第三方来测算的∶我们的监控系统。
● 这两个数字的差值就是这个季度中剩余的不可靠性预算。
● 只要测算出的正常在线时间高于SLO，也就是说，只要仍然有剩余的错误预算，就可以发布新的版本。

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

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

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

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

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

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

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

关键点

● 管理服务的可靠性主要在于管理风险，而且管理风险的成本可能很高。
● 100%可能永远都不是一个正确的可靠性目标∶ 不仅是不可能实现的，而且它通常比一项服务的用户期望的可靠性大得多。我们要将服务风险和愿意承担的业务风险相匹配。
● 错误预算在 SRE和产品研发团队之间调整激励，同时强调共同责任。错误预算使得讨论发布速率更容易，同时可有效地减少任何关于事故的讨论。这样，多个团队可以毫无怨言地对生产环境风险度达成一致。