擁抱風險 | 網站可靠性工程｜Google 的系統管理之道

SRE 並非追求最大化 uptime，而是主動管理風險。可靠性愈高，邊際成本愈陡（每多一個 9 可能貴 100 倍），而使用者通常根本感受不到差異——他們手裡的手機、家裡的 WiFi、上游的 ISP 才是體驗的真正瓶頸。

本章透過「風險」的視角審視 SRE：如何量化、如何取捨、如何用**錯誤預算（error budget）**作為中性而實用的決策機制。

為什麼要管理風險而非最大化可靠性#

把可靠性推到極致會帶來兩類成本：

SRE 把可靠性目標視為「下限」與「上限」的雙重指標：超過目標太多代表我們過度投資了，這些資源原本可拿去做新功能、清技術債、降低營運成本。

傳統做法以「時間可用度」表示：

$$\text{availability} = \frac{\text{uptime}}{\text{uptime} + \text{downtime}}$$

例如 99.99% 全年可宕機 52.56 分鐘（見附錄 A）。但 Google 服務是全球分散式的，幾乎永遠有一部分在運作，時間制不合用。改採以請求為單位的整體成功率：

$$\text{availability} = \frac{\text{successful requests}}{\text{total requests}}$$

例：日請求 2.5M、SLO 99.99% 的服務，每天可容忍 250 次失敗。

此度量同樣適用於非服務型系統——批次、管線、儲存、交易系統都有「成功 / 失敗工作單位」的概念，可套用同一框架。

通常以「季度」設定目標，並以週或日的頻率追蹤偏差。

識別風險容忍度的工作，需要 SRE 與產品負責人一起把業務目標翻譯成可量化的工程目標。

評估時的主要面向：

目標可用度：使用者期待、是否直接連動營收、付費或免費、競爭對手水準、面向 to-C 還是 to-B
- 例：Google Apps for Work（企業導向）對外承諾 99.9%，內部訂得更嚴並有合約罰則
- 例：2006 年 YouTube（消費者導向、快速迭代）可用度目標較低，把成本騰給功能開發
故障型態：低頻率但全站斷線 vs. 持續低比例失敗，總錯誤數可能相同但商業影響迥異
- 隱私洩漏型故障 → 寧可整站下線止血
- 後台型管理介面 → 可接受規律的維護窗口（屬計畫性停機）
成本：用「多 1 個 9 增加多少營收 / 成本」量化
- 例：年營收 $1M、99.9% → 99.99%（+0.09%）→ 額外營收 ≈ $900；若改善成本低於 $900 才划算
- 沒有清楚轉換函數時，可參考 ISP 背景錯誤率（約 0.01%–1%），低於此水準的錯誤對使用者「埋在雜訊裡」
其他指標：例如 AdWords 必須不拖慢搜尋；AdSense 因為跑在第三方頁面，延遲門檻寬鬆很多，可在配置上做大量取捨

基礎建設天生有多種 client，需求往往互斥：

解法是分層服務——同樣的硬體與軟體，用配置（冗餘度、地理分佈、配額）切出多個服務等級，讓 client 自行依需求選擇與付費。
例：Bigtable 的 low-latency cluster 與 throughput cluster；後者成本可能僅前者的 10–50%。

前端基礎建設（反向代理、邊緣負載平衡）因處於請求必經之路，無法「優雅降級」隱藏問題，所以一律以極高可靠性設計。

開發與 SRE 的衝突來自評估指標不同（速度 vs. 穩定）與資訊不對稱。常見的爭執點：

沒有客觀指標時，這些決策容易變成「誰嗓門大」「誰政治力強」。SRE 的非官方座右銘：「希望不是策略（Hope is not a strategy）。」

例：SLO 99.999%，預算 = 0.001%；某次事件燒掉 0.0002%，等於用掉 20% 的季預算。

更精細的控制不必是「全有或全無（bang-bang）」，也可在預算將盡時放慢發佈、自動回滾。