四份官方案例研究怎麼讀

案例不是服務名稱配對題

Google Cloud 目前公布四份標準 PCA 案例：Altostrat Media、Cymbal Retail、EHR Healthcare 和 KnightMotives Automotive。官方考試頁說明，每場標準考試會使用其中兩份，案例題約占 20–30%，考試中可以用 split screen 查看案例。

案例的作用是補充情境。題目仍會另外指定一個目標，例如降低維運、滿足資料落地、改善發布可靠性或建立 AI workflow。答案必須同時符合：

1. 題目這次問的事情。
2. 案例已寫明的 business／technical requirement。
3. 現有環境、團隊、時程和不能立即搬動的系統。

因此，「EHR 就選最嚴格安全」、「Altostrat 就選 CDN」這種背法很危險。案例內通常有多條問題線，同一家公司可以考 networking、migration、observability、AI、security 或 cost。

先把原文整理成五格筆記

每份案例只記五類資訊：

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

先忠實抄案例，再寫自己的 architecture hypothesis。不要把「我覺得它應該用 Spanner」混進原文事實，否則考場上很容易用自己腦中的假案例答題。

Altostrat Media：既有雲端平台加上 hybrid 與 GenAI

官方案例明確寫了什麼

Altostrat 管理 podcast、訪談、新聞和紀錄片等大量影音內容。既有環境不是全地端：

• Content management／delivery platform 已使用 GKE。
• 多格式 media library 存放在 Cloud Storage。
• BigQuery 是主要 data warehouse。
• Cloud Run functions 處理 video transcoding、metadata extraction 和 recommendation 等 event-driven task。
• 部分 legacy system 仍在地端，負責 content ingestion、archival 等 workflow；近期（near future）會現代化並搬到 Google Cloud。
• 身分由 Google Identity 與 third-party identity provider 混合管理。
• Cloud Monitoring、Prometheus 等工具並存，告警主要寄 email。

它想加速跨 Google Cloud／on-premises 的 operation workflow 並提高可靠性、簡化 infrastructure management 以便快速部署 application、最佳化（optimize）storage cost 並維持 media content 的 high availability 與 scalability，同時建立 natural-language support、摘要、metadata extraction、harmful-content detection、內容分析與 personalized experience。Technical requirement 另外寫明：用 centralized management platform 現代化 containerized deployment 的 CI/CD，並在 on-premises 與 cloud 都提供 scalable、performant 的 Kubernetes environment。AI decision 還要可 audit、可解釋；可靠性與成本都是 executive statement 明確點出的優先事項。

可能考你的判斷

• Modernization：不是把已在 GKE、Cloud Storage、BigQuery 的部分重新設計一次，而是找出地端 legacy system（ingestion、archival 等 workflow）與多環境管理的缺口。
• Hybrid：大量 media ingest 需要安全且高效的連線、transfer strategy、retry 和 checksum，不能只回答「開 VPN」。
• Storage：先看 access pattern、retention、retrieval need 和 lifecycle，再選 class；archive 便宜不代表適合常取用內容。
• GenAI／multimodal：摘要、metadata、內容安全和對話支援是不同 task，應分別定義 model、grounding、evaluation、human review 與 fallback。
• Operations：告警主要靠 email 發送，這指向 ownership、SLO／symptom alert、on-call 和 centralized observability，而不是再加一套 dashboard。

Altostrat 不是單純的全球影音串流題。官方文字把 hybrid operation、container management、storage cost、AI governance 和 user engagement 放在同一個案例裡。

flowchart TB
  O["地端 legacy system<br/>ingestion、archival 等"] --> T["安全傳輸<br/>retry、resume、<br/>checksum"]
  T --> S["Cloud Storage<br/>依 access pattern 管理 lifecycle"]
  S --> E["Event-driven processing<br/>轉碼、metadata、分析"]
  E --> A["摘要、內容安全<br/>personalization 等 AI task"]
  A --> G{"品質、安全與<br/>可解釋性達標？"}
  G -->|"否"| H["Human review／<br/>fallback<br/>調整 evaluation"]
  H --> A
  G -->|"是"| P["受控發布<br/>保留 model／prompt／<br/>decision evidence"]
  K["可靠性、storage cost<br/>跨環境 operations"] -. "全程約束" .-> T
  K -. "全程約束" .-> S
  K -. "全程約束" .-> P

站內的 PCA 案例研究庫另有一頁 Altostrat Media 架構分析，是原創整理、不是官方解答；拿來對照你的五格筆記，原文事實仍以官方案例為準。

Cymbal Retail：Catalog enrichment、product discovery 與人工審核

官方案例明確寫了什麼

Cymbal 是正在大幅成長的 online retailer，產品橫跨多個 retail sub-vertical，catalog 管理一直是難題（a constant challenge）。現況包含：

• On-premises 與 cloud 系統並存。
• MySQL、Microsoft SQL Server、Redis、MongoDB 等多種 data store。
• Kubernetes 上的 containerized application。
• SFTP、ETL batch 等 legacy integration。
• 自建 web application 讓 customer 瀏覽 catalog，做法是用 product 的名稱與分類查 relational database。
• IVR 先接電話再轉給對應部門或 agent；customer 無法自行完成 transaction 時，call-center agent 要手動輸入訂單。
• 用 Grafana、Nagios、Elastic 等多種 open source 工具做 monitoring。

目標分成三組：以 GenAI 從 supplier 的標題、描述和圖片推導 product attributes，產生／調整 product images；讓使用者以自然語言尋找商品並進行 conversational commerce；同時現代化 stack、integration、monitoring 和 security。Business requirement 還點名降成本：call center staffing cost 與 data-center hosting cost。

案例的 technical requirement 列了 Human-in-the-Loop（HITL）Review：提供 UI 讓 associate 審核與管理 AI-generated content，在更新 product catalog 之前可以 approve、reject 或 modify。這是寫明的需求，不是可有可無的加分項。

可能考你的判斷

• Catalog pipeline：Supplier input 需要 validation、normalization、category schema、duplicate handling 和 lineage。生成內容要先落在 review state，不直接覆寫 production catalog。
• Model output：用 structured schema 約束 attributes，仍要做 factual／image quality、brand policy 和 safety evaluation。Structured output 不保證內容正確。
• Product discovery：區分 traditional keyword search、semantic retrieval、conversation orchestration 和 transaction backend。Agent 可以協助找商品，不應自行繞過 order authorization。
• Human review：Review queue、version、approval audit、rejection reason 與 rollback 都是 workflow 的一部分。
• Customer data：Conversation history、profile 和 order data 有不同 retention／access purpose；先分類，再決定 grounding 和 personalization 能用哪些資料。
• Modernization：舊 SFTP／batch 不會因導入 agent 自動消失。要設 adapter、data contract、dead-letter／reconciliation 和 phased retirement。

原案例沒有「三個國家的實體門市、Oracle 或全球庫存必須用 Spanner」等設定。遇到題目沒提供的資訊，不要靠網路模擬題補故事。

flowchart TB
  S["Supplier text／image"] --> V["Validation、normalization<br/>category schema、lineage"]
  V --> M["Model 產生 structured suggestion<br/>記錄 model／prompt version"]
  M --> R["Review store／queue"]
  R --> D{"Associate 決定"}
  D -->|"Edit"| E["修改後<br/>重新驗證"]
  E --> D
  D -->|"Reject"| X["保留<br/>rejection reason<br/>不更新 catalog"]
  D -->|"Approve"| P["受控 workflow<br/>發布<br/>production catalog"]
  P --> A["Approval audit、<br/>版本<br/>品質監控<br/>與 rollback"]

站內對照頁：Cymbal Retail 架構分析（原創整理，非官方解答）。

EHR Healthcare：在期限內遷移，同時保留 legacy provider integration

官方案例明確寫了什麼

EHR 把電子病歷軟體以 SaaS 提供給 multi-national 的 medical office、hospital 與 insurance provider。它要以 Google Cloud 取代 colocation，其中一個 data center lease 即將到期；solution concept 還寫明要 scale environment、調整 disaster recovery plan，並推出新的 continuous deployment 能力。Customer-facing application 是 web-based，其中許多最近已 containerize（many have recently been containerized），跑在一組 Kubernetes clusters；資料存放在 relational 與 NoSQL database（MySQL、MS SQL Server、Redis、MongoDB）。

Business requirement 包括：

• 盡快 onboard 新 insurance provider。
• Customer-facing system 至少 99.9% availability。
• Centralized visibility 與 proactive action。
• 降低 customer latency 與 infrastructure administration cost。
• 維持 regulatory compliance。
• 從 provider data 產生 healthcare trend insight、prediction 和 report。

最重要的限制是：數個放在 on-premises 的 legacy file／API-based insurance provider integration 預計在未來幾年內（over the next several years）汰換，目前沒有升級或搬移計畫。User 由 Microsoft Active Directory 管理；monitoring 用多種 open source 工具，alert 用 email 寄送而且常被忽略。Technical requirement 還要求能 dynamically scale and provision new environments。

可能考你的判斷

• Migration deadline：先處理 lease expiry、dependency 與 wave；不能用全面 refactor 把時程風險藏起來。
• Legacy coexistence：保留 provider interface，建立 cloud 與 on-prem 的 secure high-performance connectivity、routing、DNS 和 failure plan。
• Container consistency：評估 GKE 的 cluster／fleet、configuration、artifact、policy 和 observability 管理，不必因為已有 Kubernetes 就自行管所有 control plane。
• Identity：規劃 AD federation／workforce access 與 workload identity，避免搬到 cloud 後再建立一套長效帳密。
• Observability：從 ignored email 轉成有 owner 的 actionable alert、central log retention、service dashboard 和 escalation。
• Healthcare data：Compliance 不能只用 CMEK 代替；仍要 data classification、least privilege、audit evidence、retention、residency 與 incident process。

EHR 的安全要求重要，但若題目問如何維持舊 provider integration，答案仍要先解 hybrid connectivity 和 phased migration。

flowchart TB
  A["Data center<br/>lease deadline"] --> B["盤點 dependency<br/>依風險與期限分 wave"]
  B --> C["建立 cloud landing zone<br/>identity、network、<br/>policy、observability"]
  C --> D["遷移可搬的 container<br/>與 data workload"]
  L["目前沒有搬遷計畫的<br/>provider<br/>file／API integration"] --> H["Redundant hybrid<br/>connectivity<br/>routing、DNS、<br/>failure plan"]
  H --> D
  D --> V{"Journey、<br/>compliance evidence<br/>與 rollback 驗證通過？"}
  V -->|"否"| R["保留舊路徑<br/>修正後再切換"]
  R --> D
  V -->|"是"| P["逐 wave 切換<br/>centralized operations"]
  P --> F["Legacy replacement<br/>核准後<br/>再退場 hybrid path"]

站內對照頁：EHR Healthcare 架構分析（原創整理，非官方解答）。

KnightMotives Automotive：全公司轉型，不只是車聯網 ingestion

官方案例明確寫了什麼

KnightMotives 製造自動駕駛 BEV、hybrid 和 ICE 車，想在五年內（within five years）翻新所有車款的 consumer experience。BEV 已有較新的 in-vehicle experience，其他車系落後；online build-to-order system 也不可靠，dealer 拿不到需要的資料。Dealer 沒有預算添購設備，service technician 與 sales staff 都需要更好的工具。

既有 IT 以 on-premises 為主（largely on-premises），另有部分 application 在 major cloud platforms 上。Supply chain mainframe、ERP 老舊，車系間 codebase 分裂且有 backward-compatibility debt；連到 manufacturing plant 的 network connectivity 與 rural area 的 vehicle connectivity 都是難題。

Business target 包括：跨車系一致體驗、AI feature、自動駕駛投資（initial implementation 先鎖定 regulatory environment 較有利的地區）、改善 build-to-order／dealer tool、data monetization、EU data protection、過往 breach 後的 security improvement，以及員工 upskilling／跨團隊溝通。Technical requirement 另外要求改善 plant 與 headquarters 之間的連線，並導入完整的 CRM（Customer Relationship Management）system。

可能考你的判斷

• Hybrid modernization：Mainframe、ERP 等 legacy system 要依 dependency 分階段 replace／modernize，不用一次大爆炸重寫。
• Intermittent connectivity：車輛在 rural area 不能假設永遠在線。Edge decision、local buffer、retry、sync conflict 和 safe degraded mode 要明確。
• AI safety：In-vehicle convenience、personalization 與 autonomous driving 的風險不同。後者需要 simulation、model／data governance、regulatory evidence、fallback 和 safety case。
• Data monetization：先處理 consent、purpose limitation、de-identification、data product access 和 audit，再談分享或 marketplace。
• Dealer tooling：既然 dealer 沒有新設備預算，browser-based、centrally managed 的選項可能比要求部署專用硬體合理，但仍需看題目要求。
• Security：過去 breach 意味著要補 identity、network、data、supply chain、detection 和 incident response 的整體 control，不是只買一個 security product。
• People：Upskilling 是案例寫明的 business requirement。導入團隊完全不會操作的平台卻沒有 training／operating model，答案就不完整。

KnightMotives 確實可能涉及 vehicle telemetry、edge 和 AI，但官方案例更廣：legacy enterprise system、dealer experience、security、privacy、talent 和 financial priority 都可能成為題目的主約束。

flowchart TB
  V["Vehicle／edge"] --> C{"Connectivity 可用？"}
  C -->|"否"| L["Local safe decision<br/>buffer event、<br/>限制依賴雲端的功能"]
  L --> C
  C -->|"是"| S["依序或可重放地同步<br/>retry、dedup、<br/>conflict handling"]
  S --> G["Central platform<br/>telemetry、dealer／service workflow"]
  G --> P{"Consent、purpose、<br/>region 與 access policy<br/>允許？"}
  P -->|"否"| X["限制使用／保留<br/>privacy evidence"]
  P -->|"是"| D["Analytics、<br/>產品改善<br/>或受控<br/>data product"]
  SAFE["Safety-critical<br/>decision<br/>simulation、<br/>fallback、<br/>regulatory evidence"] -. "獨立風險邊界" .-> L

站內對照頁：KnightMotives Automotive 架構分析（原創整理，非官方解答）。

四份案例的快速索引

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

案例題的實際解法

讀題後做這四步：

1. 圈出 action：design、migrate、reduce cost、secure、diagnose，還是 choose first step。
2. 把題目中的 must、minimize、existing、no plan、regulatory 等字眼列成約束。
3. 回案例確認相關事實，只取這題用得到的段落。
4. 比較選項是否滿足約束、增加未要求的操作負擔，或假設了案例沒說的能力。

如果兩個答案技術上都可行，問哪一個更直接處理 business outcome、尊重既有環境，而且能用可量測方式驗證。Managed service 常能降低 operation work，但不是無條件勝出；protocol、control、latency、team skill 或 legacy compatibility 都可能讓另一個選項更合理。

flowchart TB
  Q["先讀 question 與 options"] --> A["圈出 action<br/>design／migrate／secure／diagnose"]
  A --> C["列 hard constraints<br/>must、existing、deadline、RTO／RPO"]
  C --> E["回案例只找<br/>這一題需要的 evidence"]
  E --> F["逐項排除：違反約束、<br/>偷帶假設、不必要負擔"]
  F --> D{"仍有兩個可行答案？"}
  D -->|"是"| T["比較 business outcome、<br/>operation model<br/>與可驗證性"]
  D -->|"否"| S["選擇直接滿足 action 的答案"]
  T --> S
  S --> V["確認 success measure<br/>能證明改善"]

課後檢查

往下看重點之前，先試著回答這幾題；答不出來，括號裡是該回去重讀的那一節。

• 為什麼案例原文的事實和你自己的 architecture hypothesis 要分開記？（回〈先把原文整理成五格筆記〉）
• 不看表，說得出四份案例各自最容易漏掉的限制嗎？（回〈四份案例的快速索引〉）
• 兩個選項技術上都可行時，用什麼分出高下？（回〈案例題的實際解法〉）

本課重點

• 標準 PCA 每場使用兩份案例，案例題約占 20–30%；以官方頁面與考試指南為準。
• 原文事實和自己的 architecture hypothesis 要分開記。
• Altostrat 是既有 GCP media platform、hybrid workflow、GenAI 與 operation modernization 的組合。
• Cymbal 的 catalog enrichment 有明確 human-in-the-loop 要求，並包含 legacy integration／call center 現況。
• EHR 必須在 data-center lease 壓力下遷移，但 legacy provider integration 目前沒有升級或搬移計畫。
• KnightMotives 是 automotive experience 與 enterprise modernization，不應縮成單一 IoT pipeline。
• 不用案例名稱猜答案；每題仍要重新確認 action、constraint 和 success measure。

官方案例

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

下一步

下一課會用一個刻意保留衝突與未知數的案例做 architecture workshop，練習把「看起來都合理」的選項拆成可以驗證的決策。