EHR Healthcare
一句話描述（依官方原文）：一家把電子病歷軟體以 SaaS 提供給跨國診所、醫院與保險業者的公司，業務逐年指數成長，決定用 Google Cloud 取代現有的 colocation 設施；其中一個資料中心的租約即將到期，而與保險業者的舊整合目前沒有搬遷計畫。
📄 官方案例整理：背景與需求
本節只轉述 Google 官方案例原文，沒有加入站內推論。原文：EHR Healthcare Case Study（官方 PDF，英文），是現行標準考綱連到的版本。核對日期：2026-10-07。
公司概況（Company Overview）
EHR Healthcare 是醫療產業領先的電子病歷（electronic health record）軟體供應商，以 SaaS 形式把軟體提供給跨國（multi-national）的診所、醫院與保險業者。
解決方案構想（Solution Concept）
醫療與保險產業變化很快，EHR Healthcare 的業務逐年指數成長。它需要擴充環境、調整災難復原計畫（disaster recovery plan），並建立新的 continuous deployment 能力，才能快速更新軟體。公司已選定 Google Cloud 取代現有的 colocation 設施。
既有技術環境（Existing Technical Environment）
- 軟體目前放在多個 colocation 設施，其中一個資料中心的租約即將到期。
- 面向客戶的應用程式是 web-based，其中許多最近已經容器化，跑在一組 Kubernetes cluster 上。
- 資料存放在關聯式與 NoSQL 資料庫：MySQL、MS SQL Server、Redis、MongoDB。
- 與保險業者之間有數個舊的檔案式與 API 式整合，放在地端。這些系統預計未來幾年內汰換，目前沒有升級或搬遷的計畫。
- 使用者由 Microsoft Active Directory 管理。
- 監控用多種開源工具；告警用 email 寄送，而且經常被忽略。
業務需求（Business Requirements）
- 盡快讓新的保險業者上線（on-board）。
- 所有面向客戶的系統至少要有 99.9% 可用性。
- 對系統效能與使用狀況有集中的可視性，並能主動處理（proactive action）。
- 提高洞察醫療趨勢的能力。
- 降低所有客戶的延遲。
- 維持法規遵循（regulatory compliance）。
- 降低基礎設施管理成本。
- 根據業者資料（provider data）做預測，並產出產業趨勢報告。
技術需求（Technical Requirements）
- 保留與保險業者的舊介面，並能連到地端系統與雲端供應商（cloud providers）。
- 用一致的方式管理面向客戶的容器化應用程式。
- 在地端系統與 Google Cloud 之間提供安全、高效能的連線。
- 提供一致的 logging、log 保存（retention）、監控與告警能力。
- 維護並管理多個容器化環境。
- 能動態擴充並建立新環境。
- 建立介面，擷取並處理來自新業者的資料。
高層說法（Executive Statement）
高層表示，地端策略雖然運作多年，但團隊得花大量時間與金錢學習差異很大的系統、管理相似卻各自獨立的環境，並處理服務中斷。許多中斷來自系統設定錯誤、容量不足以應付流量高峰，以及監控做法不一致。他們希望用 Google Cloud 取得可擴充、有韌性的平台，能跨多個環境運作，提供一致而穩定的使用體驗。
🧭 站內原創分析（非官方內容）：讀題時先抓什麼
以下是登雲學院自己的讀法，不是 Google 的答案；官方案例只列需求，沒有指定架構。另外提醒：原文沒有點名 HIPAA、GDPR 或任何一部法規，沒有 RPO 或 RTO 數字，沒有要求零停機遷移，也沒有提到病歷保存年限、醫療影像或醫療資料格式；可用性的數字只有一個，就是面向客戶的系統至少 99.9%。
- 租約期限決定節奏一個資料中心的租約快到期，遷移要依相依性和期限分批。把時間押在全面改寫上，只是把時程風險藏起來。
- 保險業者的舊整合要共存原文明講目前沒有升級或搬遷的計畫。所以地端與雲端之間的連線不是過渡期的小註腳，而是架構的正式組成：連線、路由、DNS 和故障時的處理都要設計。
- 容器環境要一致管理已經有多個 Kubernetes cluster，需求是一致的管理方式，還要能動態建立新環境。重點在 cluster、設定、artifact、政策與觀測的一致，不是自己顧每一個 control plane。
- 99.9% 是唯一的可用性數字範圍是面向客戶的系統。設計時用它推導冗餘和容量，不要自己把數字調高，也不要假設零停機。
- 被忽略的 email 告警高層說很多中斷來自設定錯誤、容量不足和監控不一致。需求要集中的可視性與主動處理，所以告警要有負責人、要能行動，log 也要有保存規則。
- 合規只寫了一句原文只有 Maintain regulatory compliance。安全很重要，但題目如果問的是怎麼保住舊整合，答案還是要先解 hybrid 連線與分階段遷移。
🏗️ 站內延伸設計（非官方內容）：從官方需求推候選方向
左欄是官方需求，中間和右欄是登雲學院的推論。產品只是候選方向，實際要看題目給的限制。
| 官方需求 | 站內建議的候選方向 | 動手前要確認 |
|---|---|---|
| 取代 colocation、租約到期 | 用 Migration Center 建立資產清單，再補上相依關係，依風險與期限分批；容器化的應用先搬到 GKE | 哪些系統綁在快到期的機房、每一批的切換與 rollback 怎麼驗證 |
| 舊介面與 hybrid 連線 | 地端到 Google Cloud 用 Cloud Interconnect 或 HA VPN，建立備援路徑，並規劃路由與 DNS；原文還要求能連到 cloud providers，連往其他雲的路徑也要一起規劃 | 頻寬與延遲需求、專線的交期、單一路徑故障時怎麼辦、原文的 cloud providers 指哪些雲 |
| 一致管理多個容器環境 | GKE 搭配 fleet 管理；用 Terraform 這類 IaC 建立新環境，設定與政策集中同步 | 誰維護基準設定、環境之間的差異怎麼管 |
| 四種資料庫 | 依類型評估受管服務，例如 MySQL、SQL Server 對 Cloud SQL，Redis 對 Memorystore；用 Database Migration Service 這類工具壓低切換停機 | 版本相容性、MongoDB 的遷移路徑、資料量與切換順序 |
| Logging、監控、告警 | Cloud Logging 設定保存期限，Cloud Monitoring 依 SLO 告警並指定負責人 | 99.9% 的 SLI 怎麼定義、告警送給誰、log 要留多久 |
| Active Directory | 讓既有的 AD 身分能登入 Google Cloud；工作負載用 workload identity，不另建一套長效帳密 | AD 留在哪裡、同步範圍與群組對應 |
| 新業者介面、趨勢與預測 | 用 API 層（例如 Apigee）接新業者的資料，再進 BigQuery 做分析與預測 | 資料格式、資料分類與存取權限 |
| 降低所有客戶的延遲 | 先量測延遲來自哪裡，再決定部署區域與負載平衡方式 | 原文只說客戶是 multi-national 的診所、醫院與保險業者，沒有寫具體地區 |
| 法規遵循與 DR 計畫 | 資料分類、最小權限、稽核紀錄與保存規則；DR 先和業務訂出 RPO 與 RTO，再選備份還原或跨區域的做法 | 適用哪些法規、RPO 與 RTO 是多少，原文都沒有給 |
[資料中心租約期限]
│ 盤點相依性，依風險與期限分批
▼
[Landing zone] 身分、網路、政策、觀測先就緒
│
▼
[先搬可以搬的] 容器化應用、資料庫
│
│ ←── 備援的 hybrid 連線、路由、DNS ──→ [目前沒有搬遷計畫] 保險業者的檔案與 API 整合（地端）
▼
[逐批驗證後切換] 使用流程、合規證據、rollback 都通過才切
│
▼
[集中維運] 舊整合汰換後，hybrid 路徑才退場
這張圖是站內整理的遷移順序，不是官方指定架構。租約期限要求先分批搬，但保險業者的整合沒有搬遷計畫，所以混合連線要當成正式架構來設計。
🚧 站內延伸設計（非官方內容）：題目另外給條件才考慮
下面這些選項，官方案例沒有直接要求，但不代表它們一定是錯的。題目自己多給了條件，才把它們納入考慮。
如果題目點名 HIPAA 或其他具名法規
才把那部法規的要求帶進來，例如先查 Google Cloud 的 HIPAA 合規說明，確認用到的服務在涵蓋範圍內。官方案例只寫維持法規遵循，沒有點名任何一部法規。
如果題目說要防止資料被帶出指定範圍
才考慮 VPC Service Controls。它管的是受支援服務的存取邊界，IAM 管的是誰可以呼叫，兩者是不同層。原文沒有提出這項需求。
如果題目說加密金鑰要由客戶自己控管
才考慮 Cloud KMS 的 CMEK。CMEK 不能代替整體合規，資料分類、最小權限、稽核與保存規則仍然要做。
如果題目給了 RPO 或 RTO 數字
才依數字選 DR 等級（備份還原、warm standby、跨區域同時運作）。原文只說要調整 DR 計畫，沒有給數字，也沒有要求零停機遷移。
如果題目提到 FHIR、HL7 v2 或 DICOM 這類醫療資料格式
才考慮 Cloud Healthcare API。原文沒有提到任何醫療資料格式，也沒有提到醫療影像。
換你練習（站內練習，非官方題目）
到 PCA 架構師設計工作坊 把 EHR Healthcare 當情境。第一步「定義案例情境」只填官方原文有的事實，再做「定義 SLI 與 SLO」（從 99.9% 出發）、「繪製網路拓樸」（畫出地端舊整合與 Google Cloud 的連線）和「災難復原（DR）」（自己假設一組 RPO 與 RTO，並註明那是假設）。
前往工作坊🔗 延伸閱讀
- EHR Healthcare Case Study — Google 官方案例原文（PDF，英文），本頁事實的唯一來源
- Professional Cloud Architect 官方考試頁 — 考試形式、考綱與四個案例的入口
- 四份官方案例研究怎麼讀 — PCA 第 22 堂，四個案例的五格筆記與解題流程
- 遷移規劃與混合雲 — 把搬遷拆成可回退的批次
- 混合連線與多雲網路 — Interconnect 與 HA VPN 的選擇
- 高可用與災難復原架構設計 — 從可用性目標與 RPO、RTO 推導設計
- Google Cloud 的 HIPAA 合規說明 — 題目另外點名 HIPAA 時再讀；官方案例沒有點名