流程定位

IaC 的風險集中在共享狀態與不可逆資源。應用部署失敗常可回退 artifact；基礎設施變更可能刪除資料、替換節點、改掉 IAM 權限或讓 state 與真實環境分叉。發布流程應讓 reviewer 在 apply 前看到「將要改什麼」，並讓 apply 後能確認「環境是否真的符合宣告」。

Plan 階段負責產生可審查差異。Plan 是 reviewer 判斷資源替換、權限擴大、資料刪除與網路暴露的主要材料。CI 應保留 plan artifact，讓 apply 使用同一份輸入與版本。

Review 階段負責把風險放到正確 owner。平台、資安、資料庫或服務 owner 應依資源類型參與審核；高風險變更需要額外 gate，例如 maintenance window、人工 approval 或雙人審核。

Apply 階段負責把宣告狀態寫入環境。State Lock、credential、workspace 與環境變數都要固定；partial apply 或 timeout 後，要先判斷 state 與真實資源是否一致，再決定下一步。

Verify 階段負責確認平台可用。Apply 成功只代表 provider API 接受變更；仍需要 connectivity test、policy check、service smoke test、DNS / certificate check 或 cluster health，確認服務真的能跑。

Infrastructure Drift 階段負責發現宣告與現況分叉。手動 hotfix、雲端 console 調整、外部 controller 或 provider 預設值都可能造成 drift；drift detection 要定期執行，並把修復責任導回宣告檔。

Recovery 階段負責處理失敗套用。IaC 回復不一定是 git revert 後 apply；可能需要 import、state mv、taint / untaint、手動修復資料資源或 forward fix。流程要先保護資料與服務，再修正宣告與 state。

Plan review 判讀

Plan review 的責任是讓變更影響在 apply 前被看見。Reviewer 應依資源語意判斷，讓 diff 行數退居輔助訊號。

這張表讓 review 從「有人按 approve」變成風險判讀。IaC review 的價值在於提前看見不可逆或高代價變更。

Drift 處理路由

Drift 處理的責任是把現況重新帶回可管理狀態。Drift 發現後不應直接 apply 覆蓋，因為 drift 可能是事故 hotfix、外部系統自動調整或宣告檔過期。

1. 確認 drift 來源：人工 hotfix、provider 預設、外部 controller 或宣告過期。
2. 判斷 drift 是否仍需要保留：若是真實修復，應回寫到 IaC。
3. 判斷 apply 是否會破壞服務：特別看 replacement、destroy、權限與 network。
4. 修正宣告或 state：必要時使用 import、state mv 或 provider-specific repair。
5. 重新 plan，確認差異收斂到預期。

這個路由讓 drift 修復具備審查性。直接在 console 裡補到看起來正常，會讓下一次 CI apply 把修復覆蓋掉。

常見反模式

反模式的共同問題是把 IaC 降成指令自動化，忽略它承擔的狀態治理責任。

下一步路由

• IaC 部署總覽：回 IaC / Platform 部署 CI/CD。
• 環境保護：讀 Environment Protection。
• Gate 原理：讀 CI gate 與 workflow 邊界。

Console 唯讀鐵律：把 Console 當儀表板，不當方向盤

Console 唯讀鐵律是一條操作紀律：雲端 Console 只用來觀察與排查，所有會改變資源的動作都回到程式碼走 apply。這條紀律維護的是 state 與現實的一致 — IaC 工具能正確運作的前提，是它的 state 反映得了真實世界，而每一次在 Console 點按鈕改設定，都是在 state 不知情的情況下動了現實。

drift 的延遲浮現

state 與現實的分歧叫 drift。drift 的後果在後續某次 apply 時才浮現——工具用過時的 state 比對雲端現況、把手動設定判定為「不該存在」並覆蓋掉，手動改的當下一切正常。手動改的當下一切正常，後果要等到下一次不相關的 apply 才出現。

常見的 drift 路徑：在 Console 手動加了一條 security group 規則（例如讓外部監控系統連進來），state 不知道這條規則存在。後續某次 apply 時，工具比對 state 和雲端現況、把這條規則判定為「不在記憶裡」而刪除。同樣的機制也發生在手動調整的 RDS parameter group（例如增加 max_connections）— 後續 apply 會把參數重設回程式碼裡的值。

Console 改得越多、與程式碼分歧越久，某次例行 apply 就越可能掃掉一批沒人記得的手動設定。drift 的累積是單調遞增的 — 每一次手動改動都加一筆，沒有任何自然機制會讓它減少。

drift 偵測

主動偵測 drift 的方式是定期跑 terraform plan 而不做 apply — plan 的輸出會列出「code 描述的狀態」與「雲端現況」之間的差異。如果 plan 在沒有 code 變更的情況下顯示非零差異，代表有人在背後動了資源。

1# 定期 drift 偵測：plan 結果非零就告警
2terraform plan -detailed-exitcode
3# exit code 0 = 無差異, 1 = 錯誤, 2 = 有差異

把這個 plan 接進 CI，讓 drift 在累積之前就被發現。判讀 plan 輸出時，重點看那些「會被 Terraform 改回去」的差異 — 它們就是手動變更的痕跡。

import 的痛苦

鐵律越早立越好，因為回頭納管的代價隨時間累積。手動建的資源要納入 IaC，得先用 terraform import 把現實資源綁進 state，再補一段與現實完全吻合的 HCL：

1terraform import aws_security_group.web sg-0abc123def456

import 只把資源 ID 寫進 state，不會幫忙生程式碼。那個資源在 Console 上被點出來的每一個屬性 — 每條 ingress 規則、每個 tag、每項關聯設定 — 都得一字不差地補成 HCL。任何一項對不上，下次 apply 就會試圖把現實改回程式碼寫的版本 — 對 security group 來說可能是把一條正在用的規則刪掉，對 RDS 來說可能是觸發一次重啟。

Terraform 1.5 之後提供了 import 區塊，可以在 HCL 裡宣告式地寫 import，配合 terraform plan -generate-config-out=generated.tf 自動生成對應的資源描述。這比手寫減少了大量逆向工程，但生成的 code 仍然需要人工確認每一個屬性是否正確 — 自動生成是起點，不是終點。

1import {
2  to = aws_security_group.web
3  id = "sg-0abc123def456"
4}

import 成本隨資源數量非線性增長。一個資源的逆向工程可控，幾十個各自手動微調過的資源累積起來，團隊會停止嘗試納管，環境分裂成 IaC 管理的部分和手動管理的部分。第一天就立鐵律，要納管的存量永遠是零。

鐵律靠權限落地，不靠自律

光靠約定「別在 Console 改」撐不久，救火當下手最快的永遠是 Console。真正讓鐵律站得住的，是把人的日常身分收斂成唯讀、把寫入權限留給跑 apply 的自動化身分，讓「在 Console 改不動」變成預設狀態。

這道權限地基屬於模組二：身分與憑證地基的範圍，本階先確立紀律方向：人類日常用的 IAM 身分只有 ReadOnlyAccess，寫入權限只存在於 CI pipeline 使用的 role，這個 role 靠 OIDC 取得短期憑證（不存長期 key）。具體的 IAM 設計和 OIDC 信任關係在模組二展開。

最小可行：能 apply 出一個完整環境的最小資源集合

最小可行 IaC 的目標是用最少的資源，跑出一條「改程式碼 → review → apply → 環境真的變了」的完整迴路。它承擔的責任是驗證地基本身能動，把所有服務都搬上來是後面的事。判準是這套程式碼能獨立 apply 出一個雖小但自洽、別人能重現的環境。

最小集合的組成

把一個微小資源（例如一個 S3 bucket 或一台最小的測試 EC2）刻意留在最小集合裡，是因為它是最便宜的端到端驗證。apply 跑完後它確實出現、terraform destroy 後它確實消失，就證明從程式碼到雲端的整條鏈路是通的。

1resource "aws_s3_bucket" "smoke_test" {
2  bucket = "acme-smoke-test-${var.env}"
3
4  tags = {
5    purpose = "validate-iac-pipeline"
6    env     = var.env
7    owner   = "platform"
8  }
9}

刻意不放進來的東西

正式的應用服務、資料庫、跨環境的複製、複雜的模組抽象，全部留到地基驗證通過之後。在 state 與 Console 唯讀都還沒站穩前就堆服務，等於把房子蓋在還沒灌漿的地基上。

常見的過早引入包括：在最小集合裡就加 RDS（state 操作出問題時資料庫可能被影響）、在還沒有環境分離前就建多層 module 嵌套（驗證地基的複雜度不應該來自抽象層）、在一個人開發時就配好 Atlantis 或 Terraform Cloud 的完整 PR 流程（固定成本太高、且需要模組七的完整護欄才能發揮價值）。

網路骨架怎麼長、身分怎麼切，分別由模組三：網路地基與模組二：身分與憑證地基接手深入；這一階只需要它們各自最薄的一層，湊出一個能 apply、能 destroy、能交接的閉環。

驗證閉環

最小集合就位後的驗證步驟：

1. terraform init — 確認 backend 設定正確、provider 能下載
2. terraform plan — 確認 plan 輸出符合預期、沒有意外的 destroy 或 replace
3. terraform apply — 確認資源在雲端確實出現
4. terraform plan（再跑一次）— 確認輸出是零差異，代表 state 與現實一致
5. terraform destroy — 確認資源能被乾淨拆除（smoke test 資源）

第四步「再跑一次 plan」是容易被跳過卻最關鍵的一步。如果第一次 apply 之後立刻 plan 就出現差異，代表 provider 的行為和 HCL 描述之間有落差（例如某些屬性是雲端自動設的、HCL 沒寫），這類落差要在最小集合階段就修掉，等到正式服務上線後再修，成本會高很多。

最小可行 IaC 跑通後，下一步是收斂身分與憑證——把 Console 唯讀鐵律從紀律升級成權限限制，見模組二：身分與憑證地基。

跨分類引用

• → IaC 工具選型與 state 地基：state 怎麼管、backend 怎麼選
• → 模組二：身分與憑證地基：Console 唯讀鐵律靠權限落地，人類唯讀、自動化身分持有寫入權
• → 模組三：網路地基：最小集合裡的 VPC 與 subnet 怎麼設計
• → 模組七：infra 走 PR 流程：state 變更與 apply 怎麼納入 review

Drift 的代價會延遲浮現。手動改的當下看起來沒問題——設定改了、服務正常。問題出在後續某次不相關的 apply：工具用過時的 state 去比對，把手動改的設定覆蓋掉，服務因此斷線，而且在 PR 裡看不到這件事發生過。Drift 累積越多，每次 apply 的不確定性越高，最終團隊會開始害怕跑 apply，IaC 名存實亡。

概念位置

Drift 是 Console 唯讀鐵律存在的根本理由。模組一：Console 唯讀鐵律用權限機制（人類身分唯讀、寫入權限留給自動化身分）讓「在 Console 改不動」成為預設狀態，從源頭消除 drift 的產生。

可觀察訊號

Drift 存在的訊號：terraform plan 在沒人改過程式碼的情況下顯示變更（代表有人在 Console 動了東西）、團隊開始說「跑 plan 前先看看有沒有奇怪的差異」、某次例行 apply 意外改掉了不該改的設定。

偵測 drift 的主動方式是定期跑 terraform plan 但不 apply，把 diff 輸出當成 drift 偵測的報告。Terraform Cloud 有內建的 drift detection 功能，定期比對 state 與雲端現實。

設計責任

處理 drift 時要決定：

• 偵測頻率：每次 PR 觸發 plan（被動偵測）vs 定期排程 plan（主動偵測）
• 修正方向：把雲端改回程式碼的版本（apply），還是把程式碼改成雲端的版本（更新 HCL）——取捨在「程式碼是 source of truth」vs「手動改的設定有它的理由」
• 預防機制：Console 唯讀權限、CI gate 攔截未經 review 的 apply

鄰卡

• State — drift 是 state 與現實的落差
• IaC — drift 破壞 IaC 的 source of truth 地位

本篇的操作流程從盤點差距開始，經過 state 健康檢查、drift 收斂、文件重建，到最後排出收斂的優先序。每一步都在不影響線上服務的前提下進行。

state 與現實的差距盤點

盤點的第一步是跑 terraform plan 但不 apply — plan 的輸出就是程式碼描述的狀態與雲端現實之間的完整差距清單。

1terraform plan -no-color > plan-baseline-$(date +%Y%m%d).txt

把這份輸出存進 repo，它是接手時的基線快照。之後每一次收斂動作的效果都用「跟這份基線比少了幾項 diff」來衡量。

三類 diff 的判讀

plan 輸出的每一項 diff 歸屬三類，各自的風險等級與處理方式不同：

「要刪」是最危險的一類。常見成因是：前人在 Console 手動刪了某個資源但沒同步從程式碼移除（state 裡還有紀錄），或者前人在程式碼裡移除了某段 HCL 但沒跑 apply（雲端資源還在、state 記得它）。兩種情況都需要先確認該資源在雲端是否存在、是否仍被服務依賴，再決定是從 state 移除（terraform state rm）還是補回 HCL。

另一個需要留意的標記是 -/+（forces replacement）— 它代表 Terraform 判定這個屬性的變更無法原地更新，必須先刪除再重建。對 stateful 資源（RDS、EBS volume）來說這等於資料遺失，在接手階段看到這個標記要先暫停、查清楚是哪個屬性觸發了 replacement。

哪些資源在 state 裡、哪些不在

terraform state list 列出所有被 IaC 管理的資源。配合 terraform show -json 可以取得更結構化的 managed resource 摘要：

1# state 裡有什麼（清單）
2terraform state list > managed-resources.txt
3
4# state 裡有什麼（結構化摘要：type + name + provider）
5terraform show -json | jq '.values.root_module.resources[] | {type, name, provider}' > managed-summary.json

但 state 只是一份已知的清單 — 雲端上可能還有大量不在這份清單裡的資源。用 CLI 列舉雲端資源跟 state 做比對：

1
2# 雲端上有什麼（以 EC2 + RDS + SG 為例）
3aws ec2 describe-instances --query 'Reservations[].Instances[].InstanceId' --output text > cloud-ec2.txt
4aws rds describe-db-instances --query 'DBInstances[].DBInstanceIdentifier' --output text > cloud-rds.txt
5aws ec2 describe-security-groups --query 'SecurityGroups[].GroupId' --output text > cloud-sg.txt

用這兩份清單做比對，分成三類：

未管理的資源需要逐一判斷：這個資源是前人刻意排除在 IaC 外的（例如一個還在實驗的測試機），還是應該納管但漏了？判斷依據是它的角色 — security group、IAM role、VPC 這類地基資源應該優先 import；一台跑完就該關的測試 EC2 可以暫時留在手動。

手動比對 state list 與 CLI 輸出的效率有限，driftctl（現由 Snyk 維護、開源）可以自動掃描雲端資源與 Terraform state 的差異，一次列出所有 unmanaged resource。它跟 terraform plan 的差別在於 plan 只看已管理資源的 drift，driftctl 同時涵蓋根本不在 state 裡的資源。兩者互補：先用 driftctl 產出完整的 unmanaged 清單，再用 plan 處理已管理資源的 drift。

state 的健康檢查

state 本身的存放方式決定了後續所有操作的安全性。接手後第一件事是確認 state 的健康狀態。

存放位置

1# 查看 backend 設定
2grep -A 10 'backend' *.tf

如果 backend 是 local（或沒有 backend 設定），state 檔只存在某台機器的磁碟上。這代表如果有第二個人從自己的機器跑 apply，兩人會用不同版本的 state 互相覆蓋。把 state 搬到 remote backend（S3 + DynamoDB lock）是接手後的第一優先事項，做法見IaC 工具選型與 state 地基。

加密與版本控制

如果 state 已經在 S3，確認三件事：

1# bucket 有沒有 versioning
2aws s3api get-bucket-versioning --bucket <state-bucket>
3
4# bucket 有沒有加密
5aws s3api get-bucket-encryption --bucket <state-bucket>
6
7# 有沒有 lock table
8aws dynamodb describe-table --table-name <lock-table> 2>/dev/null

versioning 沒開的話，一次壞掉的 apply 寫壞 state 就回不去了。加密沒開的話，state 裡的敏感值（資料庫密碼、private key 輸出）以明文存在 S3。

state 裡的敏感值

state 檔經常包含不該暴露的值。確認 state 有沒有在 Git 歷史裡：

1git log --all --diff-filter=A -- '*.tfstate' '*.tfstate.backup'

如果命中，代表 state 曾經被推進 repo。此時 Git 歷史裡的敏感值已經無法徹底清除（git filter-branch 或 git filter-repo 可以嘗試，但無法保證所有 clone 都更新）。務實的處理是：列出 state 裡的敏感值，全部輪替。

1# 用 jq 從 state JSON 撈敏感值候選
2terraform show -json | jq -r '
3  [.. | objects | to_entries[] |
4   select(.key | test("password|secret|key|token"; "i"))] |
5  unique_by(.key) | .[] | "\(.key): \(.value)"
6' 2>/dev/null

這個 jq 查詢會遞迴掃描 state JSON 裡所有欄位名稱含 password / secret / key / token 的值。命中的每一筆都要確認是否為真實密鑰、是否需要輪替。

drift 收斂策略

盤點完差距、確認 state 健康之後，逐項收斂 drift。對 plan 輸出的每一項 diff 做一個二選一的決定：採納手動變更（改 HCL 去符合現實），或回退到程式碼版本（讓下一次 apply 把現實改回來）。

採納 vs 回退的判斷

多數 drift 應該採納。前人在 Console 手動改設定通常有一個操作理由（即使沒有記錄下來）— 加了一條 security group 規則可能是為了讓某個新服務連進來，改了 RDS 的 max_connections 可能是為了解決連線數不足。在沒有充分理解這些改動的背景之前，回退它們等於撤銷一個可能正在支撐服務運作的設定。

回退適用的情境是：drift 明顯是誤操作（例如 0.0.0.0/0 打開了不該打開的埠）、或 drift 的屬性是有標準答案的（例如 S3 的 block_public_access 被關掉了）。

操作步驟

1# 1. 刷新 state 到最新雲端狀態（不改資源、只更新 state 的快照）
2terraform apply -refresh-only
3
4# 2. 再跑一次 plan — 刷新後 diff 會減少（純 state 過期的 diff 消失）
5terraform plan -no-color > plan-after-refresh.txt
6
7# 3. 對剩餘的 diff 逐項處理
8#    採納：改 HCL 讓程式碼跟現實一致 → plan 確認該項 diff 消失
9#    回退：不改 HCL、讓 apply 把現實改回程式碼版本 → 先確認影響

-refresh-only 是安全的操作 — 它只更新 state 裡的屬性快照，不會改動任何雲端資源。但它會把手動變更「記進」state，讓後續 plan 的 diff 只剩程式碼與 state 的差異（而非程式碼與雲端的差異）。刷新後 plan 的 diff 更精確、更少、更容易逐項處理。

import 未管理的資源

對未管理的資源，用 import 區塊一次處理一個，每次 import 後都跑 plan 確認零新增 diff：

1import {
2  to = aws_security_group.legacy_app
3  id = "sg-0abc123def456"
4}

1# 生成對應的 HCL
2terraform plan -generate-config-out=generated_legacy_app.tf
3
4# 確認生成的 HCL 跟現實一致
5terraform plan
6# 預期：只有 import 動作、沒有 change/destroy

生成的 HCL 需要人工確認 — 有些屬性是雲端自動設的預設值，Terraform 會把它們全部列出來，造成 HCL 冗長。移除純預設值的屬性、只保留有意義的設定，讓 HCL 反映設計意圖而非雲端預設。

對於大量未管理資源需要一次性反推 HCL 的情境，Former2 可以從現有 AWS 資源批量生成 Terraform code。它掃描帳號裡的資源、產出對應的 HCL，品質不完美（命名會用資源 ID 而非有意義的名稱、屬性可能包含大量預設值），但作為起點比從零手寫每個資源快得多。產出後仍需逐檔清理命名與移除預設值。

文件重建

接手的環境通常沒有文件、或者文件已經過時到比沒有更糟（記載的是兩個版本前的架構）。文件重建的目標是讓下一個接手者不需要重複同樣的盤點過程，而非追求一份完美的架構文件。

來源

能重建的資訊來源有限，但每個都有價值：

terraform-docs 用一條指令就能從現有 HCL 產出每個 module 的 inputs、outputs 和 resources 清單，省去手動整理 module 介面的時間。Inframap 從 state 或 HCL 產出依賴關係圖，比 terraform graph | dot 好用的地方在於它自動過濾掉 provider 和 data source 的噪音，大型 state 也能產出可讀的圖。

最小可行文件

寫一份 INFRA-STATE.md 放在 repo 根目錄，包含：

• 管理範圍：哪些資源由 IaC 管理、哪些是手動的、為什麼手動的沒有 import（例：還在實驗、不穩定、計畫廢棄）
• 已知 drift：目前 plan 輸出裡還有哪些未處理的 diff、每個 diff 的處理方向（採納/回退/待調查）
• state 存放位置：backend 設定、bucket 名稱、lock table 名稱
• credential 狀態：有幾把 access key、哪些還在用、上次輪替時間
• 接手日期與盤點結果：盤點時的資源數量、覆蓋率（managed / total）

這份文件不需要精美，需要的是準確且持續更新。每次收斂一項 drift 或 import 一個資源，就更新對應的段落。前任團隊的知識已經不在了，這份文件取代它成為環境的記憶。

收斂到完整 IaC 的優先序

把整個收斂過程排成四個階段，每個階段都能獨立交付價值：

每個階段的驗證方式相同：terraform plan 的輸出是否比上一階段乾淨。階段一完成後，plan 的可信度才成立；階段二和三是把 plan 的 diff 清到零；階段四是擴大 plan 的管轄範圍。

每一步操作之前都先備份 state：

1# 手動備份 state（不論 bucket 有沒有 versioning 都先拉一份）
2terraform state pull > state-backup-$(date +%Y%m%d).json

state 操作失敗時的回退路徑是 terraform state push state-backup.json 從備份還原 — 資源本身不受影響，只是工具對現實的記憶回到上一個正確的版本。state push 是覆寫操作，只在確認備份版本正確時使用。

需要搬移資源在 state 裡的位址時（例如重構 module 結構），優先用 moved {} 區塊而非 terraform state mv。moved 是宣告式的、寫在 HCL 裡、可以被 PR review、plan 時會顯示搬移動作。state mv 是指令式的、直接改 state、沒有 review 機制、操作紀錄只在 CLI 歷史裡。

1moved {
2  from = aws_security_group.old_name
3  to   = module.network.aws_security_group.app
4}

跨分類引用

• → IaC 工具選型與 state 地基：state 怎麼從 local 搬到 remote backend
• → Console 唯讀鐵律：drift 的來源與偵測
• → 環境分離與模組化：收斂完成後怎麼把單環境拆成 per-env module
• → infra 走 PR 流程：收斂完成後的變更怎麼走 review
• → State 修復與清理：state 損壞的操作修復步驟
• → Drift 分類處理：逐項判斷 adopt vs revert
• → 批次 Import 工作流：unmanaged resource 的 import 操作
• → 過渡期操作：兩套真相並存時的安全操作規則

讀 plan 輸出：三種變更類型

terraform plan 的輸出用符號標示每個資源的預期變更。三種類型的風險等級不同，處理方式也不同：

 1# in-place update（~）：修改屬性，資源本身不動
 2~ resource "aws_security_group_rule" "api_ingress" {
 3    ~ cidr_blocks = ["10.0.0.0/16"] -> ["10.0.1.0/24"]
 4  }
 5
 6# forces replacement（-/+）：刪除後重建，新資源取得新 ID
 7-/+ resource "aws_db_instance" "primary" {
 8    ~ identifier = "app-prod" -> "app-prod-v2" # forces replacement
 9  }
10
11# destroy（-）：刪除資源
12- resource "aws_security_group" "legacy_api" {
13  }

-（destroy）是最危險的類型。它代表某個資源存在於雲端但不在 Terraform code 裡——可能是手動建的、可能是從 state 被 state rm 移除過、也可能是前任維護者刪了 code 但沒跑 apply。不論原因，直接 apply 會把這個資源從雲端刪除。

-/+（forces replacement）的危險在於它看起來像修改但實際是先刪後建。對 stateless 資源（security group rule、IAM policy）影響有限，對 stateful 資源（RDS、EBS volume）意味著資料遺失。

故意的 drift vs 意外的 drift

不是所有 drift 都是問題。接手的環境裡，手動改動可能有兩種來源：

故意的改動是前任維護者為了解決特定問題而做的。常見形態：臨時開了一條 security group 規則讓外部監控系統連進來、調高了 RDS 的 max_connections 參數來應對流量成長、手動把 instance type 從 t3.small 升到 t3.medium 因為記憶體不夠。這類改動通常是正確的操作決策，只是沒有同步回 code。

意外的漂移是無意中造成的。常見形態：在 Console 測試時改了某個設定但忘了改回來、另一個 Terraform workspace 的 apply 動到了共用的資源、AWS 自動更新了某些屬性（如 default security group 的描述）。

區分兩者的方法是查 CloudTrail——看這個改動是誰做的、什麼時候、有沒有對應的 ticket 或 changelog 記錄。如果 CloudTrail 顯示改動發生在一次事故期間、由當時的值班工程師執行，大概率是故意的。如果改動來自一個不認識的 IAM user、或時間點跟任何已知事件對不上，可能是意外。

1aws cloudtrail lookup-events \
2  --lookup-attributes AttributeKey=ResourceName,AttributeValue=sg-0abc123 \
3  --start-time 2026-01-01 \
4  --query 'Events[].[EventTime,Username,EventName]' \
5  --output table

每條 drift 的處理決策

每條 plan 差異都需要一個明確的決定：保留手動改動（更新 HCL）、回退到 code 的版本（apply）、還是暫時擱置（不動）。

保留（adopt into HCL）

適用條件：手動改動是正確的操作決策，雲端的現況是期望狀態。處理方式是把 HCL 改成跟雲端一致，讓下次 plan 對這項顯示零差異。

多數 drift 應該走這條路。前任維護者調大了 instance type、加了一條 security group 規則、改了 RDS parameter——這些改動通常有操作上的理由。把 code 對齊現實，比把現實改回 code 安全。

回退（apply to revert）

適用條件：手動改動是錯誤的、或已經不再需要（如臨時開的除錯 port）。確認回退不會影響運行中的服務後，讓 Terraform apply 把設定改回 code 描述的版本。

回退前要確認的事：這條規則還有沒有服務在用？這個參數改回去會不會讓連線斷開？如果不確定，先 adopt 再說——adopt 的成本是改一行 HCL，回退錯誤的成本可能是服務中斷。

擱置（defer）

適用條件：目前無法判斷該保留還是回退（缺乏 context），或改動涉及 stateful 資源的 forces replacement 需要更多準備。擱置的做法是在 code 裡加 lifecycle { ignore_changes = [...] } 暫時跳過這項差異，並留下註解說明為什麼擱置、預計什麼時候處理。

1resource "aws_db_instance" "primary" {
2  # drift: identifier 被手動改過，forces replacement
3  # 擱置原因：直接 apply 會觸發 RDS 重建、資料遺失
4  # 預計處理：確認新 identifier 後更新 HCL + 用 moved block
5  lifecycle {
6    ignore_changes = [identifier]
7  }
8}

擱置不是永久解法。ignore_changes 會讓這個屬性脫離 IaC 管理，累積越多就越接近「回到手動」。定期回顧擱置清單，逐項決定保留或回退。

Stateful 資源的高風險 drift

stateful 資源（RDS、EBS volume、DynamoDB table）的 drift 需要特別處理，因為 forces replacement 意味著資料遺失。以下屬性的改動在 plan 裡會顯示 -/+（forces replacement），直接 apply 會先刪除再重建：

發現 stateful 資源的 forces replacement 時，處理步驟：

1. 在 lifecycle 加 ignore_changes 暫時跳過
2. 備份資源（RDS snapshot、EBS snapshot）
3. 確認正確的目標狀態後，用 moved block 或 terraform state mv 處理 identity 變更
4. 用 terraform plan 驗證變更類型從 -/+ 變成 ~（in-place）或零差異
5. 移除 ignore_changes

refresh-only：安全的 state 同步

terraform apply -refresh-only 只更新 state 來反映雲端現況，不改變任何雲端資源。它適用於「雲端被手動改了、想讓 state 跟上現實但還沒準備好改 HCL」的情境。

1terraform apply -refresh-only

refresh-only 之後，state 跟雲端一致了，但 state 跟 HCL 之間的差異仍然存在——下次跑 plan 仍會看到 drift。它解的是「state 過時」的問題，不是「code 跟現實不一致」的問題。兩者要分開處理：先 refresh-only 讓 state 乾淨，再逐項決定 HCL 要不要對齊。

使用 refresh-only 的前提是確認 state backend 有 versioning——如果 refresh-only 把 state 改壞了（例如併發操作導致 state 衝突），需要能回捲到上一個版本。

批次 drift 收斂工作流

接手環境的 drift 通常不是一兩條，可能有幾十條。逐條處理可以但效率低，按類型批次處理比較實際：

第一批：安全類。security group 規則、IAM policy 的 drift 優先處理，因為它們直接影響存取邊界。全開的規則該關就關（回退），故意開的規則 adopt 進 code。

第二批：stateless 資源的 in-place drift。tag 不一致、description 不一致、非關鍵屬性的變更。這類 drift 風險低，可以批次 adopt（把 HCL 改成跟雲端一致）然後一次 apply 驗證。

第三批：stateful 資源。RDS parameter、backup retention、instance class 的變更。逐個處理，每個都要確認是 in-place update 而非 forces replacement。

第四批：擱置項。forces replacement、無法判斷的改動。加 ignore_changes 暫緩，排進 backlog 定期回顧。

每一批處理完後跑一次 plan，確認該批的 drift 消失、其他批次的 drift 沒被影響。不要一次 apply 所有批次——分批的目的是控制每次 apply 的影響範圍。

整個 drift 收斂流程的時程取決於 drift 數量和 stateful 資源的比例。20 條以內的 drift、多數是 stateless 的 in-place 變更，2-3 天可以收完。50 條以上、含多個 stateful 資源的 forces replacement，需要 1-2 週分階段處理。

跨分類引用

• → 有半套 IaC 但文件缺失的環境接管：本文的上層總覽
• → State 修復與清理：drift 處理前先確認 state 本身是健康的
• → Unmanaged resource 批次 import：drift 收斂完成後，開始 import unmanaged resource
• → Console 唯讀鐵律：drift 的根本防線
• → 模組四：環境分離與模組化：drift 收斂後的環境拆分路徑

概念位置

Infrastructure Drift 位在 IaC state、cloud resource、手動 hotfix 與外部 controller 之間，常由 console edit、事故修復、provider 預設值或自動調整造成。

可觀察訊號

• plan 顯示大量非預期變更。
• production 資源和 repository 宣告不一致。
• 下次 apply 可能覆蓋事故 hotfix。

接近真實服務的例子

事故中工程師在雲端 console 手動放寬 security group。服務恢復後，IaC plan 顯示 security group 與宣告檔不同；團隊需要判斷這個變更是短期 hotfix 還是應回寫成正式規則。

設計責任

Infrastructure Drift 要定義偵測頻率、owner、修復路由、state repair 與回寫規則，讓平台狀態重新回到可審查流程。