一家電商準備把訂單 API 部署到兩個區域。有人說這樣比較可靠，也有人擔心資料同步、成本和維運複雜度。
六大支柱不會直接替團隊選答案。它們比較像六個檢查角度，幫你看見「改善可靠性」這句話背後還牽動了什麼。
圖解：營運、安全、可靠性、效能、成本與永續性不是六張獨立清單；調整其中一個面向，通常會連動其他支柱，最後仍要回到工作負載的優先順序取捨。
框架的正確用法
Google Cloud Well-Architected Framework 提供的是原則與建議，不是一張所有系統都要照抄的產品清單。
可以用這個順序：
- 先寫出業務結果和硬性限制。
- 用六大支柱找出漏掉的問題。
- 提出兩到三個可行方案。
- 說明每個方案的取捨與風險。
- 用測試、指標和演練驗證假設。
- 上線後定期重新檢視。
框架目前也有 AI/ML、金融服務等跨支柱 Perspective。它們把同一組原則套進特定技術或產業情境，但不會取代六大支柱。
卓越營運：系統出事時，團隊接得住嗎？
卓越營運關心的不只是監控工具，而是團隊能否安全、重複地變更與維護系統。
架構審查可以問：
- 基礎設施是否用 Terraform 等 IaC 管理？
- 變更是否經過審查、測試與可回退的部署流程？
- 服務是否有明確的 SLI、SLO、告警和 Runbook？
- 誰負責事件指揮、溝通與事後檢討？
- 重複的人工操作能否自動化？
- 新團隊成員能否從文件重建關鍵環境？
常見工具包括 Terraform、Infrastructure Manager、Cloud Build、Cloud Deploy 和 Google Cloud Observability。不過有工具不等於有流程；告警若沒有負責人和處理方式，仍然只是通知。
安全、隱私與合規：誰能對什麼做什麼？
安全支柱要從身分、資料和信任邊界一起看。
可以問：
- 人員和工作負載是否使用獨立身分？
- 權限是否遵守最小權限與職責分離？
- 是否能避免長效服務帳戶金鑰？
- 敏感資料在哪裡產生、傳輸、儲存和刪除？
- 預設加密是否足夠，還是需要 CMEK 或外部金鑰控制？
- 公開入口、內部服務與管理介面的信任邊界是否清楚？
- 稽核紀錄是否完整，而且只有適當人員能讀取？
IAM、Organization Policy、Cloud KMS、Secret Manager、Sensitive Data Protection、Cloud Armor 與 VPC Service Controls 解決的是不同層次的問題，不能互相替代。
「使用某個安全產品」也不等於自動合規。法規與合約要求要由組織的法務、隱私和安全團隊共同確認。
可靠性：先定義可以壞到什麼程度
可靠性不是把每個服務都改成多區域，而是先定義可接受的服務中斷與資料損失。
可以問：
- 使用者真正需要的可用性目標是多少？
- 哪些依賴是單點故障？
- 故障範圍要防單一實例、可用區、區域，還是人為誤刪？
- RTO 與 RPO 是多少？
- 備份能否還原，最近一次演練是什麼時候？
- 容量不足、配額用完和錯誤部署要怎麼處理？
- 降級模式是否比完全中斷更有用？
高可用和災難復原不是同一件事。多副本可能抵抗硬體故障，卻會同步錯誤刪除；因此仍需要備份、版本和還原演練。
效能優化：先量到瓶頸，再決定花錢的位置
效能問題可能出在應用程式、資料庫、網路或外部依賴。直接換更大的 VM，未必處理到根因。
可以問：
- 使用者在意的是 P50、P95 還是 P99 延遲？
- 尖峰吞吐量和請求形狀是什麼？
- 哪一段耗時最多，有 Trace 或 Profile 證據嗎？
- 快取能否接受資料陳舊？
- 資料和運算位置是否造成不必要的跨區延遲？
- 壓力測試是否包含失敗、重試和下游變慢？
Cloud Load Balancing、Cloud CDN、Memorystore、Cloud Trace 和 Cloud Profiler 都可能有幫助，但要先建立基準再改。沒有基準，就不知道優化是否真的有效。
成本優化：花費是否對應業務價值？
成本優化不是把每個資源都選成最低規格，也不是看到折扣就先承諾三年。
可以問：
- 哪個團隊、產品或客戶產生這筆成本？
- 費用隨請求、資料量和區域流量如何成長？
- 工作負載穩定到足以使用 CUD 嗎？
- Spot VM 中斷時，任務能否重試或續跑？
- 是否有閒置資源、過度配置和不必要的跨區傳輸？
- 預算告警發出後，誰負責採取行動？
- 降低成本是否會破壞 SLO 或增加大量人工作業？
FinOps 是持續的共同責任。財務提供成本視角，工程團隊解釋用量，產品團隊判斷商業價值，架構師協助把三者放進同一個決策。
永續性：能否用更少資源完成同一件事？
永續性不只是挑一個碳排較低的區域。使用者延遲、資料主權與服務可用性仍是硬性條件。
可以問：
- 是否存在長期閒置或過度配置的資源？
- 資料保留期限是否合理？
- 能否使用自動擴縮、批次或代管服務提高利用率？
- 軟體是否做了不必要的重複計算與資料搬移？
- GPU、TPU 等加速器是否被充分使用？
- 在符合其他限制的候選區域中，能否優先選較低碳的位置？
效能、成本和永續性常會一起改善。例如縮短低效率查詢，不只回應更快，也減少運算時間和費用。
支柱之間沒有固定換算表
常見取捨可以這樣分析：
| 決策 | 可能改善 | 可能付出的代價 | 需要的證據 |
|---|---|---|---|
| 跨區域部署 | 區域故障承受能力 | 成本、寫入延遲、營運複雜度 | RTO/RPO、區域故障情境、流量測試 |
| 提高最小實例數 | 尖峰與冷啟動延遲 | 閒置成本 | 延遲 SLO、流量曲線 |
| 使用全代管服務 | 維運效率與標準化 | 部分控制力、遷移限制 | 功能差距、團隊能力、退出方案 |
| 增加快取 | 讀取效能與下游保護 | 資料新鮮度、失效複雜度 | 可接受陳舊時間、命中率 |
| 使用 Spot VM | 可中斷工作的成本 | 中斷與重試 | Checkpoint 能力、完成時間目標 |
同一個決策不一定只屬於一個支柱。這正是框架的價值：它迫使團隊把副作用說出來。
練習：用六大支柱審查一個全球商店
需求如下：
- 使用者分布在亞洲、歐洲和北美
- 結帳服務有明確可用性目標
- 商品瀏覽可以短暫降級
- 支付資料受合約與產業規範限制
- 團隊每週發布數次
- 流量會在活動期間快速上升
不要立刻選產品。先替每個支柱寫一個問題：
- 卓越營運：發布失敗時能否快速回退？
- 安全合規：支付資料的範圍與存取者是誰？
- 可靠性：結帳和瀏覽是否需要相同復原目標？
- 效能：哪個地區、哪個百分位延遲要達標？
- 成本：活動備援容量平時是否會閒置？
- 永續性：能否用自動擴縮減少非尖峰資源？
接著再提出候選方案，並為每個答案標記「已知事實」或「待驗證假設」。這比直接畫一張多區域架構圖更接近真正的架構工作。
課後檢查
你應該能回答：
- 為什麼有監控工具不代表已達到卓越營運？
- 高可用和可還原性差在哪裡？
- CUD 為什麼不能在沒有用量基準時直接購買？
- 一項跨區域設計會同時影響哪些支柱？
- 什麼是產品事實，什麼是仍需驗證的架構假設？
下一課會進入運算選型。我們會從工作負載需要多少控制權開始，而不是把產品名稱和題目關鍵字硬配在一起。
