错误预算在监管SLO中起到什么作用
本书的其他章节讨论了紧张局势之所以在产品研发小组和SRE 小组中产生，是因为他们基于不同的指标进行自己的绩效评估。产品研发的绩效是如何很大程度通过产品研发速度体现的，这会激励员工尽可能快地创建新的代码。同时，SRE 的绩效表现取决于该服务的可靠性，这意味着SRE 会对高频率的更改提出抗议。两个团队之间的信息不对称进一步加剧了这种内在的紧张局势。产品开发者更了解编写和发布他们的代码所需的时间，而 SRE 则更关注服务可靠性程度（以及生产环境中的其他相关事项）。这些紧张关系往往反映出他们自己对于应该投入到工程实践中的努力程度的不同意见。下面列举一些典型的紧张局势。
软件对故障的容忍度
对意外事件的容忍程度有多高?做得太少，我们就只能设计出一个脆弱无用的产品。做得太多，我们的产品可能没有人会使用（但运行非常稳定）。
测试
同时，没有足够的测试，可能会有令人尴尬的故障发生，泄露隐私数据，或发生其他会上报纸的故障事件。而过于强调测试可能会失去市场先机。
发布频率
每一次发布都是有风险的。我们应该花多少时间在减少风险上?
金丝雀测试（Canary）的持续时间和大小
测试新发布的代码的最好做法就是在一个典型工作负载的服务子集中进行测试，这种做法通常被称为金丝雀测试。我们要等多久，而且测试范围有多大?
通常，现有团队已经找到了某种非正式的风险与成本的平衡点。不幸的是，人们很少能证明这种平衡是最佳的，而不是单单由参与谈判的工程师的谈判能力决定的。这些决定也不应该受办公室政治、不理智的恐惧或一厢情愿的希望所驱使（事实上，Google SRE 的非官方座右铭就是"希望不是一种策略"）。
相反，我们的目标是定义一个双方都同意的客观指标，该指标可以用来指导谈判的方向。一项决策越是基于数据做出的，常常就越好。
页:
[1]