在讀《SRE - Google運維解密》的時候看到Google提出的錯誤預(yù)算上線機制峦萎，覺得不錯撤摸，在這里細化一下徽千，如果你們公司線上變更老是出問題，或許可以將這個機制引入珍手。
錯誤預(yù)算 = 1 - 可靠性目標(biāo)
比如某產(chǎn)品的可靠性目標(biāo)是4個9办铡，即99.99%，那么錯誤預(yù)算就是0.01%琳要，即寡具，一個月內(nèi)總共的不可用時長是：
1440 * 30 * 0.01% = 4.32分鐘
一次上線，造成不可用時長1.22分鐘稚补，那么還剩3.1分鐘童叠，又一次上線，造成不可用時長4分鐘课幕，還剩-0.9分鐘厦坛，超過了預(yù)算，那么乍惊，本月（一個月是一個記分周期）就不能再上線了杜秸。
如果非要上線不可，需研發(fā)部門大老板確認润绎。這意味著：平時大老板根本不用審核上線單撬碟，如果真有上線單走到大老板這了，說明這個團隊已經(jīng)用光了他們的錯誤預(yù)算莉撇。研發(fā)的大老板這個時候應(yīng)該干點啥了呢蛤。
年底可以建立獎勵機制：
不可用時長最少的團隊，頒發(fā)最佳質(zhì)量獎 :)
*錯誤預(yù)算可以用于什么范疇呢稼钩？
建議只用于上線升級過程導(dǎo)致的服務(wù)短暫不可用顾稀，主抓上線造成的問題，其他故障用其他機制避免坝撑，避免扯皮静秆。
*部分可用的情況如何計算？
將不可用時長按容量比例計算巡李。比如某產(chǎn)品部署了北京抚笔、上海兩個機房，容量比例是1023：2765侨拦，某個上線殊橙，當(dāng)前只是灰度了北京機房，造成這個機房3分鐘不可用狱从，但是只占了整個集群容量的一部分膨蛮，整個產(chǎn)品的不可用時長：
3 * 1023 / (1023 + 2765) = 0.81分鐘
*這會帶來哪些好處？
- 研發(fā)同學(xué)心理上會特別小心季研，提高風(fēng)險意識
- 會想各種招來減少不可用時長敞葛，比如灰度上線、AB上線
- 最終結(jié)果就是服務(wù)可靠性提高
嗯与涡，如果你是某公司運維總監(jiān)惹谐，可以考慮將上面這個機制適配到自己公司:)
