治理與變更管理簡介
對於 Professional Cloud Architect 來說，治理 (Governance) 是確保雲端環境在增長的同時保持安全、合規且具成本效益的「規則集」。變更管理 (Change Management) 則是更新這些規則並部署新基礎設施而不導致停機的「流程」。
在雲端中，治理是透過程式碼和自動化政策來執行的，而不僅僅是 PDF 文件和手動審核。有效的治理在 敏捷性 (Agility)（快速行動的能力）與 控制 (Control)（最小化風險的能力）之間取得平衡。
白話文解釋（Plain English Explanation）
類比 1 — 醫院手術同意書（Change Advisory Board）
醫院絕不會讓外科醫師憑一句「相信我」就動刀。任何手術前都要簽署 手術同意書、登錄處置紀錄，高風險案例還要另一位主治醫師會簽。在 GCP 的世界裡，這就是 Change Advisory Board (CAB) 加上 Pull Request：terraform plan 的輸出是「X 光片」，同儕審查是「會簽的第二位醫師」，merge commit 就是簽好字的同意書。萬一出事，Cloud Audit Logs 會清楚記錄誰在何時批准了什麼。
類比 2 — 民航局起降許可（Change Windows）
任何客機都不能隨機長自己心情想起飛就起飛。民航局塔台 會指定起飛時段、天氣窗口與跑道許可。生產環境部署也是同一邏輯：你定義 change windows（例如週二到週四的 10:00–16:00、絕不在週五下午），在購物旺季凍結變更，部署 Cloud Deploy rollout 前要先取得 on-call 的「塔台許可」。Org Policy 限制條件（例如 constraints/compute.requireOsLogin）執行的就是「沒有應答器的飛機不准起飛」這類強制規範。
類比 3 — 銀行金庫雙人鑰匙（Separation of Duties）
銀行金庫要求 兩位不同的人各持一把不同的鑰匙 — 經理一個人開不了，行員一個人也開不了。在 GCP 裡，這對應 IAM 的 separation of duties：寫 Terraform 程式碼的人（在 sandbox 上有 roles/editor）不能同時是擁有正式環境 roles/owner 的人。IAM Deny policies 加上 Access Approval 確保即使管理員帳號被駭，也無法擅自讀取客戶資料 — Google SRE 必須會簽存取請求。兩把鑰匙、兩個人、一個金庫。
治理的支柱：資源階層 (Resource Hierarchy)
GCP 資源階層是治理的基礎。它允許政策和權限的繼承。
- 組織 (Organization)： 根節點（例如
company.com）。對於集中帳單和組織政策 (Org Policies) 至關重要。 - 資料夾 (Folders)： 用於按部門（如「財務」）、環境（如「生產」）或業務單位對專案進行分組。資料夾最多可嵌套 10 層。
- 專案 (Projects)： 啟用服務、管理 API 和計費的基本單位。資源「必須」屬於一個專案。
- 資源 (Resources)： 實際的 VM、Buckets 和資料庫。
架構師見解： 政策繼承是累加的。如果用戶在資料夾級別被授予 Storage Admin，則他們對該資料夾內的所有專案都擁有該權限。拒絕政策（透過 IAM Deny 或 Org Policies）通常會覆蓋允許政策。
::
治理的淺顯類比
類比 1 — 樹與果實 (資源階層)
將你的 GCP 環境想像成一棵 樹。組織 是樹幹。資料夾 是樹枝。專案 是小枝，而 資源（VM、資料）是果實。如果你在樹幹上噴灑「農藥」（組織政策），它會流向每個樹枝、小枝和果實。你不需要單獨為每個果實噴藥。這就是 繼承。
類比 2 — 標準化藍圖 (組織政策)
治理就像 城市建築法規。法規規定「所有建築必須安裝消防灑水系統」且「建築高度不得超過 5 層」。組織政策 (Organization Policies) 就是這些建築法規。它們防止專案所有者（建築商）做出危險行為，例如將資料庫向整個公共網際網路開放，即使他們在技術上有權限這樣做。
類比 3 — 圖書館的借閱系統 (變更管理)
傳統的變更管理是一群人排隊等候 圖書管理員（變更諮詢委員會，CAB）蓋章。雲端變更管理 則像是一個 帶有自動掃描儀的自助服務機。你掃描你的書（你的程式碼），如果它是「安全的」且你已獲得「授權」，門會自動開啟。如果你試圖拿走一本禁書，掃描儀會發出鳴響並立即阻止你。
類比 4 — 山路上的護欄
治理不應該是阻止交通的磚牆；它應該是蜿蜒山路上的 護欄。護欄讓駕駛員（開發人員）能夠充滿信心地高速駕駛，因為他們知道即使犯了一個小錯誤，也不會掉下懸崖。
進階治理：標籤與條件政策
GCP 標籤 (Tags)（不同於 Labels）是強大的治理工具。標籤在組織或專案級別管理，可用於條件性地應用政策。
- 條件式 IAM： 僅當資源具有標籤
env: dev時才授予 "Instance Admin"。 - 條件式組織政策： 僅對標籤為
compliance: pci的專案禁用外部 IP。 - VPC Service Controls： 使用標籤來定義哪些資源可以跨邊界通訊。
Change Advisory Board (CAB)： 在雲端原生的脈絡下，CAB 已經不再是每週開會、逐條批准 gcloud 指令的會議。它是負責批准 自動化規則 的治理機構 — 包括 Org Policy 限制條件、GitHub 上必要的同儕審查人數，以及 Cloud Build 流水線裡的 terraform plan 把關 — 這些規則由 CI/CD pipeline 在每次 commit 上自動執行。
網路治理：Shared VPC
網路資源的治理對於安全至關重要。
- 主機專案 (Host Project)： 包含 VPC、子網路和 Cloud NAT。由「網路管理員」管理。
- 服務專案 (Service Projects)： 包含應用程式資源（VM、GKE）。由「專案管理員」管理。
- 好處： 集中控制 IP 空間、防火牆和混合連線，同時允許開發人員管理自己的運算資源。
FinOps 與成本治理
治理不僅關乎安全，也關乎金錢。
- 標籤 (Labels)： 使用標籤（鍵值對）進行成本分配（例如
cost-center: marketing）。 - 預算與警示： 在帳單帳戶或專案級別設定，當支出達到閾值的 50%、90% 或 100% 時通知利益相關者。
- 配額 (Quotas)： 透過限制專案可以建立的高昂資源（如 TPU 或 A100 GPU）數量來防止「成本失控」。
Audit log 保留期是合規的把關線，不是預設值。 Cloud Audit Logs 的 Admin Activity logs 預設免費保留 400 天，但 Data Access logs 預設只保留 30 天，而且對大多數服務 預設是關閉的。處理 SOX / HIPAA / PCI DSS 工作負載時，你 必須 透過 Org Policy 明確啟用 Data Access logs，並透過 sink 路由到 保留 7 年並上鎖的 Cloud Logging bucket，或匯入到啟用 Bucket Lock 的 Cloud Storage bucket 以達到不可竄改性。
讓 terraform plan 成為契約，而不是 terraform apply。 在 Cloud Build 流水線裡，對 PR branch 跑 terraform plan -out=tfplan，並把 diff 貼回 GitHub PR 的留言區。審查者批准的是 plan 輸出，而不只是原始碼 — 這能抓出 drift、出乎意料的 -/+ destroy and re-create，以及程式碼閱讀者漏掉的 IAM 授權。然後 terraform apply tfplan 只在 merge 後執行，套用的就是審查時看過的那份 plan。
變更管理：轉向 GitOps
在現代雲端環境中，基礎設施即程式碼 (IaC) 和 GitOps 是變更管理的主要驅動力。
- 版本控制 (Git)： 每項變更都是一個「提取請求」(PR)。
- 同儕審核 (Peer Review)： 另一位架構師必須審核程式碼，確保架構一致性。
- 自動化測試 (Linting/Validation)： 像
terraform plan和checkov這樣的工具在應用變更前進行驗證。 - 藍綠部署或金絲雀部署： 應用程式的變更管理，以最小化用戶影響。
- 回滾 (Rollback)： 能夠「還原」提交以恢復到上一個已知的良好狀態。
Rollback runbook 必須在部署 之前 就存在，而不是事故發生 之後 才寫。 每次正式環境變更都應該附帶：(a) 用來撤回的精確 git revert <sha> 或 terraform apply 指令、(b) 最大可接受的 rollback 時間窗口（例如「30 分鐘內必須 revert，否則 schema migration 將不可逆」）、(c) Cloud Deploy 的 rollback target 或重新打標籤的 GAR image。對於資料變更，要在變更 前 先做 bq snapshot 或 Spanner backup — 一旦新 schema 上線，光靠「git revert」是救不回資料的。
Change windows 不能取代 canary 部署。 PCA 考題裡常見的錯誤答案是「把所有正式環境變更排在週日凌晨 02:00 的時段」。在 GCP 上，正確答案幾乎都是 透過 Cloud Deploy / GKE / Cloud Run revision 流量切分做漸進式發布 — 1% → 10% → 50% → 100%，並在 SLO burn 時自動 rollback。週日時段只限制了 blast-radius 的時間點；canary 才限制 blast-radius 的範圍大小。兩者都要用，但絕不能只靠時段。
架構師準則： 絕不要在生產環境的 Google Cloud Console 中進行手動更改。這被稱為「Click-Ops」，它會導致 組態偏移 (Configuration Drift)，這是治理的大忌。應使用 Terraform 或 Config Connector 來管理狀態。 ::
合規即程式碼 (Compliance as Code)
保持持續合規，而不是定期審核。
- Config Connector： 使用 Kubernetes CRD 管理 GCP 資源，允許
kubectl強制執行狀態。 - Forseti Security (開源)： 在整個 GCP 腳印中進行清點、掃描和執行政策。
- GCP Security Command Center (SCC)： 即時監控錯誤配置和漏洞。
常見問題 — 變更管理與治理
Q1. 什麼是「組態偏移 (Configuration Drift)」？
當雲端資源的實際狀態與 Terraform 程式碼中定義的狀態不再匹配時，就會發生偏移。這通常是因為有人在控制台中進行了手動「緊急」更改，卻忘記更新程式碼。偏移檢測工具對於維持治理至關重要。
Q2. 我該如何處理「緊急變更」？
即使在緊急情況下，也請盡可能使用 IaC。如果「必須」使用控制台，請立即記錄更改並使用 terraform plan 識別偏移。危機結束後，立即更新程式碼以匹配手動更改（或反之亦然）。
Q3. 專案所有者 (Project Owner) 可以覆蓋組織政策嗎？
不可以。 組織政策是在階層中的較高層級設定的，具有較低層級權限的人無法覆蓋。這提供了「不可變的護欄」，即使專案級別的帳戶被破解，也能確保安全。
Q4. DevOps 世界中的「變更諮詢委員會 (CAB)」是什麼？
CAB 從「門神」（審核每張工單）演變為「治理機構」（審核 流程 和 自動化）。他們定義 CI/CD 流水線自動執行的規則。
Q5. 我該如何治理「雲端擴張 (Cloud Sprawl)」？
使用 配額 (Quotas) 來限制專案建立。實施「專案請求」工作流，開發人員在透過自動化配置專案之前，必須提供成本中心和停用日期。
Q6. Labels 與 Tags 的區別？
Labels 是用於篩選和計費的元數據（例如 team: web）。Tags 是強類型的資源，可用於 IAM 和組織政策條件中以執行安全（例如 environment: prod）。
最後的架構師建議
在 PCA 考試中，尋找有關「標準化」或「跨多個專案強制執行約束」的問題。答案幾乎總是 組織政策 (Organization Policies)。如果問題是關於「安全地管理多個環境」，答案則涉及 IaC (Terraform) 和 CI/CD。始終針對 繼承 進行設計——在盡可能高的層級設定政策，以減少管理開銷並確保組織中不存在「政策漏洞」。
PCA 治理記憶口訣： (1) Org Policies = 護欄（禁外部 IP、禁 public bucket、要求 OS Login）；(2) IAM = 基於身分的存取控制；(3) Tags = 條件式政策的定錨點；(4) Labels = 僅用於計費與篩選；(5) Audit Logs = 誰在何時做了什麼（Admin Activity 免費保留 400 天、Data Access 需手動開啟）；(6) Cloud Deploy + Binary Authorization = 經簽章的漸進式發布；(7) Bucket Lock + Retention Policy = 不可竄改的稽核軌跡。題目出現「prevent」或「enforce」就想 Org Policy；題目出現「investigate」或「prove」就想 Cloud Audit Logs 加 BigQuery sink。