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

PCA（Professional Cloud Architect）的案例題會先給你公司背景與需求，再要你做架構選擇。服務名稱記得再多，如果讀漏業務目標或限制，答案還是可能偏掉。

這篇是系列的第一步：先把案例裡的事實、限制和待確認假設分開，讓後面的選型有共同依據。

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

先讀出案例的優先順序

Google 官方那幾份 case study——目前是 EHR Healthcare、Cymbal Retail、Altostrat Media、KnightMotives Automotive（舊版清單中的 Helicopter Racing League、Mountkirk Games、TerramEarth 已隨 2025 年 10 月 30 日的英文標準考試改版退役）——長得都差不多：公司背景、現況、業務需求、技術需求，最後再加一段管理層的話。

讀題時要留意管理層的優先順序。例如「我們最在意上線速度」，就會影響你怎麼看待大規模重構和受管服務。這類線索往往散在背景文字裡，不只出現在條列的技術需求中。

真實專案也一樣：如果把「盡快上線」讀成「先重做所有系統」，團隊可能花了很多時間，卻離業務目標更遠。先讀懂需求，才能判斷哪種技術取捨有意義。

讀題時容易漏掉什麼？

先檢查這三件事：

• 有沒有讀敘事段落？ 管理層可能在這裡交代上線時間或預算優先順序。
• 有沒有分出硬性限制？ 不必把每項需求都當成相同權重，先圈出不能妥協的條件。
• 有沒有確認產業要求？ 醫療、金流或低延遲服務各有不同限制；先看題目實際給了哪些條件。

產業背景值得留意，但不能代替題目給出的要求。看到醫療、金流或跨國業務，先記下可能涉及的資料類型與駐留限制，再回頭查案例是否真的指定了法規、地區或稽核條件。

📝 考場提點

第一輪讀案例時，可以把公司背景、主要痛點和硬性限制（例如預算、上線時間、指定地區）整理成幾行筆記。作答時再對照原文確認，不要把「醫療」或「金流」自動當成某套固定架構的指令。

flowchart TB
  S[讀到一句案例敘述] --> E{題目有明確寫出？}
  E -- 是 --> F[記為事實或硬限制]
  E -- 否 --> I{能由產業規範合理推導？}
  I -- 是 --> A[標成必要假設<br/>保留依據]
  I -- 否 --> X[不要自行腦補]
  F --> C[放入需求摘要]
  A --> C
  X --> C
  C --> V[作答時回查原文]

把案例拆成五類資訊

讀完案例後，試著整理成五類資訊。若其中一類找不到明確答案，就先標成待確認的問題，不必急著替題目補設定。

• 業務情境：公司提供什麼服務，哪段流程目前最不順？
• 技術現況：系統在地端還是雲上？有哪些資料庫、相依服務與暫時不能替換的元件？
• 業務目標：希望在什麼時間內改善什麼指標？上線速度和成本若衝突，哪個優先？
• 技術限制：效能、可用性、資料位置、預算或期限，有哪些是不能妥協的條件？
• 利害關係人：管理層、開發、維運與使用者各自需要什麼？需求衝突時由誰決定？

後面會用到兩組指標：SLO（Service Level Objective）描述服務要達到的水準，例如可用性目標；RTO／RPO（Recovery Time／Point Objective）則分別描述故障後多久要恢復、最多能接受遺失多久的資料。

用五個問題核對需求摘要

1. 這家公司做什麼，眼前要解決哪個問題？ 先用一兩句話說清楚，不必急著列產品。
2. 哪些限制已經確定？ 例如預算、期限、資料位置與現有系統相依性；沒寫出的條件不要自行補上。
3. 哪些目標可能互相牽制？ 上線速度、重構範圍與維運成本若衝突，要先確認優先順序。
4. 有哪些成功指標？ 把延遲、可用性、RTO／RPO 等要求和量測方式對起來。
5. 哪些是必要條件，哪些只是偏好？ 先排除不符合硬限制的方案，再比較其餘取捨。

flowchart TB
  R[需求線索] --> H{違反會直接淘汰方案？}
  H -- 是 --> P0[P0 硬限制<br/>法規、駐留、期限]
  H -- 否 --> M{能量化成功與否？}
  M -- 是 --> P1[P1 成功指標<br/>SLO、RTO、<br/>RPO、成本]
  M -- 否 --> P2[P2 偏好<br/>熟悉度、便利性]
  P0 --> C[先篩掉不合格方案]
  P1 --> C
  P2 --> T[只用來處理平手]
  C --> T

這套問題在實際提案時也用得上；差別是考場上沒辦法追問客戶，只能從題目提供的資料找線索，並標出仍缺少哪些條件。

走一遍範例 — 登雲書店

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

公司背景： 登雲書店是一家經營 8 年的線上書店，台灣市占約 12%，有 80 萬會員、每月 45 萬筆訂單。系統現在跑在自家機房（台北內湖、桃園中壢各一座），用自建的 LAMP 架構配 MySQL 主從複製。

現在的痛點：

• 雙 11、春節書展流量暴衝 10 倍，每次都因為 DB 撐不住當機 2–4 小時。
• 新功能上線平均要 6 週，因為測試環境只有一套，QA 一直在排隊。
• 維運團隊 6 個人，其中 3 個全職在處理機房硬體，根本沒空改善程式品質。

未來 18 個月的業務目標：

• 進軍日本、韓國，目標合計再多 20 萬會員。
• 推電子書訂閱制，預期帶來 30% 新營收。
• 每月維運加機房折舊成本砍 35%。

技術需求：

• 尖峰時段首頁 P95 回應時間 < 1.5 秒。
• 訂單與金流資料 99.99% 可用性。
• 符合個資法與 PCI DSS 4.0.1。
• 未來 3 年不要再砸錢買機房硬體。

管理層怎麼說：

• CEO：「我不管你們用什麼技術，但上雲十二個月內要完成，而且不能讓 Day 1 的顧客感覺到任何差別。」
• CTO：「我們缺的不是技術，是一個能讓六個工程師專心寫功能的環境。」
• 財務長：「不接受把機房成本原封不動搬到雲上，我要看到真的省下來。」

這幾段也帶出一些需要確認的問題，別把它們直接當成題目已給的硬限制：

• 要服務日韓使用者 → 先量測跨區延遲，再確認資料是否有當地存放要求；不能只憑市場位置就斷定一定要多區域部署。
• 提到 PCI DSS → 先畫出持卡人資料流與適用範圍。分析資料若要進 BigQuery，也得確認去識別化、權限與稽核設計。
• 維運人力有限 → 受管服務值得優先比較，但仍要核對功能限制、費用與團隊的操作能力。

flowchart LR
  CEO[CEO<br/>12 個月完成且無感遷移] --> D[分階段遷移<br/>降低 Day 1 風險]
  CTO[CTO<br/>讓 6 人團隊專注功能] --> M[優先採 managed services]
  CFO[財務長<br/>成本必須真的下降] --> C[建立成本基線與關閉舊機房]
  D --> G[共同設計原則]
  M --> G
  C --> G
  G --> V[每個服務選擇都回查<br/>期限、維運與成本]

這份摘要會在後面反覆用到。每選一個服務，都回來確認：它解決了案例裡的哪個問題？又增加了什麼成本或維運工作？

📝 考場提點

題目沒有列出每項控制措施時，可以從資料類型與地區找出需要確認的法遵問題；但不能只因為看到「醫療」或「金流」，就自行指定某套固定產品組合。把題目明講的限制和仍待查證的假設分開寫，後面的設計才不會跑偏。

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

看到「流量暴增」就想到 Spanner，或看到「批次」就想到 Dataflow，都太早了。先問流量是哪一段增加、資料怎麼用、目前系統卡在哪裡。

第一輪先把情境、目標和限制整理好。等知道哪些是硬性要求、哪些只是希望改善的痛點，再比較服務會快得多；否則很容易拿著零碎線索拼出一張需要重畫的架構圖。

flowchart TB
  E[引用題目線索] --> R[翻譯成架構要求]
  R --> O[列出可行候選]
  O --> C[用硬限制、SLO、成本<br/>與維運能力比較]
  C --> D[選擇並說明取捨]
  D --> V{是否回應原始痛點？}
  V -- 否 --> R
  V -- 是 --> A[形成答案]

延伸閱讀

• Google Cloud Well-Architected Framework — 官方整體設計原則；考試指南把熟悉此框架列為這個角色的關鍵要求。
• Professional Cloud Architect 官方考試指南 — 考試範圍與 case study 清單。
• Google SRE Book — Embracing Risk — 怎麼從業務目標推導技術指標的經典章節。

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

🎯 換你練習

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