PCA 架構之旅 01 — 讀懂案例情境
PCA（Professional Cloud Architect）考試最特別的地方，不是考你記不記得 200 個 GCP 服務，而是給你一份 10 頁的 case study，然後要你在 2 小時內設計出一套合理的架構。
很多人第一題就翻車，不是因為不懂 GCP，而是沒讀懂題目。這是整個系列的第一步：把案例情境吃透。
這是 13 步驟 PCA 架構之旅 的開場。
為什麼這一步重要
在 PCA case study 題目中怎麼出現
Google 官方提供的 case study（目前為 EHR Healthcare、Cymbal Retail、Altostrat Media、Knight Motives Automotive；過去的 TerramEarth、Mountkirk Games 已退役）都有固定結構：公司背景、目前狀況、業務需求、技術需求、管理層陳述。考試裡大約 30% 的題目會直接引用 case study 的文字，另外 40% 能不能答對，就看你對案例情境吃得多透。
考生常見錯誤
- 跳過敘事段落直接看需求清單：管理層那段話常常藏著「我們最在意 time-to-market」這種關鍵，跳過就選錯方向。
- 把所有需求看成同等重要：case study 會塞 20 個需求，其中只有 5 個是主線，其他是干擾。
- 忽略產業特性：醫療業的 HIPAA、金融業的 PCI DSS、遊戲業的低延遲，這些隱含限制會直接否決掉一半的服務選項。
核心概念
讀懂一個 case study，本質上是回答 5 個問題：
| 面向 | 你要找到什麼 |
|---|---|
| 業務情境（Business Context） | 這家公司在做什麼生意、目前痛點是什麼 |
| 技術現況（Current State） | on-prem 還是雲上、用什麼資料庫、有沒有遺產系統（legacy system） |
| 業務目標（Business Goals） | 管理層期望在多久內達到什麼結果 |
| 技術需求（Technical Requirements） | 效能、可用性、合規、預算的硬性限制 |
| 利害關係人（Stakeholders） | CEO、CTO、開發團隊、維運團隊各自在意什麼 |
技術名詞補充：SLO（Service Level Objective）是目標服務水準，例如 99.9% 可用性；RTO/RPO（Recovery Time/Point Objective）是災難復原的時間與資料遺失上限。
思考框架
拿到自己的 case study 時，依序問自己：
- 如果要用一句話介紹這家公司給新同事聽，你會怎麼說？ 講不出來代表還沒讀懂。
- 這家公司現在最痛的三件事是什麼？ 架構設計要優先解決這三件。
- 管理層與工程團隊的目標有沒有衝突？ 例如 CEO 要 6 個月上線、CTO 要完整重構，你得在架構裡做取捨。
- 產業規範（regulatory requirements）會否決掉哪些服務？ 資料駐留（data residency）、加密、稽核要求常會刪掉 multi-region 自動複製等選項。
- 哪些需求是「必須滿足」，哪些是「加分項」？ 考試時先滿足必須項，加分項留到預算允許再加。
走一遍範例 — 登雲書店
公司背景： 登雲書店是一家經營 8 年的線上書店，台灣市場占有率約 12%，擁有 80 萬會員、每月 45 萬筆訂單。目前系統部署在地端機房（台北內湖、桃園中壢各一座），使用自建的 LAMP 架構與 MySQL 主從複製。
目前痛點：
- 雙 11、春節書展流量暴增 10 倍，每次都因 DB 過載當機 2–4 小時。
- 新功能上線平均需 6 週，因為測試環境只有一套，QA 排隊。
- 維運團隊 6 人，其中 3 人全職處理機房硬體事務，無力改善程式品質。
業務目標（未來 18 個月）：
- 進軍日本與韓國市場，目標合計 20 萬會員。
- 推出電子書訂閱制服務，預計帶來 30% 新營收。
- 將每月的維運與機房折舊成本降低 35%。
技術需求：
- 尖峰時段首頁響應 P95 < 500ms。
- 訂單與金流資料 99.99% 可用性。
- 符合個資法與 PCI DSS 4.0.1。
- 未來 3 年不需再投資機房硬體。
管理層語錄：
- CEO：「我不在乎你們用什麼技術，但上雲必須在 12 個月內完成，而且不能讓 Day 1 的顧客感覺到差別。」
- CTO：「我們缺的不是技術，是能讓 6 個工程師專心寫功能的環境。」
- 財務長：「不接受把機房成本平移到雲上，要看到實際節省。」
隱含限制：
- 日、韓擴張 → 隱含資料駐留與低延遲需求，單一 region 架構會有問題。
- PCI DSS → 信用卡資料不能隨便落到 BigQuery 做分析。
- 維運人力有限 → 架構偏向 managed service 會比較務實。
這份摘要就是後面 12 個步驟的地基，任何設計決策都要回頭對照這裡。
常見陷阱
- 把 case study 當技術規格書讀：忽略管理層陳述與業務動機，結果選了技術上最炫、但不符合商業節奏的方案。
- 假設題目沒講就可以不做：case study 不會列出 HIPAA、PCI DSS 的每一條，但你要自己從產業判斷。考試時選項會偷放「不符合規範」的陷阱答案。
- 過早聚焦在服務選型：第一步只要把情境、目標、限制整理清楚，先不要跳到「要用 Spanner 還是 Cloud SQL」。
延伸閱讀
- Google Cloud Architecture Framework — 官方整體設計原則，PCA 考題引用來源。
- Professional Cloud Architect 官方考試指南 — 考試範圍與 case study 列表。
- Google SRE Book — Embracing Risk — 如何從業務目標推導技術指標的經典章節。
- PCA case study 官方範本 — EHR Healthcare、Cymbal Retail 等。
下一步：有了情境與目標，下一篇我們就要開始把抽象的需求轉成可設計的使用者輪廓（User Personas），讓設計有具體對象。
🎯 換你練習
理論讀完，換自己來。到 架構師設計工作坊 · 步驟 1 填入你的 case study，邊寫邊內化。