什麼是雲端架構師？先學會問對問題

一家公司說：「我們要把系統搬上 Google Cloud，最好不要停機，還要比現在便宜。」

工程團隊很快就能列出 Compute Engine、GKE、Cloud Run 和 Spanner。但架構師要先踩煞車，因為真正影響答案的資訊還沒出現：

• 哪些功能不能停？
• 所謂「不要停機」要量化成多少可用性？
• 資料最多能遺失多久？
• 團隊有沒有能力維護 Kubernetes？
• 現在的成本基準包含人力、授權和機房嗎？
• 哪些法規、合約或資料位置限制真的適用？

雲端架構師的工作，不是挑一組看起來最先進的產品，而是把模糊的業務期待變成可以驗證的技術決策。

雲端架構師平常在做什麼？

常見工作可以整理成六類：

1. 釐清需求：分辨業務目標、硬性限制和偏好。
2. 設計方案：選擇運算、資料、網路、安全與營運模式。
3. 說明取捨：把成本、風險、交付速度與可維護性放在一起比較。
4. 帶領落地：和開發、維運、安全、財務與法務團隊確認責任。
5. 驗證假設：透過 PoC、負載測試、故障演練和成本資料驗證設計。
6. 持續調整：架構上線後仍要根據 SLO、事故和需求變化改善。

所以架構圖只是產物之一。更重要的是圖背後的假設、證據，以及發生變化時怎麼改。

清單和下面這張圖有幾個縮寫，先有個印象就好。PoC（概念驗證）是先小規模試做，看想法行不行得通。SLI、SLO 是把「穩不穩」寫成量得到的指標和目標；RTO、RPO 是出事後多久要恢復、最多能掉多久的資料；ADR 是把「當時為什麼這樣決定」記下來的文件。後面這五個，第 5 課會細講。

flowchart TB
  B["Business expectation<br/>快、穩、安全、便宜"] --> Q["追問 User journey、Risk、<br/>Timeline、Team、Compliance"]
  Q --> R["量化 Requirements／Constraints<br/>SLI、SLO、RTO、RPO、Budget"]
  R --> C["提出 2–3 個可行 Candidates"]
  C --> T["比較 Trade-offs<br/>Control、Reliability、Cost、Operations"]
  T --> E["PoC／Load test／Failure drill／Cost model"]
  E --> D{"Evidence 支持假設？"}
  D -->|"否"| Q
  D -->|"是"| A["ADR＋Implementation＋Runbook"]
  A --> O["觀察 SLO、Incidents、Cost、New needs"]
  O --> Q

ACE 和 PCA 的差別

兩張認證都會碰到 Google Cloud 服務，但看的角度不同。

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

PCA 並不是「背更多服務名稱的 ACE」。如果只記「看到容器就選 GKE」，遇到團隊能力、成本或維運限制時就很容易選錯。

最新標準考試怎麼考？

截至本課更新，標準考試資訊如下：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

費用、語言與考試政策可能調整。報名前請回到官方認證頁確認，不要只看課程截圖。

標準考試的六個領域

目前官方考綱分成：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

這些領域不是六個互不相干的章節。一題遷移案例可能同時考網路、安全、成本、團隊能力和復原目標。

四個案例研究

標準考試目前可能使用：

• Altostrat Media
• Cymbal Retail
• EHR Healthcare
• KnightMotives Automotive

每次考試會出現其中兩個。案例文件會在考試畫面中顯示，但如果第一次看才開始找需求，時間會很緊。

準備時不要替每個案例背一張固定架構。比較有效的做法是整理：

• 現況與主要痛點
• 商業需求
• 技術需求
• 明確限制
• 利害關係人真正重視的結果

產品會更新，這五類訊息才是選答案的依據。

flowchart TB
  C["Case document"] --> F["Existing environment<br/>Pain points／Business／Technical／Constraints"]
  F --> O["Stakeholder outcome<br/>真正要改善什麼"]
  Q["Current question"] --> A{"Action word？<br/>Design／First／Migrate／Secure／Optimize"}
  O --> A
  A --> P["逐項比對 Options"]
  P --> X["排除違反 Hard constraint、<br/>多餘複雜度或錯誤責任邊界"]
  X --> E["選最直接滿足當題要求<br/>且能由 Case evidence 支持的答案"]

續證考試是另一條路

持有仍有效的 PCA 認證，並進入續證資格期間後，可以選擇標準考試或較短的續證考試。

目前續證考試為 1 小時、25 題、費用 USD 100；包含一個生成式 AI 案例，案例題占比很高。它和第一次報考的標準考試不同，不要把兩份考綱混著準備。

官方目前也提供透過 Google Skills 指定課程或技能徽章續證的途徑。適用者須持有有效認證、進入該途徑的資格窗口，並依官方流程連結 CM Connect 與 Google Skills／Google Skills for Partners 帳號、同意所需的資料分享，再於期限內完成該次續證路徑認列的指定學習。這條途徑會在目前的認證失效日期上增加 1 年，與考試續證的效期不同；一般課程完成紀錄本身不會自動換成續證。每次仍需核對當下顯示的資格與指定路徑，詳見官方認證頁及續證選項 FAQ。

Well-Architected Framework 是共同語言

Google Cloud Well-Architected Framework 目前有六個支柱：

• 卓越營運
• 安全、隱私與合規
• 可靠性
• 效能優化
• 成本優化
• 永續性

它的用途不是替每個方案打六個勾，而是提醒團隊：改善一個面向時，是否犧牲了另一個更重要的目標。

例如跨區域部署可能改善故障承受能力，卻增加成本、寫入延遲與營運複雜度。是否值得，得回到服務的復原目標與業務損失判斷。

下一課會把這六個支柱變成實際的檢查問題。

這門課怎麼學比較有效？

每個服務都問四件事

遇到新產品時，不要急著背功能清單，先問：

1. 它解決哪一類問題？
2. 使用者仍要負責什麼？
3. 哪些限制會讓它不適合？
4. 要用什麼指標證明它真的符合需求？

練習排除，而不是只記答案

看到四個看似合理的選項時，替每個被排除的方案寫一句原因。只會說「A 正確」還不夠；能說明 B 違反資料位置限制、C 超出團隊能力、D 無法達到 RPO，才算真的會判斷。

把產品事實和設計假設分開

「Spanner 的特定多區域配置提供某個 SLA」是產品事實。

「這個系統需要 Spanner」是設計結論，中間還需要交易模型、規模、位置、延遲與成本等證據。不要把兩者混成一句考試口訣。

flowchart TB
  P["Product facts<br/>Capabilities、Limits、<br/>SLA、Regions"] --> C["Candidate fit"]
  W["Workload facts<br/>Transactions、<br/>Scale、Location、<br/>Latency、Team"] --> C
  C --> H["Architecture hypothesis<br/>此方案可能符合需求"]
  H --> V["PoC／Benchmark／Failover／Cost validation"]
  V --> D{"Evidence 足夠？"}
  D -->|"否"| H
  D -->|"是"| A["Decision＋Known trade-offs＋Review trigger"]
  A --> R["Architecture Decision Record"]

保留動手能力

PCA 偏重設計，不代表可以完全不操作。至少要親手做過 VPC、IAM、Cloud Run、資料庫備份、監控告警與 Terraform，否則很難看出架構方案的營運代價。

15 分鐘離線練習：會議上說過，等於已經證明了嗎？

以下是本站編寫的校務設備報修情境，只需筆記，不用登入或修改任何服務。你的任務是交出下一步的判斷依據，這一輪先不選 Google Cloud 產品。先獨立作答，再展開參考判斷。

同一場會議提供了五段紀錄：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

目前尚未訂出送單的量測目標、可接受中斷與資料損失，也沒有統一現行總成本的計算範圍。這些是本題明確缺少的資料，不能自行補一組數字當成已核准需求。

先交出三項成果：

1. 逐段標記已知事實、期望、限制、假設或未知；一段話可以包含多種性質，但要寫清楚哪部分屬於哪一種。
2. 選出最先問的三個問題。每個問題旁寫一句「答案會改變哪個設計或驗證」，讓追問能支援決策。
3. 提出這週先取得的一份證據，寫出對象、範圍、取得方式，以及出現什麼結果時會改變下一步。這是紙上計畫，不需實際跑壓測或還原。

改一個條件：本次範圍縮小了

專案負責人補充：三週內只改善現有的送單步驟，資料庫更換與跨區搬遷不在本次核准範圍。其他證據不變。

你的第一步與可批准範圍應如何改？原本的「搬到雲端就會更快、更省」是否因此得到證明？

課後檢查

你應該能回答：

• 一個「高可用而且便宜」的需求，還要追問哪些資訊？（回開頭那六個追問）
• ACE 與 PCA 的判斷角度差在哪裡？（回〈ACE 和 PCA 的差別〉）
• 為什麼不能替每個案例研究背一套固定產品組合？（回〈四個案例研究〉）
• Well-Architected Framework 如何幫助團隊看見取捨？（回〈Well-Architected Framework 是共同語言〉）

答不出來的話，括號裡是該回去重讀的那一節。

下一課會用六大支柱檢查同一個系統，練習把抽象原則轉成能驗證的架構問題。

官方資料

• Professional Cloud Architect 認證
• Professional Cloud Architect 標準考試指南
• Google Cloud Well-Architected Framework