在保障服务slo的前提下最大化跌代速度
在保障服务slo的前提下最大化跌代速度产品研发部门和还是SER之间，可以通过消除组织架构冲突来构建良好的合作关系，在企业中最主要的矛盾就是迭代创新的速度与产品稳定程度之间的矛盾，正如上文所说，其表现形式可能是间接的，在sre模型中，我们选择正面面对这种矛盾使用的工具是错误预算.
错误预算起源于这样一个理念，任何产品都不是，也不应该做到100%可靠，这句话并不适用于心脏起搏器和防爆式刹车系统，我们只是针对网络中的各种工具而言。相比这种跌代速度跟GoogleAdsense相比起来还是要差很多，Adsense这个部门的跌代速度在全球企业中可比肩的不多。
一般来说，任何软件系统都不应该一味的追求100%可靠，因为对最终用户来说，99.999%和100%的可能性是没有实质区别的，从最终用户到服务器之间有很多中间系统用户的笔记本电脑，家庭WiFi网络、提供商和输电线路等，这些系统综合起来，可考虑要远远低于99.999%所以在百分之九十九点九九九和百分之剑的区别基本上成为其他系统的噪声就算我们花费巨大的精力将系统变为百分之百可能并不能给用户带来实质性的好处。
如果100%不是一个正确的可靠目标，那么多少才是呢，这其实并不是一个技术问题，而是一个产品问题，要回答这个问题，常有以下几个方面。
1.基于用户的使用习惯服务可靠性要达到什么程度用户才能满意？
2.如果这项服务的可靠程度不够，用户是否有其他的替代选择?
3.服务的可靠程度是否会影响用户对这项服务的使用模式？
公司的商业部门或者产品部门必须建立起一个合理的可靠性目标，一旦建立错误预算就是一件可靠性目标，如果一个服务的可靠性目标是99.99%，那么错误预算率就是0.01%，这意味着产品研发部门和sre部门可以在这个范围内将这个预算用于新功能上线或者产品的创新等任何事情。
错误预算可以用于任何范畴，研发团队需要用这个预算上线新功能吸引新用户，理想情况下我们应该使用错误预算来最大化新功能上线的速度，同时保证服务质量，这个基本模型建立起来之后，许多常见的战术策略，例如灰度发布1%，ab测试等就全说的通了，这些战术性手段就是为了更合理地使用整个服务的错误预算。
通过引进错误预算的概念，我们解决了研发团队和SER团队之间的组织架构，冲突SER团队的目标不再是零事故运行，SER团队和产品研发团队目标一致，都是在保障业务服务可靠性需求的同时，尽可能力加快功能上线，速度，这个改动虽小，意义却很大，一次生产事故不再是一件坏事，而仅仅是创新流程中亦可不免不可避免的环节，两个团队通过协作共同管理它。
系列更新以后可能由我来更新，理解能力可能要差很多，尽力吧……
应大管家到前台来啦:lol
页:
[1]