在許多企業中，平台工程團隊（Platform Engineering Team）常扮演著「雲端警察」的角色。他們負責定義安全規範、成本控制與基礎設施標準，但最常遇到的問題是：當平台團隊試圖推動合規（Compliance，指資源配置必須符合公司預定義的安全、成本或管理標準）時，開發者往往將其視為阻礙進度的絆腳石。
本文將以 Sevdesk 公司重建平台團隊的實務經驗為例，探討如何從「強制執行」轉向「共情協作」，在確保基礎設施合規的同時，維持良好的開發者體驗。
平台工程的陷阱：過度工程與維運崩潰
許多平台團隊在起步時容易陷入「過度工程」的誤區。例如，為了避免雲端供應商鎖定（Vendor Lock-in），即便在 AWS 環境中，仍堅持部署大量第三方開源工具（如用 Keycloak 做權限管理、用 Harbor 做鏡像倉庫）。
這種做法雖然看似靈活，但會帶來巨大的維運成本。平台工程師將大量時間花在修補、更新這些第三方工具，而非開發能讓產品團隊直接受益的可重複使用組件。最終結果往往是團隊成員因過度疲勞而崩潰。
實務建議：優先利用雲端原生服務
要降低維運壓力，應優先考慮雲端原生（Cloud Native）服務。例如將自建的權限管理替換為 AWS IAM 與 SSO，將自建鏡像倉庫替換為 ECR。雖然這增加了對供應商的依賴，但能讓平台團隊將精力聚焦在「提升開發者效率」而非「維護基礎設施」。
建立基礎設施的隔離與治理
在推動合規前，必須先建立正確的帳戶結構。建議從單一帳戶遷移至多帳戶架構（Multi-account Setup），根據環境（開發、測試、生產）、團隊或職能（安全、備份、數據）來劃分帳戶。
這樣做有三個核心好處： 第一是安全隔離，單一帳戶被攻破不會影響全域。 第二是權限精細化，可以在 Sandbox 帳戶給予開發者高度自由，而在生產帳戶實施嚴格控制。 第三是成本分攤，能清晰地將雲端帳單歸屬到具體的團隊或專案。
從強制執行轉向最小可行治理
合規推動最忌諱的是「明天起不符合規範的部署全部報錯」。這種強硬作法會迅速破壞平台團隊與開發者的關係。
建議採用最小可行治理（Minimum Viable Governance）策略： 首先，定義真正關鍵的指標。不要一次要求 30 個標籤（Tags），而是專注於最核心的幾個，例如：擁有者（Owner）、服務名稱（Service）、關鍵程度（Criticality）。 其次，區分「通知」與「強制」。先讓開發者知道哪些資源不合規，給予修正時間，最後才實施強制攔截。
實作案例：自動化合規通知流程
以推動資源標籤化（Tagging）為例，單純寫在 Confluence 文檔中是沒有用的，因為開發者不會去讀，且容易打錯字。
為了降低摩擦，可以建立一套事件驅動（Event-driven）的自動化通知機制： 利用 AWS Config 監控資源變動，當偵測到新資源創建且缺少標籤時，觸發 EventBridge 啟動 Lambda 函數。 由於資源本身沒標籤，無法直接得知通知對象，此時 Lambda 可追溯 CI/CD 流水線（Pipeline）的 Git 儲存庫擁有者，找出對應的開發團隊。 將事件放入隊列（Queue）進行聚合，避免對同一批部署發送數十條重複訊息（避免 Spam），最後透過 Slack 通知開發者。
這種做法將「合規檢查」從枯燥的文檔變成了即時的反饋，讓開發者在部署當下就能意識到問題並修正。
平台工程師的心態轉型：從警察變為導師
要成功推動合規，技術手段只是其次，溝通模式才是關鍵。
定義優先級：不要試圖解決所有問題。面對數萬個安全漏洞或不合規項，應根據緊急程度、影響範圍與實作成本進行排序，優先處理「低成本、高影響」的項目。 共享目標：讓開發者理解合規不是為了管理而管理，而是為了公司的穩定與客戶的信任。 嵌入式支援：實施「巡迴專家（Embedded Expert）」制度，讓平台工程師暫時進入產品團隊，幫他們處理基礎設施的髒活，讓開發者感受到平台團隊是在提供幫助，而非單純下指令。
總結：合規是一場馬拉松
合規化是一個長期過程，不可能一夜之間完成。平台團隊應該追求的是建立一種正向的循環：通過小步快跑的迭代獲取快速勝利（Quick Wins），建立信任感，再逐步推動更深層的治理。
記住，最好的平台工程不是建立一套完美的系統，而是建立一套讓開發者願意使用且感到受支持的協作文化。
來源：infoq.com (Presentation by Davide de Paolis)
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。