🧱 「不規劃就等於失敗」：企業雲端治理的五大支柱

Hi 不專業工程師是我！小弟不才，踏入資訊的世界也快十年了！這是這一兩年來使用雲端相關的心得，這是系列的第三篇～

Photo by Sebastian Spindler on Unsplash

沒有治理的雲，只是昂貴的資料中心。當團隊各自為政、帳號四散、權限失序，成本、風險與技術負債會同時失控。治理給的是框架與護欄，讓彈性與安全共存。

為何需要治理

• 團隊自定規範、重複佈建、影子 IT 滲透 • 成本難以歸屬與預算外溢 • 權限膨脹與審計缺口 • 事故回復慢、資安事件難追蹤

Cloud Adoption Framework (CAF)

CAF 不是某一套產品，而是從策略 → 採用 → 治理 → 營運的整體方法學。重點在建立共同語言與落地路線圖，讓技術、財務、法遵、資安與業務能對齊目標與責任。

雲端五大支柱解析

1) 成本效益（Cost Optimization）

目標：以可預期的花費換取業務價值。

做法

• 預算與警示：為訂閱/專案/事業單位設定 Budget + Alert。
• 承諾與折扣：善用 Reserved/Committed Use，低波動負載用 RI，高彈性負載用自動調整。
• Tag 與費用歸屬：強制 cost_center,owner,env 標籤，未標籤資源禁止建立。
• FinOps 作業：月結成本檢討、異常費用 RCA、降本待辦（Rightsizing/停用閒置/儲存層級調整）。
• 指標：每月雲成本成長率、未標籤資源比率、RI/節省方案覆蓋率、單筆交易成本（Cost per X）。

2) 卓越營運（Operational Excellence）

目標：可預測、可復原、可審計的日常變更。

做法

• IaC：Terraform/Bicep/CloudFormation 管控一切（網路、帳號、權限、監控）。
• 變更管理：PR 審核、靜態掃描、Plan 輸出簽核、Pipeline 落地。
• 標準化藍圖：建立 Golden Module（VNet/子網、AKS/EKS 叢集、Managed DB 範本）。
• SRE 實務：SLO/SLI、變更失敗率、事後檢討（Postmortem）。
• 指標：變更失敗率、平均回復時間（MTTR）、基礎建設覆蓋率（% 由 IaC 管理）。

3) 效能效率（Performance Efficiency）

目標：以最小資源達成所需效能並可彈性擴展。

做法

• 自動擴縮與負載平衡：HPA/ASG + LB/AGW，預熱與冷啟策略。
• 正確機型/儲存層級：I/O 需求與 CPU/記憶體對齊；快取前置（Redis/Cloud CDN）。
• 容量與壓測：定期壓測、容量計畫、峰值保護（隊列與熔斷）。
• 指標：P95 延遲、資源使用率、單位效能成本。

4) 可靠性（Reliability）

目標：在故障時維持服務並快速恢復。

做法

• 拓樸彈性：多 AZ/多區域、主從或多活、存儲複寫。
• 備份與演練：RPO/RTO 目標、備份保留與異地保存、年度 DR 演練。
• 故障預演：Chaos/故障注入、Runbook 與排班待命。
• 指標：SLA/SLO 達成率、演練通過率、資料遺失量（RPO 實績）。

5) 安全性（Security）

目標：以最小權限與多層防禦降低風險暴露。

做法

• 身分與存取：MFA、Just-in-Time/Just-Enough Access、權限到期（PIM）、服務對服務用受管身分。
• 網路安全：Hub-Spoke、Private Link/Endpoint、零信任原則、東西向微分段。
• 金鑰與祕密：KMS/HSM、客戶自管金鑰（CMK）、集中式 Secret 管理。
• 偵測與修補：CSPM/CWPP、弱點掃描、基線與合規檢查、日誌集中（SIEM）。
• 指標：高風險資產數、弱點修補週期、未加密資源比率、違規政策命中。

Landing Zone：雲端起跑點

預先設好安全與治理規範的底座，讓每個新專案從第一天就合規、可觀測、可控管。

標準組件

• 身分與階層：租戶/管理群組/訂閱結構、RBAC 與 PIM。
• 政策與護欄：強制標籤、限定區域、磁碟與儲存加密、公開 IP/Port 黑名單、資源命名規範。
• 網路基座：Hub-Spoke、對外閘道、DNS、私有端點、混合連線。
• 安全與合規：CSPM 預設基線、弱掃、祕密管理、金鑰管理、檔案型惡意偵測。
• 觀測與審計：集中 Log/Metric/Trace、雲原生日誌歸檔、SIEM/SOAR 介接。
• 成本與資產：Budget、Cost Tag、資產盤點與 CMDB 同步。
• 佈建入口：專案生命週期自動化（Service Catalog/Blueprint + IaC Pipeline）。

如果沒有預先思考這些事情的狀況下，可能會出現什麼呢？

• 先上車後補票：專案先跑，治理事後補，最終重工更大。
• 只做文件不做自動化：政策沒落在 Policy/IaC 即等於沒有。
• 過度集中權限：平台團隊成為瓶頸，導致影子 IT。
• 只盯安全不看成本/可靠：單點最優化，系統整體效能低落。

讓我們來比較一下 CAF 與 Landing Zone

關係與分工

1. CAF 定義原則與政策。
2. 政策轉為技術控制與標準。
3. Landing Zone 以 IaC 實作這些控制並成為專案起跑點。

例子

• CAF 原則：資料不得公網曝露。 • Landing Zone 實作：預設私有端點、禁止公開 IP Policy、SCP 鎖定區域、Security Group 標準範本。

何時用

• 需要決策與對齊時用 CAF。 • 需要快速且一致地佈建合規環境時用 Landing Zone。

CAF 決定做對什麼；Landing Zone 決定怎麼做並立刻可用。 用 CAF 對齊語言，用五大支柱定義成功標準，用 Landing Zone 把規範寫進程式。如此，雲才會帶來速度，而不是混亂。

治理不是上鎖，而是設定護欄。先規劃，再擴張。