服務(wù)可用性必須100%？其實(shí)完全沒(méi)必要

一個(gè)服務(wù)客戶的產(chǎn)品，不需要追求極端的可用性，因?yàn)閷?shí)在是沒(méi)有必要。比如一個(gè)論壇服務(wù)，用戶使用智能手機(jī)來(lái)訪問(wèn)，手機(jī)本身有可能故障，手機(jī)的蜂窩網(wǎng)絡(luò)可能出問(wèn)題，如果用的 wifi 本地路由器可能出問(wèn)題，小區(qū)寬帶可能出問(wèn)題，運(yùn)營(yíng)商的骨干網(wǎng)可能出問(wèn)題，這些都不是論壇服務(wù)能夠控制的。簡(jiǎn)單來(lái)說(shuō)，用戶在一個(gè)有著 99% 可靠性的智能手機(jī)上，是不能分辨出 99.99% 和 99.999% 的服務(wù)可靠性的區(qū)別的。

高可靠性帶來(lái)高成本

99.99% 的可用性，每年不可用時(shí)長(zhǎng)不能超過(guò) 53 分鐘，如果是 99.999% 的可用性，每年不可用時(shí)長(zhǎng)不能超過(guò) 5.3 分鐘。多了一個(gè) 9，不可用時(shí)長(zhǎng)只是縮減了 47.7 分鐘，但是付出的成本可能是巨大的，需要衡量 ROI 是否值得。成本通常來(lái)自兩個(gè)方面：

• 冗余物理服務(wù)器/計(jì)算資源的成本
• 機(jī)會(huì)成本

機(jī)會(huì)成本是說(shuō)，我們把過(guò)多的人力投入到穩(wěn)定性建設(shè)上了，導(dǎo)致投入到業(yè)務(wù)功能開發(fā)的人力就變少了，這個(gè)機(jī)會(huì)成本是很難估量的，但是很重要。

如何度量可用性

通常的做法是按照計(jì)劃外停機(jī)時(shí)間來(lái)度量，比如：

可用性 = 系統(tǒng)正常運(yùn)行時(shí)間 / (系統(tǒng)正常運(yùn)行時(shí)間 + 系統(tǒng)計(jì)劃外停機(jī)時(shí)間)

這個(gè)計(jì)劃外停機(jī)時(shí)間，通常是指系統(tǒng)不可用的時(shí)間，比如系統(tǒng)崩潰了，或者系統(tǒng)的某個(gè)功能不可用了，或者系統(tǒng)的某個(gè)功能的性能下降了，都可以算作計(jì)劃外停機(jī)時(shí)間。與計(jì)劃外停機(jī)時(shí)間相對(duì)的，顯然是計(jì)劃內(nèi)停機(jī)時(shí)間，偶爾通知用戶，說(shuō)凌晨3點(diǎn)我會(huì)做系統(tǒng)升級(jí)，計(jì)劃停機(jī)3分鐘，這個(gè)3分鐘就是計(jì)劃內(nèi)停機(jī)時(shí)間，這3分鐘內(nèi)的不可用，不影響SLA。

但是，很多系統(tǒng)都是分布式的，尤其是 Google，一個(gè)服務(wù)，通常不會(huì)完全不可用，可能某個(gè) region 不可用，但是其他 region 還可用，所以，大型互聯(lián)網(wǎng)公司的服務(wù)通常是不會(huì) 100% 不可用的，可能會(huì)部分不可用，此時(shí)這個(gè)計(jì)劃外停機(jī)時(shí)間就不好計(jì)算了。怎么辦？使用請(qǐng)求數(shù)量來(lái)統(tǒng)計(jì)，可用性計(jì)算公式變成：

可用性 = 成功請(qǐng)求數(shù) / 總的請(qǐng)求數(shù)

這是服務(wù)可用性的度量方法，一個(gè)大型互聯(lián)網(wǎng)公司可能有幾千個(gè)微服務(wù)，老板問(wèn)技術(shù)團(tuán)隊(duì)，咱們今年的可用性如何？顯然沒(méi)法使用服務(wù)層面的數(shù)據(jù)，那就把眾多微服務(wù)做個(gè)加權(quán)平均？也不那么說(shuō)得通！那公司整體業(yè)務(wù)的 SLO 應(yīng)該怎么算？一般是看業(yè)務(wù)指標(biāo)，分享一下滴滴的做法，滴滴最核心的業(yè)務(wù)就是打車，核心就看打車的訂單量，如果訂單量下跌 10%，就開始計(jì)算不可用時(shí)長(zhǎng)，這是整個(gè)公司最重要的可用性指標(biāo)。這種指標(biāo)稱為北極星指標(biāo)，我們現(xiàn)在創(chuàng)業(yè)就專門做了一個(gè)北極星指標(biāo)的產(chǎn)品，對(duì)北極星指標(biāo)做 VIP 級(jí)別的保障。詳情可以了解這里。

誰(shuí)來(lái)制定SLO？

在 Google，對(duì)于服務(wù)于終端用戶的產(chǎn)品，通常有個(gè)產(chǎn)品技術(shù)團(tuán)隊(duì)，是這個(gè)服務(wù)的「商業(yè)所有者」，這個(gè)團(tuán)隊(duì)明確知道自己的商業(yè)目標(biāo)，可以拍板 SLO。因?yàn)椋篠LO 最終是服務(wù)于商業(yè)目標(biāo)的！

通常來(lái)講，線上 70% 的故障是變更導(dǎo)致的，更好的 SLO 意味著線上變更的頻率會(huì)降低，但是低頻的變更，就意味著有些功能 feature 不能盡快發(fā)布給終端用戶，終端用戶的體驗(yàn)就會(huì)變差，競(jìng)爭(zhēng)對(duì)手可能有更花哨好用的功能，我們無(wú)法及時(shí)跟進(jìn)。那好，那就更快的變更，更快的變更通常意味著穩(wěn)定性變差，所以就需要權(quán)衡了，這本質(zhì)上是一個(gè)商業(yè)取舍，所以，需要商業(yè)所有者來(lái)拍板。而這個(gè)商業(yè)所有者，對(duì)于服務(wù)于終端用戶的產(chǎn)品，通常就是產(chǎn)品團(tuán)隊(duì)，最終可能是這個(gè)業(yè)務(wù)的負(fù)責(zé)人最終拍板。

服務(wù)于內(nèi)部的基礎(chǔ)設(shè)施，比如 BigTable 這樣的服務(wù)，沒(méi)有終端用戶，那誰(shuí)來(lái)拍板？基礎(chǔ)設(shè)施類服務(wù)，通常是服務(wù)于內(nèi)部其他服務(wù)的，此時(shí)應(yīng)該是 BigTable 的研發(fā)團(tuán)隊(duì)和上游服務(wù)所有者一起拍板，制定 SLO。

BigTable 可能同時(shí)服務(wù)兩類上游服務(wù)，舉例：一類上游服務(wù)是面向終端用戶的，他們需要更低的延遲，另一類上游服務(wù)可能是離線任務(wù)，在 BigTable 里存儲(chǔ)離線分析數(shù)據(jù)，他們需要更大的吞吐。低延遲的上游服務(wù)希望 BigTable 的請(qǐng)求隊(duì)列（幾乎總是）為空，這樣系統(tǒng)可以立刻處理每個(gè)出現(xiàn)的請(qǐng)求。而離線分析的上游服務(wù)，需要更高的吞吐，希望 BigTable 繁忙，希望請(qǐng)求隊(duì)列永遠(yuǎn)不為空。如果拿請(qǐng)求隊(duì)列長(zhǎng)度作為 SLO，就尷尬了…

所以，對(duì)于差異化要求比較大的基礎(chǔ)設(shè)施，通常會(huì)拆分成不同的集群，提供不同維度的 SLO。

提升 SLO 的時(shí)候要注意 ROI

舉個(gè)例子，假設(shè)某個(gè)服務(wù)每一個(gè)請(qǐng)求的價(jià)值是一樣的：

• 可用性目標(biāo)希望從 99.9% 提升至 99.99%
• 增加的可用性：0.09%
• 服務(wù)收入：100萬(wàn)美金
• 改進(jìn)可用性后的價(jià)值：100萬(wàn) * 0.09% = 900 美金

可用性提升一個(gè) 9，收益是 900 美金，如果提升一個(gè) 9 的成本低于 900 美金，就是劃算的，如果高于 900 美金，就是不劃算的。

SLO和錯(cuò)誤預(yù)算構(gòu)建過(guò)程

• 產(chǎn)品管理層定義一個(gè) SLO，確定一項(xiàng)服務(wù)在每個(gè)季度預(yù)計(jì)的正常運(yùn)行時(shí)間
• 實(shí)際在線時(shí)間是通過(guò)一個(gè)中立的第三方來(lái)測(cè)算的：我們的監(jiān)控系統(tǒng)
• 這兩個(gè)數(shù)字之間的差值就是這個(gè)季度中剩余的不可靠性預(yù)算
• 只要測(cè)算出的正常在線時(shí)間高于 SLO，也就是說(shuō)，只要仍然有剩余的錯(cuò)誤預(yù)算，就可以發(fā)布新的版本