Chaos Engineering 與韌性 (Resilience)

Chaos Engineering 簡介

在分散式雲端環境中，故障是不可避免的。混沌工程 (Chaos Engineering) 是一門對系統進行實驗的學科，目的是建立對系統承受生產環境中動盪條件能力的信心。我們與其等待災難發生，不如主動注入故障來觀察系統的反應。

對於 Professional Cloud Architect 來說，Chaos Engineering 是從「希望系統可靠」轉向「證明系統具備韌性」的過程。

白話文解釋 Chaos Engineering

比喻 1 — 疫苗接種

Chaos Engineering 就像是疫苗。你將微量且受控的「病毒」（故障）注入體內（系統），以訓練免疫系統（自我修復機制）。這樣一來，當真正的「病毒」（重大停機）襲來時，身體已經準備好與之對抗，而不會生病。

比喻 2 — 消防演習

Chaos Engineering 是不預先通知的消防演習。如果你只在大家都知道演習即將到來時才進行練習，你將無法得知人們在真正遇到濃煙時會如何反應。透過出其不意地（以受控的方式）拉響警報，你可以發現逃生出口是否被堵塞，或是警報聲是否太小而聽不見。

比喻 3 — 撞擊測試

汽車製造商不只是「希望」汽車是安全的。他們會進行撞擊測試。他們故意讓汽車撞上牆壁（故障注入），以觀察安全氣囊是否彈出以及車架是否保護了乘客。Chaos Engineering 就是針對你的軟體架構進行的撞擊測試。

Chaos Engineering 的原則

1. 定義「穩態 (Steady State)」： 了解「正常」情況下的表現（例如：99.9% 的成功率，延遲 <200ms）。
2. 提出假設： 預測注入故障時會發生什麼（例如：「如果執行個體 A 故障，執行個體 B 將在 5 秒內接管」）。
3. 注入故障： 引入現實世界中的事件，如伺服器當機、網路延遲或格式錯誤的資料。
4. 觀察與學習： 系統是否恢復到穩態？假設是否成立？
5. 修復弱點： 如果系統失敗，請改進架構（例如：增加冗餘、實作斷路器）。

在 Google Cloud 上進行 Chaos Engineering

• GKE 韌性： 使用 Chaos Mesh 或 Gremlin（第三方）等工具來刪除 Pod、耗盡節點的 CPU，或模擬命名空間之間的網路延遲。
• Compute Engine： 故意刪除受管理執行個體群組 (Managed Instance Group, MIG) 中的執行個體，以測試自動修復 (Auto-healing) 和自動調整規模 (Auto-scaling) 的行為。
• 網路： 使用 Firewall Rules 模擬區域 (Region) 或可用區 (Zone) 之間的連線中斷，以測試容錯移轉 (Failover) 邏輯。

測量與最小化爆炸半徑 (Blast Radius)

Chaos Engineering 最大的恐懼是真正破壞了生產環境。為了防止這種情況：

• 從小規模開始： 先在預備環境 (Staging environment) 中開始。
• 金絲雀測試 (Canary Testing)： 僅對小部分使用者運行實驗。
• 停止按鈕： 務必設有一個「大紅鈕 (Big Red Button)」，以便在情況惡化時立即中止實驗並恢復系統。

架構師洞察： 在 PCA 考試中，如果情境詢問如何「驗證多區域 (Multi-Regional) DR 計畫的可靠性」，最佳答案是定期進行 Chaos 實驗（如演練日 Game Days），而不僅僅是「審查文件」。 ::

GCE 故障注入測試 (Fault Injection Testing)

Compute Engine 提供多種第一方工具，可以在不依賴第三方工具的情況下，安全地注入基礎架構層的故障。

透過 MIG 注入執行個體層級故障

Managed Instance Group (MIG) 搭配 autohealing 是最簡單的 chaos 測試目標。經典實驗如下：

1. 定義穩態： L7 Load Balancer backend healthy_backend_count >= 4、請求成功率 >= 99.9%。
2. 注入故障： 對 MIG 中隨機一個成員執行 gcloud compute instances delete instance-1 --zone=us-central1-a。
3. 觀察： MIG 的 autohealer 應該在設定的 initialDelaySec 內，根據 instance template 重新建立執行個體。Cloud Load Balancing 應透過 connection_draining_timeout_sec 平滑地清空連線。
4. 學習： 如果成功率掉到 99.9% 以下，代表 MIG 規模太小或 health check 的 unhealthyThreshold 太激進。

模擬可用區與區域層級故障

要進行更大爆炸半徑的實驗，可以使用 VPC Firewall Rules 來「隔離」一個 zone：

gcloud compute firewall-rules create chaos-block-zone-a \
  --direction=INGRESS --action=DENY --rules=tcp \
  --source-ranges=0.0.0.0/0 --target-tags=zone-a-instances

這可以驗證 Regional MIG 是否正確地將流量重新分配到存活的 zone（us-central1-b、us-central1-c），以及 Cloud DNS failover 政策是否在預期的 TTL 時間內生效。

磁碟與快照恢復演練

從一台運行中的 VM 卸載 Persistent Disk（gcloud compute instances detach-disk），可以驗證應用程式是否能優雅地處理 I/O 錯誤，以及 Snapshot Schedule 還原程序是否符合 RTO 目標。請將還原時間記錄在事後回顧 (post-mortem) 中，讓團隊有實際數據而非估計值。

Cloud Deploy 金絲雀部署故障測試

Cloud Deploy 負責將應用程式持續交付到 GKE、Cloud Run 與 Anthos 目標。它的 canary（金絲雀） 策略本身就是一種 chaos engineering 原則 — 你刻意把有問題的版本提供給一小部分流量，藉此驗證 rollback 安全機制是否運作。

設定金絲雀驗證階段 (Verification Phase)

DeliveryPipeline 採用 canary 策略時，可以定義漸進式階段（10%、25%、50%、100%），每個階段都明確設定 verify 步驟。搭配 Cloud Deploy automation rules（promoteRelease、repair），讓系統做到：

• 如果 verify 工作失敗（Cloud Build job 退出碼非零、Skaffold custom test 失敗），rollout 自動 rollback 回前一個 Release。
• 如果金絲雀階段在 dwell time 結束後 Cloud Monitoring 沒有觸發告警，automation 會自動推進到下一階段。

刻意製造失敗的實驗

要證明安全機制有效，就刻意在 staging 環境部署一個「壞掉」的金絲雀：

• 錯誤設定實驗： 推送一個 Release，container 的 readinessProbe 路徑故意設錯。驗證 Cloud Deploy 是否在 progressDeadlineSeconds 內偵測到不健康的 pod 並觸發 repair。
• SLO 退化實驗： 推送一個會多睡 500ms 的版本。Cloud Monitoring 的 SLO burn-rate 告警應該要觸發，下一階段的 pre-deploy hook 應該要拒絕推進。

Spanner 與多區域 GCS 的區域容錯演練

GCP 架構中最大的可靠性宣稱都在多區域儲存 — nam-eur-asia1 Spanner 執行個體、nam4 GCS dual-region、multi-region BigQuery。這些都需要定期演練，不能只是相信 SLA。

Cloud Spanner 多區域容錯演練

多區域 Spanner 設定（例如 nam3 = us-east4 + us-east1 + witness）可以在單一區域失效時透明地維持服務。要驗證它：

1. 穩態： Spanner client p99 commit latency < 100ms、錯誤率 < 0.01%，從第三個區域（例如 us-central1）跑的 workload generator 來測量，避免量測偏差。
2. 注入故障： 使用 VPC Firewall Rules 或移除 Private Service Connect endpoint，阻斷應用程式連到 read-write region。Spanner clients 應該會透明地路由到下一個 replica。
3. 驗證： 延遲可能短暫飆高，但寫入不應該失敗。spanner.googleapis.com/api/request_count 指標依 replica_type 分組可以看到流量轉移。

多區域 GCS Bucket 容錯

對於設定了 turbo replication 的 dual-region GCS bucket（nam4 = us-central1 + us-east1），RPO 為 15 分鐘。演練步驟：

• 使用 deny-all 防火牆，或從 VM 透過 gcloud storage --impersonate-service-account（該 service account 的 IAM 只授權給其中一個區域）。
• 確認應用程式 client library 的 retry policy（storage.Client(retry=...)）能在區域阻斷下存活，且不會把錯誤暴露給使用者。
• 比對演練前後的 storage.googleapis.com/replication/missing_dest_object_count，驗證 turbo replication 是否追上。

事後回顧文化與演練日 (Game Days)

Chaos Engineering 只有在組織能消化學習成果時才會產生訊號。能把迴圈閉合起來的兩個組織實踐：blameless post-mortem 與 Game Day。

Blameless 事後回顧流程

GCP 上有用的事後回顧應該引用實際 artifacts，而不是個人意見：

• Cloud Logging 連結指向衝擊發生的時刻（使用 timestamp >= "2026-05-12T10:00:00Z" AND severity >= ERROR）。
• Cloud Monitoring 儀表板快照，顯示 SLI 退化與恢復過程。
• Error Reporting 群組 ID，列出事件期間飆升的錯誤。
• 行動項目以 Cloud Build issue 或 Jira ticket 開立，指派負責人與到期日。

Blameless 思維聚焦在系統缺口（「autoscaler 花了 4 分鐘才反應」），而非個人（「工程師推了錯誤的設定」）。這樣才能解鎖誠實回報，並讓下一輪 chaos 實驗可以針對的架構問題浮上檯面。

Game Day 的運作機制

一個 Game Day 是 2 至 4 小時的預定演練，由一個團隊設計情境，另一個團隊在毫無預警下進行回應。

• 情境設計： 「14:00 將刪除 Cloud SQL prod-orders 的 read replica。Tier-1 服務必須維持可用。」
• 角色分工： Incident Commander、Communications Lead、Subject Matter Experts、Observers（負責記錄供事後回顧使用）。
• 工具： 用實際的 on-call 頻道執行演練，使用真實的 Cloud Monitoring 告警。不要「模擬」通知 — 收到真實 PagerDuty 通知的摩擦本身就是測試的一部分。

FAQ — Chaos Engineering 與韌性

Q1. Chaos Engineering 與測試 (Testing) 相同嗎？

不完全相同。傳統測試檢查程式碼是否按照預期執行（輸入 A -> 輸出 B）。Chaos Engineering 則是探索系統在壓力下的表現等未知領域（故障 X -> 系統穩定性？）。

Q2. 我們應該在生產環境中進行 Chaos 實驗嗎？

最終是需要的。在預備環境中測試很好，但預備環境永遠無法完美匹配生產環境的規模和複雜性。但是，只有在你對預備環境的結果有信心並擁有嚴格的「停止按鈕」時，才轉向生產環境。

Q3. 什麼是「斷路器 (Circuit Breaker)」？

斷路器是一種軟體模式，當達到特定的錯誤閾值時，它會停止服務嘗試呼叫發生故障的依賴項。這可以防止單一故障導致整個系統發生「級聯故障 (Cascading failure)」。

Q4. 「優雅降級 (Graceful Degradation)」是如何運作的？

優雅降級意味著當系統的一部分發生故障時，系統的其餘部分仍能保持運作，但功能會有所減少。例如，如果「推薦引擎」停機，電子商務網站仍允許使用者搜尋和購買產品，但沒有個人化的建議。

Q5. 什麼是「演練日 (Game Days)」？

演練日 (Game Day) 是一個預定的活動，團隊成員聚集在一起執行 Chaos 實驗。這是一項社交與技術性的練習，旨在協作環境中練習事件回應並發現系統弱點。