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

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

高可靠性帶來高成本

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

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

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

如何度量可用性

通常的做法是按照計劃外停機時間來度量，比如：

可用性 = 系統(tǒng)正常運行時間 / (系統(tǒng)正常運行時間 + 系統(tǒng)計劃外停機時間)

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

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

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

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

誰來制定SLO？

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

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

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

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

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

提升 SLO 的時候要注意 ROI

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

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

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

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

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