常見的斷網情境：政府或軍事機密網路（實體隔離）、工控與 OT 環境（工廠、電廠、SCADA）、金融交易系統的高安全隔離區、醫療設備網路、以及地端機房裡刻意不開 internet access 的 private zone。

這個模組是橫切約束——它影響模組一（IaC 選型）到模組七（PR 流程）的每一個操作步驟。每篇文章處理一個被斷網影響的主要面向。

章節文章

跟其他模組的關係

• → 模組一：最小可行 IaC：斷網時 IaC 工具選型和 state backend 的替代做法
• → 模組五：核心服務上 IaC：容器映像和套件依賴的離線管理
• → 模組六：可觀測性：斷網環境的監控不能 phone home
• → 模組七：PR 流程：CI/CD 在內網怎麼跑
• → 接手維運：接手斷網環境的額外約束

這個模組處理的是升級的操作框架與各類型的專屬風險，跟成熟度階梯平行而非串行——升級可能發生在任何成熟度階段。跟接手維運的關係是：接手後的下一步常常就是升級（接手一個 PHP 5.6 的站台，穩定維運後第一個任務就是升 PHP 版本）。

章節文章

跟其他模組的關係

• → 接手維運：接手後穩定維運的下一步常是升級
• → 模組負一：還沒有 infra 的環境：升級過程中建立的操作紀律可以對齊這裡
• → 模組一：最小可行 IaC：升級是導入 IaC 的好時機——新環境用 IaC 建、舊環境手動退役
• → 模組五：核心服務上 IaC：資料庫和運算平台的升級涉及 stateful 資源的特殊處理

這個模組處理的是接管的操作流程，跟成熟度階梯平行而非串行 — 接手可能發生在任何成熟度階段：接手一個只有 FTP 存取的 PHP 站、接手一個有 SSH 但沒有 IaC 的雲端環境、接手一個有半套 IaC 但文件缺失的專案。每種情境的約束不同，但操作原則相通：先拍現況、再建維運能力、最後逐步正規化。

章節文章

跟其他模組的關係

接手維運的終點是把環境帶到模組負一（可控的手動）或模組一（最小可行 IaC）的狀態。接手流程本身不做 IaC 導入 — 它的責任是讓接手者理解環境、建立維運能力、確認什麼能動什麼不能動。IaC 導入是接手完成之後的下一步。

• → 模組負一：還沒有 infra 的環境：接手完成後，環境的操作紀律對齊這裡
• → 模組零：infra 是什麼：成熟度階梯作為接手後評估現況的座標
• → 模組二：身分與憑證：接手時的 credential 盤點與輪替
• → 模組八：治理好習慣：接手後的 tagging 與 secret 管理

把手動環境做成「可控的手動」

可控的手動指的是一種中間狀態：資源還是手點的，但關鍵變更有痕跡、高風險操作有護欄、現實長什麼樣有紀錄。它的責任是降低兩種成本 — 當下出事的成本，以及未來把資源 import 進 IaC 的成本。手動起家是絕大多數服務的常態起點，從一個人驗證想法到小團隊接手都會經過這一階，把它當成需要管理的階段、而不是需要修正的錯誤。

判讀自己是否「可控」的訊號很具體：能不能在五分鐘內說出 production 有哪些對外開放的 port、上週誰動過資料庫參數、刪掉某台機器會不會連帶弄壞別的東西。任何一題答不出來，代表這個手動環境的不可見區域正在擴大，下面幾節就是把這些區域逐一收斂。

先守住代價最高的底線

護欄要先上在「一次失誤就難以挽回」的操作上，因為手動環境沒有 IaC 的 plan / diff 當預檢，人為操作直接生效。優先級看的是失誤的回退代價、不是操作頻率。

長期憑證外洩是回退代價最高的一類。手動環境常見的反模式是把長期 access key 寫進腳本、CI 變數或開發者筆電，一旦外流，攻擊者拿到的是不會過期的權限。在還沒有完整 IAM 設計之前，最低成本的護欄是：對人改用會過期的登入工作階段（如 AWS IAM Identity Center 的臨時憑證），對自動化盡量改用平台原生的角色綁定，把還在用的長期 key 列一張清單、設定定期輪替。身分與憑證的完整地基在「模組二：身分與憑證地基」展開，這裡先擋住最容易致命的那一個。

刪除 production 資源是第二類。手動操作沒有「先看會影響什麼」的步驟，刪一個 security group 或 volume 可能瞬間讓服務失聯。對承載狀態的資源（資料庫、儲存桶、有持久資料的磁碟）開啟平台的刪除保護（如 termination protection、deletion protection），讓誤點多一道阻力。網路規則的大改是第三類 — 調整 VPC 路由、subnet 或對外規則時，先確認回退方式存在再動手，網路地基的系統性設計在「模組三：網路地基」。

這三類的共同點是：護欄成本低、失誤代價高，所以即使還沒有 IaC，CP 值也足以先做。

讓變更留下痕跡

變更留痕的責任是讓「誰、在什麼時候、改了什麼、為什麼」事後可追溯，這是手動階段最接近版本控制的替代品。IaC 的 git history 天然提供這件事，手動環境得靠人為紀律補上。

最低限度是一份變更日誌，可以只是 repo 裡的一個 CHANGELOG 或團隊共用文件，每次動 production 就追加一行：時間、操作者、改了哪個資源、原因。它不需要漂亮，需要的是每次都寫。和它互補的是平台的稽核日誌（如 AWS CloudTrail），稽核日誌記錄 API 層級「發生了什麼」，人寫的日誌補上「為什麼」— 前者你查得到某個 security group 在幾點被改，後者你才知道那次改動是為了什麼需求。兩者一起，事故排查時才能從「哪裡變了」一路追到「能不能安全回退」。

常見陷阱是只在「大改動」時才記錄，結果真正出事的往往是某次以為無關緊要的小調整。判準簡化成一句：只要這個操作別人事後可能需要知道，就記。

命名與 tagging 從手動階段就開始

命名規範與資源標籤是降低未來 import 成本的最低成本投資，它的責任是讓每個資源自帶「我是誰、屬於哪個服務、誰負責、哪個環境」的身分資訊。手動點出來的資源若名稱是 test-2、new-db-final，日後納管時得靠人逐一辨認哪個還在用、屬於哪條業務線，這個考古成本遠高於當初多打幾個字。

從手動階段就固定一套規則：資源名稱帶上服務與環境（如 payments-api-prod），標籤至少包含 service、env、owner 三個維度。這套規則在還沒 IaC 時靠人手動填，等到導入 IaC，這些標籤直接成為 Terraform 把現有資源對應到程式碼的依據，也是模組八治理習慣裡成本歸因與批次操作的基礎（見「模組八：治理好習慣」的 tagging 段）。先建立規範的價值在於：早一天統一，需要回頭重命名的資源就少一批。

盤點現有資源作為納管輸入

資源盤點的責任是把「現實長什麼樣」寫成一份清單，它是日後納管的直接輸入 — 不知道有什麼，就無法決定先 import 什麼。手動環境最危險的是沒人記得還開著的資源。

盤點不必一次到位，先用平台工具把現況拉出來，存成可比對的形式：

1# 列出某區域所有 EC2 instance 與其關鍵標籤
2aws ec2 describe-instances \
3  --query 'Reservations[].Instances[].[InstanceId,Tags,State.Name]' \
4  --output table
5
6# 列出所有 security group 與開放規則，找出對外開放的 port
7aws ec2 describe-security-groups \
8  --query 'SecurityGroups[].[GroupId,GroupName,IpPermissions]' \
9  --output json

把輸出存進 repo，定期重跑比對差異，就能看出環境在背景悄悄長出了什麼。這份清單同時服務三件事：當下的安全盤查（有沒有不該開的對外 port）、未來 IaC import 的範圍界定、以及成熟度評估時「全手動到底有多少資源」的事實基礎（成熟度階梯的定位見「模組零：infra 是什麼」）。

資源與信任不足下的高槓桿取捨

當時間、人力或上層信任都不足，無法一次把上面每件事做齊時，取捨原則是先做「失誤代價高且護欄成本低」的少數幾件。在這個情境下，最划算的通常是兩件：先擋長期憑證外洩，因為一次外洩可能拖垮整個帳號；再開啟有狀態資源的刪除保護，因為資料一旦刪除多半無法復原。

變更日誌與資源盤點屬於累積型投資 — 越早開始，未來省的考古成本越多，但晚一週開始不會立刻出事，所以在資源極度受限時可以排在護欄之後。命名與 tagging 的取捨點在於：新建資源時順手套規則幾乎零成本，回頭重整存量資源才貴，所以策略是「新的一律照規範、舊的等有餘力再補」，而不是停下來先整理全部存量。資源不足時怎麼跟上層談這些工作的優先級，在「模組九：怎麼把 infra 推動起來」展開。

該開始導入 IaC 的訊號

手動環境到了某些訊號出現時，繼續手動的邊際成本會超過導入 IaC 的一次性成本，這就是該往模組一跨進去的時機。訊號是規模與協作的函數，不是時間的函數。

第一個訊號是環境數量變多：當你需要 dev、staging、production 三套幾乎一樣的環境，手動複製會在環境之間留下難以察覺的差異，而 IaC 的價值正是用同一份程式碼複製環境。第二個是多人同時動資源：一個人手動操作還能靠記憶維護，兩三個人並行時，沒有 plan / review 的手動變更會互相覆蓋、互相破壞。第三個是環境爆炸頻率上升：如果「改一個設定結果弄壞別的東西」這類事故開始每月發生，代表手動環境的隱性依賴已經超過人腦能追蹤的上限。

任一訊號穩定出現，就是把第一個資源納入 IaC 的起點 — 前面做的命名、tagging、資源盤點此時直接成為 import 的輸入，第一步怎麼跨進去在「模組一：最小可行 IaC」。在訊號出現前過早導入 IaC 也有代價：單人、單環境、低變更頻率時，IaC 的學習與維護成本可能高於它省下的手動工，所以這裡的判準是等訊號、不是趕進度。

章節文章

跨分類引用

• → 模組零：infra 是什麼：成熟度階梯上「全手動」這一階的定位
• → 模組一：最小可行 IaC：訊號出現後，第一步怎麼跨進 IaC
• → 模組二：身分與憑證地基：長期憑證護欄的系統性設計
• → 模組三：網路地基：手動階段網路大改的回退考量、之後的系統性設計
• → 模組八：治理好習慣：tagging 在成本歸因與批次操作的後續價值
• → 模組九：怎麼把 infra 推動起來：資源不足時怎麼跟上層談優先級
• → 接手維運：別人建的環境怎麼接管：接手前人的專案時的盤點與接管流程

以下步驟是寫第一行 IaC 之前需要就位的前置條件。如果已經備妥可以跳過。如果是第一次接觸雲端帳號，先讀拿到雲端帳號的第一天做安全底線和帳號現況判讀。

雲端帳號。需要一個 AWS 帳號（或 GCP / Azure，本模組以 AWS 為主要範例）。註冊完成後立刻對 root 帳號啟用 MFA（Multi-Factor Authentication）——root 帳號是整個雲端環境的最高權限，沒有 MFA 等於大門沒鎖。啟用路徑：AWS Console → 右上角帳號名稱 → Security credentials → Multi-factor authentication (MFA) → Assign MFA device。日常操作用 IAM user 或 IAM Identity Center 登入，root 帳號只在需要 root-only 操作時使用。

本機工具。安裝 IaC CLI（Terraform 或 OpenTofu）和雲端 CLI（AWS CLI）：

1# macOS
2brew install opentofu awscli
3
4# Arch Linux（opentofu 和 aws-cli-v2 在 AUR，需要 AUR helper）
5yay -S opentofu-bin aws-cli-v2
6
7# 驗證安裝
8tofu --version
9aws --version

雲端認證。本機需要能對雲端 API 認證。最直接的方式是用 AWS CLI 設定 credentials：

1aws configure
2# 輸入 Access Key ID、Secret Access Key、預設 region（如 ap-northeast-1）

這組 access key 來自 IAM user。如果帳號裡還沒有 IAM user，到 AWS Console → IAM → Users 建立一個、附加 AdministratorAccess policy、在 Security credentials 分頁建立 access key。正式環境應該用 SSO 或 short-lived credentials 取代長期 key（模組二會展開），但起步階段一組 IAM user key 足以讓 tofu apply 跑起來。

Git repo。IaC 程式碼從 day 1 就應該在版本控制裡——這是模組零「可重建路徑」的落地前提。建一個 Git repo，後續所有 .tf 檔都放在這裡：

1mkdir infra && cd infra
2git init
3echo '.terraform/' > .gitignore
4echo '*.tfstate'  >> .gitignore
5echo '*.tfstate.*' >> .gitignore
6git add .gitignore && git commit -m "init: gitignore for terraform"

.gitignore 排除 .terraform/（provider 快取）和 *.tfstate（state 檔含敏感值，存放策略見下方 remote state 段落）。

踏上成熟度階梯（從全手動到全程式碼治理的五階分級）第二階（宣告式 IaC，也就是 state 檔誕生那一階）的最小路徑，從兩件事開始：選對工具、把 state 管好。工具決定用什麼語言描述基礎設施，state 則是工具對雲端現實的唯一記憶。這份記憶存在哪、怎麼保護、怎麼防止並行寫壞，是整套 IaC 能不能站穩的地基。

IaC 工具選型：宣告式狀態管理 vs 程式語言抽象

IaC 工具的核心職責是把「我要的基礎設施長什麼樣」描述成可版本控制的程式碼，再由工具負責算出現況與目標的差異並收斂。市場上的工具分成兩條路線，差別落在「用什麼語言描述」與「狀態由誰持有」這兩個軸上，而非功能多寡。

宣告式 DSL 路線

第一條路線的代表是 Terraform 與其開源分支 OpenTofu。寫的是 HCL（HashiCorp Configuration Language），描述的是資源的最終樣貌，工具自己維護一份 state 來追蹤每個資源的真實 ID 與屬性。

 1resource "aws_s3_bucket" "artifacts" {
 2  bucket = "acme-deploy-artifacts"
 3}
 4
 5resource "aws_s3_bucket_versioning" "artifacts" {
 6  bucket = aws_s3_bucket.artifacts.id
 7  versioning_configuration {
 8    status = "Enabled"
 9  }
10}

這段 HCL 描述的是「一個開了 versioning 的 S3 bucket 應該存在」。第一次 apply 時工具建立它，之後每次 apply 時工具比對 state 與雲端現況，只做差異收斂。讀的人看 HCL 就知道最終結果長什麼樣，不需要在腦中追蹤執行順序。

這條路線適合團隊成員背景混雜、需要讓非專職後端的人也能讀懂 infra 定義的情境 — HCL 的閱讀門檻低，diff 直觀，review 時看得出「這個 PR 會新增一個 RDS、改掉一條 security group」。缺點是 HCL 的表達力有限：遇到需要大量條件分支或動態生成的場景時，語法會變得笨拙，count、for_each、dynamic 區塊很快就堆出難以閱讀的嵌套。

程式語言路線

第二條路線的代表是 AWS CDK 與 Pulumi。寫的是 TypeScript、Python、Go 這類語言，靠迴圈、函式、類別來生成資源。這條路線適合 infra 邏輯本身複雜、需要大量條件分支與抽象複用的團隊，例如要根據環境清單動態生成數十組對稱資源。

代價是 review 難度上升。一段 for 迴圈展開後到底建了哪些東西，得在腦中執行程式才看得出來，diff 不再等於變更本身。一個抽象類別改了一行建構子參數，展開後可能影響所有繼承它的資源，而 PR diff 上只看到那一行。對跨職能 review（PM、SRE、安全團隊都要看的變更）來說，這是可感知的閱讀成本。

CDK vs Pulumi：狀態由誰持有

CDK 與 Pulumi 同屬程式語言路線，但「狀態由誰持有」這個軸把它們再分開。

CDK 把程式碼 synth 成 CloudFormation 模板，再交給 CloudFormation 服務端執行與追蹤。state 由 AWS 代管 — 沒有一份 tfstate 檔要自己存放、加密、回捲，也不需要額外的鎖表來防並行。這份「狀態維運外包給雲端」正是 CDK 在 AWS 生態內的賣點之一。代價是綁定 CloudFormation 與單一雲 — CloudFormation 的更新速度、resource coverage、錯誤訊息品質都由 AWS 控制，團隊的 debug 能力受限於 CloudFormation 的回報粒度。

Pulumi 走另一邊：它維護一份自己的 state，預設交給 Pulumi Cloud 託管，也能改用 S3 之類的後端自管。形態上更接近 Terraform 的 state 模型，state 的存放、保護與並行控制重回團隊手上。同一條程式語言路線，選 CDK 等於把 state 責任讓給雲端，選 Pulumi 則保留對 state 落點的掌控。

選型判準

選型看的是團隊組成與變更的審查需求，可以用一張決策表歸納：

若多數變更要跨職能 review、希望 diff 一眼可讀，宣告式 DSL 較划算；若 infra 由專職平台團隊維護、抽象複用的收益大於審查透明度的損失，程式語言路線較划算。

Terraform 與 OpenTofu 之間，OpenTofu 是授權變更後社群分叉出的相容實作，HCL 與 provider 生態幾乎共用；選擇主要看對授權條款與治理模式的偏好，技術判準在這一階沒有實質差異。本模組後續一律以 HCL 示意，換成任一宣告式工具判準仍成立。

上述兩條路線之外，還有兩類工具走不同的運作模型。Kubernetes-native 路線（代表是 Crossplane）用 CRD 描述雲資源、由 controller 持續收斂，state 由 Kubernetes 的 etcd 持有，適合已經重度投入 Kubernetes 的團隊。Serverless-first 框架（代表是 SST）把部署與 IaC 合一，適合全 serverless 架構。這兩條路線的 state 模型與 CLI 驅動的 plan/apply 流程不同，本系列不展開。

state 是工具對現實的唯一記憶

state 是 IaC 工具用來記錄「上一次 apply 之後，每個資源在雲端真實長什麼樣」的快照。它的作用是讓工具能算出「現況」與「目標」之間的最小差異。沒有 state，工具每次都得把所有資源重新查一遍才知道該不該動，而且無法分辨「這個資源是我建的、該由我管」還是「別人手動建的、不歸我管」。

一份 state 的實際內容大致長這樣（簡化版）：

 1{
 2  "resources": [
 3    {
 4      "type": "aws_s3_bucket",
 5      "name": "artifacts",
 6      "instances": [
 7        {
 8          "attributes": {
 9            "id": "acme-deploy-artifacts",
10            "arn": "arn:aws:s3:::acme-deploy-artifacts",
11            "bucket": "acme-deploy-artifacts",
12            "tags": { "env": "prod", "owner": "platform" }
13          }
14        }
15      ]
16    }
17  ]
18}

state 裡通常含有資源的真實 ID、相依關係，以及部分敏感屬性 — 例如資料庫的初始密碼、private key 的輸出值、加密金鑰的 ARN。這帶來兩條硬邊界，違反任一條都會在未來製造代價高昂的事故。

state 絕不能進 git

state 含明文敏感值，一旦推進版控就等於把密碼寫進每個 clone 的歷史裡。事後 rotate 密碼也清不掉 git 歷史 — 因為 git 是 append-only 的，舊版本的 state 永遠留在 commit 裡，除非用 git filter-branch 或 git filter-repo 重寫整條歷史（這本身是一個破壞性操作，會影響所有已經 clone 的副本）。

在 .gitignore 裡搜尋 *.tfstate 和 *.tfstate.backup——如果這兩行不在，state 有進版控的風險。在 repo 根目錄執行一次搜索確認：

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

如果有任何結果，代表 state 曾經被 commit 過，那些 commit 裡的敏感值已經暴露。

state 不能只放本地

本地 state 的失敗模式是它把整份基礎設施的記憶綁在一台筆電上 — 換人接手、換台機器、或多人同時 apply 時，記憶就分裂了。

具體場景：工程師 A 在自己的筆電 apply 了一次，state 記住「已經建了 3 個 security group」。工程師 B 在另一台筆電上拉了同一份 code，但她的本地沒有 state（或有一份過時的 state），apply 時工具以為那 3 個 security group 不存在，又建了 3 個重複的。更糟的場景是 B 的 state 比 A 舊，工具對比後認為 A 後來新增的 security group「不在記憶裡、是多餘的」，於是 apply 時把它們刪掉 — 而 A 還以為那些規則還在保護服務。

這兩條邊界共同指向同一個結論：state 需要一個團隊共享、有版本、有存取控制、且能防止同時寫入的存放處。這就是 remote state backend 要解的問題。

remote state backend：自管 vs 託管

remote state backend 是把 state 從本地移到團隊共享儲存的機制，它要同時滿足三件事：持久保存、防止並行寫入衝突、以及保護敏感內容。達成方式分成自管儲存與託管服務兩種，差別在維運責任落在誰身上。

自管 backend

自管路線以雲端物件儲存加鎖機制為典型組合。以 AWS 為例，state 檔放 S3、用一張 DynamoDB 鎖表防止兩個人同時 apply：

1terraform {
2  backend "s3" {
3    bucket         = "acme-tf-state"
4    key            = "prod/network/terraform.tfstate"
5    region         = "ap-northeast-1"
6    encrypt        = true
7    dynamodb_table = "acme-tf-lock"
8  }
9}

這段設定的每一項都對應前一節的一條邊界：

encrypt = true 讓 state 在 S3 落地時加密，回應「state 含敏感值」的風險。加密用的是 S3 的 server-side encryption，搭配 KMS key 可以進一步控制誰能解密。

bucket versioning 是這段設定裡沒有出現、但在建立 bucket 時就該開的屬性。apply 寫壞或誤刪 state 時，versioning 是把記憶回捲到上一個正確版本的唯一退路。沒開的話一次壞寫就讓工具失去對現實的記憶，而回復的唯一方式是從雲端逐個資源重新 import。建立 state bucket 的 HCL 應該同時開 versioning 與刪除保護：

 1resource "aws_s3_bucket_versioning" "state" {
 2  bucket = aws_s3_bucket.tf_state.id
 3  versioning_configuration {
 4    status = "Enabled"
 5  }
 6}
 7
 8resource "aws_s3_bucket_lifecycle_configuration" "state" {
 9  bucket = aws_s3_bucket.tf_state.id
10
11  rule {
12    id     = "retain-old-versions"
13    status = "Enabled"
14
15    noncurrent_version_expiration {
16      noncurrent_days = 90
17    }
18  }
19}

舊版本的保留天數是成本與安全的取捨。90 天足以涵蓋大多數「發現 state 壞了再回去找正確版本」的時間差 — 超過 90 天才發現的 state 問題通常已經被後續 apply 覆蓋，回捲到更早的版本反而引入更大的落差。

dynamodb_table 指向一張鎖表。apply 開始時寫入一筆鎖、結束才釋放，第二個人同時跑就會被擋下並提示鎖被誰持有。這正是本地 state 無法提供、卻是多人協作底線的並行保護。鎖表本身的建立只需要幾行 HCL：

 1resource "aws_dynamodb_table" "tf_lock" {
 2  name         = "acme-tf-lock"
 3  billing_mode = "PAY_PER_REQUEST"
 4  hash_key     = "LockID"
 5
 6  attribute {
 7    name = "LockID"
 8    type = "S"
 9  }
10}

鎖表用 PAY_PER_REQUEST 模式足夠，因為它的讀寫頻率很低（只在 apply 開始和結束時各一次）。鎖卡住時（apply 中途失敗、沒有正常釋放鎖），用 terraform force-unlock <lock-id> 手動釋放，但前提是確認沒有其他 apply 正在執行。

key 是 state 在 bucket 內的路徑，這裡先用 prod/network 之類的分層命名。實際怎麼依環境切分 state 留待模組四：環境分離與模組化展開。

自管 backend 的雞生蛋問題

自管 backend 有一個啟動悖論：state bucket 和 lock table 本身也是雲端資源，它們該由誰來管理？用 Terraform 管理 Terraform 的 backend？

務實的做法是接受這個循環：用一份獨立的、最小化的 Terraform code 來建立 state bucket 和 lock table，這份 code 用 local state（因為它只在啟動那一次跑）。建立完成後，所有後續的 Terraform code 都指向這個 remote backend。這份啟動 code 的 local state 可以 commit 進 repo（它不含敏感值，只有 bucket 和 DynamoDB table 的 ID），或直接在跑完後丟棄 — 因為這些資源如果需要重建，幾行 CLI 就能做到。

 1# bootstrap/main.tf — 只用一次，建立 state 基礎設施
 2terraform {
 3  # 刻意用 local state，因為 remote backend 還不存在
 4}
 5
 6resource "aws_s3_bucket" "tf_state" {
 7  bucket = "acme-tf-state"
 8}
 9
10# ... versioning, encryption, lock table

託管 backend

託管路線把上述維運細節包起來，由 Terraform Cloud、Spacelift、env0 這類平台代管 state、鎖與加密，附帶 web UI 與 audit log。

判讀訊號是團隊規模與維運餘裕。自管 backend 的成本是要自己把 bucket versioning、加密、鎖表、IAM 權限配對，配錯任何一項都可能讓 state 失去保護 — 例如忘了開 versioning，一次壞寫就回不去。託管服務用月費換掉這份配置與維運負擔，代價是 state 託付給第三方、且進階治理功能常綁在付費級距。

小團隊起步、不想第一週就花在配 backend 上，託管較划算。對 state 存放位置有合規或主權要求、或希望基礎設施盡量自持的團隊，自管較划算。託管服務（Terraform Cloud / Spacelift）的免費方案涵蓋基本功能，付費級距約 $20-70/user/月；自管 backend 的成本是初次配置半天到一天的工程師時間，加上持續的 IAM 權限與 versioning 維護。

導入時程參考：最小可行 IaC（state backend + 第一批地基資源）的導入約需 2-3 天工程師時間。第一個可見里程碑是「一條指令能在新帳號重建整個地基環境」。之後每批服務的納管約 1-2 天/批，依資源複雜度而定。

State 地基設好後，下一步是立 Console 唯讀鐵律、並用最小可行資源集合驗證整條鏈路，見Console 唯讀鐵律與最小可行資源集合。

跨分類引用

• → Console 唯讀鐵律與最小可行資源集合：state 管好之後，Console 唯讀紀律與最小 apply 閉環
• → 模組二：身分與憑證地基：Console 唯讀鐵律靠權限落地
• → 模組四：環境分離與模組化：state 的 key 怎麼依環境切分

這篇文章提供三條可以直接拿去用的論述線 — 成本、風險、速度 — 以及一套簡報骨架和常見反對意見的回應。目標是讓讀完的人能在下一次預算會議上，用決策者聽得懂的語言講出 infra 投資的必要性。

成本論述：不做 infra 的隱藏成本

infra 投資的成本是可見的（工程師時間），不做的成本是隱藏的（散落在不同科目、由不同人承擔、在不同時間點浮現）。商業論證的第一步是把隱藏成本攤開來算，讓「不做」也有一個價格標籤。

事故恢復時間

沒有環境藍圖（程式碼描述）的系統，出事後的恢復時間取決於「有沒有人記得它當初怎麼建的」。一個手動點出來的環境，主要維護者離開座位的那一刻就進入「沒有藍圖」的狀態 — 重建它需要翻 Console、翻 CloudTrail、翻 Slack 對話、猜測各項設定的用意，這個過程以天計。有環境藍圖的系統，重建是一條指令加上等待資源啟動的時間，以分鐘計。

把這個差距換算成商業數字：停機每小時的營收損失乘以恢復時間的差距，就是「沒有藍圖」在一次事故中的價格。一個日營收 100 萬的服務停機 8 小時和停機 30 分鐘，差距是 750 萬。這個數字不需要精確 — 量級對了就足以讓決策者重新評估「不做」的代價。

人員依賴成本

當只有一個人懂整套環境怎麼運作，這個人的離職成本不只是招聘與交接 — 還包括新人摸索期間的生產力損失、期間無法安全改動環境的機會成本、以及「找不到一樣有經驗的人」的風險。把環境的建立方式寫成程式碼，新人讀程式碼就能理解環境結構，交接從「口耳相傳」變成「讀文件」。

量化方式：目前負責 infra 的人如果下週離職，預估團隊需要多少時間才能重新掌握環境？乘以團隊的平均日薪，就是人員依賴的隱含成本。這個成本隨著環境複雜度增長而加速 — 環境越大、手動設定越多，交接缺口越寬。

殭屍資源成本

沒有資源盤點與標籤的環境，會持續累積「沒有人記得還開著」的資源 — 測試用的機器跑完沒關、舊版服務下線但底層資源沒清、某個實驗用的資料庫一直在計費。這些殭屍資源的月費不大，但它們會無聲地長期累積。

量化方式：請雲端帳號管理者拉出過去三個月的帳單，找出「沒有標籤」或「標籤顯示是非正式環境」的資源，加總它們的費用。多數團隊第一次做這件事時，會發現 10-30% 的月費花在沒有人認領的資源上。這個數字本身就是論證素材。

合規與稽核風險

當外部稽核（SOC 2、ISO 27001、金融監管、客戶的安全問卷）要求「列出所有對外暴露的服務」「提供存取權限的變更紀錄」「證明 production 環境的變更有經過審查」，手動環境的回應方式是花一到兩週人工考古。有 infra 藍圖的環境，這些問題的答案在程式碼倉庫裡，幾分鐘就能產出。

合規的商業代價不是抽象的 — 稽核不過可能導致客戶合約無法續簽、保險費率上調、或直接的監管罰款。把「每次稽核的準備時間」和「稽核不過的潛在損失」列成數字，比講「我們需要更好的治理」有效得多。

風險論述：一張表說明影響範圍

成本論述算的是持續性的隱藏支出，風險論述算的是一次性失效的最壞情況。兩者的語言不同：成本用月費和工時講，風險用客戶影響和法律後果講。

這張表的用法是：請決策者指出「哪些情境我們現在有可能發生」，命中的每一行都是一個尚未兌現的風險。風險論述的價值在於它把抽象的技術缺口換算成具體的商業後果 — 不是「我們缺乏環境分離」，而是「一次測試操作可以直接打到正式客戶」。

使用這張表時要誠實分級。把每一行都講成即將發生的災難，幾次之後決策者會把所有警告當成危言聳聽。把真正的地基級風險（密鑰外洩、沒有藍圖）跟營運效率級的問題（缺標籤、缺變更紀錄）分開講，前者用「最壞情況」爭取優先級，後者用「累積成本」來排序。

速度論述：infra 是加速器

成本和風險是防守型論述（不做會怎樣），速度是進攻型論述（做了會快多少）。多數決策者對「變快」的興趣高於對「防災」的興趣，因為速度直接對應到他們在意的指標 — 交付頻率、上市時間、團隊效率。

速度論述的關鍵是把「infra 投入」框架成「一次性投入換取持續性加速」，而不是「持續性的額外負擔」。前 2-4 週是投入期（建立藍圖、設定自動化），之後每一次新環境、每一次排查、每一次稽核都在收割回報。投入是固定的，回報是累積的。

一頁簡報的邏輯

把前面三條論述線收斂成四頁簡報，這是可以直接拿進會議室的骨架：

第一頁：現況盤點

列出具體數字 — 我們有多少個雲端資源、其中多少百分比沒有程式碼描述、多少百分比沒有標籤、有幾把超過 90 天沒輪替的密鑰。這些數字讓決策者看到「我們目前的狀態」而非聽到一個抽象的技術判斷。數字來源是資源盤點（見模組負一）和雲端帳單。

第二頁：風險與成本

從上面的風險表挑出「我們現在確實有可能發生」的 2-3 個情境，附上最壞情況的商業影響估算。加上殭屍資源的月費和稽核準備的人工成本。這一頁的任務是讓「不做」有一個數字。

第三頁：投入規劃

把 infra 工作拆成階段，每階段標明工程師時間和里程碑。階段拆法對應成熟度階梯：第一階段（2-3 週）建立藍圖與版本控制、第二階段（2-3 週）環境分離與權限收斂、第三階段（持續）自動化護欄與治理。每個階段都能獨立交付價值 — 不是一次性的大工程，是分批兌現的投資。

第四頁：回報預期

用速度論述的表格呈現：投入完成後，新環境時間、排查時間、稽核準備時間各縮短多少。加一條「人員依賴風險」的改善 — 從「只有一個人懂」到「任何人讀程式碼都能理解」。

常見反對意見的回應

「我們還小，不需要」

地基類的設定（環境藍圖、權限管控、密鑰管理）的補救成本隨時間複利。5 個資源的環境花半天就能建好藍圖；50 個資源的環境要花兩週逐一考古、逐一對照。問題不是「現在需不需要」，而是「現在做和半年後做，成本差多少」。多數情況下，越早做越便宜 — 這跟技術規模無關，跟補救成本的增長曲線有關。

判斷該不該現在做的方式是看成熟度階梯上三個 day 1 鐵律：環境藍圖、密鑰不進程式碼、有狀態資源的刪除保護。這三項的補救成本最陡，即使「還小」也值得先立。其他的治理機制（自動化護欄、細緻的成本分攤）確實可以等規模到了再做。

「太貴了」

infra 工具本身免費或接近免費（Terraform / OpenTofu 開源、雲端 state 儲存成本極低）。真正的成本是工程師時間 — 但這個時間要跟「不做」的隱藏成本比。如果團隊每個月花 2 天處理手動環境的事故排查、花 1 天回答稽核問題、每季花 1 週準備合規報告，加起來的時間比一次性投入 2-4 週建好基礎更貴，而且是每個月都在付。

另一個角度是問：團隊裡最懂環境的那個人，他每週花多少時間回答「這個怎麼設的」「那個能不能改」這類問題？這些時間乘以他的時薪，就是「沒有程式碼描述」的持續性成本。

「會拖慢開發」

短期會 — 前 2-4 週的投入期確實在做不產出功能的工作。但這跟蓋辦公室一樣：搬進去之前要先裝修，裝修期間不能辦公，但裝修完之後每天都在受益。

具體的加速數字見上面的速度表。比較有效的框架是：這 2-4 週的投入，換到的是之後每次新環境省 3 天、每次排查省幾小時、每次稽核省一週。投入三次之後就回本，之後都是淨賺。如果決策者對時間投入有疑慮，可以提議從最高 ROI 的項目開始（通常是環境藍圖 + 密鑰管理），先用 1 週交付一個可見的改善，再爭取後續階段。

「現在能跑就好」

這個反對意見的翻譯是「我看不到壞掉的風險」。回應的方式是問一個具體問題：「如果我們的主要服務現在掛了，我們能在多久內重建起來？」如果答案超過一小時、或者答案是「不確定」，這本身就是論證 — 決策者通常能理解「不知道能不能救回來」的商業代價。

跨分類引用

• → 模組零：infra 是什麼：成熟度階梯作為投入規劃的座標
• → 模組負一：手動環境：資源盤點作為現況數字的來源
• → 模組八：治理好習慣：tagging 與成本可見性的地基
• → 模組九：怎麼推動 infra：信任赤字、期望值對齊與知識共享的組織面

infra 變更走 code 流程

infra 變更的標準路徑是 PR → plan → review diff → 合併 → apply。這個順序的核心責任是把「執行前先看清楚要改什麼」變成強制步驟，而不是 apply 之後才從事故裡發現改錯了。每個環節各自承擔一段審查責任，少掉任一段，infra 就退回到不可審查的狀態。

plan 是整條鏈最關鍵的一環

terraform plan 把當前 state、雲端實際資源、與目標設定三方比對，產出一份「會新增 / 修改 / 刪除哪些資源」的 diff。這份 diff 是 review 的對象：reviewer 直接看 plan 算出來的實際變更，而非讀 HCL 自行想像結果。

plan 輸出裡最關鍵的判讀訊號是操作類型。+ 是新增，~ 是就地更新，- 是銷毀，-/+ 是先銷毀再重建。前兩者多數情境是安全的，後兩者需要逐行細看。改一個看似無害的欄位可能觸發整個資源重建（-/+），例如某些雲資源的 name 或 identifier 是 immutable 屬性，改它的唯一方式就是銷毀再建。對有狀態的服務（RDS、帶資料的 EBS volume），-/+ 代表資料遺失或停機。Review 階段抓到這個 -/+，比 apply 到一半才發現便宜太多。

 1# plan 輸出中要特別警惕的標記
 2# forces replacement  — 某個 immutable 屬性被修改，將觸發銷毀重建
 3# must be replaced    — 跟上面同義，Terraform 新版的表達方式
 4# will be destroyed   — 資源將被刪除
 5
 6  # aws_db_instance.primary must be replaced
 7  -/+ resource "aws_db_instance" "primary" {
 8      ~ identifier = "app-prod" -> "app-production"  # forces replacement
 9        ...
10    }

把 plan 結果貼回 PR

把 plan 結果貼回 PR 是讓 review 真正生效的做法。流程上，PR 觸發 CI 跑 plan，plan 輸出回貼成 PR comment，reviewer 連同程式碼 diff 一起看；approve 後才允許合併，合併才觸發 apply。

這裡有個取捨：plan 與 apply 之間若隔了很久，雲端實際狀態可能已經漂移（有人手動改了、或別的 PR 先 apply 了），導致 apply 時的 plan 跟 review 時看到的不一致。應對方式分保守與務實兩種。保守做法是 apply 前重跑一次 plan 並比對結果 — 一致才繼續，不一致就中斷。務實做法是在合併觸發 apply 時自動跑 plan 並只在無 destroy / replace 時自動執行，有 destroy / replace 就停下來要人確認。多數團隊從務實做法開始，到遇過一次 plan-apply 不一致的事故後才升級到保守做法。

apply 失敗的回退邊界

infra apply 不像程式碼部署可以直接 rollback 到上一版 image — 中途失敗時部分資源已經建立、state 可能處於半完成狀態。例如 apply 建了一個新 subnet 但在建 route table 時 timeout，此時 subnet 存在於雲端和 state 裡，route table 只在雲端不在 state 裡（或反過來），下一次 plan 的計算基礎就不精準。

應對的紀律是：apply 失敗後，先跑一次 terraform plan 確認 state 與現實的差距，再決定是修正 code 重新 apply 還是手動清理殘留資源後 terraform state rm。在清理之前不要再改 code、不要連發第二次 apply — 第二次 apply 在不確定的 state 上跑，可能把問題擴大。

PR 流程的價值在這裡不只是事前審查，也是事後可追溯：每次變更都對應一個 commit 與一個 PR，要回溯時知道是哪次改的、為什麼改、誰 review 的。

fmt 與 validate：最便宜的第一道檢查

fmt 與 validate 是進到任何安全掃描之前的基礎檢查，責任是擋掉格式不一致與語法 / 型別錯誤這類不需要動腦判斷的問題。它們跑得快（通常不到五秒）、沒有誤判空間，適合放在 CI 最前面當作快速 fail 的關卡。

terraform fmt -check 驗證程式碼是否符合標準排版。它本身不影響基礎設施行為，價值在於消除 diff 噪音：當每個人的編輯器縮排習慣不同，PR diff 會混入大量純排版變動，把真正的邏輯變更淹沒，reviewer 更容易看漏。統一格式後，diff 裡剩下的就是語意變更。在本地開發階段配合 editor plugin 或 pre-commit hook 在存檔時自動 fmt，讓 CI 的 fmt check 幾乎不會再 fail — 它存在的意義是攔住那些沒裝 plugin 的人。

validate 則檢查設定在語法與內部一致性上是否成立 — reference 到不存在的變數、型別不匹配、必填參數缺漏、module 呼叫的 source 解析不了，這些在 validate 階段就會報錯，不必等到 plan 連線雲端才發現。validate 需要先跑 terraform init，但可以用 -backend=false 跳過連線 state backend，這樣在 CI 裡不需要雲端憑證就能跑完。

 1# .github/workflows/terraform.yml — plan 前的基礎檢查
 2jobs:
 3  validate:
 4    runs-on: ubuntu-latest
 5    steps:
 6      - uses: actions/checkout@v4
 7      - uses: hashicorp/setup-terraform@v3
 8      - run: terraform fmt -check -recursive
 9      - run: terraform init -backend=false
10      - run: terraform validate

判讀上，fmt 與 validate 失敗代表的是「這份 code 還沒準備好被認真 review」，屬於作者自己該先修掉的問題，不該佔用 reviewer 注意力。把它們設成 CI 必過的 gate，作者在本地就會先跑、先修，PR 送出時已經是乾淨的。

tflint / checkov / tfsec：抓壞寫法與安全漏洞

fmt 與 validate 確認 code「語法正確」，但語法正確的設定仍然可能是危險的設定。tflint、checkov、tfsec 這類靜態掃描工具承擔的是「語意正確」這層：在不實際建立資源的前提下，從 HCL 裡比對已知的壞寫法與安全反模式，把問題擋在 plan 之前。它們補的是 reviewer 肉眼容易漏掉的盲區 — 人會看漏一個 0.0.0.0/0，規則不會。

三者的側重

checkov 與 tfsec 的覆蓋範圍有重疊（都會掃 S3 公開與 SG 全開），差別在規則來源與報告格式。checkov 的規則對標 CIS benchmark 和多雲合規框架（AWS、Azure、GCP、Kubernetes），tfsec 更專注在 Terraform HCL 結構。兩者跑在一起時，重複的命中可以用其中一個的 skip 標記豁免。

兩個最常攔下的反模式

S3 bucket 對外公開。一個漏設 block_public_access 或 ACL 寫成 public-read 的 bucket，會讓裡面的物件對整個網際網路可讀。這類設定在 HCL 裡只是一兩行，肉眼 review 時很容易因為「看起來像樣板」而放過，但後果是資料外洩。checkov 規則 CKV_AWS_19（S3 bucket 未啟用 server-side encryption）和 CKV_AWS_53（block public access 未全開）會標記這類漏洞：

 1# checkov 會攔下的寫法 — 缺少 block_public_access
 2resource "aws_s3_bucket" "data" {
 3  bucket = "acme-customer-data"
 4}
 5
 6# 正確寫法 — 顯式關閉公開存取
 7resource "aws_s3_bucket_public_access_block" "data" {
 8  bucket                  = aws_s3_bucket.data.id
 9  block_public_acls       = true
10  block_public_policy     = true
11  ignore_public_acls      = true
12  restrict_public_buckets = true
13}

Security group 對全世界開放。一條 ingress 寫成 cidr_blocks = ["0.0.0.0/0"] 加上 port 22 或 3306，等於把 SSH 或資料庫埠暴露給全網掃描器。tfsec 與 checkov 都會標記這種「敏感埠 + 全開 CIDR」的組合。這條規則跟模組三：網路地基講的 security group 收斂原則是同一件事的兩端 — 模組三教怎麼把規則寫對，本章用靜態掃描確保寫錯時擋得下來。

1# 三道掃描串在一起，任一 fail 就中斷
2tflint --recursive
3checkov -d . --quiet --compact
4tfsec . --soft-fail=false

命中是候選不是判決

判讀這些工具的命中時，要區分「真漏洞」與「情境合理的例外」。並非每個 0.0.0.0/0 都是錯 — 一個對外的 HTTPS load balancer 在 port 443 開全網是設計本意。所以掃描的命中是候選不是判決。

多數工具支援用行內註解標記豁免。checkov 用 #checkov:skip=CKV_AWS_260:ALB 443 對外是設計本意，tfsec 用 #tfsec:ignore:aws-elb-alb-not-public。豁免的紀律是：每個 skip 都要寫理由、要在 PR 裡可見。沒有理由的 skip 跟關掉整條規則沒有差別 — review 時看到無理由的 skip 應該當成跟看到裸 0.0.0.0/0 一樣的警報。

把例外顯式化、留下為什麼豁免的紀錄，比關掉整條規則安全。隨時間累積的 skip 也要定期盤點：某個當初合理的例外，在架構演進後可能已經不再合理。

Atlantis 與 GitHub Actions：自動化 plan 與 apply

把上述流程自動化，需要一個能監聽 PR 事件、在對的時機跑 plan 與 apply 的執行層。兩種常見做法是直接用 CI 平台（如 GitHub Actions）寫 workflow，或用 Atlantis 這類專為 Terraform PR 流程設計的工具。

Atlantis

Atlantis 是一個常駐服務，掛在 git 平台的 webhook 上。PR 開啟時它自動跑 plan 並把結果貼回 PR comment，reviewer approve 後在 PR 留言 atlantis apply，它才執行 apply 並回報結果。它的價值在於把「誰能 apply、apply 前要不要 approve、plan 結果在哪看」這些規則收斂成一致的、可設定的流程。

Atlantis 內建的 state lock 語意在多 PR 並行時特別有用：當兩個 PR 都改到同一個 Terraform project，第二個 PR 的 plan 會被 lock 擋住，直到第一個 apply 完成或 PR 關閉。這避免了兩個 PR 各自拿到的 plan 基於不同的 state 快照、apply 時互相覆蓋的問題。用 GitHub Actions 要自己實作這個 lock 邏輯（通常靠 Terraform 自己的 state lock + workflow concurrency group），複雜度高得多。

Atlantis 的代價是它本身是一個要部署、要升級、要保護的常駐服務 — 它持有對雲端的寫入權限，所以它的部署環境必須嚴格控制存取。

GitHub Actions

GitHub Actions workflow 的優點是不必額外維運服務、跟既有 CI 共用同一套 runner。缺點是 apply 的 gating 邏輯要自己用 workflow 條件拼出來。一個完整的 workflow 通常分成兩個 job：PR 觸發 plan job（跑 fmt / validate / scan / plan、把結果貼回 PR），合併到 main 才觸發 apply job。

無論哪種執行層，自動化的 apply 都需要對雲端的寫入權限，而這個權限怎麼來是整條管線的安全根基。這裡正是模組二：身分與憑證地基鋪設的 OIDC 兌現的地方 — 管線不該存放長期的 access key，而是在 runner 執行時用 OIDC 向雲端換取短期 token。

 1# 合併到主幹後，用 OIDC 換短期憑證再 apply（呼應模組二）
 2jobs:
 3  apply:
 4    if: github.ref == 'refs/heads/main'
 5    runs-on: ubuntu-latest
 6    permissions:
 7      id-token: write   # 允許 runner 取得 OIDC token
 8      contents: read
 9    steps:
10      - uses: actions/checkout@v4
11      - uses: aws-actions/configure-aws-credentials@v4
12        with:
13          role-to-assume: arn:aws:iam::123456789012:role/infra-apply
14          aws-region: ap-northeast-1
15      - uses: hashicorp/setup-terraform@v3
16      - run: terraform init
17      - run: terraform apply -auto-approve

選型判準

判讀自動 apply 的邊界：對會觸發資源重建或刪除的高風險 plan，多數團隊會保留人工 apply 的關卡（Atlantis 的手動 atlantis apply、或 workflow 加 environment protection rule 要人按確認），不讓這類變更在合併瞬間無人看管地執行。自動化的目的是消除重複勞動與人為遺漏，不是把判斷也一起省掉。

知識留在 code，而不是留在個人腦中

走完整套 PR 流程後，infra 的真正收穫是知識從個人的記憶移到了 repo 裡。每一次「為什麼這個 security group 開這個埠」「為什麼這台機器選這個 instance type」的決策，都以 code + PR 描述 + review 討論的形式留下，新人讀 repo 就能還原當初的判斷，不必去問那個「只有他懂 infra」的人。基礎設施可被閱讀，等於它可被交接。PR 流程上線後，管理層可以從 repo 的 PR merge 歷史與 plan comment 確認所有 infra 變更都經過提案與審查——這本身就是稽核要求的變更紀錄證據，不需要額外產出。

git revert 的能力與邊界

可 revert 是 PR 流程最直接的兌現。當某次變更引發問題，回退手段是 git revert 那個 commit 再走一次 PR 流程，讓基礎設施回到變更前的設定 — 跟回退一段壞掉的程式碼是同一個動作。對照手動操作的舊狀態：回退靠的是當事人記得自己改了什麼、手動在 Console 改回去，記錯或人不在就無從回退。把變更歷史留在 git，回退就從「依賴某人的記憶」變成「依賴版本紀錄」。

這份 revert 能力的邊界要講清楚。revert code 救得回的是「設定」，救不回已經被銷毀的狀態與資料：

• revert 掉一個刪除 RDS 的 commit，只是讓設定回到「該資源應該存在」。apply 時 Terraform 會試圖建一個新的空資料庫 — 但被刪掉的資料庫裡的資料不會跟著回來。
• rename 或 replace 類的變更 revert 後，可能再觸發一次資源重建 — 因為 identifier 又改回去了，而 identifier 是 immutable 屬性。
• apply 到一半失敗的 state 不能直接 revert code 修復，得先處理 state 與雲端現實的不一致。

stateful 變更的真正回退仍然靠備份與快照，這正是模組五：核心服務上 IaC stateful 處理與模組八：治理好習慣 secret / state 保護要顧的事。把 git revert 當「設定層回退」就誠實，把它當「資料層回退」就會在事故裡踩空。

知識共享的判讀訊號

判讀一個團隊是否確實把知識留在 code 的訊號：當主要負責 infra 的人請假，其他人能不能只靠讀 repo 就理解現狀並安全地改一個小設定。如果答案是「得等他回來」，那不論工具鏈多完整，知識還在個人腦中，PR 流程只是形式。這個訊號比任何工具設定都更能反映 infra 的成熟度。

讓知識真正從個人腦中搬進 repo 的方式，除了 PR 流程本身，還需要組織層的配合 — 刻意的 review 輪替、on-call 輪值、配對操作。這條路線在模組九：怎麼把 infra 推動起來展開到組織層。本章解決的是技術機制 — code 留得住知識；模組九解決的是怎麼讓團隊實際願意走這套流程、把知識交出來。

跨分類引用

• → CI/CD 教學：infra 管線用的就是這套驗證 / 發布 gate，plan / apply 對應 build / deploy 階段
• → 模組二：身分與憑證地基：管線用 OIDC 取得 apply 權限，本章是該章 OIDC 設計的回報兌現處
• → 模組三：網路地基：security group 收斂原則，本章用 tfsec / checkov 在 CI 攔下寫錯的全開規則
• → 模組五：核心服務上 IaC：stateful 資源的保護策略，git revert 救不回資料層
• → 模組八：治理好習慣：secret / state 保護
• → 模組九：怎麼把 infra 推動起來：本章把知識留在 code 的技術機制，在該章展開成組織層的採用與知識共享
• → backend 模組七：資安與資料保護：S3 公開、敏感埠全開這類掃描攔截的反模式，對應的資料保護原則
• → 團隊權限分級：權限變更走 PR 流程，讓 policy 調整有審查紀錄
• → 職務交接設計：PR 歷史是交接時的知識載體
• → Terraform CI Pipeline 設定指南：GitHub Actions 完整 workflow
• → checkov 與 tfsec 規則配置：規則選擇、豁免管理、CI 整合

IaC 工具分兩條路線：宣告式 DSL（Terraform / OpenTofu，用 HCL 描述資源）與程式語言（AWS CDK / Pulumi，用 TypeScript / Python / Go 生成資源）。兩者都能達成「用程式碼描述、由工具收斂」的目標，差別在閱讀門檻與抽象能力。

概念位置

IaC 是 infra 系列的根概念，貫穿所有模組。成熟度階梯的第二階（宣告式 IaC）是 IaC 正式生效的起點，第三階（環境分離）和第四階（PR 流程治理）都建立在 IaC 之上。沒有 IaC，後續所有模組的能力都無法落地。

可觀察訊號

需要 IaC 的訊號是規模與協作的函數：環境數量超過一套、多人同時改資源、環境事故頻率上升、外部稽核要求變更紀錄。詳見模組負一：該開始導入 IaC 的訊號。

設計責任

採用 IaC 時要決定的核心問題：

• 工具選型：宣告式 DSL vs 程式語言，取捨在審查透明度 vs 抽象複用能力
• State 的存放：remote backend 的選擇與保護
• Console 唯讀紀律：所有寫入操作回到程式碼，Console 只作觀察
• 納管範圍：哪些資源先進 IaC、哪些暫時留在手動

鄰卡

• State — IaC 工具追蹤現實的記憶機制
• Drift — state 與現實不一致時的狀態
• 環境分離 — 同一份 IaC 描述套用到多環境

Tagging 規範：查帳與清資源的依據

Tag 是貼在每個資源上的結構化標籤，承擔「讓資源能被機器查詢與分群」的責任。沒有 tag 的資源在 console 裡只剩一個隨機後綴的名字，人能勉強認得幾個，但一旦數量過百，任何「列出所有 staging 的資源」「算出 team-a 這個月花多少」的問題都無法用查詢回答，只能逐筆翻。Tag 把這些問題從人工考古變成一行 filter。

最小 tag 集合

值得從第一天就強制的最小 tag 集合是三個維度，各自回答一個治理問題：

env 是清資源時的安全護欄。回收動作最大的恐懼是誤刪生產資源。當每個資源都標了 env，「列出所有 env=dev 且 30 天無流量的資源」就是一條可以放心執行的清理查詢，而 env=prod 的資源自動被排除在批次刪除之外。沒有這個 tag，任何自動化清理都因為怕誤傷而不敢落地，最後退回人工逐筆確認，於是根本沒人去清。

owner 解決資源孤兒化。服務出狀況、或是看到一個用途不明的資源時，第一個問題是「這誰的」。標了 owner，告警可以自動路由、清理前可以自動通知認領；沒標，這個資源就停在「沒人敢動、因為不知道砍了會不會弄壞什麼」的狀態，永久占用配額與費用。團隊命名比個人名好 — 人會離職，團隊邊界相對穩定。

cost-center 是成本歸屬的地基，把帳單從「一筆公共支出」拆成「每個團隊各自負責的花費」。這個維度的後續應用在成本可見性與最小可行治理節奏展開。

附加 tag 的合理時機

三個必填之外，隨著團隊規模增長，幾個常見的附加維度會自然浮現：

managed-by = terraform 搭配 env，可以快速找出「不在 IaC 管理下的生產資源」 — 這些就是 Console 唯讀紀律（模組一）鬆動的痕跡。附加 tag 不需要一次規劃完，但一旦加入就要跟必填 tag 一起走自動護欄。

用 IaC 自動標記

Tag 必須在資源建立時就由 IaC 寫進去，而不是事後補。Terraform 的 default_tags 讓一個 provider 區塊內的所有資源自動繼承一組 tag，避免逐個資源手動標、也避免漏標：

 1provider "aws" {
 2  region = "ap-northeast-1"
 3
 4  default_tags {
 5    tags = {
 6      env         = var.env
 7      owner       = var.team
 8      cost-center = var.cost_center
 9      managed-by  = "terraform"
10    }
11  }
12}

用 var 取代寫死的值，讓同一套 provider 設定跨環境複用 — 每個環境的 terraform.tfvars 填入自己的值。這和模組四：環境分離與模組化的參數化設計一致。

個別資源若需要額外 tag（例如 ttl），在資源自身的 tags block 裡寫，它會跟 default_tags 合併，不需要重複寫環境層的三個必填。兩者有相同 key 時資源層優先，所以某個特殊資源要覆蓋 owner 也行。

事後補 tag 是個會無限拖延的工作，因為它不影響任何功能、沒有 deadline、永遠排在 backlog 最後。

Tag 合規護欄

判讀訊號很簡單：定期跑一條「列出缺少必填 tag 的資源」的查詢，數字若持續成長，代表有人繞過 IaC 手動開資源 — 這既是 tag 問題，也是模組一「Console 唯讀」紀律鬆動的徵兆。

1# 列出沒有 env tag 的 EC2 instance
2aws resourcegroupstaggingapi get-resources \
3  --resource-type-filters ec2:instance \
4  --tag-filters Key=env,Values= \
5  --query 'ResourceTagMappingList[].ResourceARN'

手動查詢只是起點。更可靠的做法是用策略引擎在建立期或 PR 階段就擋住不合規的資源：

• AWS Tag Policy（Organizations 層級）：定義必填 tag 與允許值的枚舉，不符合就阻止建立。適合整個組織統一推行。
• OPA / Sentinel（CI / PR 層級）：在 terraform plan 之後、apply 之前檢查 plan 輸出，缺 tag 就讓 CI fail。適合跟模組七：infra 走 PR 流程整合。
• checkov / tfsec 自訂規則：靜態掃描 HCL，在 code push 時就擋。成本最低但只擋得住 IaC 管理的資源。

三層護欄互補：靜態掃描擋寫 code 時的遺漏、plan 檢查擋執行前的偏差、tag policy 擋繞過 IaC 的手動操作。早期只做一層也有價值，三層都做時覆蓋最完整。定期跑 tag 覆蓋率報告（缺少必填 tag 的資源數 / 總資源數）可以作為治理進度的量化指標。覆蓋率從 40% 到 90% 的趨勢比單次數字更有意義，適合放進月報讓管理層追蹤。

Tagging 在合規驅動的基礎設施中還有另一層用途：用 tag 標記資料的地理歸屬，讓合規查詢可以機器化。Hard Rock Digital 的運動博彩平台受美國 Wire Act 約束，不同州的投注資料必須留在州內。它們用 CockroachDB 跨 AWS Outposts 部署，每個 Outpost 的資源用地理 tag 標記歸屬州，合規稽核時用 tag 過濾而非逐台盤查。這個案例的 infra 教訓是：tag 的維度設計在受地理或法規約束的服務中，要提前納入合規需求的維度，而非只做成本和歸屬。詳見 9.C41 Hard Rock Digital：Wire Act 合規。

Secrets 不進 code：機密值的儲存與引用

機密值 — 資料庫密碼、第三方 API key、簽章用的私鑰 — 要存在專用的密鑰管理服務裡，而 code 與 IaC 只持有指向它的參照，不持有值本身。這條規則承擔的責任是把「機密外洩的爆炸半徑」與「程式碼的散布範圍」脫鉤：一旦密碼寫進 repo，它就跟著每一次 clone、每一份 CI 快取、每一個 fork 擴散，輪替時無法保證所有副本都更新，git 歷史更是會把它永久留存，即使後來刪掉那一行。

密鑰管理服務的選型

密鑰管理服務提供的是一個有存取控制、有審計紀錄、可輪替的集中儲存。值放在這裡，誰讀過、什麼時候讀的都有 log，輪替時只改一個地方，所有引用方下次讀取就拿到新值。

選型看的是團隊已有的生態與輪替需求。對已在 AWS 上的團隊，Secrets Manager 適合需要自動輪替的資料庫密碼，SSM Parameter Store 適合其餘設定值（免費額度通常夠用）。跨雲或對動態 secret 有需求的團隊會走 Vault。

IaC 怎麼引用 secret

IaC 應該存的是密鑰的 ARN（或等價的資源識別碼）與「在執行期去讀它」的指令，而不是密鑰的明文：

1data "aws_secretsmanager_secret_version" "db" {
2  secret_id = "prod/payments/db-password"
3}
4
5resource "aws_db_instance" "payments" {
6  password = data.aws_secretsmanager_secret_version.db.secret_string
7  # ...
8}

另一種做法是讓 IaC 只建立 secret 的「容器」（空的 Secrets Manager entry），值由人工或自動化流程在 IaC 之外寫入。這樣 state 裡只有 secret 的 metadata（ARN、名稱、版本 ID），完全不碰明文。適合密碼由安全團隊管理、IaC 只負責「確保 secret 存在且有正確的存取策略」的分工模式。

1resource "aws_secretsmanager_secret" "db" {
2  name = "${var.env}/payments/db-password"
3}
4
5# 值不由 Terraform 管理 — 在 Console 或 CLI 手動設定
6# secret version 生命週期在 IaC 之外

state 裡的機密邊界

Terraform 即使從 Secrets Manager 讀值，那個值仍然會以明文落進 state 檔。這是一個常被忽略的邊界。「不進 code」只是第一道，state 後端的加密與存取控制（模組一的 state 地基）是同等重要的第二道 — 否則密鑰只是從 repo 搬到了一個沒鎖好的 state bucket。

State 的保護措施是一道複合防線：

• S3 bucket 開 encrypt = true（AES-256 或 KMS）
• Bucket 的 IAM policy 只允許跑 apply 的 role 讀寫
• Bucket 開 versioning，誤寫或損壞時可以回捲
• DynamoDB lock table 防止並行 apply 覆蓋

這些措施在模組一的 remote state backend 段已經詳述，這裡提醒的是：state 的安全程度決定了 secret 引用策略的上限。state 沒鎖好時，把 secret 值拉進 state 的做法等於把密碼從 repo 搬到了另一個不設防的地方。

Secret 掃描

判讀訊號：定期用 secret 掃描工具掃 repo 與 CI log，任何命中都當成需要輪替的外洩事件處理，而不是刪掉那行就算了 — 因為 git 歷史與既有 clone 已經保不住了。

1# gitleaks：掃描整個 git 歷史
2gitleaks detect --source . --report-format json --report-path gitleaks-report.json
3
4# trufflehog：掃描 git、filesystem、CI
5trufflehog git file://. --json

兩個工具覆蓋面不同（gitleaks 用 regex pattern、trufflehog 用 detector + entropy），搭配用覆蓋更完整。放進 CI pipeline 讓每個 PR 自動掃，比人工定期跑更可靠。命中後的處理流程：先輪替被洩露的 secret，再從 repo 清除（git filter-repo），最後通知所有可能受影響的服務。

Secret 命名規範

機密的命名也值得約定。用 {env}/{service}/{purpose} 這類有結構的路徑（如 prod/payments/db-password），讓存取策略可以用前綴授權：

1# 給 payments service 的 role 只能讀自己的 secret
2data "aws_iam_policy_document" "payments_secrets" {
3  statement {
4    actions   = ["secretsmanager:GetSecretValue"]
5    resources = ["arn:aws:secretsmanager:*:*:secret:${var.env}/payments/*"]
6  }
7}

前綴授權的好處是新增 secret 時不需要改 IAM policy — 只要命名落在同一個前綴下，存取權限自動繼承。跟模組二的最小權限設計一致：service A 的 role 只看得到 payments/*，看不到 auth/*，即使它們存在同一個帳號的 Secrets Manager 裡。

跨分類引用

• → 模組一：最小可行 IaC：state 後端的加密與存取控制是 secret 引用策略的安全地基
• → 模組二：身分與憑證地基：誰能讀哪些 secret 的 IAM 權限設計
• → 模組四：環境分離與模組化：tag 的環境值與 module 參數化的對齊
• → 模組七：infra 走 PR 流程：tag 合規與 secret 掃描整合進 CI pipeline
• → backend 模組七：資安與資料保護：密鑰生命週期、輪替策略與資料保護的完整討論

Phase 1：差異評估

差異評估的產出是一份 change manifest——列出所有已知的新舊差異、每項的風險等級、以及需要的應對措施。這份清單是後續所有階段的依據：平行環境要驗證清單上的每一項、切換策略要先處理高風險項、退役前要確認清單上的所有相容性問題都已解決。

差異的三個維度

第一個維度是目標本身的變化。版本升級要看 changelog、breaking changes list、deprecated features list。平台遷移要看兩個平台的功能差異（共享主機沒有的 cron 彈性、VPS 有的 SSH 存取）。資料庫升級要看 SQL 語法差異、預設行為變更（如 MySQL 8.0 的 caching_sha2_password 預設認證方式）。

第二個維度是依賴關係。升級 PHP 版本時，所有 Composer 套件都可能受影響；升級 MySQL 時，ORM 的 SQL 生成可能不相容；遷移平台時，原本靠主機面板設定的 cron job 要改用系統 crontab 或雲端排程。依賴關係沒列完整，平行環境的測試就會漏掉受影響的元件。

第三個維度是過渡期的雙版本相容性。升級不是瞬間完成的——在切換的過程中，系統的某些部分跑新版本、某些部分跑舊版本。這段期間兩個版本必須能共存：資料庫的 schema 要同時相容新舊版本的程式碼、API 的回應格式要讓新舊版本的客戶端都能處理、session 格式要能跨版本延續。

風險分級

每一項差異分級後，高風險和阻塞項決定升級的可行性與時程。阻塞項超過團隊能處理的量時，升級可能需要拆成多個階段（先升到中間版本、再升到目標版本）或延後。

時程與管理層報告

差異評估的時程通常佔整個升級的 20-30%——看起來「還沒開始做」但這段時間的產出（change manifest）決定了後面所有階段的範圍。向管理層報告時用 change manifest 的風險分級表：「共 N 項差異，其中 X 項低風險、Y 項中風險、Z 項高風險、W 項阻塞。中高風險項的處理估計 M 天，阻塞項的替代方案評估需要額外 K 天。」

Phase 2：平行環境驗證

平行環境驗證的責任是用事實證明「新版本在跟 production 相同的條件下能正常運作」。它的產出是一份驗證報告——每一項 change manifest 上的差異都標上「已驗證通過 / 有問題待修 / 不影響」。沒有這份報告就切換，等於在賭新版本會正常。

建立平行環境

平行環境跟 production 越相似，驗證結果越可信。理想狀態是完全複製 production 的架構（同規格、同設定、同網路拓撲），只差目標元件的版本不同。成本限制下的折衷是用縮小版（較小的 instance、較少的資料量），但關鍵設定（PHP 模組、MySQL 參數、安全設定）必須跟 production 一致。

資料的處理要特別注意。用 production 的資料副本驗證最可靠（能觸發真實的邊界狀況），但如果資料含 PII，需要先脫敏處理。另一個選項是用 staging 環境的資料，但要確認 staging 的 schema 跟 production 一致——schema drift 會讓驗證結果失真。

驗證清單

平行期的時間長度

平行環境跑多久才能切換？取決於業務週期。如果系統有月結、季結的批次處理，平行環境至少要跑過一次完整週期。電商系統要跑過至少一個促銷活動。沒有明顯週期的系統，一到兩週的平行驗證通常足夠發現主要問題。

Phase 3：分批切換

分批切換的核心原則是不一次切 100%——先把最低風險的流量導到新環境，觀察一段時間確認正常，再逐步增加比例。

切換策略

共享主機通常只能用維護窗口策略——沒有 load balancer 做流量分配、沒有 DNS 權重可調。維護窗口的關鍵是時間規劃：備份（15 分鐘）→ 切換（30 分鐘）→ 驗證（30 分鐘）→ 恢復或回退（15 分鐘），在窗口內必須完成全部步驟，超時就回退。

切換期間的監控

切換開始後要密切觀察的指標：

• 錯誤率：5xx / 4xx 比例相對於切換前的基線
• 回應時間：p50 和 p99 相對於基線
• 業務指標：轉換率、訂單數、付款成功率（如果適用）
• 外部整合：第三方 callback 是否正常

回退觸發條件

在切換前就定義好回退條件，避免事故發生時還要開會決定要不要退：

• 錯誤率超過基線的 2 倍持續 5 分鐘 → 回退
• 核心業務流程失敗（登入、結帳、金流） → 立刻回退
• 回應時間超過基線的 3 倍持續 10 分鐘 → 回退

回退不是失敗——它是風險控制機制的正常運作。回退後排查問題、修正、重新走 Phase 2 驗證、再嘗試切換。

切換的通知

Phase 4：退役舊環境

切換完成後不要立刻刪掉舊環境——保留 1-2 週的冷備。這段時間處理長尾問題：DNS 快取還沒更新的客戶端、排程任務還指向舊 endpoint 的外部系統、舊環境上可能還有未遷移的資料。

退役前的檢查

• 舊環境的存取 log 是否歸零？（有流量代表還有東西指向它）
• 所有 cron job 是否都已在新環境運行？
• 外部系統的 webhook / callback URL 是否都已更新？
• 舊環境上有沒有需要歸檔的資料？（log、上傳檔案、備份快照）

退役步驟

1. 停止舊環境的應用服務（但不刪除）
2. 觀察 1 週——如果有問題可以快速重啟
3. 匯出需要保留的資料（log、uploaded files）
4. 刪除舊環境的運算資源（VM、容器）
5. 保留舊環境的最後一份備份 30 天，作為最後的保險
6. 清理舊環境的 DNS 記錄、SSL 憑證、IAM 角色

貫穿全程的升級紀律

一次只升一個東西

同時升級 PHP 版本 + 遷移到新主機 + 重構資料庫 schema，出問題時無法判斷是哪個變更造成的。每次升級只改一個主要元件，穩定後再升下一個。如果業務壓力要求一次完成，至少在 Phase 2 的驗證環境裡逐一引入、逐一確認。

每個階段轉換前備份

Phase 1 結束前備份 production 現況、Phase 3 切換前備份、Phase 4 退役前備份。三份備份各自獨立、各自有還原驗證。備份不只是「做了」——要實際測試過還原，確認備份的完整性。

記錄每一步

每個升級操作記錄在 repo 的 changelog 裡：什麼時間、誰做的、改了什麼、觀察到什麼結果。升級出問題時，changelog 是回溯「上一步做了什麼」的唯一依據。

在平行階段就練習回退

不要等到 Phase 3 切換時才第一次嘗試回退。在 Phase 2 的平行環境裡，刻意從新版本切回舊版本一次，確認回退路徑能走通、回退後服務能正常恢復。回退的演練跟升級的驗證同等重要。

跨分類引用

• → 接手維運：接手後穩定維運的下一步常是升級
• → 模組五：核心服務上 IaC：stateful 資源（RDS、S3）的升級涉及特殊的備份與切換策略
• → 模組八：治理好習慣：升級期間的變更紀錄對齊治理紀律
• → 模組七：infra 走 PR 流程：升級涉及的 IaC 變更走 PR review

判讀自己是否可控

可控的手動環境能在五分鐘內回答以下問題：

1. production 有哪些對外開放的 port？
2. 上週誰動過資料庫參數，動了什麼？
3. 刪掉某台機器會不會連帶弄壞別的東西？
4. 現在用了幾把長期 access key，每把用在哪裡？
5. 有沒有一份清單能對照 Console 上的資源，確認沒有漏掉的？

五題都能答的團隊不多，目標也不是一次全通。辨識出哪些區域不可見，按傷害代價從高到低逐一收斂，就是這一章的路線。

護欄先上在回退代價最高的操作

手動環境沒有 IaC 的 plan / diff 當預檢，人為操作直接生效。護欄的優先級看的是失誤的回退代價，不是操作頻率。回退代價最高的三類操作各自有最低成本的防線。

長期憑證外洩

長期 access key 一旦外流，攻擊者拿到的是不會過期的權限。回退代價高的原因不只是撤銷這把 key 本身，而是要找出所有使用它的地方同步更換 — 而「所有使用它的地方」在手動環境裡幾乎沒有完整清單。一把用了半年的 key 可能已經被複製到 CI 環境變數、某個同事的測試腳本、一個早已被遺忘但還在跑的 cron job 裡。

最低成本的護欄分三步。第一步是盤點：列出帳號裡所有長期 access key，記下建立時間、上次使用時間與對應用途。

1aws iam generate-credential-report
2aws iam get-credential-report --output text --query Content | base64 -d

第二步是替換路徑。對人類操作者，改用會過期的登入工作階段（如 AWS IAM Identity Center 的臨時憑證，幾小時後自動失效）。對跑在雲上的自動化（EC2 上的腳本、ECS task），改用平台原生的角色綁定 — instance profile 或 task role 會自動輪替短期憑證，程式碼不需要存任何 key。對跑在雲外的 CI/CD（如 GitHub Actions），改用 OIDC 聯合（見模組二：身分與憑證地基）。

第三步是輪替紀律。把還在用的長期 key 設定定期輪替提醒（60 天或 90 天，對齊 AWS IAM credential report 的建議週期），每次輪替時問自己：這把 key 能不能這次就換成臨時憑證，讓它成為最後一次輪替？

刪除 production 資源

在 Console 選中一個 security group 按刪除，平台可能只問「確定嗎？」就直接執行，不會告訴你有三個 EC2 instance 正在引用這個 group。EBS volume 被刪除後，上面的資料就不存在了 — 除非之前有做 snapshot，而手動環境裡有沒有做 snapshot 通常取決於某個人的記憶。

對承載狀態的資源，最低成本的護欄是開啟平台的刪除保護：

1aws rds modify-db-instance \
2  --db-instance-identifier payments-prod \
3  --deletion-protection \
4  --apply-immediately
5
6aws ec2 modify-instance-attribute \
7  --instance-id i-0abc123 \
8  --disable-api-termination

RDS 有 deletion_protection，EC2 有 termination_protection，S3 bucket 可以開 MFA delete。這些機制把「一鍵刪除」變成「先關保護再刪除」兩步操作，擋不住蓄意刪除，但能擋住手滑跟批次操作的誤傷。

刪除保護之外，備份是另一道防線。手動環境裡至少確認 RDS 的自動備份是開著的（預設保留 7 天），以及 S3 bucket 的 versioning 是開著的。S3 bucket 的 versioning 預設是關的，一個沒開 versioning 的 bucket，覆寫或刪除物件後就回不去了。

網路規則的大改

手動調整 VPC 路由、subnet 關聯的 route table、或 security group 的入站規則，影響範圍跨越多個服務，而且在手動環境裡沒有版本控制可以 diff 改了什麼。一條路由改錯，某些 private subnet 的服務可能瞬間失去出站能力。

最低成本的護欄是「改之前先把現況存下來」：

1aws ec2 describe-security-groups \
2  --group-ids sg-0abc123 \
3  --output json > sg-backup-$(date +%Y%m%d).json

用 CLI 把當前的 security group 規則、route table 設定匯出一份 JSON。改完後如果出問題，這份 JSON 就是回退的依據。這不是自動回退 — 手動環境沒有那個能力 — 但至少讓「改回去」有個明確的目標狀態。網路地基的系統性設計在模組三：網路地基展開。

該先做什麼

這三類護欄的共同判準是：護欄成本低（幾條 CLI 指令或 Console 設定）、失誤代價高（憑證外洩、資料遺失、服務中斷）。判讀某個資源該不該現在就加護欄，問自己一個問題：「這個資源出事的回退時間是分鐘級、小時級、還是不可回退？」不可回退的（資料刪除、key 外洩）優先加；分鐘級可回退的（重啟一個 stateless service）可以排後面。

讓變更留下痕跡

變更留痕的責任是讓「誰、在什麼時候、改了什麼、為什麼」事後可追溯。IaC 的 git history 天然提供這件事，手動環境得靠人為紀律補上。

人工變更日誌

最低限度是一份變更日誌，可以只是 repo 裡的一個 markdown 檔或團隊共用文件。一條記錄至少包含四個欄位：

1## 2026-06-20
2
3- **操作者**：alice
4- **資源**：sg-0abc123 (payments-api-prod)
5- **變更**：新增 ingress rule, port 8080 from 10.0.0.0/16
6- **原因**：內部監控服務需要存取 health check endpoint
7- **回退方式**：刪除該 ingress rule

格式不需要精美，需要的是「每次都寫」。常見陷阱是只在「大改動」時才記錄，結果真正出事的往往是某次以為無關緊要的小調整 — 改了一個 parameter group 的值、調了一條路由的目標、把某個 instance 的 security group 換了一個。判準簡化成一句：只要這個操作別人事後可能需要知道，就記。

平台稽核日誌

和人工日誌互補的是平台的稽核日誌（如 AWS CloudTrail、GCP Audit Log）。稽核日誌自動記錄 API 層級「發生了什麼」— 某個 IAM user 在某個時間對某個資源呼叫了哪個 API — 不依賴人為紀律、也不會漏。但它只記錄事實，不記錄意圖。它告訴你 security group 在幾點被改，卻不告訴你改的原因。人寫的變更日誌補上的正是「為什麼」這一段。

1aws cloudtrail describe-trails \
2  --query 'trailList[].{Name:Name,S3Bucket:S3BucketName}'
3
4aws cloudtrail lookup-events \
5  --lookup-attributes AttributeKey=EventName,AttributeValue=AuthorizeSecurityGroupIngress \
6  --max-items 10

CloudTrail 在 AWS 帳號裡預設開啟 management event 的 90 天查閱。手動環境裡至少確認 management event 的 trail 存在且在寫入 — 這是事後回推「到底誰動了什麼」的最後防線。兩者一起，事故排查時才能從「哪裡變了」一路追到「為什麼改、能不能安全回退」。

命名與 tagging 從手動階段就開始

命名規範與資源標籤讓每個資源自帶「我是誰、屬於哪個服務、誰負責、哪個環境」的身分資訊。手動點出來的資源若名稱是 test-2、new-db-final、temp-sg，日後納管時得靠人逐一辨認哪個還在用、屬於哪條業務線，考古成本遠高於當初多打幾個字。

命名規範

從手動階段就固定一套命名規則，讓名稱本身攜帶足夠的上下文。一個實用的格式是 {service}-{component}-{env}：

命名不需要完美或涵蓋所有維度，需要的是一致。同類資源都用同一套格式，人眼掃一頁 Console 就能分辨「這個屬於 payments 的 prod」跟「這個屬於 auth 的 dev」。不一致的命名（有些用底線、有些用連字號、有些帶 env 有些不帶）會在日後盤點時讓每個資源都變成需要考古的謎題。

最小 tag 集合

標籤至少包含三個維度：

手動階段的 tag 靠人工填。在 Console 建資源時順手加 tag 幾乎零成本 — 多打三行字而已。但如果沒有約定「哪些 tag 是必填」，多數人會跳過。最低限度的紀律是：在團隊文件裡寫下「建任何資源前先填這三個 tag」，並在每次盤點時檢查有沒有漏標的資源。

這套規則在導入 IaC 後直接升級成 Terraform 的 default_tags — 自動套用、不靠人記（見模組八：治理好習慣）。先在手動階段建立習慣，導入 IaC 時只是換一個強制機制，而不是從零學起一套分類法。

盤點現有資源作為納管輸入

資源盤點把「現實長什麼樣」寫成一份清單，它是日後納管的直接輸入。接手別人建的環境時，盤點的範圍和方法更完整的版本見接手維運模組。手動環境裡最難管理的是未標記的閒置資源 — 測試用的 EC2、實驗用的 RDS — 持續計費但沒有標籤，無法用查詢系統性找出，也無法確認是否仍有服務依賴。

盤點方法

按資源類型分批拉，每批存一份 JSON 或 CSV 進 repo：

 1aws ec2 describe-instances \
 2  --query 'Reservations[].Instances[].[InstanceId,InstanceType,State.Name,Tags[?Key==`Name`].Value|[0],Tags[?Key==`env`].Value|[0]]' \
 3  --output table
 4
 5aws rds describe-db-instances \
 6  --query 'DBInstances[].[DBInstanceIdentifier,Engine,DBInstanceClass,MultiAZ,DeletionProtection]' \
 7  --output table
 8
 9aws ec2 describe-security-groups \
10  --query 'SecurityGroups[].[GroupId,GroupName,IpPermissions]' \
11  --output json > security-groups-$(date +%Y%m%d).json
12
13aws s3api list-buckets --query 'Buckets[].Name'

盤點後的三件事

這份清單同時服務三個目的。

當下的安全盤查：security group 清單裡有沒有不該開的對外 port？有沒有 EC2 直接掛著公網 IP 卻不是 load balancer？用 0.0.0.0/0 搜一遍 security group 的輸出，命中的每一條都要能說出「這個全開是故意的、理由是什麼」。

未來 IaC import 的範圍界定：哪些資源該先 import。判準是「改動頻率」與「改錯代價」的乘積 — 頻繁改動且改錯代價高的（security group、IAM role）先排進來，很少動的（一個已經穩定的 S3 bucket）可以排後面。

成熟度評估的事實基礎：成熟度階梯的定位（見模組零：infra 是什麼）需要知道「全手動到底有多少資源、分布在幾個帳號、跨幾個 region」，這份清單就是評估的輸入。

盤點的節奏

第一次盤點最花時間，因為很多資源的用途需要考古。之後每月或每季重跑一次比對差異 — 重點是看「上次到這次之間長出了什麼新資源」。如果每次比對都發現大量未標記的新資源，這本身就是一個訊號：手動操作的可見性不足，該考慮導入 IaC 了。

資源與信任不足下的高槓桿取捨

當時間、人力或上層信任都不足，無法一次把上面每件事做齊時，取捨原則是先做「失誤代價高且護欄成本低」的少數幾件：

長期憑證盤點與刪除保護兩者加起來的實施時間可能不到一小時。命名與 tagging 的策略是「新的一律照規範、舊的等有餘力再補」，而不是停下來先整理全部存量。資源不足時怎麼跟上層談這些工作的優先級，在模組九：怎麼把 infra 推動起來展開。

該開始導入 IaC 的訊號

手動環境到了某些訊號出現時，繼續手動的邊際成本會超過導入 IaC 的一次性成本。訊號是規模與協作的函數，不是時間的函數 — 一個人運維一個簡單服務，手動可能撐很久；三個人同時動一個稍微複雜的環境，幾週內就會踩到手動的極限。

環境數量變多：當需要 dev、staging、production 三套幾乎一樣的環境，手動複製會在環境之間留下難以察覺的差異。某個人在 staging 加了一條 security group 規則，忘了在 prod 也加，結果 staging 測通了、prod 部署後服務連不上。IaC 用同一份程式碼複製環境，環境差異只存在於參數值。

多人同時動資源：一個人手動操作還能靠記憶維護，兩三個人並行時，沒有 plan / review 的手動變更會互相覆蓋。A 改了一個設定解了自己的問題，B 幾天後改了另一個設定把 A 的修正覆蓋掉，事故原因得靠翻 CloudTrail 才查得到。

環境爆炸頻率上升：如果「改一個設定結果弄壞別的東西」這類事故開始每月發生，代表手動環境的隱性依賴已經超過人腦能追蹤的上限。一個典型的隱性依賴：security group A 被 instance X 和 instance Y 同時引用，改 A 時只想著 X 的需求、忘了 Y 也依賴它，改完 Y 就斷了。

合規或稽核要求：外部稽核（SOC 2、ISO 27001）開始要求「列出所有對外暴露的服務」「提供存取權限的變更紀錄」「證明 production 環境的變更有經過審查」。手動環境回答這些問題時，每次都是一場考古工程。IaC 加上 PR 流程後，答案就在 repo 裡。

任一訊號穩定出現，就是把第一個資源納入 IaC 的起點 — 前面做的命名、tagging、資源盤點此時直接成為 import 的輸入。第一步怎麼跨進去在模組一：最小可行 IaC。

在訊號出現前過早導入 IaC 也有代價：單人、單環境、低變更頻率時，IaC 的學習與維護成本可能高於它省下的手動工 — 寫一份 HCL、配一個 state backend、設一條 pipeline 的固定成本，在只有三個資源的環境裡不一定划得來。這裡的判準是等訊號、不是趕進度。

跨分類引用

• → 接手維運：如果這個手動環境是接手來的，先走接手維運的盤點流程
• → 模組零：infra 是什麼：成熟度階梯上「全手動」這一階的定位
• → 模組一：最小可行 IaC：訊號出現後，第一步怎麼跨進 IaC
• → 模組二：身分與憑證地基：長期憑證護欄的系統性設計
• → 模組三：網路地基：手動階段網路大改的回退考量、之後的系統性設計
• → 模組八：治理好習慣：tagging 在成本歸因與批次操作的後續價值
• → 模組九：怎麼把 infra 推動起來：資源不足時怎麼跟上層談優先級

沒有同生命週期管理時，新服務上線後的監控覆蓋率取決於有沒有人記得手動建立 log group 和 alarm，而這個記憶在服務數量增長後會衰退。監控缺口在平時不被注意，在事故排查時才浮現 — 需要回溯「什麼時候開始劣化」時，可能發現劣化期間根本沒有對應的 metric 資料。

同生命週期的落地方式

可觀測性是基礎設施的一部分，它的建立、變更與銷毀要跟被監控的資源綁在同一個 apply 單位裡。一個 RDS 實例被 IaC 建立時，它的 log group、它的關鍵 metric alarm 應該在同一份 terraform plan 裡一起出現；這個資源被 destroy 時，對應的 alarm 也一起收掉。

落地方式是把監控宣告收進服務的 module。模組四（環境分離與模組化）談的模組化在這裡延伸成「每個服務模組自帶它的 observability 宣告」。一個 database module 內部除了 aws_db_instance，還包含它的 log group、CPU alarm、連線數 alarm：

 1# modules/database/monitoring.tf — 跟 database 資源同一個 module
 2resource "aws_cloudwatch_log_group" "db_slow_query" {
 3  name              = "/rds/${var.env}/${var.db_identifier}/slowquery"
 4  retention_in_days = var.log_retention_days
 5  kms_key_id        = var.log_kms_key_arn
 6}
 7
 8resource "aws_cloudwatch_metric_alarm" "db_cpu" {
 9  alarm_name          = "${var.env}-${var.db_identifier}-cpu-high"
10  comparison_operator = "GreaterThanThreshold"
11  evaluation_periods  = 3
12  metric_name         = "CPUUtilization"
13  namespace           = "AWS/RDS"
14  period              = 300
15  statistic           = "Average"
16  threshold           = 80
17  alarm_actions       = [var.oncall_sns_arn]
18
19  dimensions = {
20    DBInstanceIdentifier = aws_db_instance.primary.identifier
21  }
22}

這樣 terraform apply 建資料庫的同一刻，監控就存在；terraform destroy 砍資料庫時，孤兒 alarm 也一起清掉。新環境套用同一個 module 時，監控覆蓋率自動跟著資源走，不需要額外的人工記憶。

監控脫鉤造成的兩類漂移

把監控外掛在資源之外（用另一份 IaC、另一個 repo、或手動在 console 設定）會製造兩種方向相反的漂移，兩者的共同根因都是監控跟資源不在同一個 apply 單位裡。

漂移一：新資源沒有監控

service 透過 PR 加上去了，但 alarm 的建立依賴某人事後手動進 console 設定，或等另一個 repo 的 PR 跟上。於是有些 service 有 alarm、有些沒有，覆蓋率取決於「誰記得」。沒有 alarm 的 service 出事時，事故發現路徑從「告警 → 排查」退化成「客訴 → 排查」，反應時間從分鐘級退化到小時級。

用一條查詢就能看出這個漂移有多嚴重：列出所有 RDS instance，比對各自有沒有對應的 CloudWatch alarm。沒有 alarm 的 instance 就是漂移的活證據。

1# 列出所有 RDS instance，比對有沒有對應的 CloudWatch alarm
2aws rds describe-db-instances \
3  --query 'DBInstances[].DBInstanceIdentifier' --output text | tr '\t' '\n' | while read db; do
4  count=$(aws cloudwatch describe-alarms \
5    --alarm-name-prefix "${db}" --query 'MetricAlarms | length(@)')
6  echo "${db}: ${count} alarms"
7done

漂移二：死資源留下殘響

資源砍了但 alarm 還在，orphan alarm 對不存在的 target 持續報 INSUFFICIENT_DATA，跟有效 alarm 混在同一個通知頻道裡，降低告警的訊噪比。訊噪比低到一定程度後，有效的 INSUFFICIENT_DATA（某個服務停止送 metric）也被一起略過 — 告警疲勞讓 alarm 從保護機制退化成背景噪音。

漂移二的成本不只是注意力。殘留的 alarm 會佔用 CloudWatch alarm 的配額（每個帳號有配額上限），大量孤兒 alarm 累積後，新服務要加 alarm 可能需要先清理舊的 — 這在事故當下是最不該花時間的事。

修法是把 alarm 的生命週期綁進 module：資源 destroy 時 alarm 跟著 destroy，不需要另一個流程去「記得清理」。如果因為歷史原因已經有大量孤兒 alarm，可以用 alarm 的 StateValue 為 INSUFFICIENT_DATA 且持續超過 7 天作為清理候選的篩選條件。

log group 設計

Log group 是日誌的歸屬與保存單位，它要回答兩個治理問題：留多久（retention）、誰能讀（access control）。這兩個問題寫進 IaC 才能稽核，而非依賴 vendor 的隱性預設。

Retention：三方取捨

許多雲端服務在沒有明確宣告 log group 時會自動建一個、套上「永久保留」的預設值。永久保留的問題不是技術性的 — CloudWatch Logs 可以存到無限久 — 而是治理性的：日誌無限堆積、帳單緩慢長大，而沒有人做過「這條 log 該留多久」的顯式決定。

Retention 是成本、合規與除錯需求的三方取捨：

較合理的做法是按日誌類型分層：高頻、除錯用的 application log 設短 retention，稽核相關的 access log 按合規要求設長期保留，必要時再把冷資料用 subscription filter 歸檔到更便宜的物件儲存（S3 + Glacier）。把這些值寫進 IaC，讓「為什麼這條 log 留 90 天」是一個能在 PR 上被討論的決定，而非某人半年前在 console 點的一個數字。成本參考：CloudWatch Logs 的儲存費用約 $0.03/GB/月。一個每天產生 10GB log 的服務，30 天 retention 的月費約 $9，7 天約 $2。retention 天數的選擇是合規需求（留多久才合規）與儲存成本的直接取捨，可以按 log 類型分層設定。

觀測平台的帳單在規模化後容易超線性成長，而缺乏 per-team cost attribution 的環境只能靠全域砍 retention 或降 sampling 來控制成本，兩者都會傷害觀測品質。把 log retention 跟 cardinality budget 的決定從全域級拆到團隊級（用 tag 歸因），才能做到「該省的省、該留的留」。這個取捨在 4.C14 觀測平台成本治理 有多家企業的具體經驗。

 1resource "aws_cloudwatch_log_group" "api" {
 2  name              = "/app/${var.env}/api"
 3  retention_in_days = var.env == "prod" ? 30 : 7
 4  kms_key_id        = aws_kms_key.logs.arn
 5}
 6
 7resource "aws_cloudwatch_log_group" "audit" {
 8  name              = "/app/${var.env}/audit"
 9  retention_in_days = 365
10  kms_key_id        = aws_kms_key.logs.arn
11}

Dev 環境的 retention 可以大幅縮短（7 天甚至 3 天），因為它不承擔合規責任，存取量也低，帳單節省直接對應這個差值。

存取控制與加密

「誰能讀」是 retention 之外的另一半。Log 經常夾帶 PII（使用者信箱、IP）、token 或內部結構，讀取權限要跟模組二（身分與憑證地基）建立的 IAM 角色一起管。

常見陷阱是 log 在傳輸與儲存都加密了（kms_key_id 有設），卻對整個團隊開放讀取。加密保護的是靜態資料不被未授權存取，但如果整個開發團隊都有 logs:GetLogEvents 權限，加密形同虛設 — read 權限應該縮到值班與稽核需要的最小集合。

 1# 只允許 oncall role 讀取 prod log
 2data "aws_iam_policy_document" "log_read" {
 3  statement {
 4    actions   = ["logs:GetLogEvents", "logs:FilterLogEvents"]
 5    resources = [aws_cloudwatch_log_group.api.arn]
 6  }
 7}
 8
 9resource "aws_iam_role_policy" "oncall_log_read" {
10  role   = var.oncall_role_name
11  policy = data.aws_iam_policy_document.log_read.json
12}

應用層該怎麼決定哪些欄位根本不該進 log（例如在 logger 層做 PII masking），屬於資料保護的範圍，見 backend 模組七：資安與資料保護。

metric 與 alarm 設計

Metric 與 alarm 寫進 IaC，目的是讓「資源被建立的同時就帶著它的健康判準」。Alarm 是一份成文約定：哪條 metric、跨多長的評估窗口、超過什麼值要通知誰。把這份約定寫進 code，它就能被 review、被版本控制、被跨環境複用。

症狀型 vs 成因型告警

閾值設計是訊號與雜訊的取捨。告警可以分成兩類：症狀型（symptom-based）對應的是「使用者已經受影響」的指標 — 5xx 錯誤率、p99 延遲、佇列積壓。成因型（cause-based）對應的是「某個元件在劣化但使用者可能還沒感知」的指標 — CPU 使用率、記憶體使用率、磁碟 IOPS。

收益最高的起點是：症狀型設 alarm 並綁通知，成因型留在 dashboard 上作為診斷線索。理由是成因和症狀之間不一定有直接關係 — CPU 在 80% 不代表使用者受影響（可能 auto-scaling 正在長新節點），而 CPU 在 30% 也不代表安全（可能是某個 goroutine 卡住了，CPU 反而閒下來）。如果每個成因指標都獨立設 alarm，告警數量會與資源數量等比增長，訊噪比下降後症狀型告警容易被成因型告警淹沒。

 1# 症狀型 alarm：5xx 超過閾值代表使用者已受影響
 2resource "aws_cloudwatch_metric_alarm" "api_5xx" {
 3  alarm_name          = "${var.env}-api-5xx-rate"
 4  comparison_operator = "GreaterThanThreshold"
 5  evaluation_periods  = 3
 6  metric_name         = "5XXError"
 7  namespace           = "AWS/ApiGateway"
 8  period              = 60
 9  statistic           = "Sum"
10  threshold           = 10
11  treat_missing_data  = "notBreaching"
12  alarm_actions       = [var.oncall_sns_arn]
13}
14
15# 成因型指標：CPU 放 dashboard、不設 alarm
16# 除非確認「CPU 到 X% 一定代表服務即將不可用」這個因果關係

當成因和症狀之間有明確的因果閾值（例如 RDS 磁碟用量到 90% 就會開始拒絕寫入），那條成因也值得設 alarm — 關鍵是因果關係要確認過、而非假設。

INSUFFICIENT_DATA 的處理

treat_missing_data 決定了「沒收到 metric 資料點」時 alarm 怎麼判定。這個設定常被忽略，但它在兩個情境下會造成顯著差異：

持續有資料的 metric（如 API request count）：資料突然消失通常代表服務掛了或 metric 管線斷了，應該設 treat_missing_data = "breaching" — 沒資料本身就是異常訊號。

間歇性的 metric（如錯誤 count、某個低頻 Lambda 的 invocation）：平常就沒有資料點，沒資料代表正常運作，應該設 treat_missing_data = "notBreaching" — 避免每次低谷時段都觸發假告警。

判讀方式是問自己：「這條 metric 如果 10 分鐘沒有任何資料，代表好事還是壞事？」好事用 notBreaching，壞事用 breaching，不確定用 ignore（不改變 alarm 狀態，等下一個有資料的評估週期再判定）。

告警必須連到動作

一條有用的 alarm 至少要綁定通知去向。alarm_actions 為空的 alarm 只會在 CloudWatch console 裡變色，而事故發生時沒有人會盯著 console 看 — alarm 的價值在於它主動推送到值班的人手上。

1resource "aws_sns_topic" "oncall" {
2  name = "${var.env}-oncall-alerts"
3}
4
5resource "aws_sns_topic_subscription" "pagerduty" {
6  topic_arn = aws_sns_topic.oncall.arn
7  protocol  = "https"
8  endpoint  = var.pagerduty_integration_url
9}

通知去向也該寫進 IaC — SNS topic、subscription、整合端點都是基礎設施的一部分。手動建的 SNS subscription 跟手動建的 alarm 有同樣的問題：沒人記得、沒人維護、出事才發現斷了。

把基礎告警做成 module 預設

如果每次新服務上線都要有人「記得」去加 alarm，代表 alarm 還沒進 module 模板。把基礎告警（錯誤率、延遲、健康檢查失敗）做成服務模組的預設輸出，新服務 apply 時 alarm 跟著一起生出來：

 1# modules/service/variables.tf
 2variable "alarm_5xx_threshold" {
 3  type    = number
 4  default = 10
 5}
 6
 7variable "alarm_latency_p99_ms" {
 8  type    = number
 9  default = 3000
10}

開新服務時 alarm 跟著資源一起生出來，調整閾值才是該服務 owner 的選配。預設值的選擇依據是「保守但不擾民」— 初始閾值設寬一點，上線穩定後再根據實際基線收斂。

觀測訊號的設計有一個容易忽略的盲區：aggregated metric 會遮蔽局部惡化。Discord 在三代儲存架構的遷移過程中反覆遇到同一個問題——整體 p95 延遲正常，但少數 hot partition 或大型群組的延遲已經飆升，直到使用者回報才發現。教訓是 alarm 的維度要跟業務的 fan-out 結構對齊，而非只看全域聚合。詳見 4.C13 Discord：從儲存問題回推觀測缺口。規模化後叢集的動態擴縮也會改變觀測模型——擴縮事件本身要成為觀測對象，見 4.C8 Airbnb：K8s 規模化觀測訊號治理。

基礎設施訊號 vs 客戶端行為訊號

本模組的可觀測性處理基礎設施訊號，Monitoring 監控體系處理客戶端與業務行為訊號。兩者觀測的對象不同、生命週期也不同，因此分屬不同的 code 與不同的部署管道。

基礎設施訊號是資源層的健康狀態：log group retention、CPU、佇列深度、5xx 比例、實例存活。它們跟著資源被 IaC 建立與銷毀，回答的問題是「這個系統還活著嗎、哪裡壞了」。

客戶端行為訊號則是 SDK、Collector、業務埋點那一層：使用者點了什麼、轉換漏斗在哪裡流失、前端 JS 錯誤率、自訂業務事件。它們跟著產品功能演進、不跟著基礎設施資源同生共滅。

判讀分界的問法是：這個訊號是「資源建立時就該存在」還是「功能開發時才埋」。前者進本模組的 IaC，後者進 monitoring 那層的應用程式碼。

兩者在事故排查時會合流 — 基礎設施 alarm 告訴值班「RDS CPU 飆到 95%」，客戶端訊號告訴產品團隊「結帳頁面的失敗率從 0.1% 跳到 12%」。把兩條訊號交叉比對才能判斷影響範圍。但它們的擁有者、變更節奏與部署管道不同 — 基礎設施 alarm 跟著 infra PR 走，前端埋點跟著產品 sprint 走。混在同一份 code 裡會讓「誰負責這條訊號的閾值」變模糊，也讓 infra PR 的 review 範圍擴大到不相干的業務邏輯。

跨分類引用

• → monitoring 監控體系：客戶端 SDK / Collector 那層的監控
• → 模組四：環境分離與模組化：module 化在這裡延伸成「每個模組自帶 observability 宣告」
• → 模組五：核心服務上 IaC：每個核心服務帶自己的 log 與 alarm
• → 模組七：infra 走 PR 流程：observability 變更也走 PR 與自動化護欄
• → backend 模組七：資安與資料保護：哪些欄位不該進 log、PII 處理

IAM 的心智模型

IAM（Identity and Access Management）是雲端平台用來回答「某個身分能不能對某個資源做某件事」的授權系統。它把授權拆成三個獨立的零件：identity（身分，發起動作的主體）、policy（政策，描述允許或拒絕的規則）、role（角色，一組可以被臨時取得的權限集合）。理解這三者的分工，是後面所有憑證決策的前提。

identity：長期主體 vs 臨時假扮

identity 分兩類，這個區分在後面設計權限邊界時會反覆用到。一類是 user，代表一個長期存在的主體，通常對應到一個真人或一個固定的服務帳號，本身可以持有長期憑證（密碼或 access key）。另一類是 role，代表一組權限的暫時授予 — 沒有自己的長期密碼，而是讓某個被信任的身分「假扮（assume）」成它、換取一段有時效的臨時憑證。

把 identity 想成「護照」和「通行證」的差別：user 是護照，長期有效、全程攜帶；role 是通行證，到了管制區域臨時換發、離開就失效。多數安全事故源自於把通行證當護照用 — 某個 role 被長期假扮且從未被撤回，或某個 user 持有永不輪替的 access key。

policy：描述「允許對什麼做什麼」

policy 是貼在 user 或 role 上的規則文件，列出 Action（能做什麼，如 s3:GetObject）、Resource（對哪個資源，如特定 bucket 的 ARN）、Effect（Allow 或 Deny）。一條 policy 可以包含多個 statement，每條 statement 描述一組操作許可。

1# 最小權限範例：CI 只能讀寫特定 bucket，不給整個 S3
2data "aws_iam_policy_document" "ci_artifacts" {
3  statement {
4    effect    = "Allow"
5    actions   = ["s3:GetObject", "s3:PutObject"]
6    resources = ["arn:aws:s3:::myapp-artifacts/*"]
7  }
8}

這段 policy 只允許對 myapp-artifacts 這一個 bucket 做讀寫。如果寫成 resources = ["*"]，同一把身分被攻破時，攻擊者就能讀寫帳號內所有 bucket — 差別不在語法，在 Resource 欄位收到多緊。

role：臨時身分的載體

role 本身不持有長期密碼。它靠 trust policy（信任政策）定義「誰能假扮我」，靠 permissions policy 定義「假扮後能做什麼」。trust policy 和 permissions policy 是兩份獨立的文件，分別回答「誰進得來」與「進來後能做什麼」。

 1# trust policy：只允許 ECS 服務假扮此 role
 2data "aws_iam_policy_document" "ecs_trust" {
 3  statement {
 4    actions = ["sts:AssumeRole"]
 5    principals {
 6      type        = "Service"
 7      identifiers = ["ecs-tasks.amazonaws.com"]
 8    }
 9  }
10}
11
12resource "aws_iam_role" "api_task" {
13  name               = "api-task-prod"
14  assume_role_policy = data.aws_iam_policy_document.ecs_trust.json
15}

trust policy 裡的 principals 決定能進門的身分。上面這段把進門權限限給 ECS 服務本身，意味著只有跑在 ECS 上的 task 才能取得這個 role 的臨時憑證 — 一個在本地筆電跑的程式呼叫 AssumeRole 會被拒絕。

最小權限：持續收斂而非一次設定

最小權限（least privilege）是貫穿整套系統的設計原則：一個身分只應該拿到完成它本職工作所需的最小權限集合。多一個 action 是多一條攻擊面，多一個 resource 是多一個爆炸半徑。

最小權限是持續收斂的過程，而非一次設定就結束的靜態狀態。服務初期常為了快速上線給寬鬆權限 — 一個新的 ECS task role 掛上 AmazonS3FullAccess 讓它能跑起來，半年後這個 role 實際只用了 s3:GetObject 和 s3:PutObject 兩個 action、針對一個 bucket，但 policy 裡寫的還是全部 S3 操作對所有 bucket。

收斂的工具是 access analyzer。AWS IAM Access Analyzer 能分析 CloudTrail 日誌，列出某個 role 在過去 N 天內實際用了哪些 action 與 resource，據此產出一份建議的最小 policy。用它的步驟是：開著寬 policy 跑一段時間 → 用 access analyzer 產出實際使用清單 → 把 policy 收斂到這份清單 → 確認服務仍正常。

 1# 產出建議 policy：分析 api-task-prod role 過去 90 天的實際用量
 2aws accessanalyzer generate-policy \
 3  --policy-generation-details '{
 4    "principalArn": "arn:aws:iam::123456789012:role/api-task-prod",
 5    "cloudTrailDetails": {
 6      "trailArn": "arn:aws:cloudtrail:ap-northeast-1:123456789012:trail/main",
 7      "startTime": "2026-03-01T00:00:00Z",
 8      "endTime": "2026-06-01T00:00:00Z"
 9    }
10  }'

一個快速的盤點方式：列出所有掛著 AdministratorAccess、PowerUserAccess、*FullAccess 這類寬鬆 managed policy 的 role，每個命中都問一次「這個 role 確實需要這些權限嗎」。CI role 的 policy 裡出現 *:* 更是明確的收斂目標。

長期 access key 的風險

長期 access key 是一組沒有到期時間的靜態憑證（access key ID + secret），任何持有它的人或程式都能以對應身分的全部權限呼叫 API，直到有人手動撤銷為止。它最大的問題是「沒有時效」這個性質本身，會在三個方向上累積風險，而且風險隨團隊規模與時間單調上升。

散落

長期 key 為了被程式使用，會被複製進 .env 檔、CI 設定、本機 ~/.aws/credentials、Slack 訊息、甚至誤推進 git 歷史。每多一個副本就多一個外洩點。一把 key 在半年內可能被貼到六個地方 — 部署腳本、兩個 CI 平台的環境變數、某台共用跳板機的 profile、一封交接信、一位已離職同事的筆電 — 而這六個副本沒有任何中央清單能列舉。

權限過大

因為輪替麻煩，團隊傾向給一把 key 配足夠寬的權限「一次搞定」。建立時圖方便掛了 AdministratorAccess，打算「等穩定了再收斂」，但那天從來沒有到來。於是一把本來只該讀 artifact 的 key 同時握有刪除 production 資料庫的能力。

難以輪替

輪替一把長期 key 意味著找出所有副本、同步替換、確認沒有遺漏。這個成本高到讓多數團隊選擇拖延，於是 key 的有效期變成「無限」，外洩後的曝險窗口也跟著變成無限。用一個問題辨認風險：能不能在五分鐘內回答「這把 key 被用在哪些地方、上次輪替是什麼時候」？答不出來，它就已經是技術債。

常見的散落路徑：部署腳本使用的 admin key 留在 CI 環境變數，建立者離職後沒人知道這把 key 的存在與權限範圍。這類情境的風險在於外洩後沒有手段限制影響範圍 — key 的權限有多大，影響範圍就有多大。用 credential report 定期盤點帳號內所有 access key 的建立時間與使用時間，見模組負一：還沒有 infra 的環境。

長期憑證風險的實際規模可以從兩個案例看到。Snowflake 2024 事件中，攻擊者利用外洩的長期憑證登入缺少 MFA 的客戶環境，執行大量資料匯出，造成跨客戶的資料竊取與勒索（見 Snowflake 2024：憑證濫用與資料竊取）。LastPass 2022 事件則顯示備份路徑的憑證管理缺口會讓影響範圍沿信任鏈擴散——開發環境取得的資訊被用來存取雲端備份，整條路徑的金鑰隔離不足是根因（見 LastPass 2022：備份路徑與鏈式入侵）。兩個案例的共同教訓是：長期憑證的風險不止於外洩本身，而在於外洩後缺乏限制影響範圍的機制。

OIDC：給 CI/CD 的短期憑證

OIDC（OpenID Connect）聯合讓 CI/CD 平台用一段每次執行才簽發、幾分鐘後就失效的短期憑證取代長期 key，從根本上消掉「靜態密鑰散落」這個問題。它的運作方式是建立信任關係：雲端帳號信任某個外部 identity provider（如 GitHub Actions 的 OIDC issuer），當管線執行時，CI 平台簽發一個帶有可驗證 claim 的 token（描述「這是哪個 repo、哪個 branch、哪個 workflow 在跑」），雲端用這個 token 換出一段臨時憑證。沒有任何長期 secret 需要被儲存在 CI 設定裡。

trust policy 的收斂

關鍵設計在 role 的 trust policy 上 — 它規定「哪個外部身分被允許假扮成這個 role」。trust policy 要用 token 的 claim 把假扮條件收到最緊。

 1# OIDC trust policy：只允許特定 repo 的 main branch 假扮此 role
 2data "aws_iam_policy_document" "ci_trust" {
 3  statement {
 4    actions = ["sts:AssumeRoleWithWebIdentity"]
 5
 6    principals {
 7      type        = "Federated"
 8      identifiers = [aws_iam_openid_connect_provider.github.arn]
 9    }
10
11    condition {
12      test     = "StringEquals"
13      variable = "token.actions.githubusercontent.com:aud"
14      values   = ["sts.amazonaws.com"]
15    }
16
17    condition {
18      test     = "StringLike"
19      variable = "token.actions.githubusercontent.com:sub"
20      values   = ["repo:my-org/my-app:ref:refs/heads/main"]
21    }
22  }
23}

每個 condition 各守一段邊界。aud 的 StringEquals 確認 token 是發給 AWS STS 的（防止用錯 audience 的 token 闖入）。sub 的 StringLike 把假扮限定在特定 repo 的 main branch — 設成 repo:my-org/* 等於讓組織內任何 repo 的任何 branch 都能假扮這個 role，這是常見的設定陷阱。

收斂 trust policy 的判讀問法是：「如果 my-org 底下某個公開 fork 跑了一個惡意 workflow，它能不能假扮這個 role？」如果答案是能，sub 條件就太鬆了。

分離 plan 與 apply 的 role

進一步的收斂是替 plan 和 apply 分別建立 role。plan 只需要唯讀存取（讀 state、讀雲端現況），apply 需要寫入權限。把兩者分成獨立 role，讓 PR 階段的 CI 用唯讀 role 跑 plan、合併後才用寫入 role 跑 apply。任何拿到 plan role 的 token 無法修改基礎設施。

 1# plan role：只需讀取 state 與雲端現況
 2resource "aws_iam_role" "ci_plan" {
 3  name               = "infra-ci-plan"
 4  assume_role_policy = data.aws_iam_policy_document.ci_trust.json
 5}
 6
 7resource "aws_iam_role_policy_attachment" "ci_plan_read" {
 8  role       = aws_iam_role.ci_plan.name
 9  policy_arn = "arn:aws:iam::aws:policy/ReadOnlyAccess"
10}
11
12# apply role：需要寫入權限，trust policy 限定只有 main branch
13resource "aws_iam_role" "ci_apply" {
14  name               = "infra-ci-apply"
15  assume_role_policy = data.aws_iam_policy_document.ci_trust_main_only.json
16}

這一章把 role 與 trust policy 設計好，OIDC 的實際回報要到模組七：infra 走 PR 流程建管線時才兌現 — 屆時管線用這裡定義好的 role 取得短期權限執行 plan 與 apply，CI 環境裡不需要存任何 access key。

權限邊界設計

權限邊界是把不同類型的身分與不同環境之間的權限刻意隔開，讓任何一個身分被攻破時，爆炸半徑都被限制在它本職的範圍內。邊界設計有兩條軸線需要分別處理：人 vs 機器，以及環境之間。

人 vs 機器

兩者的存取模式根本不同，混在同一個身分上會同時喪失兩邊的保護。

人類身分需要互動式登入、應該強制 MFA、權限隨職責變動，且通常透過 SSO 集中管理。機器身分（CI runner、ECS task、Lambda function）需要的是程式化、無人值守的存取，應該用 role 假扮取得短期憑證，永遠不該配長期 key。

機器身分還要再依「跑在哪裡」分兩類。跑在雲上的 workload（EC2 instance、ECS task、Lambda）由平台直接把 role 綁在執行環境上 — AWS 用 instance profile 把 role 掛在 EC2、用 task role 掛在 ECS task，workload 從實例 metadata 端點自動取得輪替的短期憑證。跑在雲外的 CI/CD（GitHub Actions、GitLab CI）拿不到實例 metadata，需要前面那套 OIDC 信任關係換憑證。

一個常見陷阱是工程師用自己的個人 key 跑自動化腳本 — 這把人的廣泛權限直接送進了無人值守的執行環境，MFA 保護形同虛設（API 呼叫不需要 MFA challenge），權限範圍比任何 CI role 都大。

環境之間

環境之間的邊界，目的是讓 production 的權限與 staging、dev 完全不交叉。驗證邊界的方式是用 dev 環境的 CI role 嘗試列出或刪除 production 的資源——能做到，就代表邊界沒有建立。

帳號級護欄：SCP

Organizations 把環境拆成獨立帳號，再用 SCP（Service Control Policy）對整個帳號或組織單位設定權限天花板，連帳號內的管理員都越不過去。SCP 是 deny-based 的頂層限制 — 它不授予任何權限，只限制「即使有人給了權限也不准做」。

 1{
 2  "Version": "2012-10-17",
 3  "Statement": [
 4    {
 5      "Sid": "DenyLeaveOrg",
 6      "Effect": "Deny",
 7      "Action": ["organizations:LeaveOrganization"],
 8      "Resource": "*"
 9    },
10    {
11      "Sid": "DenyDisableCloudTrail",
12      "Effect": "Deny",
13      "Action": [
14        "cloudtrail:StopLogging",
15        "cloudtrail:DeleteTrail"
16      ],
17      "Resource": "*"
18    }
19  ]
20}

這份 SCP 掛在整個組織底下的所有帳號上，確保任何帳號都不能關閉稽核日誌或退出組織 — 即使該帳號裡有人持有 AdministratorAccess。SCP 的定位是組織層的不可踰越底線。

Role 級護欄：Permissions Boundary

Permissions Boundary 是掛在單一 role 上的權限上限。它跟 SCP 的差別在粒度：SCP 管整個帳號，Permissions Boundary 管單一身分。即使有人後來給一個 role 貼了過寬的 policy，Boundary 也會擋住超出上限的部分。

 1# Permissions Boundary：CI role 最多只能操作特定服務
 2resource "aws_iam_policy" "ci_boundary" {
 3  name = "ci-boundary-prod"
 4  policy = jsonencode({
 5    Version = "2012-10-17"
 6    Statement = [
 7      {
 8        Effect   = "Allow"
 9        Action   = ["ecs:*", "ecr:*", "s3:*", "logs:*"]
10        Resource = "*"
11      },
12      {
13        Effect   = "Deny"
14        Action   = ["iam:*", "organizations:*", "account:*"]
15        Resource = "*"
16      }
17    ]
18  })
19}
20
21resource "aws_iam_role" "ci_apply" {
22  name                 = "infra-ci-apply"
23  assume_role_policy   = data.aws_iam_policy_document.ci_trust.json
24  permissions_boundary = aws_iam_policy.ci_boundary.arn
25}

SCP 與 Permissions Boundary 疊起來的效果是：SCP 在帳號層鎖住最危險的操作（關日誌、退組織），Boundary 在 role 層限制單一身分最多能做什麼，permissions policy 在這兩層天花板之內授予實際需要的權限。三者各管一層，缺一層就少一道屏障。

身分控制面本身的韌性在兩個案例中被檢驗。Azure AD 2021 事件中，身分服務的控制面故障導致所有依賴身份驗證的服務同時受影響，事故處理需要在身份恢復與服務降級策略之間排優先序（見 Azure AD：Identity Control-plane 事件）。Microsoft Storm-0558 事件則顯示簽章金鑰一旦失守，token 驗證的信任鏈會跨租戶失效，修復不只是修補漏洞、而是重建整條 key lifecycle 與 issuer 驗證流程（見 Microsoft：Storm-0558 簽章金鑰事件）。這兩個案例揭露的是：權限邊界只管「某個身分能做什麼」，但身分系統本身的控制面如果失效，所有建立在它之上的邊界都跟著失效。

環境隔離的更完整實作（帳號結構、模組化參數）會在模組四：環境分離與模組化展開。

身分層 vs 應用層 secret 的邊界

這一章談的是身分與憑證 — 誰是誰、怎麼證明、能動什麼。憑證背後引用的應用層 secret（資料庫密碼、第三方 API key）怎麼安全儲存與注入，屬於模組八：治理好習慣的 secret management 範圍。兩者的交集是：身分層決定「誰能讀到 secret store」，secret 層決定「secret 怎麼存與輪替」。把 IAM role 的 policy 收到只能讀取該服務路徑下的 secret（如 prod/payments/*），是同時落實最小權限與 secret 隔離的結合點。

身分與憑證的地基備妥後，下一步是劃清服務之間的網路邊界——這正是模組三：網路地基的範圍。

跨分類引用

• → 模組負一：還沒有 infra 的環境：長期 key 盤點與護欄
• → 模組三：網路地基：身分備妥後，劃清服務之間的網路邊界
• → 模組四：環境分離與模組化：環境之間的帳號結構與隔離強度
• → 模組七：infra 走 PR 流程：CI/CD 管線用 OIDC 取得短期權限
• → 模組八：治理好習慣：應用層 secret 的儲存與引用
• → backend 模組七：資安與資料保護：Secret Management 與憑證管理交集
• → Access Key 輪替手冊：key 盤點與輪替的操作步驟
• → OIDC Trust Policy 設定指南：GitHub Actions OIDC 的 step-by-step 設定

這個結構的操作極限會在兩個時間點浮現：第一次需要在正式環境以外的地方驗證變更時，以及第二個人開始操作同一組資源時。以下依序說明每個階段的操作現實與對應的 infra 需求。

資料庫變更需要驗證環境

應用新增功能時經常需要改資料庫的表結構 — 加欄位、改索引、拆表。這類操作（database migration）如果語法有誤或邏輯有缺，可能導致服務中斷或資料不一致。正常做法是先在非正式環境驗證通過，再推到 production 執行。

單一環境的情況下沒有驗證的場所。三種應對方式各有不同的風險邊界：

直接在 production 執行。成本最低，風險最高。migration 腳本跑下去的那一刻，正在使用服務的使用者直接承受後果 — 一個鎖住整張大表的 ALTER TABLE 會讓所有查詢卡住，一個 DROP COLUMN 刪錯欄位會造成不可逆的資料遺失。服務規模小、使用者少時代價尚可承受；一旦服務開始承載營收或外部依賴，這個做法的風險代價就超過了它省下的時間。

手動複製一套環境。到 Console 上照 production 的設定重新建一台 EC2、開一台 RDS、配一組 security group，得到一套「看起來一樣」的 staging。migration 先在 staging 驗證再推 production。這解決了驗證場所的問題，但引入了漂移問題 — 下一節說明。

用程式碼描述環境，讓工具複製。把 production 的設定寫成描述檔，用 Terraform 或 OpenTofu 根據同一份描述建出 staging。初始成本比手動複製高（要學工具、寫描述檔），但它保證了手動複製保證不了的一件事：staging 和 production 的結構來自同一份描述，差異只存在於刻意不同的參數（機器規格、備份天數）。這就是 Infrastructure as Code（IaC）的起點。

手動複製的環境會漂移

手動複製的 staging 在建立當天跟 production 一致。一個月後通常不再一致。

漂移的來源是日常操作中的局部調整：staging 的 security group 多了一條規則（某次除錯時加的，事後忘了刪）、production 的 RDS 參數被調過（線上出現慢查詢，DBA 改了 work_mem 但沒同步 staging）、staging 的 IAM role 多了一條 policy（測試新功能時加的，測完沒拿掉）。每一筆差異都很小，小到不值得專門同步，但它們會累積。

漂移引爆的時機跟產生的時機通常隔很遠。一個 migration 在 staging 通過、推到 production 失敗，排查半天後發現是一個月前的參數調整造成的 — staging 的 work_mem 跟 production 不同，剛好影響了這次 migration 的執行計畫。這種因果關係跨越時間的錯誤，排查成本遠高於錯誤本身。

漂移的根源是「兩套環境各自獨立維護」。只要兩份設定各自存在，同步就完全依賴操作者的記憶與紀律，而記憶會衰退、紀律會在壓力下鬆懈。結構性的解法是讓兩套環境共用同一份設定，差異只存在於刻意控制的參數。

同一份描述、不同的參數

IaC 工具消除漂移的方式，是把環境的結構寫成一份 module，用不同的參數值建出不同環境。程式碼只有一份，結構保證相同；差異全部收斂在參數裡，每一處「故意不同」都是明確且可審查的。

一個描述資料庫的 module：

 1variable "instance_class" {
 2  type = string
 3}
 4
 5variable "backup_retention_days" {
 6  type    = number
 7  default = 7
 8}
 9
10resource "aws_db_instance" "main" {
11  engine                  = "postgres"
12  instance_class          = var.instance_class
13  backup_retention_period = var.backup_retention_days
14}

Production 傳入大機器和長備份，staging 傳入小機器和短備份：

 1# production
 2module "database" {
 3  source                = "./modules/database"
 4  instance_class        = "db.r6g.large"
 5  backup_retention_days = 14
 6}
 7
 8# staging
 9module "database" {
10  source                = "./modules/database"
11  instance_class        = "db.t3.small"
12  backup_retention_days = 3
13}

兩個環境跑的是同一段 module 程式碼。引擎版本、連線方式、安全設定完全相同（寫在 module 裡、不是參數），差異只有機器規格和備份天數（刻意透過參數控制）。改動 module 一次、兩個環境同時生效，漂移的空間被結構性消除。

IaC 工具會維護一份 state 記錄，追蹤每個環境裡實際建了哪些資源和它們的屬性。改了程式碼後跑 terraform plan，工具會比對新的程式碼和 state 的差異，列出「會新增 / 修改 / 刪除什麼」。確認差異符合預期後才執行 apply。state 的角色與安全存放方式在模組一：最小可行 IaC 展開，環境的目錄結構與 module 設計在模組四：環境分離與模組化 展開。

環境分離牽出的後續關注點

環境分離解決了「在哪裡驗證」和「為什麼 staging 跟 production 不同」的問題。但多環境運行後，一組後續的操作需求會依序浮現，每一個對應 infra 的一個能力層：

身分與權限隔離。三個環境代表三組資源。如果所有人對所有環境都有完整操作權限，一次誤操作就可能改壞 production。production 的修改權限應該比 staging 嚴格、操作身分應該分開。這是模組二：身分與憑證地基的範圍。

變更審查流程。多人同時操作 infra 時，沒有經過 review 的變更會互相覆蓋。把 infra 變更接上跟應用程式碼相同的 PR 流程 — 開分支、自動跑 plan、review 通過才 apply — 讓每一次改動都有提案、審查和歷史。這是模組七：infra 走 PR 流程的範圍。

機密值管理。資料庫密碼、API key 這些機密值在有版本控制之前可能直接寫在 .env 或 CI 變數裡。一旦有了 IaC 和 git，這些值如果跟著程式碼進了版本歷史，就會隨著每一次 clone 擴散。機密值要存在專用的密鑰管理服務裡，程式碼只持有指向它的參照。這是模組八：治理好習慣的範圍。

可觀測性。三個環境各自需要 log、metric 和告警，這些監控要跟環境本身一起建立，而非等服務中斷後才發現沒有可查的資料。這是模組六：可觀測性與 log 的範圍。

網路邊界。三個環境如果共用同一個網段和防火牆規則，staging 的某個被入侵的服務可能橫向觸及 production 的資料庫。每個環境需要有自己的網路邊界。這是模組三：網路地基的範圍。

這些關注點的共同根源是同一件事：當服務從單人單環境長成多人多環境，原本藏在記憶和手動操作裡的決策，必須變成可描述、可審查、可重建的規則。整套教材的地圖在模組零：infra 是什麼，每個模組各自處理一個能力層。

跨分類引用

• → 模組零：infra 是什麼：責任邊界與成熟度階梯（從全手動到全程式碼治理的五階分級）的完整定義
• → 模組負一：還沒有 infra 的環境：導入 IaC 之前的低成本護欄
• → 模組一：最小可行 IaC：state 與 IaC 工具的選型與起步
• → 模組四：環境分離與模組化：目錄結構、module、參數化的完整設計

本篇先確立依賴圖怎麼驅動部署順序，再展開核心服務裡最需要謹慎描述的一類 — 資料庫。資料庫持有無法重建的狀態，它的 IaC 描述比其他 stateless 資源多出保護策略、連線管理與讀寫分流三個維度。

核心服務的部署順序

核心服務的部署順序由依賴方向決定：被依賴的先建，依賴別人的後建。網路與身分是幾乎所有上層服務的共同前置 — 資料庫要放進私有 subnet、運算要套用 IAM role 才能讀 S3、load balancer 要掛在公開 subnet 並引用 security group。這些底層平面若還沒成形，上層資源會在 apply 時因為找不到 subnet ID 或 role ARN 而失敗，或更糟，建在預設 VPC 裡繞過了所有隔離設計。

把順序交給 IaC 工具的依賴圖自動推導，比人工排序可靠。當運算資源的定義引用了 subnet 與 security group 的資源屬性，Terraform 會解析出「subnet 先於運算」的邊，apply 時自動排程。人工維護一份「先做 A 再做 B」的清單會隨資源增加而失準，依賴圖則隨程式碼本身演進。

四層依賴結構

依賴圖的典型展開順序呈現四層結構：

這四層不需要手動編排。只要程式碼裡的引用關係正確，Terraform 就會自動按這個順序 apply。當 plan 輸出的順序看起來不合直覺 — 例如 ALB 先於 ECS — 通常代表某個引用斷了、兩者之間沒有依賴邊。

順序失控的徵兆

順序失控的早期徵兆是：某個上層資源的定義裡寫了一串 hardcode 的 subnet ID 或 VPC ID。

1# 硬編碼 ID — 依賴圖斷裂，底層重建時上層不會跟上
2resource "aws_db_subnet_group" "private" {
3  subnet_ids = ["subnet-0abc123", "subnet-0def456"]
4}

這段 code 跟底層的 subnet 資源沒有引用關係。底層一旦重建、ID 改變，上層不會自動跟上，state 與雲端現實之間的不一致（即 drift）就此產生。修法是把硬編碼的 ID 換成對底層資源屬性的引用：

1# 引用資源屬性 — 依賴圖自動推導，底層重建時上層自動取得新 ID
2resource "aws_db_subnet_group" "private" {
3  subnet_ids = [for s in aws_subnet.private : s.id]
4}

跨 state 的情境（網路地基與核心服務分屬不同 state）則用 data source 取代直接引用 — 這個取捨在服務依賴與跨 state 引用展開。

隱性依賴與 depends_on

自動推導涵蓋的是「引用屬性時產生的邊」。少數情況下兩個資源之間有依賴卻沒有屬性引用 — 例如一個 IAM policy attachment 必須在某個 role 被 ECS task 使用之前完成，但 task 引用的是 role ARN 而非 attachment 的輸出。這時用 depends_on 顯式宣告邊：

1resource "aws_ecs_service" "api" {
2  # ...
3  depends_on = [aws_iam_role_policy_attachment.ecs_task_s3]
4}

depends_on 應該只出現在自動推導覆蓋不了的場景。如果一個 module 裡到處都是 depends_on，通常代表引用關係寫得不夠明確，該把隱性依賴改成屬性引用。

資料庫（RDS）

資料庫是核心服務裡最需要謹慎描述的資源，因為它持有無法重建的狀態。IaC 定義它的 instance class、引擎版本、所在的 subnet group（決定它落在哪些私有 subnet）、套用的 parameter group 與 security group。連線端點不要硬編碼，改用資源 output 暴露給上層運算引用，這樣端點隨主庫 failover 或重建而改變時，上層引用自動更新。

 1resource "aws_db_instance" "primary" {
 2  identifier             = "app-${var.env}-primary"
 3  engine                 = "postgres"
 4  engine_version         = "16.3"
 5  instance_class         = var.db_instance_class
 6  allocated_storage      = 100
 7  storage_encrypted      = true
 8
 9  db_subnet_group_name   = aws_db_subnet_group.private.name
10  vpc_security_group_ids = [aws_security_group.db.id]
11
12  multi_az                  = var.env == "prod" ? true : false
13  backup_retention_period   = var.env == "prod" ? 14 : 1
14  backup_window             = "03:00-04:00"
15  deletion_protection       = var.env == "prod" ? true : false
16  skip_final_snapshot       = var.env == "prod" ? false : true
17  final_snapshot_identifier = var.env == "prod" ? "app-prod-final-${formatdate("YYYYMMDD", timestamp())}" : null
18
19  tags = { service = "payments" }
20}
21
22output "db_endpoint" {
23  value = aws_db_instance.primary.endpoint
24}

加密的不可逆性

storage_encrypted = true 確保磁碟層級的加密在資源建立時就生效。RDS 不支援事後對既有 instance 開加密 — 漏了只能重建。補救路徑是匯出快照、用加密 KMS key 複製快照成加密版本、再用加密快照還原成新 instance。這個過程需要停機或切換端點，對已經承載流量的 production 資料庫代價很高。prod 的 RDS 若 storage_encrypted 為 false，這筆技術債越早處理越便宜。

parameter group 的角色

parameter group 定義資料庫引擎層級的行為參數（如 max_connections、work_mem、log_min_duration_statement），是 RDS instance 的設定骨架。IaC 描述 parameter group 的好處是讓這些參數進版本控制 — 有人改了 max_connections 會出現在 PR diff 裡，而不是某天在 Console 改了沒人知道。

 1resource "aws_db_parameter_group" "postgres16" {
 2  family = "postgres16"
 3  name   = "app-${var.env}-pg16"
 4
 5  parameter {
 6    name  = "log_min_duration_statement"
 7    value = "1000"
 8  }
 9
10  parameter {
11    name  = "shared_preload_libraries"
12    value = "pg_stat_statements"
13  }
14}

修改 parameter group 的某些參數需要重啟 RDS instance（稱為 apply_method = "pending-reboot"），修改前要先確認這個參數屬於「立即生效」還是「要重啟」。在 Terraform plan 裡不會明確標示重啟，要靠 AWS 文件交叉比對。

連線管理

運算到資料庫之間有一段常被略過的接線：連線管理。無狀態運算水平擴張時，每個實例各自開連線，容易把資料庫的連線數打滿。一個 ECS service 從 5 個 task 擴到 50 個、每個 task 開 10 條連線，就從 50 條跳到 500 條 — 而一台 db.r6g.large 的 max_connections 預設約在 1600 左右，500 條已經吃掉三分之一。

出現「擴運算反而拖垮 DB」的訊號時，解法是引入連線池或受管的連線代理。RDS Proxy 是 AWS 的受管方案：它在運算與 RDS 之間當一層連線池，把下游的數百條短連線收斂成對 RDS 的少量長連線。在 IaC 裡一併定義，輸出 proxy 端點給運算引用：

 1resource "aws_db_proxy" "app" {
 2  name                   = "app-${var.env}-proxy"
 3  engine_family          = "POSTGRESQL"
 4  role_arn               = aws_iam_role.rds_proxy.arn
 5  vpc_subnet_ids         = [for s in aws_subnet.private : s.id]
 6  vpc_security_group_ids = [aws_security_group.db.id]
 7
 8  auth {
 9    auth_scheme = "SECRETS"
10    secret_arn  = aws_secretsmanager_secret.db_password.arn
11  }
12}
13
14output "db_proxy_endpoint" {
15  value = aws_db_proxy.app.endpoint
16}

運算端引用 db_proxy_endpoint 而非 db_endpoint，連線管理就從各 task 自己處理轉成由 proxy 統一收斂。RDS Proxy 同時提供 failover 的連線保持 — 主庫切換到 standby 時，proxy 維護的連線不會全部斷開重建，應用端感受到的是短暫延遲而非連線錯誤。

判讀是否需要 RDS Proxy 的訊號是連線數成長曲線：如果運算的擴縮範圍固定且連線數上限遠低於 max_connections，直連即可；如果運算會頻繁擴縮或連線數可能逼近上限，proxy 值得引入。proxy 本身有額外成本（按 vCPU 計費），不是所有環境都划算 — dev 環境通常直連就夠。

read replica

當讀流量遠大於寫、且能容忍副本的複寫延遲（通常是毫秒到秒級）時，read replica 是把讀請求導離主庫的下一步。replica 在 IaC 裡用獨立資源描述，引用主庫的 identifier：

 1resource "aws_db_instance" "read_replica" {
 2  identifier             = "app-${var.env}-replica"
 3  replicate_source_db    = aws_db_instance.primary.identifier
 4  instance_class         = var.db_replica_class
 5  vpc_security_group_ids = [aws_security_group.db.id]
 6}
 7
 8output "db_replica_endpoint" {
 9  value = aws_db_instance.read_replica.endpoint
10}

運算端依讀寫分流引用不同端點 — 寫走 db_endpoint（或 db_proxy_endpoint），讀走 db_replica_endpoint。這個分流邏輯屬於應用層的責任，infra 只負責把端點暴露出來。

read replica 的邊界要講清楚：它緩解讀流量對主庫的壓力，但它不是備份。replica 會同步複製主庫的所有變更 — 包括誤刪的資料。需要還原到某個時間點的保護由 backup retention 與 PITR（point-in-time recovery）提供，這兩者的 IaC 描述在 stateful 保護策略。

引擎版本升級的取捨

RDS 引擎版本（engine_version）寫進 IaC 後，版本升級就成為一個需要 PR review 的變更。升級分 minor 和 major：minor 升級（16.2 → 16.3）通常向後相容、可在維護視窗自動套用；major 升級（15 → 16）可能有 breaking change，需要先在 dev 環境驗證、備份、排維護窗口。

在 IaC 裡把 engine_version 寫死是刻意的選擇 — 它阻止 AWS 在背景自動升級 major 版本，讓版本變更必須走 PR。代價是需要定期檢查是否有 EOL 版本還在用。如果 engine_version 指向的版本已經超過 AWS 的支援期限，Terraform apply 會在某天失敗（AWS 會強制升級），這比主動升級更不可控。

資料庫在規模放大後的治理維度也會改變。Netflix 把分散的 Aurora 叢集整併後成本降了 28%——多個團隊各自開的 RDS instance 加起來的閒置容量遠超一個整併後的叢集。infra 層的教訓是 RDS 的 IaC 描述不只管單一 instance 的設定，長期還要管叢集的分布與合併策略。另一個維度是合規需求驅動的資料落地：Hard Rock Digital 因為 Wire Act 法規要求資料留在特定州，用 AWS Outposts 在地端跑運算——這類情境下 infra 的 region 與可用區選擇由法規約束驅動，而非純技術決策。

跨分類引用

• → 模組三：網路地基：資料庫的 subnet group 引用 private subnet
• → 模組二：身分與憑證地基：RDS Proxy 的 IAM role 與 secret 存取
• → 模組四：環境分離與模組化：prod / dev 用同一個 module、不同參數值
• → stateful 保護與跨 state 引用：backup retention、deletion protection、multi-AZ 的完整討論
• → 運算上 IaC：運算端怎麼引用資料庫端點
• → backend 模組一：資料庫：schema 設計、migration、query 層面的服務端討論

這篇文章的操作順序按風險排列：先做不碰 prod 的盤點（零風險），再建本地開發環境（只動本機），然後才是碰 prod 的部署與資料庫紀律。

拍下完整現況（不動 prod）

接手後的第一個工作日只做一件事：把 prod 的完整狀態拍一份下來存到本地。這一步不改 prod 的任何東西，目的是讓自己手上有一份可對照的快照。

環境不同，拍照的工具和流程不同。先判斷自己的情境：

• 有 cPanel / Plesk 完整備份功能 → 用主機面板一次打包
• 只有 FTP 存取 → 用 FTP 逐層拍照
• 有 SSH 存取（部分 VPS 或獨立主機）→ 改讀有 SSH 但沒有 IaC 的雲端環境接管

用主機面板一次打包

如果主機有 cPanel，「備份精靈（Backup Wizard）」可以一次打包程式碼 + 資料庫 + email 設定 + cron jobs，是最快的完整快照方式。Plesk 的對應功能在「工具與設定 → 備份管理員」。

面板備份通常包含：網站檔案（含隱藏檔）、所有 MySQL 資料庫、email 帳戶與轉寄規則、cron job 設定、DNS zone 記錄。下載打包檔後解壓到本地、用 Git 初始化（見下方「初始化 Git repo」段）。

面板備份可能不包含的：SSL 憑證的私鑰（Let’s Encrypt 自動續期的通常不需要手動備份）、PHP 版本與模組設定（需要另外記錄，見環境設定的拍照）、.htaccess 以外的 Apache/LiteSpeed 自訂設定。拿到面板備份後仍然要跑「環境設定的拍照」段，因為面板備份拍的是檔案、不是環境設定。

用 FTP 逐層拍照

沒有主機面板（或面板不提供完整備份）時，要用 FTP 和 phpMyAdmin 分別拍程式碼和資料庫。

程式碼與靜態資源：用 FTP client 把整個網站目錄鏡像到本地。FileZilla 的操作路徑：站台管理員連線後，在遠端面板對根目錄按右鍵 → 「下載」，或用「伺服器 → 同步瀏覽」模式讓本地與遠端目錄結構保持對齊。WinSCP 提供「保持更新（Keep Remote Directory up to Date）」功能，但接手階段只需要一次性的完整下載，不需要持續同步。下載前確認 FTP client 的設定有勾選「顯示隱藏檔案」——.htaccess、.env、.user.ini 這類隱藏檔經常包含關鍵設定。

資料庫：用 phpMyAdmin 的「匯出」功能匯出完整資料庫（詳見下方「資料庫」段）。FTP 只拍程式碼，資料庫要另外匯出。

初始化 Git repo

不論用面板備份還是 FTP 逐層拍，拿到檔案後都初始化成 Git repo：

1mkdir project-takeover && cd project-takeover
2# FTP 下載完整站台到此目錄後
3git init
4git add -A
5git commit -m "initial snapshot from production FTP"

這個 commit 是接手的基準線。之後任何改動都能 diff 回這個起點，知道自己改了什麼。

資料庫

用 phpMyAdmin 的「匯出」功能：選「自訂」模式 → 勾選所有資料表 → 格式選 SQL → 勾選「加入 DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT / TRIGGER 敘述」（讓匯入時能乾淨覆蓋）→ 壓縮選 gzip（大型資料庫避免瀏覽器逾時）→ 編碼選 UTF-8 → 執行。

phpMyAdmin 的匯出在資料庫超過幾百 MB 時容易因 PHP max_execution_time 或記憶體限制中斷。替代方案：如果主機有 cPanel，「phpMyAdmin → 匯出」旁邊通常有「MySQL 資料庫備份」或透過 cPanel API 的 mysqldump 介面，比 phpMyAdmin 的 PHP 層匯出更可靠。另一個選項是本地安裝 DBeaver（免費、跨平台）或 TablePlus（macOS/Windows），用主機提供的遠端 MySQL 連線（cPanel → 遠端 MySQL → 加入本機 IP 白名單）直接從本機執行 mysqldump。HeidiSQL（Windows 免費）也支援同樣的遠端連線匯出。

把匯出的 .sql 檔存進 repo：

1mkdir db-snapshots
2# 把 phpMyAdmin 匯出的檔案存到這裡
3mv ~/Downloads/production-dump.sql db-snapshots/$(date +%Y%m%d)-initial.sql
4git add db-snapshots/
5git commit -m "initial database snapshot from phpMyAdmin"

如果主機面板有提供 mysqldump 的 web 介面（部分 cPanel 有），用那個比 phpMyAdmin 的匯出更可靠——phpMyAdmin 在大資料庫上容易因為 PHP 記憶體限制而中斷。

環境資訊記錄

在 repo 根目錄建一份 ENVIRONMENT.md，記錄以下資訊：

 1## Production 環境
 2
 3- **主機商**：[名稱]、方案：[方案名稱]
 4- **PHP 版本**：cPanel/Plesk 的 PHP 設定頁直接顯示；沒有控制面板時，FTP 上傳一個 `phpinfo.php`（內容 `<?php phpinfo();`）到站台根目錄、瀏覽器開啟後記錄版本、確認後立刻刪除（phpinfo 會暴露伺服器完整設定）
 5- **MySQL 版本**：phpMyAdmin 首頁顯示
 6- **Web server**：Apache / LiteSpeed / Nginx（控制面板或 response header）
 7- **域名 / DNS**：誰管的、nameserver 指向哪裡
 8- **SSL**：Let's Encrypt 自動續期 / 主機商代管 / 手動上傳
 9- **Cron jobs**：控制面板 → Cron Jobs 頁面截圖或列表
10- **Email**：有沒有用主機的 email 服務、轉寄規則
11- **.htaccess**：已包含在 FTP 下載中（注意隱藏檔有沒有漏）

掃描 hardcoded credential

PHP 專案常見的做法是把資料庫密碼、API key 直接寫在 config.php 或 wp-config.php 裡。在本地 repo 跑一次掃描：

1grep -rn "password\|passwd\|secret\|api_key\|apikey\|api_secret" \
2  --include="*.php" --include="*.ini" --include="*.env" .

把找到的每一筆記錄下來：哪個檔案、什麼 credential、用在哪裡。這份清單是後續 credential 輪替的輸入。

第三方整合清單

翻 code 找出所有對外部服務的呼叫——金流（綠界、藍新、Stripe）、簡訊（Twilio、三竹）、Email（SendGrid、SMTP）、社群登入（Facebook、Google）、CDN、Analytics。每一個整合都有對應的 API key 或 webhook URL，這些都是接手後需要確認存取權的項目。

環境設定的拍照

程式碼和資料庫之外，伺服器的執行環境本身也要記錄。非 container 環境沒有 docker commit 可以一次打包整台機器，要逐層拍：

PHP 設定：在站台根目錄上傳一個 phpinfo.php（內容 <?php phpinfo();），用瀏覽器打開後把完整輸出另存為 HTML 檔。記錄完立刻刪掉這個檔案——phpinfo 會暴露伺服器的完整設定與路徑。需要記錄的關鍵項：PHP 版本、載入的模組（mysqli、curl、mbstring、gd、imagick）、upload_max_filesize、post_max_size、max_execution_time、memory_limit、error_reporting、session.save_handler。這些值直接影響程式碼能不能在本地環境重現相同的行為。

Cron jobs：cPanel 的 Cron Jobs 頁面或 Plesk 的排程工作清單，截圖或逐條抄到 ENVIRONMENT.md。每一條 cron 記錄三項：排程時間、執行的指令（通常是 /usr/local/bin/php /home/user/public_html/cron.php）、這條 cron 的業務用途（如果能從指令或檔案名推斷）。

SSL 憑證：記錄域名、簽發者（Let’s Encrypt / 自購 / 主機商代管）、到期日。瀏覽器的鎖頭圖示可以查看憑證詳情。從本機也可以用 CLI 確認：

1echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates -issuer

如果是 Let’s Encrypt 自動續期，要確認續期機制是 cPanel 內建（AutoSSL）還是某個自訂 cron。手動購買的憑證要記錄到期日並設日曆提醒——過期後站台會直接出現瀏覽器安全警告。

.htaccess 規則：.htaccess 可能散在多個目錄（根目錄、uploads/、wp-admin/、api/）。FTP 下載時已包含在內（前提是 FTP client 有設定顯示隱藏檔案），確認一下這些檔案都在 repo 裡。

外部服務連線：除了前一節的第三方整合清單，用 grep 掃程式碼找出所有對外 URL。這些連線在未來遷移時要同步處理——搬了伺服器但 callback URL 沒改，金流通知就收不到。

1grep -rn "https\?://" --include="*.php" . \
2  | grep -v "localhost\|127\.0\.0\.1\|example\.com" \
3  | sort -u > _environment/external-urls.txt

檔案權限：FileZilla 的遠端檔案清單有權限欄。記錄 uploads/、cache/、sessions/、config 檔案的權限。777 的目錄是安全風險（任何使用者都能寫入），在多租戶的主機上尤其危險——同台主機的其他帳戶也能存取。

把以上資料存進 repo 的 _environment/ 目錄：

1_environment/
2├── phpinfo-20260626.html      # phpinfo 完整輸出
3├── cron-jobs.md               # cron 清單
4├── ssl-cert-info.txt          # 憑證資訊
5├── external-urls.txt          # 外部連線清單
6└── file-permissions.txt       # 目錄權限記錄

_environment/ 可加進 .gitignore（phpinfo 含敏感資訊），或只 ignore HTML 檔、其餘進 Git。

建立本地開發環境

本地能跑起來，才有安全的測試空間。目標是在本機重現 prod 的 PHP + MySQL 版本組合。

選型：Docker vs 本地堆疊

選型判準：如果 prod 的 PHP 版本是 5.6 或 7.0 這類已停止維護的舊版，Docker 是唯一能精確對齊的選項——MAMP/XAMPP 通常只提供仍在維護的版本。常見版本（7.4、8.0、8.1、8.2）用 MAMP/Laragon 會比 Docker 更快跑起來。

Docker 方式

Docker Compose V2（docker compose 指令）不需要 version 欄位。如果使用舊版 docker-compose CLI，在檔案開頭加 version: '3.8'。

 1# docker-compose.yml
 2services:
 3  web:
 4    image: php:8.1-apache
 5    volumes:
 6      - ./:/var/www/html
 7    ports:
 8      - "8080:80"
 9  db:
10    image: mysql:8.0
11    environment:
12      MYSQL_ROOT_PASSWORD: localdev
13      MYSQL_DATABASE: project
14    volumes:
15      - ./db-snapshots/initial.sql:/docker-entrypoint-initdb.d/init.sql
16    ports:
17      - "3306:3306"
18  phpmyadmin:
19    image: phpmyadmin/phpmyadmin
20    environment:
21      PMA_HOST: db
22    ports:
23      - "8081:80"

PHP 版本要對齊 prod。如果 prod 是 PHP 7.4，本地用 php:7.4-apache。版本差異會導致函式行為不同（str_contains 在 8.0 才有、mysql_* 系列在 7.0 移除），測試通過但 prod 壞掉。phpmyadmin service 讓本地也有跟 prod 相同的資料庫操作介面，方便驗證 phpMyAdmin 上要執行的操作。

匯入資料庫

Docker 啟動後匯入初始快照：

1docker exec -i project-db-1 mysql -uroot -plocaldev project < db-snapshots/20260626-initial.sql

MAMP/Laragon/XAMPP 的匯入方式：開啟對應的 phpMyAdmin（通常在 localhost/phpmyadmin）→ 選資料庫 → 匯入 → 選 .sql 檔案 → 執行。或用 DBeaver/TablePlus 連本地 MySQL 後執行 SQL 檔。

常見的「本地跑不起來」原因

本地能完整跑起來之後，這個環境就是所有變更的測試場。任何改動都先在這裡驗證。

資料庫變更紀律

phpMyAdmin 讓修改 prod DB 只需要幾次點擊，這正是它危險的原因——沒有 preview、沒有 undo、沒有 review。紀律要靠流程補上。

變更流程

1. 在本地 DB 寫好 SQL 並執行，確認結果正確
2. 把 SQL 存進 repo 的 migrations/ 目錄，檔名帶日期：

1# migrations/2026-06-26-add-status-column.sql
2ALTER TABLE orders ADD COLUMN status VARCHAR(20) DEFAULT 'pending';

3. 在 phpMyAdmin 上對要改的資料表做匯出（只匯出該表的結構 + 資料），存進 db-snapshots/ 作為回退依據
4. 在 phpMyAdmin 的 SQL 頁籤貼上已驗證的 SQL 執行
5. 在 repo 的 CHANGELOG.md 記錄：時間、操作者、改了什麼、為什麼

高風險操作的額外防護

修改欄位型別、刪除欄位、刪除資料表、批次更新資料——這些操作在 phpMyAdmin 上執行就生效，沒有乾淨的 undo。額外防護是在執行前先確認：

• 有沒有剛做的該資料表備份（不是上週的，是剛剛做的）
• 這張表有沒有 foreign key 或觸發器會連帶影響其他表
• 如果改錯了，回退的具體步驟是什麼（從備份 SQL 重建整張表？還是用 UPDATE 改回來？）

部署紀律

FTP 部署沒有 CI pipeline 的自動化保護，但不代表不能有流程。流程的目標是讓每次部署都可追溯、可回退。

部署步驟

11. git diff HEAD~1 --name-only          # 確認這次改了哪些檔案
22. 本地測試通過
33. FTP client 開兩個窗格：左邊本地、右邊 prod
44. 用 FileZilla 的目錄比較功能確認差異
55. 只上傳有變更的檔案（不要整站覆蓋）
66. 上傳完在瀏覽器驗證功能
77. git tag deploy-20260626 && git push   # 標記這次部署的版本

備份策略

無 SSH 的主機環境通常不提供自動快照。備份要自己做：

如果主機面板有自動備份功能（cPanel 的 Backup Wizard），確認它有開並且能還原。但不要把它當唯一備份——主機商的備份可能在主機出問題時一起不見。

備份自動化（沒 SSH 也能做）

無 SSH 的環境沒有 cron + CLI 的組合，但可以用本機排程 + FTP client 的 CLI 模式達成自動化備份。

用 lftp（macOS/Linux 可透過 Homebrew 或 apt 安裝）做定期站台鏡像：

1# backup.sh — 加入本機的 cron 或 launchd 每日執行
2lftp -e "mirror --verbose /public_html/ /local/backup/site/; quit" \
3  -u username,password ftp.example.com

rclone 是另一個選項，支援 FTP/SFTP 且有更好的增量同步（只傳有變更的檔案）：

1# 設定 rclone remote（首次）
2rclone config  # 選 FTP、填入主機資訊
3
4# 同步（之後每次只傳差異）
5rclone sync myhost:/public_html/ /local/backup/site/ --progress

macOS 用 launchd plist、Windows 用工作排程器（Task Scheduler）排定每日執行這些腳本，讓備份不再依賴人工記得。

資料庫的自動備份較受限——phpMyAdmin 沒有 CLI 介面。如果主機允許遠端 MySQL 連線，可以在本機 cron 裡加一條 mysqldump：

1mysqldump -h mysql.example.com -u dbuser -p'password' dbname | gzip > /local/backup/db/$(date +%Y%m%d).sql.gz

不允許遠端連線時，退而求其次：每週手動從 phpMyAdmin 匯出一次、存進 repo。

回退方式

FTP 部署沒有 rollback 按鈕。回退的方式是：

1git checkout deploy-20260625 -- path/to/changed/file.php
2# 把特定檔案回到上一次部署的版本，再 FTP 上傳

整站回退則是 checkout 到上一個 deploy tag，再整批 FTP 上傳。這就是為什麼 deploy tag 重要——沒有 tag 就不知道要回退到哪個版本。

credential 盤點與保護

接手後要回答的問題是：有哪些 credential、誰有存取權、哪些需要輪替。

盤點清單

最高優先輪替的是前人可能仍持有存取權的 credential：主機面板密碼、資料庫密碼。如果前人的離開不是善意的（被解僱、爭端），這些應該在接手的第一天就改。

從 hardcode 到 config 分離

長期目標是把 credential 從 code 裡搬出來。即使在沒有 SSH 的環境也能做：

1// 改前：password 直接寫在 code 裡
2$db_password = 'p@ssw0rd123';
3
4// 改後：從 .env 讀取（用 vlucas/phpdotenv 或手寫 parse）
5$db_password = getenv('DB_PASSWORD') ?: parse_ini_file(__DIR__ . '/.env')['DB_PASSWORD'];

.env 放在 webroot 之外（如果主機允許）或在 .htaccess 裡禁止存取：

1<Files ".env">
2    Require all denied
3</Files>

外部監控（prod 不用裝東西）

無 SSH 的環境裝不了監控 agent，但可以用外部 HTTP 檢查服務從外面看。這類服務從多個地理位置定期對網站發送 HTTP request，回應異常時通知。

UptimeRobot 的免費方案提供 50 個 monitor、每 5 分鐘檢查一次，夠用於一個站台的首頁 + 幾個關鍵頁面（登入頁、API endpoint、金流回呼 URL）。Better Stack（原 Better Uptime）提供類似功能並附帶 status page。兩者都只需要填入 URL 和通知方式（email / Slack / webhook），不需要在 server 上裝任何東西。

設定後至少加三個 monitor：首頁（網站是否活著）、登入或後台入口（PHP 是否正常執行）、以及任何有外部依賴的頁面（金流 callback、API endpoint）。這不是完整的可觀測性，但至少讓「網站掛了」這件事從「使用者打電話來」變成「手機收到通知」。

時程參考

完整走完盤點（FTP mirror + DB dump + 環境記錄）約需半天到一天。本地環境建立與驗證約需半天到一天（取決於 PHP 版本對齊的難度）。紀律建立（changelog + 部署流程）是持續的、但框架搭建約需 2-3 小時。CI 化 FTP 部署約需半天。整體從接手到穩定維運約 2-3 個工作天。

升級路徑的切入點

接手穩定後，逐步脫離無 SSH 環境的約束。每一步都獨立且可回退。

最低成本的第一步：CI 化 FTP 部署

在 GitHub repo 設定 GitHub Actions，推到 main 時自動跑測試（如果有的話）+ 自動 FTP 部署。FTP credential 存在 GitHub Secrets 裡，不在 code 裡。

 1# .github/workflows/deploy.yml
 2name: Deploy via FTP
 3on:
 4  push:
 5    branches: [main]
 6jobs:
 7  deploy:
 8    runs-on: ubuntu-latest
 9    steps:
10      - uses: actions/checkout@v4
11      - uses: SamKirkland/FTP-Deploy-Action@v4
12        with:
13          server: ${{ secrets.FTP_HOST }}
14          username: ${{ secrets.FTP_USER }}
15          password: ${{ secrets.FTP_PASS }}
16          server-dir: /public_html/

這一步的價值是部署從「開 FileZilla 手動上傳」變成「push to main 自動部署」，人為失誤的空間顯著縮小。Prod 伺服器不需要任何改動。

下一步：遷移到有 SSH 的 VPS

當以下任一條件出現時，無 SSH 環境的約束會變成瓶頸：

• 需要 SSH 存取（裝 Git、跑 CLI 工具、設排程）
• 需要自訂 PHP extension 或 PHP 版本
• 需要更多的運算資源或記憶體
• 需要環境分離（dev / staging / prod）

遷移到 VPS（DigitalOcean、Linode、AWS Lightsail）後，SSH 存取讓所有雲端環境的工具鏈成為可用——Git on server、composer、artisan、mysqldump CLI、cron 的完整控制。這一步之後，接手維運的環境開始對齊模組負一：還沒有 infra 的環境的操作紀律，後續可以按成熟度階梯逐步往 IaC 推進。

跨分類引用

• → 有 SSH 但沒有 IaC 的雲端環境接管：搬到 VPS 或雲端後的接管流程
• → 模組負一：還沒有 infra 的環境：接手完成、環境穩定後，操作紀律對齊這裡
• → 模組零：infra 是什麼：成熟度階梯作為接手後評估現況的座標
• → 模組二：身分與憑證地基：credential 盤點與輪替的系統性設計
• → 模組八：治理好習慣：tagging、secret 管理、成本可見性

這篇文章建立四層邊界：最外層的 VPC 隔離、中層的 public / private subnet 切分、流量進出的 route table 與 NAT、以及最貼近服務的 security group。每一層解決的問題不同，疊起來才是一個可審計、可收斂的網路。

VPC：網路隔離的最外層邊界

VPC（Virtual Private Cloud）先圈定整個系統的網路地址空間 — 一塊邏輯隔離的私有網段，是其餘所有網路切分的起點。在 VPC 裡開出來的所有資源預設只看得到同一個 VPC 內的成員，與其他 VPC、與其他帳號的網路天然隔離。它是後面所有切分動作的容器 — 沒有 VPC，subnet 與 security group 無處依附。

CIDR 規劃：一次決定、事後難改

建立 VPC 時最關鍵的決策是 CIDR 區塊的大小。這個範圍要一次規劃足夠大，因為事後擴張地址空間在多數雲上是麻煩且容易出錯的操作。AWS 雖然允許在 VPC 上追加 secondary CIDR，但追加的網段不能與原有的重疊，也不是所有服務都能自然使用跨 CIDR 的 subnet，routing 的複雜度會因此上升。

CIDR 規劃要同時考慮三件事。第一是容量：/16 提供約六萬五千個位址，對多數單一環境的 VPC 足夠寬裕，切成 /24 的 subnet 也有 256 個可用子網。第二是不重疊：未來若要透過 VPC peering、Transit Gateway 或 VPN 把這個 VPC 接回地端機房或其他環境，重疊的 CIDR 會讓路由無法解析。三個環境各自是 10.0.0.0/16，在彼此不需要互連時不是問題，但一旦要開 peering 就會撞車 — 這時候改 CIDR 的代價是重建整個 VPC。第三是預留：如果公司同時有多個 VPC（不同環境或不同產品線），用連續但不重疊的大段分配（如 dev 10.0.0.0/16、staging 10.1.0.0/16、prod 10.2.0.0/16）讓路由表更乾淨。

 1resource "aws_vpc" "main" {
 2  cidr_block           = "10.0.0.0/16"
 3  enable_dns_support   = true
 4  enable_dns_hostnames = true
 5
 6  tags = {
 7    Name        = "platform-prod"
 8    Environment = "production"
 9  }
10}

enable_dns_support 和 enable_dns_hostnames 在多數場景都該開啟。沒開 DNS hostname 時，EC2 instance 不會拿到可解析的 hostname，某些服務依賴 DNS 尋址而非 IP（如 VPC endpoint 的 private DNS），關著會讓它們靜靜失敗而不報錯。

判讀訊號：規劃 CIDR 時先問「這個環境三年後會有幾個 subnet、跨幾個可用區、要不要跟其他 VPC 或地端互連」。風險集中在地址耗盡與網段衝突 — 兩者都得在開第一個 subnet 之前定案。VPC 只負責隔離與定址，它不決定哪個服務能對外，那是 subnet 與 security group 的工作。環境之間的 VPC 該怎麼分，是模組四：環境分離與模組化的主題。

public 與 private subnet 的切分原則

一塊資源對外暴露到什麼程度，取決於它被放進哪個 subnet。VPC 內部按可用區與暴露程度切出來的子網段，決定資源有沒有一條通往網際網路的路徑。判斷一個資源該放 public 還是 private，問題只有一個：它需不需要被網際網路直接定址。

兩類 subnet 的定位

public subnet 放的是必須接收外部入站流量的元件 — 對外的負載平衡器、NAT Gateway、堡壘主機（bastion）。這些資源透過 route table 連到 Internet Gateway，因此能被外部 IP 直接觸及。private subnet 放的是只該在內網被存取的元件 — 應用伺服器、資料庫、快取、內部佇列。它們沒有通往 Internet Gateway 的路由，外部無法主動連入，需要對外時才透過 NAT 出去。

public subnet 的真實樣貌是「薄薄一層」：它通常只住負載平衡器與 NAT 這類入口設施，而不是業務邏輯。常見陷阱是為了 SSH 方便把應用伺服器直接開在 public subnet 並配公網 IP，等於把每一台業務主機的管理埠暴露在掃描流量下 — 全球的 bot 會在秒級頻率對公網 IP 的 22 埠嘗試登入。private subnet 的住戶反而是系統的主體 — 資料庫放這裡是因為它一旦能被外網定址，攻擊面就從「打穿入口層」變成「直接連資料庫埠試密碼」。

跨可用區冗餘

每個 subnet 綁定單一可用區（Availability Zone）。高可用設計通常是每種角色跨至少兩個可用區各開一個 subnet：兩個 public、兩個 private，讓單一可用區故障時另一區的同類 subnet 還能承接。subnet 的 CIDR 切法要留足空間 — 如果 VPC 是 /16，每個 subnet 用 /20（約四千個位址）可以在三個可用區各開 public + private 共六個 subnet，還有大量空間留給未來擴展。

 1locals {
 2  azs = ["ap-northeast-1a", "ap-northeast-1c", "ap-northeast-1d"]
 3}
 4
 5resource "aws_subnet" "public" {
 6  for_each          = toset(local.azs)
 7  vpc_id            = aws_vpc.main.id
 8  cidr_block        = cidrsubnet(aws_vpc.main.cidr_block, 4, index(local.azs, each.key))
 9  availability_zone = each.key
10
11  tags = { Name = "public-${each.key}" }
12}
13
14resource "aws_subnet" "private" {
15  for_each          = toset(local.azs)
16  vpc_id            = aws_vpc.main.id
17  cidr_block        = cidrsubnet(aws_vpc.main.cidr_block, 4, index(local.azs, each.key) + length(local.azs))
18  availability_zone = each.key
19
20  tags = { Name = "private-${each.key}" }
21}

cidrsubnet 函式自動切分子網段，避免手動計算 CIDR。第二個參數 4 表示在 /16 基礎上加 4 bit 得到 /20，第三個參數是序號。public 與 private 各佔不同序號區間，保證不重疊。

對外入口怎麼把流量分到跨可用區的 private 後端，是 devops 層負載平衡的範圍。這裡只要確保 subnet 的地圖在多 AZ 下對稱。

route table 與 NAT：流量的進出路徑

離開一個 subnet 的封包往哪走，逐條寫在 route table 這組轉送規則裡 — 它掛在 subnet 上，是封包出口方向的依據。一個 subnet 是 public 還是 private，技術上的差別就在它關聯的 route table 裡有沒有一條指向 Internet Gateway 的預設路由。subnet 的對外性質由它關聯的 route table 賦予，而非寫在 subnet 自身的屬性。

public 與 private 的路由差異

public subnet 的 route table 有一條 0.0.0.0/0 → Internet Gateway，讓未知目的地的流量直接出網、也讓外部可達。private subnet 的 route table 則把 0.0.0.0/0 指向 NAT Gateway。

NAT（Network Address Translation）解決的問題是：private subnet 的資源需要主動對外（拉套件、呼叫第三方 API、抓 OS 更新），但不能因此變得可被外部入站連入。NAT 讓出站流量借用一個公網位址出去、把回應導回原請求者，同時不開放任何外部主動發起的連線。

每 AZ 一個 NAT vs 共享 NAT 的取捨

NAT Gateway 是綁定單一可用區的資源 — 一個 NAT Gateway 活在某一個 public subnet，也就活在那個可用區裡。這帶來一個架構取捨：

共享 NAT（成本優先）：全部 private subnet 的 route table 都指向同一個 NAT。用一份 NAT 成本服務整個 VPC，代價是把 NAT 所在的可用區變成出站方向的單點 — 該可用區故障時，所有 private subnet 的對外連線同時中斷，即使其他可用區的節點本身健康。

每 AZ 一個 NAT（可用性優先）：每個可用區各放一個 NAT Gateway，並讓每一區的 private subnet route table 指向同區的 NAT。出站路徑與 subnet 的跨可用區冗餘對齊，單一 AZ 故障只影響該區。每個 NAT Gateway 的固定月費約 $32 加流量費 $0.045/GB 處理量。三個可用區各一個就是三倍固定費。這筆成本與業務對出站中斷的容忍度對齊——如果單一可用區故障導致全部出站中斷可接受（例如有重試機制），共享 NAT 的成本效益較高。

 1resource "aws_eip" "nat" {
 2  for_each = toset(local.azs)
 3  domain   = "vpc"
 4  tags     = { Name = "nat-${each.key}" }
 5}
 6
 7resource "aws_nat_gateway" "per_az" {
 8  for_each      = aws_subnet.public
 9  allocation_id = aws_eip.nat[each.key].id
10  subnet_id     = each.value.id
11  tags          = { Name = "nat-${each.key}" }
12}
13
14resource "aws_route_table" "private" {
15  for_each = aws_subnet.private
16  vpc_id   = aws_vpc.main.id
17
18  route {
19    cidr_block     = "0.0.0.0/0"
20    nat_gateway_id = aws_nat_gateway.per_az[each.key].id
21  }
22
23  tags = { Name = "private-rt-${each.key}" }
24}
25
26resource "aws_route_table_association" "private" {
27  for_each       = aws_subnet.private
28  subnet_id      = each.value.id
29  route_table_id = aws_route_table.private[each.key].id
30}

判讀訊號：private subnet 的服務拉不到外部套件、或第三方 API 全部逾時，先查它關聯的 route table 有沒有指向健康的 NAT；若只有某一個可用區的節點受影響，多半是那一區的 NAT 或其所在 subnet 出狀況。

NAT 的成本邊界

NAT Gateway 按處理流量計費（每 GB 一個費率），把大量出站流量長期走 NAT 會讓帳單可觀。常見的高流量場景包括：備份上傳到 S3、跨區資料同步、大量 API 呼叫。對於走向 AWS 自家服務的流量，成本效益較好的做法是用 VPC Endpoint（Gateway 型或 Interface 型）讓流量直連服務、繞過 NAT。S3 與 DynamoDB 的 Gateway Endpoint 是免費的，光是把 S3 備份流量從 NAT 改走 Gateway Endpoint 就能在流量大的環境省下可觀的費用。

1resource "aws_vpc_endpoint" "s3" {
2  vpc_id       = aws_vpc.main.id
3  service_name = "com.amazonaws.ap-northeast-1.s3"
4
5  route_table_ids = [for rt in aws_route_table.private : rt.id]
6
7  tags = { Name = "s3-gateway-endpoint" }
8}

NAT 的數量取捨與出站成本的更完整討論在 devops 模組八：成本管理。route table 與 NAT 只管「能不能出去、走哪條路」，至於某個埠允不允許連，是 security group 的職責。

security group 設計：最小開放

一條連線究竟能不能打到某個埠，由 security group 逐埠拍板 — 它是掛在資源網卡（ENI）層級的有狀態防火牆，規則描述的是哪些來源連得進這個資源。它是貼著服務的最後一道網路邊界 — 即使封包順著 route table 抵達了 private subnet，security group 仍能逐埠決定放不放行。「有狀態」的意思是：放行一條入站連線後，對應的回應出站自動允許，規則只需描述入站方向想開放什麼。

用 group 引用取代 IP 範圍

設計原則是最小開放：每條規則只開「這個服務確實需要被誰連的那個埠」。資料庫的 security group 入站只允許來自應用層 security group 的資料庫埠，而不是某個 IP 範圍。用 security group 互相引用、而非寫死網段，是因為應用節點會隨擴縮而換 IP — 引用來源 group 讓規則跟著成員身分走、不跟著位址走。

 1resource "aws_security_group" "app" {
 2  name_prefix = "app-"
 3  vpc_id      = aws_vpc.main.id
 4  tags        = { Name = "app-sg" }
 5}
 6
 7resource "aws_security_group" "database" {
 8  name_prefix = "db-"
 9  vpc_id      = aws_vpc.main.id
10  tags        = { Name = "db-sg" }
11}
12
13resource "aws_security_group_rule" "db_from_app" {
14  type                     = "ingress"
15  from_port                = 5432
16  to_port                  = 5432
17  protocol                 = "tcp"
18  security_group_id        = aws_security_group.database.id
19  source_security_group_id = aws_security_group.app.id
20}

這條規則表達的語意是「資料庫只接受來自 app group 成員的 5432 連線」。app 的 instance 數量從 2 台增長到 20 台時，規則本身不需要改 — 新 instance 只要也掛了 app 的 security group 就自動被允許。

0.0.0.0/0 的盤點紀律

把入站來源設成 0.0.0.0/0 等於允許整個網際網路連這個埠。對資料庫埠（5432、3306、6379）或管理埠（22、3389）這麼做，會讓服務暴露在持續性的自動掃描與暴力嘗試下。

合理出現 0.0.0.0/0 的位置只有對外負載平衡器的 80 / 443 入站 — 因為它的工作本來就是接收公開流量。其餘所有 0.0.0.0/0 都該被質疑。

盤點的做法：列出所有 security group，過濾 source 是 0.0.0.0/0 的 ingress rule，逐條問「這個埠確實需要全世界都連得到嗎」。在 CLI 上可以用一條查詢掃：

1aws ec2 describe-security-groups \
2  --query 'SecurityGroups[].{
3    ID:GroupId,
4    Name:GroupName,
5    OpenPorts:IpPermissions[?IpRanges[?CidrIp==`0.0.0.0/0`]].[FromPort,ToPort]
6  }' \
7  --output table

資料庫埠、SSH、內部 API 出現在這份清單上就是該收斂的目標。管理埠的存取更安全的替代方案是 SSM Session Manager — 它讓你透過 IAM 權限建立 shell session，完全不需要開 22 埠，連線經由 Systems Manager 的控制通道走、不走公網，同時自動留下 session log。誰能透過 IAM 改動這些規則，銜接模組二：身分與憑證地基。

在 CI 層面，模組七：infra 走 PR 流程用 tfsec / checkov 做靜態掃描，自動攔截「敏感埠 + 全開 CIDR」的組合，把 security group 的盤點從人工定期做變成每次 PR 自動做。

邊界設備漏洞帶來的教訓同樣適用於 security group 設計。Check Point CVE-2024-24919 事件顯示 VPN 邊界設備的資訊外洩漏洞可以直接轉為憑證與會話濫用，攻擊路徑是「邊界入口 → 會話竊取 → 內部橫向擴散」。Citrix Bleed 2023 則是邊界設備的會話資料外洩導致重放攻擊。這兩個案例的 infra 層教訓是：邊界設備（VPN concentrator、ADC、bastion）的 security group 只開必要的管理埠，且事件後需要全域 session/token 失效流程。

網路控制面的自動化也有風險。Cloudflare 2026 Route Leak 事件中，自動化路由政策配置的錯誤導致流量擁塞。infra 層的教訓是：路由與 security group 規則的自動化變更需要 pre-check 與影響範圍評估，且要有快速撤回機制——這正是 infra 走 PR 流程的 plan → review → apply 流程要擋的。

NACL 與 security group 的分工

subnet 這一層還有另一道防火牆 — network ACL（NACL），它與 security group 分工在兩個層級。

NACL 的特點是無狀態與支援顯式 deny。無狀態意味著放行了入站不代表回應的出站自動放行，回程封包得自己對得上另一條出站規則 — 這讓 NACL 的維護比 security group 複雜。支援顯式 deny 則是它獨有的能力：security group 只能說「誰可以進」，NACL 能說「誰一定不能進」，這在需要 subnet 邊界封鎖特定已知惡意網段時有用。

多數設計的主力是 security group：它貼著服務、用 group 互相引用就能表達「誰能連誰」，已經涵蓋大部分最小開放需求。NACL 留給少數情境 — 需要在 subnet 邊界擋掉一整段已知惡意網段、或要對某類流量做顯式 deny 時才展開。多數環境讓 NACL 維持預設全通、把存取控制集中在 security group，是可以接受的選擇。重點是知道這一層存在、在需要 subnet 層粗篩時記得它。

為什麼網路要先於核心服務鋪好

網路地基先行，是因為核心服務的安全位置由網路拓樸決定，而不是反過來。資料庫該落在哪個 private subnet、它的 security group 只接受哪個來源、它的出站走不走 NAT — 這些都是服務「出生時」就該確定的屬性。

先有規劃好的 subnet 與 security group，新服務上線只是挑一塊已定義安全等級的位置放進去。網路還沒鋪就先開服務，則往往落在預設 VPC 與寬鬆規則上。預設 VPC 是所有人共享的、CIDR 不可控的、security group 預設全通的 — 把正式服務放在這裡，等於跳過了所有隔離設計。事後再回頭收斂，要在服務已經有流量、有依賴的情況下改網段與防火牆，風險和協調成本都高得多。

這也呼應模組零：infra 是什麼的 day-1 鐵律：邊界與隔離屬於一開始就該存在的地基，不是長出問題後才補的修補。網路規劃好之後，照「從零建置」路線下一步先進模組四：環境分離與模組化確定環境怎麼切，再讓核心服務落進這些 subnet（見模組五：核心服務上 IaC）。

跨分類引用

• → 模組二：身分與憑證地基：誰有權改動 security group 與路由表
• → 模組四：環境分離與模組化：環境之間的 VPC 怎麼分
• → 模組五：核心服務上 IaC：核心服務怎麼落進規劃好的 subnet
• → 模組七：infra 走 PR 流程：tfsec / checkov 自動攔截 security group 全開
• → devops 模組八：成本管理：NAT 與出站流量的成本取捨
• → Security Group 稽核與清理：SG 規則盤點、未使用 SG 識別、清理工作流

IaC 工具選型：宣告式狀態管理 vs 程式語言抽象

IaC 工具的核心職責是把「我要的基礎設施長什麼樣」描述成可版本控制的程式碼，再由工具負責算出現況與目標的差異並收斂。市場上的工具分成兩條路線，差別落在「用什麼語言描述」與「狀態由誰持有」這兩個軸上，而非功能多寡。

第一條路線是宣告式 DSL，代表是 Terraform 與其開源分支 OpenTofu。寫的是 HCL，描述的是資源的最終樣貌，工具自己維護一份 state 來追蹤每個資源的真實 ID 與屬性。這條路線適合團隊成員背景混雜、需要讓非專職後端的人也能讀懂 infra 定義的情境 — HCL 的閱讀門檻低，diff 直觀，review 時看得出「這個 PR 會新增一個 RDS、改掉一條 security group」。

第二條路線是用通用程式語言寫 infra，代表是 AWS CDK 與 Pulumi。寫的是 TypeScript、Python、Go 這類語言，靠迴圈、函式、類別來生成資源。這條路線適合 infra 邏輯本身複雜、需要大量條件分支與抽象複用的團隊，例如要根據環境清單動態生成數十組對稱資源。代價是 review 難度上升：一段 for 迴圈展開後到底建了哪些東西，得在腦中執行程式才看得出來，diff 不再等於變更本身。

CDK 與 Pulumi 同屬程式語言路線，但「狀態由誰持有」這個軸把它們再分開。CDK 把程式碼 synth 成 CloudFormation 模板，再交給 CloudFormation 服務端執行與追蹤，state 由 AWS 代管 — 沒有一份 tfstate 檔要自己存放、加密、回捲，也不需要額外的鎖表來防並行，這份「狀態維運外包給雲端」正是 CDK 在 AWS 生態內的賣點之一，代價是綁定 CloudFormation 與單一雲。Pulumi 走的是另一邊：它維護一份自己的 state，預設交給 Pulumi Cloud 託管，也能改用 S3 之類的後端自管 — 形態上更接近 Terraform 的 state 模型，state 的存放、保護與並行控制重回團隊手上。同一條程式語言路線，選 CDK 等於把 state 責任讓給雲端，選 Pulumi 則保留對 state 落點的掌控。

選型看的是團隊組成與變更的審查需求。若多數變更要跨職能 review、希望 diff 一眼可讀，宣告式 DSL 較划算；若 infra 由專職平台團隊維護、抽象複用的收益大於審查透明度的損失，程式語言路線較划算。Terraform 與 OpenTofu 之間，OpenTofu 是授權變更後社群分叉出的相容實作，HCL 與 provider 生態幾乎共用；選擇主要看對授權條款與治理模式的偏好，技術判準在這一階沒有實質差異。本模組後續一律以 HCL 示意，換成任一宣告式工具判準仍成立。

state 是工具對現實的唯一記憶

state 是 IaC 工具用來記錄「上一次 apply 之後，每個資源在雲端真實長什麼樣」的快照，它的作用是讓工具能算出「現況」與「目標」之間的最小差異。沒有 state，工具每次都得把所有資源重新查一遍才知道該不該動，而且無法分辨「這個資源是我建的、該由我管」還是「別人手動建的、不歸我管」。

state 裡通常含有資源的真實 ID、相依關係，以及部分敏感屬性 — 例如資料庫的初始密碼、private key 的輸出值。這帶來兩條邊界。

第一條：state 絕不能進 git。state 含明文敏感值，一旦推進版控就等於把密碼寫進每個 clone 的歷史裡，事後 rotate 也清不掉 git 歷史。

第二條：state 不能只放本地。本地 state 的失敗模式是它把整份基礎設施的記憶綁在一台筆電上 — 換人接手、換台機器、或多人同時 apply 時，記憶就分裂了。兩個人各自拿著不同版本的本地 state 去 apply，工具會用各自過時的記憶去算差異，互相把對方建的資源判定成「不該存在、刪掉」，基礎設施被反覆來回破壞。

這兩條邊界共同指向同一個結論：state 需要一個團隊共享、有版本、有存取控制、且能防止同時寫入的存放處。這就是 remote state backend 要解的問題。

remote state backend：自管 vs 託管

remote state backend 是把 state 從本地移到團隊共享儲存的機制，它要同時滿足三件事：持久保存、防止並行寫入衝突、以及保護敏感內容。達成方式分成自管儲存與託管服務兩種，差別在維運責任落在誰身上。

自管路線以雲端物件儲存加鎖機制為典型組合。以 AWS 為例，state 檔放 S3、用一張鎖表防止兩個人同時 apply：

1terraform {
2  backend "s3" {
3    bucket         = "acme-tf-state"
4    key            = "prod/network/terraform.tfstate"
5    region         = "ap-northeast-1"
6    encrypt        = true
7    dynamodb_table = "acme-tf-lock"
8  }
9}

這段設定的每一項都對應前一節的一條邊界，值得逐項拆開。encrypt = true 讓 state 在 S3 落地時加密，回應「state 含敏感值」的風險。承載 state 的 bucket 必須開 versioning：apply 寫壞或誤刪 state 時，versioning 是把記憶回捲到上一個正確版本的唯一退路，沒開的話一次壞寫就讓工具失去對現實的記憶。dynamodb_table 指向一張鎖表，apply 開始時寫入一筆鎖、結束才釋放，第二個人同時跑就會被擋下並提示鎖被誰持有 — 這正是本地 state 無法提供、卻是多人協作底線的並行保護。key 則是 state 在 bucket 內的路徑，這裡先用 prod/network 之類的分層命名，實際怎麼依環境切分 state 留待模組四：環境分離與模組化展開。

託管路線把這些維運細節包起來，由 Terraform Cloud、Spacelift 這類平台代管 state、鎖與加密，附帶 web UI 與 audit log。判讀訊號是團隊規模與維運餘裕：自管 backend 的成本是要自己把 bucket versioning、加密、鎖表、IAM 權限配對，配錯任何一項都可能讓 state 失去保護；託管服務用月費換掉這份配置與維運負擔，代價是 state 託付給第三方、且進階治理功能常綁在付費級距。小團隊起步、不想第一週就花在配 backend 上，託管較划算；對 state 存放位置有合規或主權要求、或希望基礎設施盡量自持的團隊，自管較划算。

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

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

這種 state 與現實的分歧叫 drift。drift 的代價會延遲引爆，而非當下浮現。某人在 Console 臨時把一條 security group 規則打開救火，state 並不知道；下一次別人為了不相干的變更跑 apply，工具拿過時的 state 去比對，會把那條手動規則判定成「不在我的記憶裡、刪掉」，於是悄悄關掉，救火的洞重新出現，而且沒人在 PR 裡看得到這件事發生過。Console 改得越多、與程式碼分歧越久，某次例行 apply 就越可能掃掉一批沒人記得的手動設定。

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

1terraform import aws_security_group.web sg-0abc123def456

import 只把資源 ID 寫進 state，不會幫忙生程式碼。那個資源在 Console 上被點出來的每一個屬性 — 每條 ingress 規則、每個 tag、每項關聯設定 — 都得一字不差地補成 HCL，任何一項對不上，下次 apply 就會試圖把現實改回程式碼寫的版本。一個資源還能忍，等到累積了幾十個各自手動微調過的資源才想納管，逆向工程的工作量會大到讓人乾脆放棄，基礎設施就此分裂成「程式碼管的」與「沒人敢動的」兩塊。第一天就立鐵律，要納管的存量永遠是零。

讓鐵律落地靠的是權限、不是自律。光靠約定「別在 Console 改」撐不久，救火當下手最快的永遠是 Console。真正讓鐵律站得住的，是把人的日常身分收斂成唯讀、把寫入權限留給跑 apply 的自動化身分，讓「在 Console 改不動」變成預設狀態 — 這道權限地基屬於模組二：身分與憑證地基的範圍，本階先確立紀律方向。

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

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

這一階的最小集合通常包含：一個設定好 versioning、加密與鎖表的 remote state backend；一個收斂後人類唯讀的身分權限基線；一個能放東西的網路骨架（一個 VPC 加最少的 subnet）；以及一個微不足道但真實存在的資源（例如一個 S3 bucket 或一台最小的測試機），用來證明 apply 確實作用到了雲端。把這個微小資源刻意留在最小集合裡，是因為它是最便宜的端到端驗證 — apply 跑完後它真的出現、terraform destroy 後它真的消失，就證明從程式碼到雲端的整條鏈路是通的。

刻意不放進來的東西同樣重要：正式的應用服務、資料庫、跨環境的複製、複雜的模組抽象，全部留到地基驗證通過之後。在 state 與 Console 唯讀都還沒站穩前就堆服務，等於把房子蓋在還沒灌漿的地基上。網路骨架怎麼長、身分怎麼切，分別由模組三：網路地基與模組二：身分與憑證地基接手深入；這一階只需要它們各自最薄的一層，湊出一個能 apply、能 destroy、能交接的閉環。

第一篇文章開頭有一段「動手前的前提」，列出寫第一行 IaC 之前需要就位的前置條件（雲端帳號 + MFA、CLI 工具安裝、雲端認證、Git repo 初始化）。已經備妥的讀者可以跳過。

章節文章

跨分類引用

• → 模組二：身分與憑證地基：Console 唯讀鐵律靠權限落地，人類唯讀、自動化身分持有寫入權
• → 模組三：網路地基：最小集合裡的 VPC 與 subnet 怎麼設計
• → 模組四：環境分離與模組化：state 的 key 怎麼依環境切分、state 跟環境怎麼對應
• → 模組七：infra 走 PR 流程：state 變更與 apply 怎麼納入 review
• → 接手維運：接手既有環境後的 IaC 導入路徑

環境分離從第一天的目錄結構就定好

環境分離的本質是把「同一套基礎設施定義」複製成多份隔離的執行實例，每份有自己的 state、自己的雲端資源、自己的故障半徑。它承擔的責任是讓 dev 的實驗、staging 的驗證、prod 的真實流量彼此不可見也不可達 — 在 dev 跑壞一個資料庫、套錯一條 security group 規則，prod 完全無感。

這個邊界要在第一天就用目錄結構表達出來，原因是 state 一旦混在一起就難以無痛拆開。Terraform 這類工具用 state 檔記錄「哪個資源由哪段 code 管理」，如果 dev 跟 prod 的資源都登記在同一份 state，後續想把 prod 移出去，等於要對正在服務的資源做 state mv 或 import/remove 操作 — 任何一步算錯，工具可能判定資源該銷毀重建，而那是 prod 的資料庫。第一天就分目錄，dev 與 prod 從來不曾共用 state，這個風險根本不存在。

檢查自己的 repo：如果現在只有一份 main.tf、裡面同時宣告了 dev-db 跟 prod-db，或者 terraform.tfstate 裡同時記錄了兩個環境的資源，這個專案已經欠下環境分離的債，債齡每天都在增加。下一步路由是先確立目錄骨架，再決定差異怎麼參數化。

目錄分離 vs Terraform workspace 的取捨

切分環境有兩條主流路徑：每個環境一個獨立目錄（各自持有 backend 與 state），或共用一份 code 用 Terraform workspace 切換不同 state。兩者都能讓 state 隔離，差別在「環境差異藏在哪裡」以及「誤操作的故障半徑多大」。

隔離強度光譜

在挑這兩條路之前，先把它們放回完整的分離強度光譜。環境分離橫跨一條從帳號到 workspace、隔離由粗到細的階梯：

光譜越靠粗的一端，隔離越強、跨環境共用越少、初始與維運成本越高；越靠細的一端，重複越少、邊界越隱性。多數早期團隊在目錄分離這一格落腳，因為它在顯式邊界與維運成本之間平衡得宜。當隔離需求升高（例如 prod 要法規等級的帳務與權限隔離），再沿光譜往帳號級或獨立 repo 移。帳號級隔離的權限邊界設計見模組二：身分與憑證地基。

目錄分離的結構

目錄分離把每個環境寫成可獨立進入的工作目錄，差異透過各自的 terraform.tfvars 表達，prod 的 backend 設定、變數值、甚至 provider 版本都各自鎖定。

 1infra/
 2├── modules/                  # 可重用模組、不含任何環境專屬值
 3│   ├── network/
 4│   ├── database/
 5│   └── service/
 6└── environments/
 7    ├── dev/
 8    │   ├── main.tf           # 呼叫 modules、傳 dev 參數
 9    │   ├── backend.tf        # state 指向 dev 專屬位址
10    │   └── terraform.tfvars  # dev 的差異值
11    ├── staging/
12    │   └── ...
13    └── prod/
14        ├── main.tf
15        ├── backend.tf        # state 指向 prod 專屬位址
16        └── terraform.tfvars  # prod 的差異值

它的代價是目錄之間有重複的 boilerplate（main.tf 裡的 module 呼叫在每個環境幾乎一樣），好處是邊界顯式 — cd 進哪個目錄、apply 就只會動那個環境，prod 的 state 位址寫死在 prod 目錄的 backend 設定裡，不會因為忘記切換而打錯環境。

每個環境目錄的 backend.tf 各自指向獨立的 state 路徑，這是邊界的物理保證：

 1# environments/prod/backend.tf
 2terraform {
 3  backend "s3" {
 4    bucket         = "acme-tf-state"
 5    key            = "prod/terraform.tfstate"
 6    region         = "ap-northeast-1"
 7    encrypt        = true
 8    dynamodb_table = "acme-tf-lock"
 9  }
10}

 1# environments/dev/backend.tf
 2terraform {
 3  backend "s3" {
 4    bucket         = "acme-tf-state"
 5    key            = "dev/terraform.tfstate"
 6    region         = "ap-northeast-1"
 7    encrypt        = true
 8    dynamodb_table = "acme-tf-lock"
 9  }
10}

Terragrunt 收斂 boilerplate

目錄分離的 boilerplate 重複可以用 Terragrunt 收斂。Terragrunt 的存在理由正是把跨環境目錄共通的 backend、provider、module 呼叫抽成一份範本，各環境目錄只留差異值，等於在保留目錄顯式邊界的前提下補上一層 DRY。它值得引入的情境是環境數量多（超過三個）、共通 boilerplate 開始拖慢維護時；環境只有兩三個時，直接維護幾份目錄的成本通常還低於多引入一個工具與它的學習曲線。

Workspace 的邊界

Workspace 共用同一份 code、用 terraform workspace select prod 在執行期切換 state。它的好處是零重複，所有環境的 code 保證同步；代價是環境差異只能靠 terraform.workspace 在 code 裡寫條件判斷，而當前選中哪個 workspace 是 shell 的隱性狀態。

這個隱性狀態正是早期最該避免的失誤來源。在 dev workspace 以為自己在改 dev、其實上一個指令切到了 prod，apply 下去才發現故障半徑是 prod。沒有任何檔案層級的信號能防止這件事 — workspace 的當前狀態存在本地的 .terraform/ 目錄裡，git diff 看不到、code review 也看不到。

早期推薦目錄分離，理由是故障半徑與認知負荷的取捨在小團隊明顯偏向「顯式邊界」這一側：團隊還沒有成熟的 CI gate 攔截誤 apply，顯式目錄是最便宜的防呆。Workspace 較划算的情境是環境數量多且高度同構（例如每個客戶一個隔離環境、差異只有名稱與配額），重複目錄的維護成本開始超過 workspace 隱性狀態的風險時，再切過去。每個環境的 state 要怎麼各自隔離、backend 怎麼設定，見模組一：最小可行 IaC。

module 化：同一套 code、不同參數

Module 是把一組會被多環境重複使用的資源封裝成有輸入參數的單元，承擔的責任是讓 dev 與 prod 共享同一份邏輯定義、只在參數上分歧。沒有 module 時，dev 與 prod 各自維護一份 copy-paste 的資源宣告，兩份會隨時間漂移 — 有人只在 prod 補了一條 security group 規則、忘了同步 dev，於是「dev 能跑、prod 卻爆掉」或更糟的「dev 測過了、prod 行為不同」。

避免漂移的關鍵是讓環境之間唯一合法的差異來源是傳進 module 的參數，而不是 module 內部的 code 分支。Module 內部不寫 if env == "prod" 這類判斷，所有環境相關的值都從 variable 進來：

 1# modules/database/variables.tf — module 只宣告它需要什麼參數
 2variable "instance_class" {
 3  type        = string
 4  description = "RDS instance type"
 5}
 6
 7variable "multi_az" {
 8  type    = bool
 9  default = false
10}
11
12variable "backup_retention_days" {
13  type    = number
14  default = 7
15}
16
17variable "deletion_protection" {
18  type    = bool
19  default = true
20}

 1# modules/database/main.tf — module 用參數建資源，不含環境判斷
 2resource "aws_db_instance" "primary" {
 3  identifier              = "${var.service_name}-${var.env}"
 4  engine                  = "postgres"
 5  engine_version          = var.engine_version
 6  instance_class          = var.instance_class
 7  multi_az                = var.multi_az
 8  backup_retention_period = var.backup_retention_days
 9  deletion_protection     = var.deletion_protection
10  db_subnet_group_name    = var.subnet_group_name
11  vpc_security_group_ids  = var.security_group_ids
12}

 1# environments/prod/main.tf — prod 傳自己的值
 2module "database" {
 3  source                = "../../modules/database"
 4  service_name          = "payments"
 5  env                   = "prod"
 6  instance_class        = "db.r6g.xlarge"
 7  engine_version        = "16.3"
 8  multi_az              = true
 9  backup_retention_days = 30
10  deletion_protection   = true
11  subnet_group_name     = module.network.private_subnet_group
12  security_group_ids    = [module.network.db_security_group_id]
13}

 1# environments/dev/main.tf — dev 傳縮小版的值
 2module "database" {
 3  source                = "../../modules/database"
 4  service_name          = "payments"
 5  env                   = "dev"
 6  instance_class        = "db.t3.micro"
 7  engine_version        = "16.3"
 8  multi_az              = false
 9  backup_retention_days = 1
10  deletion_protection   = false
11  subnet_group_name     = module.network.private_subnet_group
12  security_group_ids    = [module.network.db_security_group_id]
13}

這樣 dev 與 prod 跑的是位元層級相同的 module code，差異全部收斂在 main.tf 的呼叫參數裡、一眼可審。Review 時只要 diff 各環境的參數區塊就能看完所有環境差異。如果發現有人為了某環境的特例去改 module 內部，那是漂移正在發生的徵兆——該把特例改寫成新的參數，而非在 module 裡加 if env == "prod" 分支。核心服務怎麼用 module 跨環境重用，見模組五：核心服務上 IaC。

環境差異參數化：prod 放大、dev 縮小

環境之間真正該不同的是規模與冗餘等級，而這些差異全部表達成參數值、不表達成不同的 code。Prod 承擔真實流量與可用性承諾，所以跨多個可用區（multi-AZ）部署、機器規格放大、備份保留更久、開啟刪除保護；dev 承擔的是迭代速度與成本控制，所以單 AZ、最小機型、短備份甚至無備份，壞了重建即可。

把這些差異參數化的好處是「環境拓樸的形狀一致、只有刻度不同」。Dev 與 prod 都經過同一段 module 邏輯，prod 不會出現一段 dev 從未執行過的 code path — 真正上線的設定，在 dev 已經以縮小版驗證過邏輯正確性。

常見陷阱是把成本差異做成「dev 直接砍掉某個元件」：例如 dev 為了省錢不建負載平衡器、prod 才建，結果 prod 的 LB 相關設定從來沒在 dev 測過。較合理的做法是 dev 也建同型元件、只把規格與數量縮到最小，讓拓樸保持同構、只縮放刻度。

邊界在於少數差異無法只靠刻度表達。Prod 需要合規要求的稽核 log、dev 不需要；prod 要開 WAF、dev 不需要。這類差異用 count 或 for_each 配一個布林參數開關：

1resource "aws_cloudwatch_log_group" "audit" {
2  count             = var.enable_audit_log ? 1 : 0
3  name              = "/app/${var.env}/audit"
4  retention_in_days = 365
5}

仍然走參數化、不分叉 code — 分叉 code 是漂移的起點。跨可用區與冗餘的網路面怎麼鋪，見模組三：網路地基。

retrofit 路徑：把單環境拆成 per-env module

很多專案是先在單一環境把 IAM、VPC、核心資源都建起來、跑通了，才意識到需要環境分離 — 這是常見且合理的演進順序，尤其是先救火上線、之後才回頭納管的情況。Retrofit 的目標是在不破壞正在服務的資源前提下，把這份「隱含為 prod」的單環境，重構成「modules + per-env 呼叫」的結構，並讓現有資源平移成 prod 環境。

安全的步驟順序是先重構 code、再動資源歸屬，且每一步都用 terraform plan 確認「零變更」。

第一步：抽 module、宣告搬遷

把現有資源宣告抽成 module：把 main.tf 裡的資源搬進 modules/，原地用 module 呼叫取代，所有值先寫死成現況。資源在 state 裡的位址會從 aws_db_instance.primary 變成 module.database.aws_db_instance.primary，用 moved {} 區塊宣告搬遷，避免工具誤判為「銷毀舊的、建新的」：

1moved {
2  from = aws_db_instance.primary
3  to   = module.database.aws_db_instance.primary
4}
5
6moved {
7  from = aws_security_group.db
8  to   = module.database.aws_security_group.db
9}

此時 plan 必須顯示無任何新增或銷毀 — 只是重新組織 code。如果 plan 出現任何 destroy 或 forces replacement，在 prod 路徑上停下來查 moved 區塊哪裡寫錯。

第二步：參數化

把寫死的值換成 prod 的參數：把現況值搬進 environments/prod/terraform.tfvars，module 改吃參數。plan 仍須零變更，因為參數值就等於現況值。這一步的驗證方式很機械：每個從字面值改成變數引用的欄位，都能在 tfvars 裡找到完全相同的值。

第三步：新增其他環境

複製 prod 的呼叫結構成 environments/dev/，給它自己的 backend（獨立 state）與縮小的參數值。這一步是純新增、不碰 prod。先在 dev apply 出一套完整的縮小版環境、確認 module 在新環境也能 plan/apply 乾淨，再回頭確信 prod 的重構沒有副作用。

風險控制

最大的風險集中在前兩步：現有資源是活的，任何讓工具判定「需要替換」的改動，對 IAM 角色可能是短暫權限真空、對 VPC 可能是子網重建導致服務中斷。防護措施有三個層級：

第一，把每一次 plan 的輸出當成必須為零的驗收條件。非零就停下來查 moved 區塊或參數值哪裡跟現況不符。狀態危險的訊號是 plan 出現任何 destroy 或 forces replacement，在 prod 路徑上這幾乎都該暫停。

第二，在 retrofit 開始前備份 state 檔。S3 backend 有 versioning 可以回捲，但多一份本地備份增加保險層：

1# retrofit 前備份 state
2aws s3 cp s3://acme-tf-state/prod/terraform.tfstate \
3  ./state-backup-$(date +%Y%m%d).tfstate

第三，moved 區塊優先用宣告式（可 review、可回滾），手動 state mv 留給 moved 表達不了的跨 module 搬遷。整個 retrofit 走 PR 流程、讓 plan 輸出在 review 時可見，見模組七：infra 走 PR 流程。

時程參考：10-20 個資源的典型環境，從單環境拆成 module + per-env 結構約需 1-2 週（含每步 plan 驗證與跨環境推送）。50 個以上資源的環境需要 3-4 週分階段執行，每階段以一組功能相關的資源為單位。這些時程的主要變數是 stateful 資源的數量——每個 stateful 資源的 moved/import 操作都需要額外的 plan 驗證與備份保險。

跨分類引用

• → 模組一：最小可行 IaC：每個環境的 state 怎麼隔開
• → 模組二：身分與憑證地基：帳號級隔離的權限邊界
• → 模組三：網路地基：跨可用區冗餘的網路面
• → 模組五：核心服務上 IaC：核心服務怎麼用 module 跨環境重用
• → 模組七：infra 走 PR 流程：retrofit 的 plan 輸出怎麼進 review
• → 跨帳號策略：帳號級隔離是環境分離光譜最粗的一端

內容搬運模式（Content Ferry）

斷網環境裡的所有外部依賴（套件、映像、工具、更新）都要經過一條可控的搬運路徑進入。這條路徑的設計決定了環境的安全性和維護效率。

搬運路徑的三種形態

離線媒介搬運：用 USB 隨身碟、外接硬碟或光碟把檔案從有網路的工作站搬進隔離網路。適合高安全環境（軍事、政府機密網路），搬運頻率通常是週或月級。每次搬運的內容要經過掃毒和完整性驗證。

1# 外部工作站：準備搬運包
2mkdir -p ferry/$(date +%Y%m%d)
3# 把需要的套件、映像、工具複製進去
4cp -r packages/ images/ tools/ ferry/$(date +%Y%m%d)/
5# 產生 checksum
6find ferry/$(date +%Y%m%d) -type f -exec sha256sum {} \; > ferry/$(date +%Y%m%d)/manifest.sha256

1# 隔離網路內：驗證搬運包完整性
2cd /mnt/usb/ferry/20260626
3sha256sum -c manifest.sha256

跨網段閘道搬運：在隔離網路的邊界放一台 staging gateway（跳板機），它有兩張網卡——一張連外部網路（或 DMZ）、一張連內部隔離網路。外部的內容先傳到閘道、經過掃描和審查後再推進內部。適合金融和工控環境，搬運頻率可以是日級。

閘道的安全約束：只允許特定的檔案類型通過、所有傳入的檔案經過掃毒、傳輸記錄要保留 audit log、閘道本身定期更新安全軟體。

單向資料二極體（Data Diode）：硬體層面只允許資料單向流動（外 → 內），物理上無法從內部網路傳資料出去。用在最高安全等級的環境。搬運頻率和內容由二極體的設定決定。

搬運的操作紀律

每次搬運都要記錄：日期、搬運者、搬運內容清單（檔名 + 版本 + checksum）、搬運理由。這份紀錄存在內部網路的版本控制裡，讓「這個套件是誰、什麼時候、為什麼帶進來的」事後可追溯。

搬運內容的安全審查至少包含：掃毒（ClamAV 或商業掃毒）、checksum 驗證（確認搬運過程沒有被竄改）、版本確認（確認搬進來的版本跟預期的一致、不是被降級的舊版）。

時程參考：建立搬運流程（含閘道設定、掃描工具安裝、紀錄模板）約需 2-3 天。之後每次搬運操作約 1-2 小時（含準備、掃描、驗證、紀錄）。

離線套件管理

連網環境的 apt install、yum install、npm install 背後都在連線到公開的套件倉庫。斷網環境需要在內部建立這些倉庫的離線鏡像。

作業系統套件

Debian/Ubuntu：用 apt-mirror 或 aptly 在有網路的環境建立 mirror，把整個 mirror 搬進內部網路，內部機器的 /etc/apt/sources.list 指向內部 mirror。

1# 外部：建立 mirror（首次約 50-200GB，後續增量）
2apt-mirror /etc/apt/mirror.list
3
4# 內部：設定 sources.list 指向內部 mirror
5echo "deb http://internal-mirror.local/ubuntu jammy main restricted" > /etc/apt/sources.list
6apt update

RHEL/CentOS：用 reposync 把 yum repo 同步到本地，搬進內部後用 createrepo 建立 repo metadata。

1# 外部：同步 repo
2reposync --repoid=baseos --download-metadata -p /path/to/mirror/
3
4# 內部：建立 repo 並設定
5createrepo /path/to/mirror/baseos

應用層套件

Node.js（npm）：npm pack 把每個依賴打包成 .tgz，搬進內部後用 npm install --offline 或建立 Verdaccio private registry。

1# 外部：打包所有依賴
2npm pack --pack-destination ./offline-packages/
3# 或用 npm-offline-mirror
4npm install --prefer-offline --cache ./npm-cache

Python（pip）：pip download 把依賴下載成 wheel 或 tarball，搬進內部後 pip install --no-index --find-links=./packages/。

PHP（Composer）：composer install 後整個 vendor/ 目錄打包搬進去。或建立 Satis 作為 private Packagist mirror。

套件鏡像的維護節奏

離線 mirror 需要定期更新——安全補丁、版本升級都要透過搬運流程進入。更新頻率取決於安全需求：高安全環境至少月更（安全補丁）、一般環境季更可接受。每次更新都是一次搬運操作，要走完整的審查流程。

多格式統一：Nexus Repository

上面的做法是每個套件生態各自建 mirror（apt-mirror + Verdaccio + Satis + pip local index）。Nexus Repository 是多格式統一的 artifact proxy，同時支援 apt / yum / npm / Maven / PyPI / Docker / Helm——在企業級斷網環境裡，用一個 Nexus 實例取代多個獨立的離線 repo mirror，維護成本較低。代價是 Nexus 本身的安裝和維運（Java 應用、需要磁碟空間和記憶體），小團隊各自建 mirror 可能反而更簡單。

離線 Configuration Management：Ansible

斷網環境的 OS 設定、套件安裝、服務啟動等 configuration management 需求，Ansible 是運作良好的工具——它不需要在目標機器安裝 agent、透過 SSH 推送 playbook 執行，playbook 本身是 YAML 可版本控制。在沒有雲端 IaC（Terraform 管的是雲端資源 API）的地端斷網環境裡，Ansible 負責 configuration management 層。Ansible 自身的安裝只需要 Python，控制端安裝後即可透過 SSH 管理內部所有機器。

變更追蹤：沒有 GitHub 怎麼辦

斷網環境不能 push 到 GitHub、不能開 PR、不能用 GitHub Actions。但 git 本身是離線工具——git 的所有操作（commit、branch、merge、log、diff）都不需要網路。

內部 Git Server

在隔離網路內架設 git server：Gitea（輕量、單一二進位、適合小團隊）、GitLab CE（功能完整、含 CI/CD runner、適合中大團隊）、或最簡單的 bare repo on NFS。

1# 最簡單的方式：bare repo on 共用檔案系統
2git init --bare /shared/repos/infra.git
3
4# 開發者 clone
5git clone /shared/repos/infra.git

Git Bundle 跨網段傳遞

如果需要在有網路的環境開發、完成後搬進隔離網路，用 git bundle 把 commit 打包成單一檔案：

1# 外部：把 main branch 的所有 commit 打包
2git bundle create infra-$(date +%Y%m%d).bundle main
3
4# 搬運後，在內部 clone 或 pull
5git clone infra-20260626.bundle infra-repo
6# 或增量更新
7git pull infra-20260626.bundle main

bundle 檔案可以用 git bundle verify 驗證完整性。增量 bundle（只包含某個 tag 之後的 commit）可以減少搬運的資料量：

1git bundle create incremental.bundle last-imported-tag..main

Code Review 的替代方案

沒有 GitHub PR，code review 可以用：

• GitLab CE / Gitea 的內建 merge request（如果架了內部 git server）
• git format-patch 產出 patch 檔 + email review（傳統做法、不需要 web UI）
• git diff main..feature | less 直接在終端機 review（最簡陋但可行）

Staging Gateway 的設計

staging gateway 是搬運路徑的關鍵節點——它決定了什麼能進、什麼不能進。設計要點：

最小安裝：閘道上只裝搬運需要的工具（scp、rsync、掃毒軟體、checksum 工具），不裝開發工具、不跑應用服務。攻擊面越小越好。

雙網卡隔離：一張網卡連外部（或 DMZ）、一張連內部。兩張網卡之間沒有自動路由——檔案必須經過人工或腳本從外部目錄搬到內部目錄，中間經過掃描。

審計紀錄：閘道上的所有檔案操作（建立、複製、刪除）都要記錄。auditd 或等價工具提供核心層級的操作追蹤。

定期輪替：閘道本身的 OS 和掃毒軟體需要更新。這是一個遞迴問題（用什麼搬運閘道的更新？）——通常用離線媒介搬運閘道自身的更新，或用另一台更上游的閘道。

時程參考：閘道的初次設定（含 OS 安裝、雙網卡配置、掃描工具、審計設定）約需 1-2 天。搬運流程文件化約需半天。

安全審查：什麼能跨越隔離邊界

每一筆跨越隔離邊界的內容都是潛在的攻擊向量。審查的原則是：預設拒絕，逐項允許。

審查清單：

對決策者的重點：斷網環境的安全不是「隔離就安全」——搬運路徑是唯一的攻擊面，這條路徑的安全審查品質決定了整個隔離環境的安全水位。

跨分類引用

• → 斷網環境的 IaC：Terraform provider 和 module 的離線管理
• → 斷網環境的容器管理：映像搬運用的是本篇的 content ferry 模式
• → 模組八：治理好習慣：斷網環境的搬運紀錄是治理的一部分

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}

刻意不放進來的東西