错误预算上线机制

在读《SRE - Google运维解密》的时候看到Google提出的错误预算上线机制,觉得不错,在这里细化一下,如果你们公司线上变更老是出问题,或许可以将这个机制引入。

1
错误预算 = 1 - 可靠性目标

比如某产品的可靠性目标是4个9,即99.99%,那么错误预算就是0.01%,即,一个月内总共的不可用时长是:

1
1440 * 30 * 0.01% = 4.32分钟

一次上线,造成不可用时长1.22分钟,那么还剩3.1分钟,又一次上线,造成不可用时长4分钟,还剩-0.9分钟,超过了预算,那么,本月(一个月是一个记分周期)就不能再上线了。

如果非要上线不可,需研发部门大老板确认。这意味着:平时大老板根本不用审核上线单,如果真有上线单走到大老板这了,说明这个团队已经用光了他们的错误预算。研发的大老板这个时候应该干点啥了。

年底可以建立奖励机制:

不可用时长最少的团队,颁发最佳质量奖 :)

*错误预算可以用于什么范畴呢?

建议只用于上线升级过程导致的服务短暂不可用,主抓上线造成的问题,其他故障用其他机制避免,避免扯皮。

*部分可用的情况如何计算?

将不可用时长按容量比例计算。比如某产品部署了北京、上海两个机房,容量比例是1023:2765,某个上线,当前只是灰度了北京机房,造成这个机房3分钟不可用,但是只占了整个集群容量的一部分,整个产品的不可用时长:

1
3 * 1023 / (1023 + 2765) = 0.81分钟

*这会带来哪些好处?

  • 研发同学心理上会特别小心,提高风险意识

  • 会想各种招来减少不可用时长,比如灰度上线、AB上线

  • 最终结果就是服务可靠性提高

嗯,如果你是某公司运维总监,可以考虑将上面这个机制适配到自己公司:)