在读《SRE - Google运维解密》的时候看到Google提出的错误预算上线机制，觉得不错，在这里细化一下，如果你们公司线上变更老是出问题，或许可以将这个机制引入。
错误预算 = 1 - 可靠性目标
比如某产品的可靠性目标是4个9，即99.99%，那么错误预算就是0.01%，即，一个月内总共的不可用时长是：
1440 * 30 * 0.01% = 4.32分钟
一次上线，造成不可用时长1.22分钟，那么还剩3.1分钟，又一次上线，造成不可用时长4分钟，还剩-0.9分钟，超过了预算，那么，本月（一个月是一个记分周期）就不能再上线了。
如果非要上线不可，需研发部门大老板确认。这意味着：平时大老板根本不用审核上线单，如果真有上线单走到大老板这了，说明这个团队已经用光了他们的错误预算。研发的大老板这个时候应该干点啥了。
年底可以建立奖励机制：
不可用时长最少的团队，颁发最佳质量奖 :)
*错误预算可以用于什么范畴呢？
建议只用于上线升级过程导致的服务短暂不可用，主抓上线造成的问题，其他故障用其他机制避免，避免扯皮。
*部分可用的情况如何计算？
将不可用时长按容量比例计算。比如某产品部署了北京、上海两个机房，容量比例是1023：2765，某个上线，当前只是灰度了北京机房，造成这个机房3分钟不可用，但是只占了整个集群容量的一部分，整个产品的不可用时长：
3 * 1023 / (1023 + 2765) = 0.81分钟
*这会带来哪些好处？
- 研发同学心理上会特别小心，提高风险意识
- 会想各种招来减少不可用时长，比如灰度上线、AB上线
- 最终结果就是服务可靠性提高
嗯，如果你是某公司运维总监，可以考虑将上面这个机制适配到自己公司:)
