可靠性工程流程 (SRE)

SRE (網站可靠性工程) 簡介

網站可靠性工程 (Site Reliability Engineering, SRE) 是當你要求軟體工程師設計維運功能時所產生的結果。對於 Professional Cloud Architect 來說，SRE 是用來平衡 開發速度 (Velocity)（發布新功能）與 穩定性 (Stability)（可靠性）需求的框架。

SRE 的核心原則是：對於幾乎所有事物來說，100% 的可靠性都是錯誤的目標。

白話文解釋（Plain English Explanation）

類比 1 — SLI/SLO/SLA 就像時速表、速限與罰單

想像在高速公路上開車。SLI 是你的 時速表，量測實際速度（例如過去 5 分鐘內 HTTP 200 回應的百分比）。SLO 是 標示的速限，是你內部承諾的目標（例如 30 天內 99.9% 成功率）。SLA 則是 超速罰單，是合約上的處罰（service credits），當你超出限制時要付給客戶。時速表不會跟你爭辯，速限引導駕駛行為，只有罰單具有法律效力。在 Cloud Monitoring 中，你把 SLI 設為「Service Level Indicator」物件，附加一個 SLO 與 compliance period，讓平台在你開太快時用 burn-rate 警報通知你。

類比 2 — 錯誤預算就像每月行動數據方案

錯誤預算 (Error Budget) 就像每月會重設的 行動數據方案。如果你的 SLO 是 99.9% 在 30 天窗口內，你會收到大約 43 分鐘的「停機數據」可以花。發布一個有風險的 Cloud Run 版本就像串流 4K 影片，會快速燒掉預算；穩定且測試完善的發布就像讀文字文章，幾乎不耗預算。當方案耗盡，電信公司（錯誤預算政策）就會限速：新功能發布暫停，直到下個帳單週期。Cloud Monitoring 的 SLO burn-rate 警報就是「您已用掉 80% 數據」的警示簡訊。

類比 3 — 減少瑣事就像把收銀員換成自助結帳機

瑣事 (Toil) 是人工收銀員逐項掃描商品，緩慢、重複，且隨顧客數量線性增長。工程工作 (Engineering) 是自助結帳機：前期成本高（設計使用者介面、整合支付），但之後一位員工可以監看十條走道。在 GCP 上，收銀員就是凌晨三點手動執行 gcloud compute instances reset 的 on-call 工程師。自助結帳機則是由 Cloud Monitoring 警報透過 Pub/Sub topic 觸發的 Cloud Function，自動重啟不健康的 MIG。結果相同，不需人介入，工程師也能一覺到天亮。

SRE 的支柱：SLI、SLO 與 SLA

理解這三個術語之間的差異對於 PCA 考試至關重要。

1. SLI (服務水準指標)： 對所提供服務水準某個方面的量化衡量。
   • 範例： 「成功 HTTP 請求的百分比」。
2. SLO (服務水準目標)： 由 SLI 衡量的服務水準的目標值或數值範圍。
   • 範例： 「在 30 天的滾動窗口內，99.9% 的 HTTP 請求必須成功」。
3. SLA (服務水準協議)： 與用戶簽訂的法律合約，定義了如果未達到 SLO 的後果（通常是財務補償）。SRE 關注 SLO；律師關注 SLA。

SLI/SLO/SLA 層級與選擇

這三層的層級結構不只是術語，它決定了你要用哪個 Google Cloud 介面，以及誰會被呼叫。

選擇正確的 SLI 類別

SRE Workbook 定義了四個典型的 SLI 類別。請從這些選擇，而非從 CPU 之類的系統指標：

• 可用性 (Availability)： 有效 HTTP 回應的比例（2xx + 3xx，排除 4xx 客戶端錯誤）。
• 延遲 (Latency)： 在門檻內完成的請求比例（例如 p95 < 300 ms）。
• 品質 (Quality)： 未以降級模式回應的比例（例如完整搜尋 vs. 快取 fallback）。
• 新鮮度 (Freshness)： 提供資料的年齡（對於 ETL 進 BigQuery 的 pipeline 尤其關鍵）。

在 Cloud Monitoring 中，每個 SLI 都是一個 ServiceLevelIndicator 資源，可用 request_based 或 windows_based 定義。Stateless RPC 服務用 request-based；資料庫等 stateful 系統用 windows-based。

對應 SLO 到 compliance period

Cloud Monitoring 支援 rolling window（1、7、28 天）與 calendar window（週、月、季）。對於面向客戶的 API，28 天的 rolling window 是標準，因為它可平滑掉每週的流量模式，並提供穩定的月度檢視。對於批次 pipeline，使用 calendar month，因為帳務與報告會對齊該邊界。

把 SLA 連回 SLO

SLA 是 商業文件，不是監控設定。但你的 SLA credits 應由 Cloud Monitoring 的 SLO 違反觸發。使用一個訂閱 SLO 警報策略的 Cloud Function，把記錄寫入 BigQuery 的「credits owed」資料表，由財務部門每月對帳。

錯誤預算：平衡創新與風險

錯誤預算是 SRE 中最強大的概念。其計算方式為：100% - SLO。

• 如果你的 SLO 是 99.9%，你的錯誤預算就是 0.1%。
• 如果預算還有剩： 你可以快速發布功能，即使它們帶有某些風險。
• 如果預算已耗盡： 停止功能發布。團隊必須專注於可靠性、自動化以及修復故障的根本原因。

架構師見解： 錯誤預算在開發人員（想要快速移動）和 SRE（想要穩定性）之間建立了一個共同的激勵機制。如果預算花光了，每個人都有責任恢復可靠性。 ::

實務上的錯誤預算政策

沒有政策的預算只是一個指標。錯誤預算政策 (Error Budget Policy) 是一份簽署過的文件，明定預算燒光時的處理方式。

Cloud Run API 的實作範例

SLO：99.9% 可用性，28 天視窗（約 40 分鐘預算）
燃燒率 (Burn rate)：
  - 14.4× burn 持續 1 小時  → 呼叫 on-call（快速燃燒警報）
  - 6× burn 持續 6 小時    → 開單給開發團隊（慢速燃燒警報）
  - 1× burn 持續 3 天      → 每週 SLO 會議檢討

在 Cloud Monitoring 中將這些設為 multi-window, multi-burn-rate 警報策略，這是 Google 推薦的模式。單一 14.4× 燃燒率持續一小時，如果持續下去就會耗光整個 28 天預算，足以理由立即呼叫人員。

政策升級層級

1. 預算健康（剩餘 >50%）： 正常功能開發速度。Canary 部署為 5%/25%/100%。
2. 預算吃緊（剩餘 10–50%）： 縮小 canary blast radius；高風險變更需 staff engineer 簽核；凍結混沌工程演練。
3. 預算耗盡（剩餘 0%）： 功能凍結。所有工程量能轉向可靠性工作（事後分析的行動項目、移除瑣事、修復不穩定的測試）。只發布安全修補與明確的「fix-forward」可靠性變更。

減少瑣事 (Toil)

瑣事是指具備以下特性的工作：

• 手動 (Manual)
• 重複 (Repetitive)
• 可自動化 (Automatable)
• 戰術性 (Tactical)（無長期價值）
• 隨服務規模線性增長

SRE 團隊的目標是將瑣事限制在 50% 的時間內。剩下的 50% 必須花在改善系統的 專案工作（工程）上。

瑣事減少量化

無法量測的東西就無法消除。SRE 團隊每季追蹤瑣事，並把減少瑣事視為第一線的工程目標。

量測瑣事

每位 on-call 工程師維護一份 toil log，通常是 Google Sheet 或標記為「Toil」的 Jira 標籤。每次中斷都加上：

• 持續時間（分鐘）
• 類別（手動重啟、客戶單分流、容量擴增、憑證輪替等）
• 是被呼叫的還是自己發現的

把這些資料彙整到由 BigQuery 提供資料的 Looker Studio dashboard。目標是每位工程師每季的 瑣事百分比。若某人超過 50%，這是人力／自動化訊號，不是「叫他更努力工作」的訊號。

自動化投資報酬率 (ROI) 計算

對每個候選自動化，計算：

ROI = (每年節省小時數 × 員工每小時負擔成本) - 建置工程成本
回本期間 = 工程成本 / 每年節省小時數

一個 40 小時的自動化每週節省 2 小時，約 5 個月回本。回本期低於 12 個月的就是必做。超過 24 個月則需要策略性理由（例如該瑣事也在燒 SLO 預算）。

GCP 上的主要瑣事候選

• 憑證輪替： 改用全域負載平衡器上的 Google-managed SSL 憑證。
• VM 修補： 改用 Cloud Run / GKE Autopilot，由 Google 管理主機。
• 手動擴容： 使用 Managed Instance Group autoscaler 或 Cloud Run min/max instances。
• 日誌分流： 改用 Cloud Logging log-based metrics 加上把警報路由到正確團隊的策略。

事件管理與不問責的事後分析

當出現問題時，SRE 遵循結構化的流程。

1. 事件響應 (Incident Response)

• 識別 (Identify)： 檢測故障（通常透過基於 SLO 的警報）。
• 分流 (Triage)： 確定嚴重程度和影響範圍。
• 緩解 (Mitigate)： 盡快恢復服務（例如回滾、重啟、容錯移轉）。在緩解過程中 不要 試圖尋找根本原因。

2. 不問責的事後分析 (Blameless Post-mortems)

在事件發生後撰寫的文件，旨在了解發生的原因以及如何預防。

• 不問責 (Blameless)： 專注於系統故障而非人為錯誤。如果人犯了錯，系統應該設有護欄來防止它。
• 可執行 (Actionable)： 每一份事後分析都必須產生「行動清單 (Action Items)」來修復潛在問題。

透過 Cloud Functions 實作 Runbook 自動化

靜態的 runbook wiki 老化得快，工程師在凌晨 3 點貼上過時的指令。可程式化的 runbook 把這件事翻轉：runbook 本身就是程式碼，由 Cloud Function 執行。

模式：警報觸發的補救

Cloud Monitoring 警報策略
        │ （通知 channel = Pub/Sub topic）
        ▼
Pub/Sub topic：「ops-remediation」
        │
        ▼
Cloud Function（2nd gen, Python）
        │
        ├── 驗證警報是否仍在觸發（idempotency）
        ├── 採取動作（重啟 MIG、drain pod、清快取）
        ├── 把處理結果發到 Slack #incidents
        └── 在 Firestore 更新事件

該 Cloud Function 使用一個 最小權限 IAM 的服務帳號，只擁有特定動作所需的角色（例如 roles/compute.instanceAdmin.v1，且範圍限於一個 MIG）。每個動作都會發出 Audit Log 紀錄，事後分析時可重建機器人的所有行為。

何時不該自動化

自動補救在以下情況很危險：

• 故障模式未知（機器人可能放大它，例如持續壞掉的 persistent disk 上的「重啟」迴圈）。
• 動作不可逆（刪除資料、終止 Spanner instance）。
• 影響範圍是全域（不要在沒有人工介入的情況下，自動把多區域服務切換到備援）。

容量規劃與負載測試

可靠性最常見的失敗原因不是程式碼 bug，而是 容量緩衝不足。SRE 容量規劃是每季的循環，不是一次性的事。

容量模型

為每個服務維護一份試算表（或 Looker Studio dashboard），包含：

• 需求預測： 接下來 4 季每個區域的預估 QPS / GB / 連線數，由產品發布與季節性驅動。
• 單元容量： 一個 GKE pod 或一個 Cloud Run instance 在 SLO 下能承受多少負載（用負載測試量測，不是用猜的）。
• 緩衝目標： 通常是 50%，意即今天以 50% 使用率運行，這樣當某個區域故障切換、區域負載加倍時仍能撐住。

在 GCP 上做負載測試

• Locust 或 k6 跑在 GKE Autopilot 上，做分散式負載產生（便宜，可擴展到每秒數百萬請求）。
• Cloud Load Balancing 合成流量，透過 Cloud Monitoring uptime check（輕量基準）。
• 針對 BigQuery / Spanner：使用 performance overview dashboard 識別熱點 key，避免在 production 上熔毀。

容錯移轉壓力測試

每季至少進行一次 regional failover drill：drain us-central1，驗證 us-east1 能在 SLO 內承接負載，然後再 drain 回去。這同時驗證你的容量模型和 runbook。使用 Cloud Deploy 或 Terraform workflow，讓 drain 能在數分鐘內可逆。

Google Cloud 上的 SRE 實踐

GCP 提供實施 SRE 的工具：

• Cloud Monitoring： 定義並追蹤 SLI 與 SLO。
• Cloud Logging： 分析日誌以進行根本原因分析。
• Cloud Trace / Profiler： 識別效能瓶頸。
• Error Reporting： 自動分組並追蹤應用程式崩潰情況。

區域 vs 全域服務層級

不是每個服務都需要全域化。請將服務分層，讓可靠性投資與商業價值對齊。

Tier 0 — 全域多區域 active-active

• 範例：付款處理、認證、行銷首頁。
• GCP 構件：Spanner 多區域（nam-eur-asia1）、Cloud Storage 多區域 bucket、全域外部 HTTPS 負載平衡器，後端在 3 個以上區域。
• SLO 目標：99.99% 以上可用性，p95 延遲預算跨區域分配。
• Failover RTO：數秒（由 DNS 或 Anycast 處理）。

Tier 1 — 區域型，跨區域 failover

• 範例：客戶 dashboard、內部管理工具。
• GCP 構件：兩個區域的 regional GKE cluster、Cloud SQL 跨區域 read replica + promotion、Cloud Storage dual-region bucket。
• SLO 目標：99.9% 可用性。Failover RTO：5–15 分鐘（手動 promotion + DNS 更新）。

Tier 2 — 單區域、多可用區

• 範例：內部報表、批次工作、開發／staging 環境。
• GCP 構件：regional MIG 跨 3 個 zone、regional Cloud SQL、multi-zonal GKE。
• SLO 目標：99.5%——接受區域故障為可恢復事件，從備份在 RTO 內復原。

優雅降級 (Graceful Degradation) 模式

當依賴服務故障時，最糟的結果是全面失敗。優雅降級 在卸除非必要功能的同時，讓核心體驗繼續運作。

Feature flag 控制的降級

• 把每個非必要功能（推薦、個人化、複雜圖表）用 Firebase Remote Config 或 LaunchDarkly 管理的 feature flag 包起來。
• 事件中，on-call 把 flag 切到「關閉」。Cloud Run / GKE pod 會在數秒內接收變更。
• 使用者看到的是簡化版頁面而不是 500 錯誤。

唯讀模式 (Read-only mode)

對於電商與 SaaS，實作 唯讀模式，在主資料庫降級時啟用：

• 透過 envoy 層的 flag 停用寫入（加入購物車、修改設定）。
• 從 Memorystore Redis 用延長的 TTL 提供已快取的商品目錄。
• 顯示清楚的橫幅：「我們正在處理問題——購買功能稍後恢復」。

Stale-while-revalidate 快取

為 Cloud CDN 設定 stale-while-revalidate 與 stale-if-error 指令。當 origin（Cloud Run）掛掉時，CDN 會繼續提供最後快取的回應，最長 N 秒，為你爭取修復 origin 的時間，且不影響使用者。

靜態 fallback page

針對 origin 全面故障，把流量路由到 Cloud Storage 主機的靜態頁面，透過負載平衡器的 backend bucket。使用者看到「我們很快回來」而不是連線被拒的錯誤。

斷路器 (Anthos Service Mesh)

斷路器藉由 快速失敗 來阻止下游依賴不健康時的連鎖故障。

Anthos Service Mesh 的實作方式

Anthos Service Mesh (ASM) 內建 Envoy 作為 sidecar proxy。透過 Kubernetes DestinationRule 設定斷路：

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: payments-api
spec:
  host: payments.svc.cluster.local
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 50
        maxRequestsPerConnection: 10
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 30s
      baseEjectionTime: 60s
      maxEjectionPercent: 50

這給你的好處

• maxConnections： 限制併發 TCP 連線，避免單一失控 client 耗盡所有人的 pool 容量。
• outlierDetection： 連續 5 次 5xx 錯誤後，把 pod 從負載平衡 pool 中踢出 60 秒。這能在不影響整個服務的情況下，隔離一個生病的 replica。
• maxEjectionPercent: 50： 確保你永遠不會踢出超過一半的 pool，避免斷路器本身造成故障。

可觀測性 hook

ASM 把斷路器指標（envoy_cluster_outlier_detection_ejections_active）匯出到 Cloud Monitoring。建立 dashboard，把 ejection 事件與 SLO 燃燒率並列，可關聯斷路器跳脫與使用者可見的失敗。

Retry、Timeout 與 Backoff 設定

設定錯誤的 retry 是微服務連鎖故障的頭號原因。以重要性排序的三條規則：

規則 1 — 永遠設 timeout

沒有 timeout 的請求最終會永遠卡住，耗盡 thread / connection pool。在 GCP 上：

• Cloud Run： 請求 timeout 預設 5 分鐘，最多 60 分鐘。把它設為端點實際需要的最低值（通常 API 是 10–30 秒）。
• gRPC client： 永遠用 context.WithTimeout(ctx, 2*time.Second)。不要對 RPC 用 context.Background()。
• HTTPS LB → backend： 在 URL map 上設定 backend timeout（預設 30 秒）。

規則 2 — 用 exponential backoff 加 jitter 的 retry

第 1 次：立即
第 2 次：等 1s ± random(0–500ms)
第 3 次：等 2s ± random(0–1s)
第 4 次：等 4s ± random(0–2s)
最大次數：3 次（不是 10 次！）

Jitter 可以防止短暫故障後多個 client 同時 retry 造成的 thundering herd。Google 的 google.api.core.retry library 預設就正確實作這套。

規則 3 — 只對 idempotent 操作 retry

retry 一個 POST /payment 可能會向客戶收兩次錢。對任何寫入操作使用 idempotency key（client 產生的 UUID，server 端去重）。讀取（GET）以及明確 idempotent 的寫入（PUT）可安全 retry。

On-Call 訓練與輪值

可靠性是團隊能力，不是個人英雄主義的故事。成熟的 on-call 計畫能同時保護服務與工程師。

Shadow on-call 輪值

新工程師的第一個月當 shadow on-call——與 primary 配對，觀察呼叫，但無權採取動作。這能熟悉：

• Cloud Monitoring dashboard 與警報語法
• 團隊的 runbook 慣例
• 如何宣告事件並主持事件 channel

Wheel of Misfortune (桌面演練)

每月團隊舉行 1 小時的 Wheel of Misfortune 會議。一位資深工程師挑一個真實的過往事件（或編一個合理的），由受訓者敘述他會如何回應——要打開哪個 dashboard、要跑哪個 gcloud 指令、要升級給誰。「Game Master」揭曉後果。便宜、訊號高、production 風險為零。

災難復原 game day

每季舉辦一次 真正的 game day：在鏡像 production 的 staging 環境注入真實故障（殺掉一個 GKE node pool、用壓力測試節流一個 Cloud SQL replica）。on-call 輪值像對 production 一樣回應。記錄時間資料：花多久偵測、緩解、撰寫文件。

On-call 健康指標

追蹤並採取行動：

• 每班呼叫次數： 每晚 > 2 次 = 無法持續，需要自動化或調整警報。
• 睡眠中斷率： 22:00–06:00 之間的呼叫。
• 自願留任率： 如果工程師要求離開輪值，是輪值壞了，不是工程師壞了。

公平補償：許多公司會為夜間與週末提供 on-call 津貼（現金或同等補休）。

常見問題 — 可靠性工程流程

Q1. 為什麼不追求 100% 的可靠性？

因為從 99.99% 提升到 100% 的成本是天文數字，而且如果用戶自己的 ISP 或裝置只有 99% 的可靠性，他們根本不會察覺到差異。那份「額外」的可靠性最好花在提高功能開發速度上。

Q2. 「面向用戶」的 SLI 與「系統級」的 SLI 有什麼區別？

面向用戶的 SLI 衡量 體驗（例如請求延遲）。系統級 SLI 衡量 利用率（例如 CPU 使用率）。SRE 優先考慮面向用戶的 SLI 作為 SLO，因為用戶不在乎你的 CPU，他們只在乎頁面是否能載入。

Q3. 如何在傳統的「孤島式 (Siloed)」組織中啟動 SRE？

從為一項服務定義 SLO 開始。爭取對錯誤預算概念的認同。利用預算來證明將時間花在自動化上是合理的，而不僅僅是忙於「救火」。

Q4. 我可以在沒有 SLI 的情況下擁有 SLO 嗎？

不行。如果你沒有衡量方法 (SLI) 來確定是否達到目標，你就無法設定目標 (SLO)。

Q5. 監控中的「黃金指標 (Golden Signals)」是什麼？

你應該始終為任何服務監控的四個指標：延遲 (Latency)、流量 (Traffic)、錯誤 (Errors) 和 飽和度 (Saturation)。

最後的架構師建議

在 PCA 考試中，如果問題問如何處理一個「經常發布 Bug」的團隊，答案是 「實施錯誤預算並在預算耗盡時凍結發布」。如果問題問如何改進手動流程，答案是 「透過自動化減少瑣事 (Toil)」。請始終記住：SRE 關乎對風險進行 數據驅動的決策。