一家公司說：「我們要把系統搬上 Google Cloud，最好不要停機，還要比現在便宜。」
工程團隊很快就能列出 Compute Engine、GKE、Cloud Run 和 Spanner。但架構師要先踩煞車，因為真正影響答案的資訊還沒出現：
- 哪些功能不能停？
- 所謂「不要停機」要量化成多少可用性？
- 資料最多能遺失多久？
- 團隊有沒有能力維護 Kubernetes？
- 現在的成本基準包含人力、授權和機房嗎？
- 哪些法規、合約或資料位置限制真的適用？
雲端架構師的工作，不是挑一組看起來最先進的產品，而是把模糊的業務期待變成可以驗證的技術決策。
圖解：架構師不是直接選產品，而是先釐清風險、時間、成本與團隊能力，再比較候選方案並以證據驗證；上線後的結果還會回饋下一輪決策。
雲端架構師平常在做什麼？
常見工作可以整理成六類：
- 釐清需求：分辨業務目標、硬性限制和偏好。
- 設計方案：選擇運算、資料、網路、安全與營運模式。
- 說明取捨：把成本、風險、交付速度與可維護性放在一起比較。
- 帶領落地：和開發、維運、安全、財務與法務團隊確認責任。
- 驗證假設：透過 PoC、負載測試、故障演練和成本資料驗證設計。
- 持續調整：架構上線後仍要根據 SLO、事故和需求變化改善。
所以架構圖只是產物之一。更重要的是圖背後的假設、證據，以及發生變化時怎麼改。
ACE 和 PCA 的差別
兩張認證都會碰到 Google Cloud 服務，但看的角度不同。
| 面向 | Associate Cloud Engineer | Professional Cloud Architect |
|---|---|---|
| 核心問題 | 如何正確建立與操作資源？ | 為什麼這個方案符合目前需求？ |
| 常見任務 | 部署、設定、監控與排錯 | 需求分析、選型、遷移與治理 |
| 判斷依據 | 指令、權限與產品行為 | 業務目標、風險與架構取捨 |
| 題目特色 | 操作情境為主 | 跨產品情境與案例研究 |
| 學習方式 | 動手做出可運作的資源 | 比較候選方案並說明淘汰理由 |
PCA 並不是「背更多服務名稱的 ACE」。如果只記「看到容器就選 GKE」，遇到團隊能力、成本或維運限制時就很容易選錯。
最新標準考試怎麼考？
截至本課更新，標準考試資訊如下：
| 項目 | 官方資訊 |
|---|---|
| 時間 | 2 小時 |
| 題數 | 50–60 題 |
| 題型 | 單選與複選 |
| 費用 | USD 200，另加適用稅費 |
| 語言 | 英文、日文 |
| 案例研究 | 每次 2 個，約占 20–30% |
| 認證效期 | 2 年 |
| 正式先修 | 無 |
| 建議經驗 | 3 年以上業界經驗，其中 1 年以上設計與管理 Google Cloud 方案 |
費用、語言與考試政策可能調整。報名前請回到官方認證頁確認，不要只看課程截圖。
標準考試的六個領域
目前官方考綱分成：
| 領域 | 權重 |
|---|---|
| 設計與規劃雲端解決方案架構 | 約 25% |
| 管理與佈建雲端解決方案基礎架構 | 約 17.5% |
| 設計安全與合規 | 約 17.5% |
| 分析與優化技術和業務流程 | 約 15% |
| 管理雲端架構實作 | 約 12.5% |
| 確保解決方案與營運卓越 | 約 12.5% |
這些領域不是六個互不相干的章節。一題遷移案例可能同時考網路、安全、成本、團隊能力和復原目標。
四個案例研究
標準考試目前可能使用：
- Altostrat Media
- Cymbal Retail
- EHR Healthcare
- KnightMotives Automotive
每次考試會出現其中兩個。案例文件會在考試畫面中顯示，但如果第一次看才開始找需求，時間會很緊。
準備時不要替每個案例背一張固定架構。比較有效的做法是整理：
- 現況與主要痛點
- 商業需求
- 技術需求
- 明確限制
- 利害關係人真正重視的結果
產品會更新，這五類訊息才是選答案的依據。
續證考試是另一條路
持有仍有效的 PCA 認證，並進入續證資格期間後，可以選擇標準考試或較短的續證考試。
目前續證考試為 1 小時、25 題、費用 USD 100；包含一個生成式 AI 案例，案例題占比很高。它和第一次報考的標準考試不同，不要把兩份考綱混著準備。
Well-Architected Framework 是共同語言
Google Cloud Well-Architected Framework 目前有六個支柱：
- 卓越營運
- 安全、隱私與合規
- 可靠性
- 效能優化
- 成本優化
- 永續性
它的用途不是替每個方案打六個勾，而是提醒團隊：改善一個面向時，是否犧牲了另一個更重要的目標。
例如跨區域部署可能改善故障承受能力，卻增加成本、寫入延遲與營運複雜度。是否值得，得回到服務的復原目標與業務損失判斷。
下一課會把這六個支柱變成實際的檢查問題。
這門課怎麼學比較有效？
每個服務都問四件事
遇到新產品時，不要急著背功能清單，先問：
- 它解決哪一類問題？
- 使用者仍要負責什麼？
- 哪些限制會讓它不適合？
- 要用什麼指標證明它真的符合需求？
練習排除，而不是只記答案
看到四個看似合理的選項時，替每個被排除的方案寫一句原因。只會說「A 正確」還不夠；能說明 B 違反資料位置限制、C 超出團隊能力、D 無法達到 RPO，才算真的會判斷。
把產品事實和設計假設分開
「Spanner 的特定多區域配置提供某個 SLA」是產品事實。
「這個系統需要 Spanner」是設計結論，中間還需要交易模型、規模、位置、延遲與成本等證據。不要把兩者混成一句考試口訣。
保留動手能力
PCA 偏重設計，不代表可以完全不操作。至少要親手做過 VPC、IAM、Cloud Run、資料庫備份、監控告警與 Terraform，否則很難看出架構方案的營運代價。
課後檢查
你應該能回答：
- 一個「高可用而且便宜」的需求，還要追問哪些資訊？
- ACE 與 PCA 的判斷角度差在哪裡？
- 為什麼不能替每個案例研究背一套固定產品組合？
- Well-Architected Framework 如何幫助團隊看見取捨？
下一課會用六大支柱檢查同一個系統，練習把抽象原則轉成能驗證的架構問題。
