PCA 雲端架構師之旅 01 — 讀懂案例情境

PCA（Professional Cloud Architect）最特別的地方，不是考你記不記得 GCP 有幾百個服務，而是丟一份十頁的 case study 給你，要你在兩小時內生出一套說得通的架構。

很多人第一題就翻車。不是因為不懂 GCP，是沒讀懂題目。這篇是整個系列的第一步，也是最容易被跳過、卻最不該跳過的一步：把案例情境真正吃透。

這是 13 步驟 PCA 雲端架構師之旅 的開場。

---

讀題這件事，比你想的值錢

Google 官方那幾份 case study——目前是 EHR Healthcare、Cymbal Retail、Altostrat Media、KnightMotives Automotive（早期的 TerramEarth、Mountkirk Games 已經退役）——長得都差不多：公司背景、現況、業務需求、技術需求，最後再加一段管理層的話。

重點來了：case study 那幾題的分數不低，而且很多看起來跟案例無關的題目，答案其實藏在敘述裡。你以為在考一個獨立的技術觀念，實際上題目早在前面那句「我們最在意 time-to-market」裡就給了你方向。讀題讀得淺，等於把這些分數白白送掉。

我自己帶過幾個上雲的案子，最深的體會是：最貴的錯，通常不是技術選錯，是需求沒讀懂。技術選錯頂多重來一次；需求讀錯，是整個方向都錯，做得越快、賠得越多。考試只是把這件事濃縮成兩小時，本質一模一樣。

---

讀題的時候，新人都怎麼踩雷

我看過最常見的三種：

• 跳過敘事段落，直接看需求清單。 管理層那段話常常藏著「我們最在意上線速度」這種關鍵，跳過就整個方向選錯。
• 把所有需求都當成一樣重要。 一份 case study 塞二十個需求很正常，但真正是主線的可能只有五個，剩下的是來干擾你的。
• 忽略產業特性。 醫療業的 HIPAA、金融業的 PCI DSS、遊戲業的低延遲——這些題目不一定明寫，卻會直接幹掉一半的服務選項。

第三點最陰。case study 不會好心地把 HIPAA 每一條列給你，它預設你看到「醫療」「病歷」就該自己想到。然後選項裡再偷放一個「技術上很漂亮但其實違規」的答案，等你跳進去。

📝 考場提點

第一輪先花 8–10 分鐘，把公司背景、三個主要痛點、硬性限制（合規、預算、上線時間）抄在草稿紙上。後面每一題都回頭對照這張小抄，不要每題重讀整份文件——時間絕對不夠。看到產業關鍵字（醫療、金流、跨國）就先在心裡標一個「這裡有合規紅線」。

---

讀懂一份 case study，其實就是問清楚幾件事

說穿了，就是把這幾件事問清楚：這家公司靠什麼賺錢、現在卡在哪、老闆到底要什麼、有哪些紅線不能踩、誰會在你的設計上挑毛病。

講具體一點：

• 業務情境——這家公司做什麼生意、現在的痛點是什麼。如果你連一句話都介紹不出來，代表還沒讀懂。
• 技術現況——在地端還是雲上、用什麼資料庫、有沒有甩不掉的 legacy 系統。
• 業務目標——管理層期望多久內看到什麼結果。要的是 time-to-market 還是省成本，方向天差地遠。
• 技術需求——效能、可用性、合規、預算這些硬性限制。
• 利害關係人——CEO、CTO、開發、維運各自在意什麼，而且他們的目標常常彼此打架。

順手補兩個後面會一直用到的名詞：SLO（Service Level Objective）是你給自己訂的服務水準目標，例如 99.9% 可用性；RTO / RPO（Recovery Time / Point Objective）是災難復原時你能容忍多久才復原、最多丟多少資料。

---

拿到題目，照著這幾個問題問自己

1. 用一句話介紹這家公司給新同事，你講得出來嗎？ 講不出來就是還沒讀懂，別急著往下。
2. 這家公司現在最痛的三件事是什麼？ 架構要優先解決這三件，其他都是配角。
3. 管理層跟工程團隊的目標有沒有打架？ CEO 要六個月上線、CTO 想好好重構，這種衝突就是你在架構裡要做取捨的地方。
4. 有哪些法規會直接否決掉某些服務？ 資料駐留、加密、稽核要求，常常一刀砍掉 multi-region 自動複製這類選項。
5. 哪些是「一定要」，哪些是「有更好」？ 考場上先把必須項顧好，加分項等預算有餘再加。

這套問題不是考試專用，真實提案前我也是這樣盤一遍。差別只在考場上你沒有客戶可以追問，所有答案都得自己從那十頁裡挖出來。

---

走一遍範例 — 登雲書店

後面 12 步都會回來用這個例子，先把它讀熟。

公司背景： 登雲書店是一家經營 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：「我不管你們用什麼技術，但上雲十二個月內要完成，而且不能讓 Day 1 的顧客感覺到任何差別。」
• CTO：「我們缺的不是技術，是一個能讓六個工程師專心寫功能的環境。」
• 財務長：「不接受把機房成本原封不動搬到雲上，我要看到真的省下來。」

光是這幾段，就能讀出題目沒明講、但你必須自己補上的限制：

• 要打日韓 → 背後是資料駐留跟低延遲，單一 region 的架構會出問題。
• PCI DSS → 信用卡資料不能隨便丟進 BigQuery 做分析。
• 維運人力就這麼點 → 架構往 managed service 靠會務實很多，不然沒人顧。

這份摘要就是後面所有設計的地基。每做一個決定，都回頭對一次：這真的有解到他們的痛點嗎？還是只是我覺得很酷？

📝 考場提點

「題目沒講」不等於「你可以不做」。case study 不會把 HIPAA、PCI DSS 每條規定攤開給你，但你得從產業自己判斷。反過來也一樣危險——沒有任何線索就腦補一堆需求，把架構做得又貴又複雜，這在考場上同樣是會被扣分的過度設計。

---

一個提醒：先別急著選服務

讀題階段最大的誘惑，就是看到「流量暴增」馬上想「那用 Spanner」、看到「批次」就想「丟 Dataflow」。先忍住。

第一步只有一個任務：把情境、目標、限制整理乾淨。服務選型是後面的事，現在就跳過去，你會發現自己是在用零碎的需求硬拼架構，拼到一半又得打掉重來。實務上這叫「需求還沒收斂就開工」，是最浪費時間的做法，考場上也一樣——還沒讀完題就開始消去選項，通常死得很快。

---

延伸閱讀

• Google Cloud Architecture Framework — 官方整體設計原則，PCA 考題的引用來源。
• Professional Cloud Architect 官方考試指南 — 考試範圍與 case study 清單。
• Google SRE Book — Embracing Risk — 怎麼從業務目標推導技術指標的經典章節。

---

下一步：情境跟目標到手了，下一篇我們把抽象的需求變成具體的使用者輪廓（User Personas），讓設計有對象可以對著做。

🎯 換你練習

理論讀完，換自己來。到 架構師設計工作坊 · 步驟 1 填入你的 case study，邊寫邊內化。