這篇文章將聚焦於《Site Reliability Engineering》中的：

• Chapter 3 - Embracing Risk

探討 SRE 如何重新定義可靠性，並運用錯誤預算（Error Budget）這一核心工具，在風險與創新之間取得精準的平衡。

📗〔讀書心得〕- SRE Ch3：擁抱風險與錯誤預算實務

• 📗〔讀書心得〕- SRE Ch3：擁抱風險與錯誤預算實務
  • SRE 的核心概念：管理風險，而非避免風險
  • 為什麼 100% 可用性是個陷阱?
• 錯誤預算（Error Budget）衡量方式的選擇
  • 衡量可靠性：從「停機時間」到「請求成功率」
• SRE 如何評估服務風險容忍度（Risk Tolerance）
• SRE 評估故障的「型態」與影響 - 服務水準目標之外的例外情況
• SRE 如何評估可用性的投資回報率
• SRE 如何評估可用性之外的其他指標
  • 延遲：AdWords 與 AdSense 的案例比較
  • 基於延遲(Latency)指標造成的實務影響
• SRE 如何評估企業內部服務的 SLO
  • 基礎設施服務的風險容忍度：以 Bigtable 為例
  • 分級服務：將成本選擇權交給上游服務
• 我的 TAKEAWAY
• Extended Reference ＆ FYI

在數位服務爆炸性成長的今天，使用者對於服務的可靠性抱持著理所當然的期待。然而，你是否曾想過，追求100% 可用性真的是對的策略嗎？

傳統的思維或許會說：「當然！服務永不當機才是王道。」但當我們將目光從單純的技術層面，轉向更廣泛的商業成本與使用者體驗時，這個答案就變得不再那麼理所當然。過度的可靠性追求，不僅可能導致巨大的維運成本，更會扼殺新功能開發的速度，最終傷害到使用者與產品的長遠價值。

SRE 的核心概念：管理風險，而非避免風險

SRE 認為，服務的可靠性管理，本質上就是風險管理。SRE 不應該希望系統永遠不壞，而是要找出一個「恰到好處」的平衡點。

• SRE 的目標是明確地將特定服務所承擔的風險與企業願意承擔的風險相匹配。
• 我們使服務足夠可靠，但不會超過其所需的可靠性。

為什麼 100% 可用性是個陷阱?

追求 100% 可用性看似崇高，但實際上卻是個不切實際的目標，原因如下：

• 無感的邊際效益： 對使用者而言，一個達到 99.999% 可用性的服務，與 99.99% 或 99.9% 的差異微乎其微。因為此時影響使用者體驗的，往往是他們自己的網路、手機或外部網路供應商（ISP）等不可控因素。企業花費數百萬美金提升那微不足道的 0.001% 可用性，對使用者來說可能毫無察覺。
• 巨大的機會成本： 為了達到極致可靠性，團隊必須投入大量資源在冗餘架構、容錯設計與嚴格的測試流程上。這意味著原本可以用來開發新功能、改善使用者體驗的工程師人力，都必須轉向降低風險，導致大幅地減緩產品創新速度。

錯誤預算（Error Budget）衡量方式的選擇

錯誤預算是 SRE 用來平衡風險與創新的關鍵。它的核心思想是：既然我們不追求 100% 可用性，那麼允許的一定程度的「不可用時間」或「失敗次數」，就是我們可以使用的「預算」。

• 在大多數情況下，衡量服務風險承受度最直接的方法就是 計算可接受的非計畫性停機時間。
• 這種非計畫性停機時間是由你希望達成的服務可用性等級來決定，通常用「幾個九」來表示，例如：99.9%、99.99% 或 99.999%。每增加一個「九」，就代表可靠性向 100% 邁進了一個數量級的提升。

衡量可靠性：從「停機時間」到「請求成功率」

1. 傳統的「時間導向」衡量方式

在過去，業界習慣用「停機時間」來計算服務可用性。

• 舉例來說，一個可用性目標為 99.99% 的系統，一年內可以容許最高 52.56 分鐘的停機時間，只要在這範圍內，就算達標。
• 這種方式簡單明瞭，對於單一或非分散式系統來說相當有用。

2. Google 的「請求導向」衡量方式

然而，對 Google 這種遍佈全球的分散式系統而言，「停機時間」這個指標就不再具備實質意義。因為我們的架構設計，讓服務隨時都可能在世界的某個角落為部分使用者提供服務，系統幾乎不會有完全「停機」的時刻。

因此，Google 轉而採用「請求成功率」來定義可用性，這是一種更精確且能反映真實用戶體驗的指標。

• 舉個例子，一個每天處理 250 萬個請求的系統，如果其可用性目標為 99.99%，那麼它每天可以容許最高 250 個失敗的請求，仍然算是在目標範圍內。
• 這種以「請求成功率」為基礎的衡量方式，不僅適用於直接面對終端使用者的服務，也適用於後端系統，如批次處理、資料管線或儲存服務。對於這類系統，我們可以將「成功」和「失敗」定義為工作是否完成，藉此來計算出有意義的可用性指標。

SRE 如何評估服務風險容忍度（Risk Tolerance）

要評估一個服務的風險容忍度，SRE 團隊會與產品負責人（Product Owners）合作，將抽象的商業目標轉化為具體的工程目標。這項工作需要考慮多個面向：

• 消費性服務： 對於像 Google Search 或 YouTube 這樣的消費性服務，我們需要考慮：
  • 使用者期望： 使用者對服務的期望有多高？
  • 市場競爭： 競爭對手提供了什麼樣的服務等級？
  • 營收影響： 服務故障是否會直接影響營收？

舉例來說，針對企業用戶的 Google Workspace（如 Gmail, Docs），其服務穩定性直接影響企業運作，因此會設定極高的可用性目標（如 99.9%），並以更嚴格的內部標準來達成，同時也可能在合約中訂定未達標的罰則。相較之下，在 YouTube 發展初期，其重點是快速成長與功能迭代，因此會設定較低的可用性目標，將更多資源投入到產品開發上。

SRE 評估故障的「型態」與影響 - 服務水準目標之外的例外情況

服務故障的形式多樣：

• 何種故障更具破壞性？ 是零星、持續性的低頻率錯誤，還是偶爾發生、但影響範圍廣泛的全面性中斷？
• 業務對故障的承受度如何？ 某些故障可能只會影響使用者體驗，而另一些則可能導致資料洩露、營收損失或品牌聲譽受損。

舉例來說，在一個聯絡人管理應用程式中，有兩種截然不同的故障：

• 輕微故障： 使用者的個人資料照片偶爾無法載入。
• 嚴重故障： 由於系統錯誤，導致使用者的個人資訊被錯誤地顯示給其他使用者。這種故障雖然可能只影響少數用戶，但其暴露私密資料的風險會從根本上破壞使用者信任。
  • 在這種情況下，SRE 會認為立即全面停用服務，以便進行除錯與清理，是更為恰當且負責任的決策。

因此，SRE 必須理解，某些風險類型（例如：資料完整性和隱私安全）的優先級遠高於服務的持續上線（可用性），如不幸發生了，應該以解決重大故障為問題為優先。

SRE 如何評估可用性的投資回報率

使用 Google 的廣告服務作為案例：每一次成功的請求都代表營收，而每一次失敗的請求則意味著營收損失。因此，SRE 在為這類服務設定可用性目標時，會問自己幾個核心問題：

• 如果將服務的可用性從 99.9% 提升到 99.99%，能帶來多少額外營收？
• 為了達到這更高的可靠性水平，所需的成本（如增加硬體資源、投入更多工程人力）是否值得？

用一個具體的例子來量化這個權衡：

假設一個服務每個月創造 100 萬美元的營收。如果我們將其可用性從 99.9% 提升至 99.99%，相當於減少了 0.09% 的潛在錯誤。

• 可用性提升的價值 = 100 萬美元 × 0.09% = 900 美元

在這個案例中，如果提升一個「9」（99.9% 提升到 99.99%）的成本低於 900 美元，這項投資就是划算的；反之，則不值得。

然而，並非所有服務都能將可靠性直接轉換為營收。對於這類服務，SRE 有另一種策略：參考網路環境的背景錯誤率。

研究顯示，網際網路服務提供商（ISP）本身的錯誤率通常介於 0.01% 到 1% 之間。如果我們的服務能將自身的錯誤率控制在低於這個範圍，那麼對於終端使用者來說，服務的失敗將被歸因於他們自身網路的不穩定，而非我們的服務。這意味著，只要我們的服務比網路本身更可靠，用戶就不太會感知到我們的故障。這個原則為那些難以量化營收的服務，提供了一個可用性目標的參考點。

SRE 如何評估可用性之外的其他指標

除了可用性與錯誤預算，SRE 在評估服務風險容忍度時，也會仔細檢視其他服務指標（Service Metrics），最常見的就是延遲（Latency）。了解哪些指標至關重要，哪些可以放寬，能為 SRE 提供更大的彈性來進行控制哪些風險的決策。

延遲：AdWords 與 AdSense 的案例比較

• AdWords (關鍵字廣告)：Google 搜尋服務的成功基於其極致的速度。當關鍵字廣告（AdWords）被引入時，一個不容妥協的原則是：廣告的載入速度絕不能拖慢搜尋結果頁面的呈現。這使得 AdWords 的延遲目標非常嚴格，推動了每一代 AdWords 服務的工程目標，並被視為一個不變的原則。

• AdSense (內容關聯廣告)：相較之下，AdSense 的延遲目標則寬鬆得多。這項服務透過發布商網站內嵌的 JavaScript 程式碼來顯示廣告，其核心目標是避免拖慢發布商網頁的渲染速度。由於發布商網站本身的載入速度各有不同，AdSense 廣告的延遲可以比 AdWords 廣告高出數百毫秒，依然能符合目標。

基於延遲(Latency)指標造成的實務影響

AdSense 相對寬鬆的延遲要求，讓 SRE 團隊得以做出許多聰明的資源配置（Provisioning）決策。由於服務對延遲不那麼敏感，我們可以將服務部署在更少的地理位置，而非在各地分散部署。這項決策可以降低了營運開銷與成本，體現了 SRE 權衡服務效能與營運效率的核心思想。

SRE 如何評估企業內部服務的 SLO

相較於直接面對消費者的服務，底層服務的可用性要求更為複雜。由於底層基礎設施元件（Component） 通常有多個上游服務作為其客戶（client），且這些客戶的需求各不相同，這使得為基礎設施設定統一的服務等級目標（SLO）幾乎不可能。

基礎設施服務的風險容忍度：以 Bigtable 為例

以 Google 的大規模分散式儲存系統 Bigtable 為例，其面臨兩種截然不同的上游服務需求：

• 低延遲、高可靠性：部分使用者服務直接從 Bigtable 讀取資料以回應使用者請求。這類服務對延遲（Latency）非常敏感，需要 Bigtable 的請求隊列幾乎是空的，以確保請求能立即處理。
• 高吞吐量、不苛求可靠性：另一部分團隊使用 Bigtable 進行離線分析。他們更關心系統的吞吐量（Throughput），希望請求隊列永遠不空閒，以便系統能持續工作、最大化資源利用。

顯然，這兩種需求是互相矛盾的：對第一類使用者而言的「成功」，對第二類使用者而言可能意味著「失敗」。若要以最極致且單一的 SLO 標準來滿足所有上游的服務，將會產生巨大的成本，這在實務上是幾乎不可行的。

分級服務：將成本選擇權交給上游服務

為了解決這個問題，SRE 可以採取將基礎設施分級的策略。我們不提供單一、高成本的「萬用」服務，而是提供多個獨立的服務等級，讓上游服務可以根據自身的風險承受度和預算做出選擇。

• 低延遲集群（Low-Latency Clusters）：專為需要高可靠性和低延遲的服務設計。這些集群會配置大量的備用容量，以減少資源競爭，滿足嚴格的延遲要求。
• 高吞吐量集群（Throughput Clusters）：專為離線分析等對延遲不敏感的服務設計。這些集群會將資源利用率調到很高，並減少備援，以吞吐量而非延遲作為主要優化目標。這種模式的成本可能只有低延遲集群的 10-50%，在大規模應用下，能帶來顯著的成本節省。

這個策略體現了 SRE 將成本差異「外部化」的理念。透過明確標示不同服務等級所提供的承諾與成本，基礎設施服務提供者能引導上游服務在建構系統時，做出最符合他們需求的權衡決策。例如，一個應用程式可以選擇將涉及使用者隱私的關鍵資料，儲存在高可用性的全球複製資料儲存系統（如 Spanner），而將非關鍵性的、僅用於增強體驗的資料，放在更便宜、最終一致性（Eventual Consistency）的資料庫中（如 Bigtable）。

• 值得注意的是，SRE 能夠使用相同的硬體和函式（Function），但通過調整資源數量、備援程度、部署區域和最關鍵的軟體配置（Software Configuration），來提供截然不同的服務保證。這讓分級服務策略在技術上變得可行，並最大化了資源的利用效率。

我的 TAKEAWAY

• 成本、成本、成本，在閱讀這一章節的時候，除了如果管理風險之外，時不時就提及這種情況，可以使用哪些方式去達到節約成本的目的。
• Error Budget 的主要好處是它提供了一種共同的激勵，使產品開發和 SRE 能夠專注於在創新和可靠性之間找到適當的平衡。
• 管理服務可靠性很大程度就是管理風險，而不合理地管理風險的成本可能很高。
• 優化至 100% 的可靠性並非最佳策略：完全可靠既無法實現，也不符合實際需求。過高的可靠性往往超過服務使用者的期望或感知門檻，使得投入的成本與複雜度遠大於其帶來的邊際效益。SRE 應該將服務的 SLO 設定在與組織能夠接受的風險相符的水準，確保可靠性與成本、速度、創新之間取得平衡。

Extended Reference ＆ FYI

1. https://sre.google/sre-book/embracing-risk/

This Content is Authored by the writer, with AI-assisted proofreading and SEO optimization.