SRE心裡話：要求100%服務可用性就是老闆的無知

《SRE Google 運維解密》第3章講了擁抱風險，一些關鍵的觀點，在這裡與大家分享，融入了我自己的一些了解，希望對你有些幫助。

服務可用性必須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，也就是說，隻要仍然有剩餘的錯誤預算，就可以釋出新的版本