先分清楚漂移、預期變更與工具雜訊
基礎設施漂移是指雲端資源的實際狀態與 IaC 宣告或狀態檔不一致。常見原因包括工程師為了排障直接修改安全群組、平台服務自動調整屬性、另一套部署工具管理相同資源，以及供應商新增或改變預設值。並非每一筆差異都是事故，但未分類的差異會讓下一次部署難以預測：看似無關的版本更新，可能同時撤銷緊急修正、重建資源或改變權限。
我們通常把差異分成四類：未授權漂移應還原或調查；緊急操作應補回程式碼與變更紀錄；外部管理欄位應明確劃分責任；非實質雜訊則應以固定版本、正規化或精準的忽略規則處理。不要一看到差異就加入 ignore_changes。廣泛忽略整個資源雖能讓計畫變乾淨，卻也可能遮蔽真正的網路、加密或存取權限變更。
把漂移偵測做成可重複的唯讀管線
漂移偵測應由固定環境執行，而不是依賴某位工程師的筆電。Terraform 可在鎖定供應商版本與模組版本後執行 refresh-only plan 或一般 plan；CloudFormation 等平台工具則可搭配原生漂移檢查。不論採用哪種方式，偵測身分都應盡量唯讀，遠端狀態需有加密、版本保留與鎖定機制，工作目錄也必須使用與正式部署相同的版本設定。
排程頻率要依風險調整。身分權限、對外網路規則、金鑰與正式資料庫通常需要較短的偵測週期；低風險開發環境可降低頻率以控制 API 呼叫、執行時間與警報量。每次結果至少應保存執行時間、提交版本、工作區、工具版本與差異摘要，並將完整計畫視為可能含有敏感資料的受控產物。
- 先建立基準：確認目前狀態可由既有程式碼重現，並清理長期未解的差異。
- 降低雜訊：固定工具與 provider 版本，只忽略已確認由平台管理的特定屬性。
- 依風險通知：權限擴張、公網暴露、刪除與強制重建應立即升級；標籤或描述差異可進入一般待辦。
- 避免偵測時變更：排程工作只產生報告，不自動 apply，除非是邊界明確且經充分驗證的修復。
讓變更審核聚焦於影響，而不只是語法
IaC 拉取請求應同時提供程式碼差異與由目標環境產生的計畫。審核者首先確認計畫是否對應最新提交、正確帳號與工作區，再檢查新增、原地修改、刪除及強制替換的資源。只看 HCL、YAML 或模組輸入不足以判斷實際影響，因為供應商行為、模組內部邏輯與既有狀態都會改變最終結果。
高價值的審核問題包括：是否擴大 IAM 權限或網路來源範圍？資料庫、磁碟或訊息佇列是否可能被重建？變更順序會不會造成停機？是否需要資料備份、分階段部署或回復步驟？共用模組升級影響哪些環境？自動政策檢查適合攔截明確規則，例如禁止未加密儲存或任意來源的管理埠，但它無法取代對服務依賴、資料生命週期與業務時窗的人工判斷。
為緊急變更與漂移修復保留明確出口
完全禁止主控台操作往往不切實際，尤其在服務中斷或權限鎖死時。較穩健的做法是建立 break-glass 流程：使用具時效性的高權限、記錄操作者與原因、限制可修改範圍，並要求事件結束後立即建立追蹤項目。下一步不是盲目執行 apply，而是判斷應以程式碼採納現況、匯入既有資源，或將環境還原到宣告狀態。
修復策略取決於哪一側才是正確來源。若手動調整已證明必要，就先更新 IaC，再確認計畫只保留預期差異；若變更未經授權且回復安全，才由受控部署還原。對可能刪除資料或重建關鍵資源的差異，應先停止自動化、確認備份與相依服務，再安排維護窗口。成熟的流程不是追求永遠零漂移，而是讓每一筆差異都能被發現、解釋、審核並安全收斂；跨雲端與企業系統整合時，也應由平台與應用團隊共同定義這些責任邊界。