产品研发部门和SRE 之间可以通过消除组织架构冲突来构建良好的合作关系。在企业中，最主要的矛盾就是迭代创新的速度与产品稳定程度之间的矛盾。正如上文所说，其表现形式可能是间接的。在SRE模型中，我们选择正面面对这种矛盾，使用的工具是错误预算。

"错误预算"起源于这样一个理念∶任何产品都不是，也不应该做到100%可靠（显然这并不适用于心脏起搏器和防抱死刹车系统等）。一般来说，任何软件系统都不应该一味地追求 100% 可靠。因为对最终用户来说，99.999% 和 100%的可用性是没有实质区别的（详见附录 A）。从最终用户到服务器之间有很多中间系统（用户的笔记本电脑、家庭WiFi、网络提供商和输电线路等），这些系统综合起来可靠性要远低于 9999%。所以，在99.99% 和 100%之间的区别基本上成为其他系统的噪声。就算我们花费巨大精力将系统变为100% 可靠也并不能给用户带来任何实质意义上的好处。

如果100% 不是一个正确的可靠性目标，那么多少才是呢?这其实并不是一个技术问题，而是一个产品问题。要回答这个问题，必须考虑以下几个方面∶
● 基于用户的使用习惯，服务可靠性要达到什么程度用户才会满意?
● 如果这项服务的可靠程度不够，用户是否有其他的替代选择?
● 服务的可靠程度是否会影响用户对这项服务的使用模式?

公司的商业部门或者产品部门必须建立起一个合理的可靠性目标。一旦建立，"错误预算"就是"1-可靠性目标"。如果一个服务的可靠性目标是99.99%，那么错误预算就是 0.01%。这意味着产品研发部门和 SRE 部门可以在这个范围内将这个预算用于新功能上线或者产品的创新等任何事情。

错误预算可以用于什么范畴呢?研发团队需要用这个预算上线新功能，吸引新用户。理想情况下，我们应该使用错误预算来最大化新功能上线的速度，同时保障服务质量。这个基本模型建立起来之后，许多常见的战术策略，例如灰度发布、1%AB测试等就全说得通了。这些战术性手段都是为了更合理地使用整个服务的错误预算。

通过引进"错误预算"的概念，我们解决了研发团队和SRE团队之间的组织架构冲突。SRE 团队的目标不再是"零事故运行"，SRE团队和产品研发团队目标一致，都是在保障业务服务可靠性需求的同时尽可能地加快功能上线速度。这个改动虽小，意义却很大。一次"生产事故"不再是一件坏事，而仅仅是创新流程中一个不可避免的环节，两个团队通过协作共同管理它。

产品研发部门和SRE 之间可以通过消除组织架构冲突来构建良好的合作关系。在企业中，最主要的矛盾就是迭代创新的速度与产品稳定程度之间的矛盾。正如上文所说，其表现形式可能是间接的。在SRE模型中，我们选择正面面对这种矛盾，使用的工具是错误预算。

"错误预算"起源于这样一个理念∶任何产品都不是，也不应该做到100%可靠（显然这并不适用于心脏起搏器和防抱死刹车系统等）。一般来说，任何软件系统都不应该一味地追求 100% 可靠。因为对最终用户来说，99.999% 和 100%的可用性是没有实质区别的（详见附录 A）。从最终用户到服务器之间有很多中间系统（用户的笔记本电脑、家庭WiFi、网络提供商和输电线路等），这些系统综合起来可靠性要远低于 9999%。所以，在99.99% 和 100%之间的区别基本上成为其他系统的噪声。就算我们花费巨大精力将系统变为100% 可靠也并不能给用户带来任何实质意义上的好处。

如果100% 不是一个正确的可靠性目标，那么多少才是呢?这其实并不是一个技术问题，而是一个产品问题。要回答这个问题，必须考虑以下几个方面∶
● 基于用户的使用习惯，服务可靠性要达到什么程度用户才会满意?
● 如果这项服务的可靠程度不够，用户是否有其他的替代选择?
● 服务的可靠程度是否会影响用户对这项服务的使用模式?

公司的商业部门或者产品部门必须建立起一个合理的可靠性目标。一旦建立，"错误预算"就是"1-可靠性目标"。如果一个服务的可靠性目标是99.99%，那么错误预算就是 0.01%。这意味着产品研发部门和 SRE 部门可以在这个范围内将这个预算用于新功能上线或者产品的创新等任何事情。

错误预算可以用于什么范畴呢?研发团队需要用这个预算上线新功能，吸引新用户。理想情况下，我们应该使用错误预算来最大化新功能上线的速度，同时保障服务质量。这个基本模型建立起来之后，许多常见的战术策略，例如灰度发布、1%AB测试等就全说得通了。这些战术性手段都是为了更合理地使用整个服务的错误预算。

通过引进"错误预算"的概念，我们解决了研发团队和SRE团队之间的组织架构冲突。SRE 团队的目标不再是"零事故运行"，SRE团队和产品研发团队目标一致，都是在保障业务服务可靠性需求的同时尽可能地加快功能上线速度。这个改动虽小，意义却很大。一次"生产事故"不再是一件坏事，而仅仅是创新流程中一个不可避免的环节，两个团队通过协作共同管理它。