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 描述套用到多環境

State 裡通常含有資源的真實 ID、相依關係，以及部分敏感屬性（例如資料庫的初始密碼、private key 的輸出值）。這帶來兩條硬邊界：state 不能進 git（含敏感值，推進版控等於把密碼寫進每個 clone 的歷史）、state 不能只放本地（本地 state 的失敗模式是記憶綁在一台筆電上，多人並行 apply 會互相覆蓋）。

概念位置

State 是 IaC 的記憶機制。模組一：最小可行 IaC 的核心主題就是怎麼把 state 管好——remote backend、加密、鎖機制。State 管不好，後續所有 IaC 操作都建立在不可靠的記憶上。

可觀察訊號

State 出問題的訊號包括：terraform plan 顯示大量非預期的變更（state 與現實不一致）、兩個人同時 apply 後環境出現矛盾狀態、state list 的資源數與 Console 上看到的不一致。

設計責任

管理 state 時要決定：

• 存放位置：S3 + DynamoDB（自管）vs Terraform Cloud（託管），取捨在維運負擔 vs 控制權
• 加密：state 含敏感值，落地加密（S3 SSE）是底線
• 版本保留：bucket versioning 讓 state 損壞時能回捲到上一個正確版本
• 鎖機制：防止兩個人同時 apply 互相覆蓋
• 分割策略：一個大 state vs 多個小 state，取捨在引用便利性 vs 影響範圍控制

鄰卡

• IaC — state 是 IaC 工具的核心依賴
• Drift — state 與現實的落差

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

概念位置

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

可觀察訊號

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

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

設計責任

處理 drift 時要決定：

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

鄰卡

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

VPC 用 CIDR 區塊定義地址空間。建立時的 CIDR 大小是一次性決策——事後擴張地址空間在多數雲端平台上是麻煩且容易出錯的操作（AWS 允許追加 secondary CIDR，但追加的網段在 routing 與服務相容性上有限制）。

概念位置

VPC 是模組三：網路地基的最外層邊界。Infra 系列的網路設計從 VPC 開始：先圈定地址空間，再往內切 subnet、掛 route table、設 security group。環境之間的 VPC 怎麼分（每個環境一個 VPC），屬於模組四：環境分離的設計決策。

可觀察訊號

VPC 設計需要關注的訊號：CIDR 空間快用完（subnet 切不出新的子網段）、需要跟其他 VPC 或地端互連時發現 CIDR 重疊（peering 無法建立）、服務被放在預設 VPC 裡（預設 VPC 是所有人共享的、CIDR 不可控的、security group 預設全通的）。

設計責任

規劃 VPC 時要決定：

• CIDR 大小：/16 提供約六萬五千個位址，對多數單一環境足夠
• 不重疊：多個 VPC（不同環境或產品線）用連續但不重疊的大段分配
• DNS 設定：enable_dns_support 和 enable_dns_hostnames 在多數場景都該開啟
• 預設 VPC 的處理：正式服務不該放在預設 VPC，新帳號的預設 VPC 可以刪除或保留唯讀

鄰卡

• Subnet — VPC 內按可用區與暴露程度切出的子網段
• Security Group — 掛在資源上的有狀態防火牆
• CIDR — VPC 的地址空間定義方式
• NAT — 讓 private subnet 出站的地址轉換機制

Subnet 分兩類：

• Public subnet：route table 有 0.0.0.0/0 → Internet Gateway，讓資源能被外部 IP 直接觸及。典型住戶是對外負載平衡器、NAT Gateway。
• Private subnet：route table 把 0.0.0.0/0 指向 NAT Gateway，外部無法主動連入。典型住戶是應用伺服器、資料庫、快取。

Public subnet 的真實樣貌是「薄薄一層」——它通常只住入口設施，業務邏輯跟資料儲存都在 private subnet。

概念位置

Subnet 是模組三：網路地基的中層邊界。VPC 定好地址空間後，subnet 決定「哪些資源能被外網碰到、哪些只能在內網存取」。每個 subnet 綁定單一可用區，高可用設計通常是每種角色跨至少兩個可用區各開一個 subnet。

可觀察訊號

Subnet 配置有問題的訊號：應用伺服器被放在 public subnet 並配了公網 IP（管理埠暴露在掃描流量下）、private subnet 的服務拉不到外部套件（route table 沒指向健康的 NAT）、新服務上線時找不到適合的 subnet（CIDR 切得太小、空間不夠）。

設計責任

規劃 subnet 時要決定：

• CIDR 切法：VPC 是 /16 時，每個 subnet 用 /20（約四千位址）可以在三個可用區各開 public + private 共六個 subnet
• 跨可用區對稱：每種角色至少跨兩個 AZ，讓單一 AZ 故障時另一區能承接
• public 的住戶限制：只放入口設施，業務邏輯一律放 private

鄰卡

• VPC — subnet 的容器
• NAT — 讓 private subnet 出站的機制
• Security Group — 掛在資源上的埠級存取控制

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

概念位置

Security group 是模組三：網路地基的最內層邊界——貼著服務的最後一道網路防線。即使封包順著 route table 抵達了 private subnet，security group 仍能逐埠決定放不放行。模組七：infra 走 PR 流程用 tfsec / checkov 在 CI 攔截 0.0.0.0/0 全開的規則。

可觀察訊號

Security group 需要收斂的訊號：入站來源是 0.0.0.0/0（允許全網連入），且目標埠是資料庫（5432、3306、6379）或管理埠（22、3389）——合理出現 0.0.0.0/0 的位置只有對外負載平衡器的 80 / 443。盤點方式是列出所有 source 為 0.0.0.0/0 的規則，逐條問「這個埠需要全世界都連得到嗎」。

設計責任

設計 security group 時要決定：

• 引用方式：用 group 互相引用（推薦）vs 用 CIDR 限定範圍
• 開放範圍：只開需要的埠與來源，0.0.0.0/0 只給對外 LB
• 管理埠存取：SSH（22）改用 SSM Session Manager 取代，從公網清單上拿掉
• 與 NACL 的分工：security group 是主力（有狀態、group 引用），NACL 留給少數需要 subnet 層顯式 deny 的情境

鄰卡

• VPC — security group 依附的網路容器
• Subnet — security group 與 subnet 各守不同層級的邊界

概念位置

NAT Gateway 在網路地基裡的角色是 private subnet 的出站閘道。它解決的問題是：private subnet 的設計意圖是「外部連不進來」，但服務仍需要主動對外。沒有 NAT，private subnet 的資源完全無法對外通訊 — 連 apt update 或 pip install 都做不到。

NAT Gateway 是綁定單一可用區的資源，活在某個 public subnet 裡。這帶來一個架構取捨：共享一個 NAT（成本低、出站方向有單點）還是每個可用區各放一個（成本高、出站與 subnet 冗餘對齊）。

可觀察訊號

以下狀況指向 NAT 相關問題：

• Private subnet 的服務拉不到外部套件或第三方 API 全部逾時 — 先查 route table 有沒有指向健康的 NAT
• 只有某一個可用區的節點受影響 — 該區的 NAT 或其所在 subnet 可能故障
• 雲帳單裡 NAT Gateway 的流量費用異常高 — 大量走 NAT 的流量（S3 備份、跨區同步）可用 VPC Endpoint 繞過

設計責任

使用 NAT Gateway 時要決定：

• 數量：每個可用區一個（可用性優先）還是全 VPC 共享一個（成本優先）。每個 NAT 固定月費約 $32 加流量費 $0.045/GB
• 高流量路徑：對 AWS 自家服務的流量（S3、DynamoDB）改用 Gateway Endpoint 直連，繞過 NAT 省流量費
• route table 關聯：每個 private subnet 的 route table 要明確指向哪個 NAT

鄰卡

• Subnet — NAT 放在 public subnet、服務放在 private subnet
• VPC — NAT 屬於 VPC 內部的出站路徑設施

概念位置

OIDC 聯合在身分與憑證地基裡的角色是「雲外機器身分的認證機制」。跑在雲上的 workload（EC2、ECS task）可以用平台原生的 instance profile 或 task role 取得短期憑證；跑在雲外的 CI/CD 沒有這個管道，OIDC 就是替代方案。

運作方式是建立信任關係：雲端帳號信任某個外部 identity provider（如 GitHub Actions 的 OIDC issuer），CI 執行時平台簽發一個帶 claim 的 token（描述哪個 repo、哪個 branch、哪個 workflow），雲端用這個 token 換出一段臨時憑證。

可觀察訊號

以下狀況指向 OIDC 相關問題：

• CI pipeline 裡有 AWS_ACCESS_KEY_ID 和 AWS_SECRET_ACCESS_KEY 環境變數 — 這是長期 key，應該替換成 OIDC
• Trust policy 只驗 issuer 不驗 repo — 任何掛在同一個 CI 平台的專案都能假扮這個 role
• Pipeline 突然無法取得權限 — 可能是 trust policy 的 condition 跟 token claim 不匹配（常見於 repo 改名或 branch 改名後）

設計責任

設定 OIDC 聯合時要決定：

• Trust policy 的 claim 收斂：限定 issuer + audience + 特定 repo + 特定 branch，每個條件都收到最緊
• Role 的權限範圍：OIDC 換到的 role 仍然要遵循最小權限 — 只給 pipeline 需要的 action
• Plan 與 apply 分開的 role：plan 只需要 read 權限、apply 需要 write 權限，用兩個 role 降低 PR 階段的風險

鄰卡

• IAM — OIDC 是 IAM 身分系統的一種外部身分來源
• Security Group — OIDC 解的是身分層的認證問題，跟網路層的 security group 正交

概念位置

環境分離在 infra 成熟度階梯上對應第三階。它建立在宣告式 IaC（第二階）的基礎上 — 有了 state 追蹤和模組化描述之後，才能用「同一份 code、不同參數」的方式複製出多個隔離環境。

分離的實作方式有一條隔離強度光譜：從帳號級（不同雲端帳號，最強隔離）到目錄級（同一 repo 內各環境一個目錄，各自持有 state）到 workspace 級（同一份 code 用執行期切換 state，隔離最弱）。多數早期團隊在目錄級落腳，因為它在顯式邊界與維運成本之間取得平衡。

可觀察訊號

以下狀況指向環境分離不足：

• 在 staging 測試的變更意外影響了 production 的資源 — dev 跟 prod 共用同一份 state
• 某人的 terraform apply 把另一個環境的資源改掉了 — workspace 的隱性狀態切換導致打錯環境
• dev 與 prod 的設定差異散落在 code 裡的 if env == "prod" 判斷 — 環境差異沒有集中在參數值裡

設計責任

環境分離的設計要決定：

• 隔離層級：帳號級、目錄級、還是 workspace 級。判斷依據是團隊規模、合規要求、與維運餘裕
• 參數化邊界：dev 與 prod 之間的差異全部用參數表達（instance size、multi-AZ、backup retention），module 內部不寫環境判斷
• state 位址分離：每個環境的 state backend 位址獨立，互不交叉

鄰卡

• IaC — 環境分離的前提是有可重用的 IaC 描述
• State — 每個環境持有獨立的 state 檔
• Drift — 環境分離降低 drift 的跨環境影響範圍

概念位置

CloudTrail 在 infra 治理裡的角色是「發生了什麼」的最後防線。人工變更日誌記錄「為什麼改」，CloudTrail 記錄「改了什麼」— 兩者一起才能從事故回推到可回退的操作。

CloudTrail 預設記錄 management event（建立、修改、刪除資源的 API 呼叫）並保留 90 天可查閱。要長期保存或記錄 data event（S3 物件存取、Lambda 呼叫等更細粒度的操作），需要建立 trail 並指定 S3 bucket 儲存。

可觀察訊號

以下狀況指向 CloudTrail 的使用場景：

• 事故排查需要回答「誰在過去 24 小時改過這個 security group」— CloudTrail 的 LookupEvents API 可以按事件名稱、資源類型或使用者名稱查詢
• 安全稽核要求提供「過去 90 天內所有 IAM policy 變更的紀錄」— CloudTrail 是標準的證據來源
• 發現不預期的資源變更（drift），需要確認是人為操作還是自動化觸發 — CloudTrail 的 userIdentity 欄位區分人類使用者和 assume-role 的服務

設計責任

使用 CloudTrail 時要決定：

• 保留期限：預設 90 天免費查閱；超過需要建 trail 存到 S3，費用是 S3 儲存成本
• 事件範圍：management event 預設開啟；data event（S3 物件讀寫、Lambda invoke）要額外設定，且量大時儲存成本可觀
• 跨帳號整合：多帳號架構下，Organization trail 可以把所有帳號的事件集中到一個 S3 bucket
• 存取控制：CloudTrail 的 S3 bucket 本身要限制存取 — 能修改稽核日誌等於能掩蓋操作痕跡

鄰卡

• IAM — CloudTrail 記錄的是 IAM 身分的 API 呼叫
• Drift — CloudTrail 是追查 drift 來源（誰手動改了什麼）的工具

概念位置

ECS 在核心服務層裡的角色是「應用程式的執行載體」。它跑在 VPC 的 private subnet 裡，用 IAM task role 存取其他 AWS 資源，前面掛 ALB 接收流量。IaC 描述 ECS 時，重點在「接線」（subnet、security group、IAM role、target group）而非容器映像版本 — 映像版本由 CI/CD 在部署期注入。

ECS 的執行模式分 EC2 launch type（自己管運算實例、要管 AMI 更新與 capacity provider）和 Fargate launch type（AWS 代管運算、不需管實例）。Fargate 進一步降低運維面，代價是單位成本較高（同規格約多 20-40%）且不支援 GPU workload。

可觀察訊號

以下狀況指向 ECS 相關問題：

• Task 頻繁被 kill 後重啟 — 健康檢查失敗或 OOM，先看 task 的 stopped reason 和 CloudWatch log
• 部署後新版本遲遲不上線 — rolling update 的 minimum healthy percent 設太高，新 task 啟動空間不足
• Task 無法拉到 ECR image — 通常是 private subnet 沒有 NAT 或 VPC Endpoint 到 ECR

設計責任

使用 ECS 時要決定：

• Launch type：Fargate（低運維、較高成本）還是 EC2（低成本、要管實例）。多數 web API 的初始選擇是 Fargate，流量穩定後再評估 EC2
• Task IAM role：task execution role（拉 image 和寫 log 用）和 task role（應用程式存取其他 AWS 資源用）是兩個不同的 role，不要混用
• 映像版本解耦：task definition 裡的 image tag 由 CI/CD 部署期注入，infra code 不寫死版本號
• Auto-scaling 指標：用 CPU / memory 還是 ALB request count，取決於服務是計算密集還是 IO 密集

鄰卡

• Subnet — ECS task 跑在 private subnet 裡
• Security Group — ECS service 套用 security group 控制入站
• IAM — task role 與 execution role 是 ECS 的兩個身分接線
• ALB — 流量透過 ALB target group 導入 ECS task

概念位置

ALB 在核心服務層裡的角色是「入口設施」。它掛在 public subnet 的 security group 上（入站允許 80/443），把流量導向 private subnet 裡的 ECS task 或 EC2 instance。ALB 本身是 stateless 的 — 重建一個 ALB 不會遺失資料，但會換掉它的 DNS 名稱，所以對外服務通常在 ALB 前面掛一個穩定的 Route 53 alias record。

TLS 終結是 ALB 的標準職責：HTTPS listener 引用 ACM（AWS Certificate Manager）簽發的憑證，ALB 處理加解密，後端收到的是 HTTP 明文。憑證由 ACM 自動續期，IaC 用 DNS 驗證方式描述憑證 — 讓「憑證存在、續期、掛載」整條鏈都進版本控制。

可觀察訊號

以下狀況指向 ALB 相關問題：

• 使用者看到 502 — ALB 轉發請求但後端回應異常（健康檢查可能通過但實際請求處理失敗），查 target group 的健康狀態和後端 log
• 使用者看到 503 — target group 裡沒有健康的後端，通常是部署期間所有舊 task 停了但新 task 還沒通過健康檢查
• HTTPS 憑證過期警告 — 如果用 ACM 搭配 DNS 驗證，憑證自動續期；看到過期警告代表 DNS 驗證記錄被刪了或 ACM 服務異常

設計責任

使用 ALB 時要決定：

• 健康檢查參數：檢查路徑（用應用層的 health endpoint、不用根路徑）、間隔、閾值。閾值太寬鬆會把壞掉的後端留在輪替裡，太嚴格會在部署瞬間誤判
• HTTP → HTTPS redirect：port 80 的 listener 設定固定回應 301 redirect 到 443，確保所有流量走加密
• TLS 憑證：用 ACM 搭配 DNS 驗證，讓憑證的簽發和續期自動化
• 穩定 DNS：ALB 前面掛 Route 53 alias record，對外暴露的是自己的 domain name 而非 ALB 的隨機 hostname

鄰卡

• Subnet — ALB 跑在 public subnet，後端跑在 private subnet
• Security Group — ALB 的 security group 是系統對外唯一合理開放 0.0.0.0/0 的位置（僅限 80/443）
• ECS — ALB 透過 target group 把流量導向 ECS task

概念位置

CIDR 是 VPC 規劃的起點決策。建立 VPC 時指定的 CIDR 區塊決定了這個 VPC 能容納多少 subnet 和多少資源。這個決策在建立後難以修改——事後擴張意味著追加 secondary CIDR，而追加的網段在 routing 與服務相容性上有限制。

在 infra 系列中，CIDR 規劃出現在模組三：網路地基的 VPC 段落。Terraform 的 cidrsubnet 函式可以從 VPC 的 CIDR 自動切出 subnet 的子網段，避免手動計算。

可觀察訊號

CIDR 規劃出問題的訊號有兩類。第一類是地址耗盡：subnet 切不出新的子網段、或 subnet 內的 IP 分配用完，新資源無法取得位址。第二類是網段衝突：需要透過 VPC peering、Transit Gateway 或 VPN 互連兩個 VPC 時，發現兩端的 CIDR 重疊，路由無法解析，peering 建立失敗。

設計責任

規劃 CIDR 時要決定：

• 大小：單一環境用 /16 通常足夠寬裕，切成 /20 的 subnet 可分配 16 個子網段
• 不重疊：多個環境（dev 10.0.0.0/16、staging 10.1.0.0/16、prod 10.2.0.0/16）用連續但不重疊的區段，為日後互連預留空間
• 與地端的協調：如果未來可能接 VPN 回地端機房，CIDR 要避開地端已使用的私有網段

鄰卡

• VPC — 用 CIDR 區塊定義的邏輯隔離網段
• Subnet — 從 VPC CIDR 切出的子網段

概念位置

IAM 是模組二：身分與憑證地基的核心機制。它決定了誰能動什麼——人、服務、CI pipeline 各拿剛好夠用的權限（最小權限），憑證有明確的生命週期。身分層失守的代價在五個 infra 責任面向中最高，因為它是其他所有資源的閘門。

在 infra 系列中，IAM 的設計從三個維度展開：最小權限的持續收斂（不是一次設定就結束）、用 OIDC 短期憑證取代長期 access key、以及跨帳號的權限邊界（SCP + Permissions Boundary）。

可觀察訊號

IAM 需要關注的訊號：某個 role 的 policy 有 *:* 或 AdministratorAccess（權限過大）；credential report 顯示有長期 access key 超過 90 天未輪替（憑證散落風險）；Access Analyzer 顯示某個 role 的實際使用 action 遠少於授予的 action（權限擴散）；dev 環境的 CI role 能列出 production 的資源（環境隔離失效）。

設計責任

IAM 設計時要決定：

• 身分類型區分：人用 SSO 登入（強制 MFA）、雲上服務用 instance profile / task role、雲外 CI 用 OIDC 聯合
• 權限分級：admin / operator / viewer 三級，見團隊權限分級
• 環境隔離：每個環境的 role 不能存取其他環境的資源
• 收斂節奏：定期用 Access Analyzer 觀察實際使用的 action，收掉沒用到的權限

鄰卡

• OIDC — 用短期 token 取代長期 access key 的聯合機制
• Security Group — 網路層的存取控制（IAM 是 API 層的存取控制）
• CloudTrail — 記錄 IAM 身分的 API 呼叫歷史

概念位置

Route table 決定了一個 subnet 是 public 還是 private。技術上的差別只有一行：route table 裡有沒有一條 0.0.0.0/0 → Internet Gateway 的預設路由。有這條路由的 subnet 是 public（封包可以直接出網、外部也可以連入）；把預設路由指向 NAT Gateway 的 subnet 是 private（只能主動出站、外部無法入站）。subnet 本身的屬性不含 public/private 標記，性質完全由關聯的 route table 賦予。

可觀察訊號

private subnet 的服務突然拉不到外部套件或第三方 API 全部逾時時，排查路徑的第一步是檢查該 subnet 關聯的 route table：預設路由是否指向健康的 NAT Gateway。如果只有某一個可用區的節點受影響，通常是那一區的 NAT Gateway 或其所在 subnet 出狀況。

另一個常見訊號是新建的 subnet 沒有手動關聯 route table，被 VPC 的 main route table 自動關聯——main route table 的預設設定可能跟預期不符。

設計責任

使用 route table 時要決定：每個 subnet 的預設路由指向什麼（Internet Gateway / NAT Gateway / Transit Gateway / 無）、VPC 內部流量是否需要自訂路由（peering、endpoint）、以及 main route table 是否該保持空白以避免新 subnet 意外取得對外路由。每一條路由的目的地網段和目標要在 IaC 裡明確描述，讓 route table 的語意可被 review。

鄰卡

• Subnet — route table 掛在 subnet 上
• NAT — private subnet 的預設路由目標
• VPC — route table 存在於 VPC 內

概念位置

SCP 跟 IAM policy 的關係是交集而非覆蓋：一個操作要同時被 SCP 允許且被 IAM policy 允許才會生效。SCP 的設計目的是讓組織管理者設定「即使帳號管理員也做不了」的護欄，常見的 day-1 SCP 包括：禁止關閉 CloudTrail、禁止離開指定 region、禁止刪除 VPC Flow Logs。

SCP 套用在 OU 上時會繼承給 OU 下所有帳號和子 OU。Management account（Organizations 的根帳號）不受 SCP 約束——這是設計上的逃生門，也是 management account 應該盡量不跑 workload 的原因。

可觀察訊號

當帳號內的 IAM role 執行某個操作時收到 AccessDeniedException、但該 role 的 IAM policy 確實允許該操作，SCP 是第一個要檢查的位置。另一個訊號是新帳號加入 OU 後某些原本能用的服務突然不可用——通常是繼承了 OU 的 SCP deny list。

設計責任

SCP 的設計要決定：用 deny-list 策略（預設全開、明確列出禁止項）還是 allow-list 策略（預設全關、明確列出允許項）。Deny-list 較常見也較易維護——只需要管「哪些該禁」。Allow-list 更嚴格但維護成本高——每次有新服務需求都要更新 SCP。

套用 SCP 前要確認不會擋到正在運作的服務——先在 sandbox OU 測試，確認既有 workload 不受影響再推到 workload OU。SCP 的變更跟 IAM 一樣要走 PR review。跨帳號策略的完整設計見跨帳號策略文章。

鄰卡

• IAM — SCP 是 IAM policy 的上層天花板
• 環境分離 — SCP 靠 OU 結構實現環境之間的權限隔離

概念位置

State 是 IaC 工具對現實的唯一記憶。把它放在本地檔案系統等於把整個基礎設施的記憶綁在一台機器上——換人接手、換台電腦、或兩人同時 apply，記憶就分裂了。Remote state backend 解決的是「讓 state 變成團隊共用的、有保護的事實來源」。

典型的自管組合是 S3（存放 state 檔、開 versioning 和加密）加上 DynamoDB（提供 apply 時的並行鎖）。託管服務（Terraform Cloud、Spacelift）把存放、鎖和加密包在一起，用月費換掉配置和維運負擔。

可觀察訊號

本地 state 的失敗訊號是：跑 terraform plan 時出現「想刪掉」明知存在的資源——通常代表本地 state 跟雲端實際狀態已經脫節。另一個訊號是兩個人同時跑 apply 但沒有任何鎖機制阻擋——結果是互相覆蓋對方的變更，state 進入不一致狀態。

Remote backend 設定後，如果 terraform init 提示 state 遷移確認，代表正在從本地搬到遠端——這是正確的一次性操作，但搬遷過程中不能有其他人在 apply。

設計責任

選擇 remote state backend 時要決定：自管還是託管（取決於團隊規模和維運餘裕）、state bucket 的加密與存取控制（誰能讀 state 等於誰能看到所有資源的敏感屬性）、versioning 是否開啟（是 state 回捲的唯一退路）、以及鎖表的設定（DynamoDB 的表名和 partition key）。

State 絕不能進 git——它含明文敏感值，推進版控等於把密碼寫進每個 clone 的歷史裡。Backend 設定本身（bucket name、region、鎖表名稱）寫在 HCL 裡進 git，state 檔本身只存在 backend 裡。

鄰卡

• State — remote backend 存放的對象
• Drift — state 與現實不一致時的現象
• IaC — remote state backend 是 IaC 工具的基礎設施

概念位置

Trust policy 是 OIDC 聯合的核心配件。當 CI/CD 平台（GitHub Actions、GitLab CI）要用短期憑證存取雲端資源時，trust policy 用 OIDC token 裡的 claim（issuer、audience、subject）決定「這個 token 代表的身分能不能 assume 這個 role」。

Trust policy 的設計要點是 claim 的收斂程度。只驗 issuer 而不驗 repo 和 branch，等於同一個 CI 平台上所有專案都能 assume 這個 role——這是常見的設定陷阱。收到最緊意味著限定到「某個 org 的某個 repo 的某個 branch 或 environment」。

可觀察訊號

sts:AssumeRoleWithWebIdentity 呼叫失敗、回傳 AccessDenied 時，問題通常在 trust policy 的 condition 比對不上。排查路徑是把 CI 平台簽發的 OIDC token decode（JWT 的 payload 部分），逐一比對 token 裡的 iss、aud、sub 跟 trust policy 的 condition 值。

另一個訊號是 trust policy 的 condition 用了 StringLike 但 pattern 太寬（如 repo:my-org/*），讓非預期的 repo 也能 assume——這類過寬的 trust policy 在安全稽核時會被標記。

設計責任

設計 trust policy 時要決定：允許哪些外部身分 assume（issuer + subject 的精確匹配）、audience 是否需要額外驗證（AWS 預設 sts.amazonaws.com）、以及是否把 plan role 和 apply role 分開（plan 只需 read-only、apply 需要 write，用兩個 role 各自設不同 trust condition 來區分 branch 或 environment）。

Trust policy 的變更跟 IAM policy 一樣要走 PR review——因為改寬一個 condition 就等於給更多外部身分開門。設定指南見 OIDC Trust Policy 設定指南。

鄰卡

• IAM — trust policy 是 IAM role 的一部分
• OIDC — trust policy 用 OIDC token 的 claim 做 assume 判斷

概念位置

Deletion protection 是 stateful 資源保護的第一道防線。運算節點可以隨時重建，資料一旦遺失通常無法重來——這條分界線決定了哪些資源該開保護。對 stateful 資源（資料庫、持久化儲存）來說，這是 day-1 該開的設定，不是「等穩定再開」的選項。

不同 AWS 服務的保護機制名稱不同但行為一致：

可觀察訊號

需要開啟 deletion protection 的訊號是資源承載了不可重建的狀態。判斷方式是問一個問題：「這個資源被刪除後，能不能在 10 分鐘內從程式碼或備份完整恢復？」不能的就該開。

terraform plan 輸出裡出現 destroy 或 forces replacement（-/+）時，deletion protection 是阻擋意外資料遺失的最後一道閘門。有保護的資源在 apply 時會報錯而非直接刪除，讓操作者有機會停下來確認。

設計責任

用 IaC 描述 stateful 資源時，把 deletion protection 寫進程式碼而非手動在 Console 開啟——這讓保護策略本身成為可審查、可追蹤的設定。同時搭配 skip_final_snapshot = false（RDS）確保刪除前自動做最後一份快照。

Deletion protection 擋的是刪除操作，不擋資料覆寫或邏輯損壞——一段錯誤的 UPDATE 不會被 deletion protection 攔截。資料層的完整防線還需要備份保留與時間點還原（PITR），跟 deletion protection 正交。

鄰卡

• State — deletion protection 在 state 裡記錄為資源屬性，plan 會顯示保護狀態
• IaC — 保護策略寫進 IaC 讓它可審查

概念位置

checkov 在 infra PR 流程裡的位置是 fmt → validate → checkov / tfsec → plan。前兩步檢查語法正確，checkov 檢查語意安全，plan 檢查實際差異。checkov 補的是 reviewer 肉眼容易漏的盲區——一條 security group 規則寫成 0.0.0.0/0 在 HCL 裡只是一行字串，人會看漏，規則不會。

三個常見的 IaC 掃描工具各有側重：

checkov 的規則庫最廣（涵蓋 CIS Benchmark、SOC 2、PCI DSS 等合規框架），tfsec 的規則更聚焦安全面，tflint 偏向「這個 instance type 在這個 region 存不存在」的 provider 正確性。三者可疊加使用。

可觀察訊號

需要引入 checkov 的訊號是 PR review 開始漏掉安全問題——S3 bucket 缺 public access block、RDS 沒開加密、IAM policy 過寬。這些問題的 pattern 是固定的、可以用規則比對，不應該靠人記憶來擋。

checkov 命中後要區分「真漏洞」和「情境合理的例外」。ALB 的 HTTPS listener 在 port 443 開 0.0.0.0/0 是設計本意，不是漏洞。豁免用行內註解標記並寫理由：#checkov:skip=CKV_AWS_260:ALB public HTTPS listener。詳細的規則配置與豁免管理見 checkov 與 tfsec 規則配置。

設計責任

引入 checkov 時要決定兩件事：啟用哪些規則（全部 vs 漸進啟用），以及命中時 CI 要不要擋（hard fail vs warning）。常見的漸進策略是先從高嚴重度規則開始、設為 hard fail，中低嚴重度設為 warning，隨團隊習慣逐步收緊。

鄰卡

• IaC — checkov 掃描的對象
• Security Group — checkov 最常攔截的 0.0.0.0/0 全開規則

概念位置

ECS 有兩種 launch type，差別在運算層的管理責任：

Fargate 降低的是運維面（不用管 OS patch、不用管 instance 容量），代價是單位成本較高（同規格約比 EC2 高 20-40%）和啟動延遲（cold start 通常在 30-60 秒，EC2 上的 task 因為 instance 已在所以秒級啟動）。多數 web API 的初始選擇是 Fargate，流量穩定且成本壓力大時再切回 EC2 launch type。

可觀察訊號

評估是否從 Fargate 切到 EC2 的訊號是月費曲線。Fargate 按 vCPU-hour 和 memory-hour 計費，task 數量少時費用低、管理簡單。當 task 數量穩定在 10-20 個以上且流量模式可預測時，EC2 launch type 搭配 reserved instance 或 Savings Plans 的成本優勢開始顯著——但要承擔 instance 管理的運維負擔。詳細的成本分析見 ECS Fargate 成本分析與優化。

Fargate Spot 是介於兩者之間的選項：費用約為 on-demand Fargate 的 30%，但 AWS 可以隨時中斷 task（提前 2 分鐘通知）。適合可容忍中斷的 workload（批次處理、非即時的資料轉換），不適合面對使用者的即時 API。常見的混合策略是用 on-demand Fargate 跑基線流量、Fargate Spot 跑彈性擴張的部分。

設計責任

選 Fargate 時要決定三件事：task 的 vCPU / memory 規格（Fargate 的可選組合是固定的，不是任意搭配）、是否混用 Spot、以及 health check 的 grace period（Fargate 的 cold start 比 EC2 長，health check 太早判定失敗會讓 task 反覆重啟）。

task 規格的 rightsizing 靠 CloudWatch Container Insights 的 CPU / memory utilization 決定——p95 使用率低於 30% 代表規格過大、持續高於 80% 代表該升級。

鄰卡

• ECS — Fargate 是 ECS 的 launch type 之一
• ALB — Fargate task 通常掛在 ALB 的 target group 後面

概念位置

在無 SSH 的主機環境裡，phpMyAdmin 通常是唯一可用的資料庫管理入口。它取代了 mysql CLI client 和 mysqldump 指令的角色——查詢用 SQL 編輯器、匯出用匯出頁面、匯入用上傳 SQL 檔。接手維運時，phpMyAdmin 是拍下資料庫現況（SQL dump）的主要工具。

可觀察訊號

以下情境會遇到 phpMyAdmin：主機面板（cPanel / Plesk）裡有「phpMyAdmin」按鈕可以進入；接手的專案的資料庫操作文件提到「在 phpMyAdmin 裡執行」；或者專案的部署流程包含「登入 phpMyAdmin 匯入 SQL」。

設計責任

使用 phpMyAdmin 時要處理三個限制。第一是匯出 timeout：大資料庫（50MB 以上）的匯出可能因為 PHP 的 max_execution_time 限制而中斷，需要分表匯出或調整 phpMyAdmin 設定。第二是沒有 CLI 可腳本化：所有操作都要手動點擊，無法排程自動備份。第三是安全暴露：phpMyAdmin 掛在 web 上、可被外部存取，如果沒有設密碼保護或 IP 白名單，等於把資料庫管理介面開給全世界。

如果主機允許遠端 MySQL 連線（port 3306 開放），可以改用桌面工具（DBeaver、TablePlus、HeidiSQL）直連資料庫，繞過 phpMyAdmin 的 timeout 限制。

鄰卡

• cPanel：phpMyAdmin 通常內嵌在 cPanel 裡

概念位置

FTP 是無 SSH 環境裡傳輸檔案的主要協定。FileZilla 把 FTP 操作從 CLI（如 ftp 或 lftp 指令）包裝成圖形介面，降低操作門檻。接手維運時，FileZilla 的角色是「把整個站台拉回本地」和「把改好的檔案推上 prod」。

可觀察訊號

以下情境會用到 FileZilla：接手的專案只有 FTP 帳密沒有 SSH key；部署方式是「FTP 上傳改過的檔案」；或者需要對比本地版本和伺服器版本的差異。

設計責任

使用 FileZilla 時有三個關鍵功能和注意事項。

站台管理員：儲存多組 FTP 連線設定（主機、帳號、密碼、port），避免每次手動輸入。接手時第一步是在站台管理員建好 prod 的連線，並確認協定選擇正確（FTP 明文、FTPS 加密、SFTP 走 SSH）。

目錄比較：「檢視 → 目錄比較 → 啟用」功能會標示本地與遠端的檔案差異——哪些本地較新、哪些遠端較新、哪些只存在於一邊。上傳前先跑目錄比較可以看到即將改動的範圍。

隱藏檔：預設不顯示以 . 開頭的檔案（如 .htaccess、.env、.user.ini）。要在「伺服器 → 強制顯示隱藏檔案」啟用，否則接手時會漏拉這些關鍵設定檔。

FTP 傳輸是逐檔覆寫、沒有原子性——上傳到一半斷線會讓伺服器上同時存在新舊版本的混合狀態。對關鍵檔案（index.php、.htaccess）的上傳需要額外小心。

鄰卡

無。FileZilla 是獨立工具。替代工具包括 WinSCP（Windows）、Cyberduck（macOS）、Transmit（macOS）。

概念位置

cPanel 是無 SSH 環境裡的「控制中心」。它整合了多種工具的圖形入口：phpMyAdmin（資料庫）、檔案管理員（web 版 FTP）、PHP 設定、cron 編輯器、SSL/TLS 管理。接手維運時，第一步是確認有沒有 cPanel 存取權——有的話很多操作（備份、PHP 版本、cron）可以在面板裡完成，不需要 SSH。

可觀察訊號

以下情境代表環境有 cPanel：主機商提供了 cPanel 登入 URL（通常是 domain:2083）；接手時收到的帳密包含「cPanel 帳號」；或者主機商的服務說明提到 cPanel / WHM。

設計責任

接手維運時，cPanel 有幾個關鍵功能要確認：

完整備份：「備份精靈」可以一次打包整個帳號（檔案 + 資料庫 + email + cron + DNS 設定）。這是最快的「拍下現況」方式——比 FTP 逐檔拉 + phpMyAdmin 匯出快得多。但完整備份通常只能下載、不能自動排程到外部儲存（部分主機商限制）。

PHP 版本選擇器：可以切換整個帳號或單一域名的 PHP 版本。升級 PHP 時，可以先在 staging 子域名切到新版本測試、確認沒問題再切主域名。這是無 SSH 環境裡最安全的 PHP 升級方式。

cron job 管理：圖形介面設定排程任務，語法是 cron 標準格式。接手時要截圖或匯出所有 cron——它們可能是系統運作的隱性依賴（定期清快取、寄報表、同步資料）。

SSL/TLS：管理 HTTPS 憑證。部分主機商整合了 Let’s Encrypt 自動簽發，部分需要手動上傳憑證。

鄰卡

• phpMyAdmin：通常內嵌在 cPanel 的「資料庫」區塊裡

概念位置

在 Apache 為主的主機環境（多數共享主機和部分 VPS），.htaccess 是不需要重啟伺服器就能調整行為的設定機制。WordPress、Laravel、Drupal 等 PHP 框架都依賴 .htaccess 的 URL rewrite 規則來實現 pretty URL（把 /blog/post-title 轉成 index.php?page=post-title）。

可觀察訊號

站台根目錄有 .htaccess 檔案（注意它是隱藏檔，FTP client 要啟用「顯示隱藏檔案」才看得到）。上傳目錄（uploads/）、後台目錄（admin/、wp-admin/）可能各有一份獨立的 .htaccess 做額外的存取控制。

設計責任

接手維運時，.htaccess 要注意四件事：

URL rewrite 規則：這些規則決定了站台的 URL 結構。亂改或刪除會讓所有內頁都回 404。修改前先備份原始版本。

安全設定：Options -Indexes 禁止目錄列表、php_flag engine off 禁止上傳目錄執行 PHP、Require all denied 禁止存取 .env 等機密檔案。這些設定分散在多個目錄的 .htaccess 裡，接手時要全部找出來。

PHP 設定覆寫：部分 PHP 設定（如 upload_max_filesize、max_execution_time）可以在 .htaccess 裡用 php_value 或 php_flag 指令覆寫。這些覆寫可能不在 php.ini 裡，只存在於 .htaccess。

遷移到 nginx 的影響：nginx 沒有 .htaccess 的對等機制——所有設定都在集中的 nginx 設定檔裡。從 Apache 遷移到 nginx 時，.htaccess 裡的每一條規則都要手動轉換成 nginx 語法。

鄰卡

• php.ini / .user.ini：.htaccess 管 Apache 行為，.user.ini 管 PHP 行為，兩者互補

概念位置

.env 是跨語言的設定分離慣例。PHP 用 vlucas/phpdotenv 套件讀取、Node.js 用 dotenv 套件、Python 用 python-dotenv、Go 用 godotenv。這些套件的行為相同：程式啟動時讀 .env 檔案，把裡面的變數載入到執行環境的環境變數裡，讓程式碼用 $_ENV['KEY']（PHP）或 process.env.KEY（Node）存取。

可觀察訊號

站台根目錄有 .env 或 .env.production 檔案；.gitignore 裡有 .env 這一行；repo 裡有 .env.example 或 .env.sample 列出所有需要的變數但不填實際值。如果接手的專案沒有 .env 但 config.php 裡直接寫了資料庫密碼，代表設定分離還沒做——這是接手後應該處理的事。

設計責任

使用 .env 時有三個紀律：

不進 Git：.env 包含明文密碼，進了 Git 就跟著每一次 clone、fork、CI 快取擴散。.gitignore 必須排除 .env。如果 .env 已經在 Git 歷史裡，刪掉那一行不夠——密碼留在 history 裡，要輪替所有外洩的密碼。

範本檔進 Git：repo 裡放一份 .env.example，列出所有必要的環境變數但不填實際值。新接手的人複製 .env.example 成 .env，再填入自己環境的值。

不用 .env 管非機密設定：應用程式的功能開關、UI 設定、feature flag 不屬於 .env——這些設定沒有機密性、應該進版本控制。.env 只放「換一個環境就要改的值」和「不能被看到的值」。

鄰卡

• php.ini / .user.ini：.env 管應用程式設定、php.ini 管 PHP runtime 設定

概念位置

php.ini 由伺服器管理員管理，租用主機的使用者通常不能直接修改。.user.ini 是使用者層級的設定覆寫——功能上類似 .htaccess 對 Apache 的角色，但只管 PHP 設定。在 cPanel 環境裡，部分設定也可以透過「PHP 選擇器」的圖形介面調整。

可觀察訊號

PHP 行為異常時要檢查的第一個地方。常見的情境：上傳檔案失敗（upload_max_filesize 太小）、長時間運算被中斷（max_execution_time 太短）、記憶體不足錯誤（memory_limit 太低）、看不到錯誤訊息（display_errors 關閉）。用 phpinfo() 可以看到每一項設定的目前值和來源（php.ini / .user.ini / .htaccess）。

設計責任

接手維運時要知道的關鍵設定：

.user.ini 的修改不需要重啟 Apache/nginx，但有快取時間（預設 300 秒）——改完後要等最多 5 分鐘才生效。php.ini 的修改在多數環境需要重啟 web server。

鄰卡

• .htaccess：.htaccess 管 Apache 行為（URL rewrite、存取控制），.user.ini 管 PHP 行為（記憶體、執行時間），兩者互補
• .env：.env 管應用程式設定（DB 密碼、API key），php.ini 管 PHP runtime 設定（記憶體、上傳大小）

概念位置

DNS 在 infra 裡扮演「服務的門牌」角色。平台遷移、環境切換、TLS 憑證驗證都經過 DNS。ALB 或 CDN 前面通常掛一層 DNS record 作為穩定入口——IP 會隨資源重建而變，DNS 名稱不變。

常見的記錄類型

可觀察訊號

平台遷移時 DNS 切換是最後一步也是最不可控的一步——TTL（Time To Live）決定舊記錄被各地 DNS resolver 快取多久。TTL 300 秒代表切換後最多 5 分鐘全部 client 會指向新 IP；TTL 86400（1 天）代表最慢要等一天。遷移前 48 小時先降 TTL 到 300 秒，讓快取過期後所有 resolver 都拿到短 TTL 版本，切換時才能快速生效。

設計責任

DNS 設定要決定：誰管這個域名的 zone（Route 53 / Cloudflare / 域名商）、子域怎麼委派（dev / staging 用 NS delegation 交給不同 zone）、TTL 設多少（平常 3600 秒夠用、遷移前降到 300）。ACM 的 DNS 驗證也依賴 DNS——建立 TXT 或 CNAME 記錄證明域名歸屬。

鄰卡

• ALB — DNS 記錄通常指向 ALB 作為流量入口
• SSL/TLS — TLS 憑證的 DNS 驗證依賴 DNS record

概念位置

TLS 在 infra 裡負責「傳輸安全」。ALB 的 HTTPS listener 需要掛一張 TLS 憑證；ACM（AWS Certificate Manager）提供免費的憑證申請與自動續期；Let’s Encrypt 是跨平台的免費 CA（Certificate Authority，憑證簽發機構）。

可觀察訊號

TLS 憑證有到期日。過期的憑證會讓瀏覽器顯示安全警告、部分 client 直接拒絕連線。ACM 管理的憑證會自動續期（前提是 DNS 驗證記錄仍然存在）；手動上傳的憑證需要人工追蹤到期日。接手維運時要確認：憑證的簽發者是誰、到期日是什麼時候、續期是自動還是手動。

用 CLI 查看遠端憑證資訊：

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

設計責任

TLS 設定要決定：憑證從哪裡來（ACM 免費但只能用在 AWS 服務上、Let’s Encrypt 免費且跨平台）、驗證方式（DNS 驗證適合自動化、email 驗證較手動）、是否需要多域名的 SAN 憑證（一張憑證涵蓋 example.com + *.example.com）、HTTP → HTTPS 的強制跳轉怎麼設。

鄰卡

• DNS — TLS 憑證的 DNS 驗證依賴 DNS record
• ALB — HTTPS listener 需要掛 TLS 憑證

概念位置

SSH 在接手維運的情境裡是一條關鍵分界線：有 SSH 存取就能用 mysqldump、git、systemctl 等 CLI 工具操作伺服器；沒有 SSH 就只能用 FTP 傳檔案、用 phpMyAdmin 管資料庫、用 cPanel 改設定。兩種情境的操作流程和可用工具完全不同。

可觀察訊號

判斷有沒有 SSH 存取：嘗試 ssh user@host。如果連線成功進入命令列就有；如果 timeout 或被拒，可能是主機不開放 SSH（共享主機常見）、或 port 不是預設的 22、或需要 IP 白名單。cPanel 的「終端機」功能有時提供 web-based SSH，但功能受限。

設計責任

SSH 的認證方式有兩種：密碼（簡單但不安全，容易被暴力嘗試）和 SSH key pair（公鑰放在 server 的 ~/.ssh/authorized_keys，私鑰留在 client）。生產環境應該用 key 認證並關閉密碼登入。

接手維運時要確認：SSH 的登入帳號是什麼、用密碼還是 key、key 在哪裡、有沒有其他人也有存取權限。前任維護者的 SSH key 如果還在 authorized_keys 裡，離職後應該移除。

1# 產生 SSH key pair
2ssh-keygen -t ed25519 -C "your-email@example.com"
3
4# 把公鑰加到遠端 server
5ssh-copy-id -i ~/.ssh/id_ed25519.pub user@host

鄰卡

• FTP — 沒有 SSH 時的檔案傳輸替代方案

概念位置

FTP 在無 SSH 的環境裡是唯一的檔案管理途徑——程式碼部署靠 FTP 上傳、備份靠 FTP 下載、檔案比對靠 FTP client 的目錄比較功能。它是接手維運模組「無 SSH 環境」路線的核心工具。

FTP 的變體

多數 FTP client（FileZilla、WinSCP）同時支援三種協定。如果伺服器有 SSH，用 SFTP 比 FTP 安全且功能更多。

可觀察訊號

FTP 操作的三個限制在接手維運時要意識到：第一，非原子操作——檔案逐一上傳，上傳過程中伺服器上同時存在新舊版本的混合狀態。第二，不支援指令執行——只能傳檔案、不能跑腳本或重啟服務。第三，沒有版本控制——上傳覆蓋就是覆蓋，沒有 diff、沒有 rollback。

設計責任

用 FTP 部署時要建立的紀律：本地先 Git commit 再上傳（Git 提供版本控制、FTP 只負責傳輸）；上傳前用目錄比較確認差異；關鍵檔案（index.php、.htaccess）上傳前先從 server 下載一份備份。

鄰卡

• SSH — 有 SSH 時用 SFTP 或 SCP 替代 FTP
• FileZilla — 最常用的 FTP client

概念位置

cron 在接手維運時是容易被忽略的隱藏工作——它不像 web 服務有明顯的入口，但可能負責資料庫備份、快取清除、報表產出、日誌清理等關鍵任務。漏掉一個 cron job 可能讓備份停止、快取永不過期、報表不再更新，而且不會立刻有人發現。

crontab 格式

1# 分 時 日 月 週  指令
20  3  *  *  *    /usr/bin/php /var/www/backup.php
3*/5 * *  *  *    /usr/bin/curl -s https://example.com/cron/heartbeat
40  0  1  *  *    /usr/bin/find /tmp -mtime +7 -delete

五個時間欄位依序是分鐘（0-59）、小時（0-23）、日（1-31）、月（1-12）、星期幾（0-7，0 和 7 都是星期日）。* 代表「每一個」，*/5 代表「每 5 個」。

可觀察訊號

接手維運時盤點 cron job：

 1# 當前使用者的 crontab
 2crontab -l
 3
 4# 所有使用者的 crontab（需要 root）
 5for user in $(cut -f1 -d: /etc/passwd); do
 6  crontab -u "$user" -l 2>/dev/null && echo "=== $user ==="
 7done
 8
 9# 系統級 cron
10cat /etc/crontab
11ls /etc/cron.d/

沒有 SSH 時（cPanel 環境），在 cPanel 的「Cron 工作」頁面查看和匯出。

設計責任

cron job 要決定：排程頻率、執行失敗時的通知方式（cron 預設把輸出寄 email，但 email 常沒配好）、日誌記錄（指令的 stdout/stderr 導到 log 檔）。遷移或升級時，cron job 要隨著遷移——忘了搬等於停掉排程但沒人知道。

雲端替代品：AWS CloudWatch Events / EventBridge、GCP Cloud Scheduler、Azure Logic Apps。這些服務提供 web UI 管理、失敗通知、執行歷史，但需要額外設定。

鄰卡

• SSH — 盤點和管理 cron 需要 SSH 存取

概念位置

nginx 在 infra 裡常見的角色有三種：作為 reverse proxy 把請求轉給後端應用（Node.js、PHP-FPM、Python WSGI）、作為靜態檔案伺服器、作為 TLS 終結點處理 HTTPS。ALB 在雲端環境承擔了部分 nginx 的職責（負載平衡、TLS 終結），但 VPS 環境裡 nginx 仍然是標準選擇。

跟 Apache 的關鍵差別

可觀察訊號

OS 升級或平台遷移時，如果從 Apache 換成 nginx，所有 .htaccess 規則要手動轉成 nginx 設定：URL rewrite、目錄保護、PHP 設定覆寫、安全標頭。nginx 沒有 .htaccess 的等價物——所有設定都在集中的設定檔裡，需要 reload nginx 才能生效（Apache 的 .htaccess 每次請求都重新讀取）。

設計責任

nginx 設定要決定：server block（類似 Apache 的 VirtualHost）怎麼組織、upstream 指向哪個 app server、靜態檔案的 root 路徑、TLS 憑證掛在哪裡、access log 和 error log 的路徑。設定改完跑 nginx -t 驗證語法後再 nginx -s reload。

鄰卡

• .htaccess — Apache 的分散設定，遷移到 nginx 時需要轉換
• ALB — 雲端環境裡承擔部分 nginx 職責

概念位置

MySQL 在 infra 裡是典型的 stateful 資源——資料不可重建、備份和刪除保護是 day-1 需求。接手維運時，MySQL 的版本、備份設定、認證方式是第一批要確認的項目。雲端環境裡 MySQL 常以 RDS 形式運行（受管服務、代管備份與 failover）。

大版本升級的關鍵差異

MySQL 5.7 → 8.0 的 breaking change 在接手和升級情境裡經常遇到：

可觀察訊號

接手維運時的確認清單：SELECT VERSION(); 查版本、SHOW DATABASES; 看有哪些資料庫、SHOW VARIABLES LIKE 'character_set%'; 確認字元集、SHOW VARIABLES LIKE 'max_connections'; 看連線上限。

CLI 工具

mysqldump 是備份的核心工具——一行指令把整個資料庫匯出成可還原的 SQL。phpMyAdmin 的匯出功能底層也是類似的邏輯，但受 web server timeout 限制，大資料庫更適合用 CLI。

設計責任

MySQL 的 infra 設計要決定：備份頻率和保留天數（RDS 預設 7 天自動備份）、是否開 multi-AZ（failover 保護）、連線池設定（RDS Proxy 或應用層 pool）、慢查詢日誌是否開啟。

鄰卡

• RDS — AWS 的受管 MySQL 服務
• phpMyAdmin — Web 介面的 MySQL 管理工具

概念位置

RDS 是 infra 系列中 stateful 資源的代表。它持有不可重建的資料，所以它的 IaC 描述、備份策略、刪除保護、變更審查都比 stateless 資源（如 EC2 web server）嚴格。模組五（核心服務）和接手維運模組的資料庫相關段落都以 RDS 為主要範例。

可觀察訊號

需要理解 RDS 的情境包括：接手一個已經在跑的 production 資料庫、評估要不要從自建 MySQL 遷移到 RDS、設定資料庫的備份和高可用、或在 IaC 裡描述資料庫資源。

設計責任

使用 RDS 時要決定的關鍵設定：

跟自建 MySQL on EC2 的取捨：RDS 省去 OS 層運維，但 parameter group 和 option group 的可調整範圍比直接操作 my.cnf 窄。需要完全控制 OS 層（如自訂 plugin、特殊檔案系統）時，自建較合理。

鄰卡

• MySQL
• Deletion Protection
• Subnet

概念位置

S3 在 infra 系列裡有三個角色：Terraform state 的存放處（remote state backend）、應用程式的靜態檔案儲存（上傳內容、備份歸檔）、以及 log 的長期保存目的地。模組一（state backend）、模組五（storage）、模組八（治理）都涉及 S3。

可觀察訊號

需要理解 S3 的情境包括：設定 Terraform 的 remote state backend、管理使用者上傳的檔案、設計備份歸檔策略、或評估儲存成本。

設計責任

使用 S3 時要決定的關鍵設定：

versioning 開啟後，刪除物件只是加一個 delete marker、實際資料還在。要真正刪除需要刪除 delete marker 和所有歷史版本。這是保護 state 檔的關鍵機制——誤寫 state 後可以回捲到上一個版本。

鄰卡

• Remote State Backend
• Deletion Protection

概念位置

EC2 是 infra 系列中「運算」面向的基礎單位。容器服務（ECS、EKS）底層也跑在 EC2 上（除非用 Fargate）。模組五（核心服務）的運算段落、接手維運（雲端篇）的 VM 快照、升級模組的 OS 遷移都以 EC2 為操作對象。

可觀察訊號

需要理解 EC2 的情境包括：接手一個跑在 VM 上的應用程式、評估容器化 vs VM 部署、設定 auto-scaling、或建立 AMI 快照作為備份。

設計責任

一台 EC2 instance 由五個組件構成：

跟容器（ECS / EKS）的差別：EC2 管整台 VM（含 OS 更新、安全性修補、磁碟管理），容器只管應用程式及其依賴。EC2 的運維負擔較高、但控制粒度也較高。

鄰卡

• AMI
• ECS
• Subnet
• Security Group

概念位置

EBS 是 infra 系列中儲存面向的底層組件。RDS 的資料實際存在 EBS 上（由 AWS 代管）、EC2 的根磁碟和附加磁碟都是 EBS volume。接手維運時對 VM 做快照（AMI），背後就是在對 EBS volume 做 snapshot。

可觀察訊號

需要理解 EBS 的情境包括：EC2 instance 的磁碟快滿了需要擴容、要對 VM 做快照備份、評估磁碟效能（IOPS）是否足夠、或清理不再掛載的孤立 volume（殭屍 volume 持續計費）。

設計責任

跟 instance store 的差別：instance store 是 EC2 實體主機上的臨時磁碟，效能高但 instance 停止資料就消失。EBS 是持久化儲存，instance 停止資料仍在。

鄰卡

• EC2
• Deletion Protection

概念位置

HCL 是 infra 系列中 IaC 程式碼的語言層。IaC 卡講的是「用程式碼管理基礎設施」的概念，HCL 是這個概念落地時最常用的語言。模組一到八的所有 HCL 範例都用這個語言寫成。

可觀察訊號

需要理解 HCL 的情境包括：第一次打開一份 .tf 檔案、要讀懂 Terraform 的 plan 輸出、要修改或新增一個 resource 定義、或要 review 別人的 infra PR。

設計責任

HCL 的基本結構：

1resource "aws_s3_bucket" "example" {
2  bucket = "my-bucket"
3  tags   = { env = "prod" }
4}

• resource：宣告一個雲端資源
• "aws_s3_bucket"：資源類型（由 provider 決定）
• "example"：這個資源在程式碼裡的名稱（用來引用）
• {}：這個資源的屬性

跟其他格式的差別：

HCL 的定位在 JSON 和通用語言之間——比 JSON 有表達力（能做迴圈和條件）、比通用語言好 review（diff 直觀、不需要在腦中「執行」程式碼才知道結果）。

鄰卡

• IaC
• State

概念位置

plan/apply 的分離是 IaC 可審查性的基礎。模組七（PR 流程）的核心機制就是「PR 觸發 plan → plan 結果貼回 PR → reviewer 看 plan 再決定要不要 apply」。這個「先看再動」的流程跟手動操作（直接在 Console 改）的根本差別。

可觀察訊號

需要理解 plan/apply 的情境包括：第一次跑 Terraform、review 別人的 infra PR（看 plan 輸出）、排查 drift（plan 在沒有 code 變更的情況下顯示差異）、或決定一次 apply 是否安全。

設計責任

plan 輸出的三種動作標記：

review plan 時最需要警惕的是 -/+（forces replacement）——看起來只是改一個屬性，但某些屬性的修改會觸發資源重建（例如 RDS 的 identifier 改名）。

plan 與 apply 之間可能有時間差。如果 plan 之後、apply 之前有人手動改了雲端資源，apply 時的實際行為可能跟 plan 預期的不同。多數團隊在 apply 階段會重跑一次 plan 並要求結果一致。

鄰卡

• State
• Drift
• IaC

概念位置

AMI 在 infra 系列裡有兩個角色。第一個是接手維運時的保險——對 VM 建一個 AMI 等於把整台機器拍下來，做任何改動前都有一個可回退的基線。第二個是環境標準化——把裝好軟體的 instance 做成 AMI（golden image），之後開新機器都從這個 AMI 啟動，確保每台機器的基線一致。

可觀察訊號

需要理解 AMI 的情境包括：接手一台不確定裡面裝了什麼的 EC2（先拍 AMI 再動）、要在另一個 region 或帳號複製一台同樣的機器、OS 升級時要保留舊環境作為 rollback、或設計 auto-scaling 的 launch template（需要指定 AMI）。

設計責任

AMI 包含 EBS snapshot——AMI 的儲存成本就是底層 EBS snapshot 的成本（按儲存量計費）。不再使用的 AMI 要記得 deregister 並刪除對應的 snapshot，否則持續計費。

跟 container image 的差別：AMI 是整台 VM 的映像（含 OS、kernel、系統套件），container image 只包含應用程式和它的依賴（共用 host OS 的 kernel）。AMI 以 GB 計（通常 8-50 GB），container image 以 MB 計（通常 50-500 MB）。

鄰卡

• EC2
• EBS

概念位置

接手 PHP 專案時，Composer 是判斷「專案依賴了什麼、版本有沒有已知漏洞」的入口。專案根目錄通常有三個 Composer 相關的檔案：

可觀察訊號

接手專案時如果根目錄有 composer.json 但沒有 vendor/，代表需要先跑 composer install 才能讓專案運作。如果連 composer.lock 都沒有，代表套件版本沒有鎖定——每次安裝可能拿到不同版本。

設計責任

兩個常用指令的差別：

• composer install：按 composer.lock 安裝確切版本。用於部署和接手——確保每台機器安裝的版本一致。
• composer update：重新解析 composer.json 的版本範圍、更新到最新的符合版本、改寫 composer.lock。用於主動升級依賴。

接手時的關鍵操作：

• composer audit：掃描已安裝套件的已知安全漏洞
• composer outdated：列出可更新的套件及其最新版本

鄰卡

• .env：Composer 管套件、.env 管設定值，兩者都是 PHP 專案的基礎設施
• php.ini / .user.ini：Composer 需要 PHP CLI 執行，php.ini 的 memory_limit 和 max_execution_time 會影響 Composer 能不能跑完

概念位置

mysqldump 是有 SSH 存取（或 remote MySQL 存取）時的主要備份手段。比 phpMyAdmin 的匯出更可靠——不受 web server 的 timeout 和記憶體限制影響，可以處理數 GB 的資料庫。沒有 SSH 的環境只能退回 phpMyAdmin 匯出。

可觀察訊號

接手時如果 server 上有 cron job 在跑 mysqldump，代表前任有做自動備份——確認輸出的 dump 檔案存在哪、保留幾天、有沒有被驗證過能還原。如果沒有任何 mysqldump cron，代表備份可能只靠 phpMyAdmin 手動匯出或完全沒做。

設計責任

常用的 flag 組合：

1mysqldump -u user -p \
2  --single-transaction \
3  --routines \
4  --triggers \
5  dbname > dump-$(date +%Y%m%d).sql

還原指令：

1mysql -u user -p dbname < dump-20260626.sql

mysqldump 產出的是邏輯備份（SQL 語句），還原速度取決於資料量——幾百 MB 以內分鐘級，數 GB 可能要半小時以上。需要更快的備份/還原（物理備份），要用 Percona XtraBackup 或 MySQL Enterprise Backup。

鄰卡

• phpMyAdmin：無 SSH 時的替代備份手段
• cron：搭配 cron 做定期自動備份

概念位置

nginx 和 ALB 都扮演 reverse proxy 角色。差別在層級：nginx 通常部署在應用層（跟應用伺服器同一台或同一個 VPC 內），ALB 是雲端平台提供的受管服務。兩者的核心功能相同——接收外部流量、轉發到後端、回傳結果。

跟 forward proxy 的方向相反：forward proxy 代替 client 發送請求（client 在內網、proxy 幫它出去）；reverse proxy 代替 server 接收請求（server 在內網、proxy 幫它面對外部）。

可觀察訊號

接手時如果 server 上跑著 nginx 但應用程式用的是 PHP-FPM 或 Node.js，nginx 多半扮演 reverse proxy——它接 HTTP/HTTPS 請求、轉發給後端的 application server。設定檔裡的 proxy_pass（nginx）或 ProxyPass（Apache）就是 reverse proxy 的轉發規則。

設計責任

reverse proxy 常承擔的功能：

鄰卡

• ALB：雲端的受管 reverse proxy + 負載平衡器
• nginx：最常見的 reverse proxy 軟體

概念位置

migration 解決的問題是「資料庫的 schema 怎麼從 A 狀態安全地變成 B 狀態」。沒有 migration 時，schema 變更靠在 phpMyAdmin 或 CLI 手動執行 SQL，改了什麼只存在操作者的記憶裡。有 migration 時，每次變更都是 repo 裡的一份檔案，跟程式碼一起 commit、一起 review。

可觀察訊號

接手專案時，如果 repo 裡有 migrations/ 目錄（或框架特定的路徑如 Laravel 的 database/migrations/、Rails 的 db/migrate/），代表專案使用 migration。如果 repo 裡只有一份 schema.sql 或完全沒有 schema 相關檔案，代表 schema 變更是手動的——這時候建立 migration 紀律是接手後的優先事項之一。

設計責任

每份 migration 檔案包含兩個方向：

• UP（套用）：執行 schema 變更的 SQL
• DOWN（回退）：撤銷這次變更的 SQL（不是所有變更都能完美回退，如刪除欄位後資料就沒了）

1-- migrations/2026-06-26-001-add-users-email-verified.sql
2
3-- UP
4ALTER TABLE users ADD COLUMN email_verified BOOLEAN DEFAULT FALSE;
5
6-- DOWN
7ALTER TABLE users DROP COLUMN email_verified;

常用的 migration 工具：

沒有框架時，用日期 + 序號命名 SQL 檔案（2026-06-26-001-描述.sql），搭配一張 migration_log 表記錄哪些已經套用過，就是最低限度的 migration 系統。

鄰卡

• RDS：migration 在 production 資料庫上執行時要格外小心——大表的 ALTER TABLE 可能鎖表
• mysqldump：執行 migration 前先做一次完整備份

概念位置

Prometheus 在 infra 監控層負責「收集與儲存指標」。它搭配 Grafana 做視覺化（Prometheus 自己的 UI 只有基礎的 query 介面）、搭配 Alertmanager 做告警路由（Prometheus 偵測異常、Alertmanager 決定通知誰）。斷網環境裡它是取代 Datadog / New Relic 的預設方案——不需要連外、self-hosted、社群龐大。

可觀察訊號

系統需要 Prometheus 的訊號是：需要追蹤隨時間變化的數值指標（CPU 使用率、request 延遲、佇列深度、錯誤率），且這些指標要能查詢歷史趨勢和設定告警閾值。如果只需要 log（文字紀錄），Loki 或 ELK 更適合；Prometheus 處理的是結構化的數值 metrics。

設計責任

使用 Prometheus 時要決定：scrape interval（多久拉一次、預設 15 秒）、retention（資料保留多久、預設 15 天）、哪些 target 要監控（service discovery 或靜態設定）、告警規則的閾值和評估窗口。斷網環境的額外考量是 storage capacity——所有資料留在本地磁碟、沒有 cloud auto-scale。

鄰卡

• Grafana：視覺化 Prometheus 的指標

概念位置

Grafana 在監控體系裡負責「讓指標和 log 變成人可以讀的畫面」。Prometheus 收集指標、Loki 收集 log、Grafana 把兩者的資料用圖表、表格、熱力圖呈現。不同角色看不同 dashboard——DevOps 看資源健康、開發者看應用指標、管理層看 SLA 達成率。

可觀察訊號

系統需要 Grafana 的訊號是：已經有 Prometheus 或其他資料源在收集指標，但需要一個視覺化介面來建 dashboard、設告警（Grafana 也有自己的告警功能）、分享給團隊。如果只需要 CLI 查詢，PromQL 直接在 Prometheus 跑就好。

設計責任

使用 Grafana 時要決定：dashboard 的組織（按服務、按環境、按角色）、資料源的連線設定、使用者權限（viewer / editor / admin）、告警通知管道（email / Slack / webhook）。斷網環境裡 Grafana 的 plugin 需要離線安裝（grafana-cli --pluginUrl 指向本地檔案）。

鄰卡

• Prometheus：Grafana 最常見的 metrics 資料源

概念位置

Vault 在 infra 裡負責「機密值的集中管理」。跟直接把密碼寫在環境變數或設定檔的差別是：Vault 提供存取控制（只有被授權的身分能讀特定 secret）、稽核軌跡（誰在什麼時候讀了什麼）、以及動態 secret（每次請求產生一組臨時憑證、用完即銷毀）。

連網環境通常用雲端的 secret manager（AWS Secrets Manager、GCP Secret Manager）。斷網環境沒有雲端服務可用、Vault 是 self-hosted 的替代方案。

可觀察訊號

系統需要 Vault 的訊號是：多個服務共用同一組資料庫密碼且密碼寫在設定檔裡、沒有人知道上次輪替是什麼時候、或是稽核要求「列出誰能存取哪些機密」而答不出來。

設計責任

使用 Vault 時要決定：unseal 方式（連網用 cloud auto-unseal、斷網用 Shamir’s secret sharing——需要 N 把 key 中的 M 把才能解鎖）、storage backend（Consul、PostgreSQL、filesystem）、認證方式（人用 LDAP/OIDC、機器用 AppRole）、secret engine 的選擇（KV 存靜態值、PKI 簽發憑證、database 動態產生 DB 帳號）。

鄰卡

• IAM：Vault 的存取政策跟 IAM 的 policy 概念類似
• SSL/TLS：Vault 的 PKI engine 可以當內部 CA 簽發憑證

概念位置

Harbor 在容器生態裡負責「映像的儲存、分發和安全把關」。連網環境裡這個角色通常由 Docker Hub、AWS ECR 或 GCR 擔任。斷網環境沒有公開 registry 可用、Harbor 是 self-hosted 的替代——所有 base image 和應用 image 都推進 Harbor、所有 docker pull 都從 Harbor 拉。

可觀察訊號

系統需要 Harbor 的訊號是：團隊開始用容器部署服務、且環境無法連到公開 registry（斷網或受限網路）、或需要在 pull 時自動掃描漏洞。如果只是幾個人在開發機上用 Docker、Docker Registry（無 UI、無掃描）就夠了。

設計責任

使用 Harbor 時要決定：project 的組織（按團隊、按環境、按產品線）、使用者認證（本地帳號 or LDAP 整合）、漏洞掃描政策（push 時自動掃、block 有 Critical CVE 的 image）、映像保留政策（保留最近 N 個 tag、自動清理舊 image）、以及 storage backend（本地磁碟或 NFS）。

鄰卡

• ECS：ECS task 從 registry 拉 image
• Fargate：Fargate task 同樣需要 registry

概念位置

Helm 在 K8s 生態裡的角色類似 apt 在 Linux、npm 在 Node.js——把「安裝一個應用」從「逐一 apply 多個 YAML」變成「一條 helm install 指令」。chart 可以參數化（values.yaml），同一份 chart 在不同環境用不同參數部署。

公開 chart 從 Artifact Hub 下載。斷網環境裡用 helm pull 在外部下載 chart tarball、搬進內網、從本地檔案安裝，或用 Harbor 的 OCI chart 支援當內部 chart registry。

可觀察訊號

系統需要 Helm 的訊號是：用 K8s 部署的應用超過 3 個、每個應用由 5+ 個 K8s 資源組成、且需要在多個環境（dev/staging/prod）用不同參數部署同一套定義。如果只有 1-2 個簡單應用、直接 kubectl apply 就好。

設計責任

使用 Helm 時要決定：chart 的粒度（一個 chart = 一個微服務 or 一整個平台）、values 的組織（per-environment values file）、chart 版本管理（chart version vs app version）、以及升級策略（helm upgrade --atomic 失敗自動回退）。

鄰卡

• ECS：ECS 是非 K8s 的容器編排替代