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

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

高可靠性帶來高成本

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

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

機會成本是說，我們把過多的人力投入到穩定性建設上了，導致投入到業務功能開發的人力就變少了，這個機會成本是很難估量的，但是很重要。

如何度量可用性

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

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

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

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

可用性 = 成功請求數 / 總的請求數

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

誰來制定SLO？

在 Google，對于服務于終端用戶的產品，通常有個產品技術團隊，是這個服務的「商業所有者」，這個團隊明確知道自己的商業目標，可以拍板 SLO。因為：SLO 最終是服務于商業目標的！

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

服務于內部的基礎設施，比如 BigTable 這樣的服務，沒有終端用戶，那誰來拍板？基礎設施類服務，通常是服務于內部其他服務的，此時應該是 BigTable 的研發團隊和上游服務所有者一起拍板，制定 SLO。

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

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

提升 SLO 的時候要注意 ROI

舉個例子，假設某個服務每一個請求的價值是一樣的：

• 可用性目標希望從 99.9% 提升至 99.99%
• 增加的可用性：0.09%
• 服務收入：100萬美金
• 改進可用性后的價值：100萬 * 0.09% = 900 美金

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

SLO和錯誤預算構建過程

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