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

概念位置

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

可觀察訊號

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

設計責任

IaC 要讓程式碼成為基礎設施的 source of truth，採用時的決定分別處理程式碼用什麼寫、state 放在哪裡、誰還能繞過程式碼直接改、以及哪些資源先納管：

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

鄰卡

• State — IaC 工具追蹤現實的記憶機制
• Drift — state 與現實不一致時的狀態
• 環境分離 — 同一份 IaC 描述套用到多環境
• Configuration Management（組態管理） — 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 的設定裡事後最難改的是分割策略：資源分進不同的 state 之後，要移動就得在兩份 state 之間逐個資源遷移。存放位置、加密、版本保留與鎖機制管的是 state 的安全與復原：防止兩次 apply 同時寫入、限制外洩的範圍、在損壞後回捲到上一個版本：

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

鄰卡

• IaC — state 是 IaC 工具的核心依賴
• Drift — state 與現實的落差
• Configuration Management（組態管理） — 由 Terraform 的輸出產生 Ansible 的 inventory 時，那份檔案的內容記在 state 裡
• 多台主機維護清單的實作紀錄：在容器上安裝 ansible-core 與 Terraform、由 Terraform 產生 inventory、用 Ansible 的範本部署每台的清單、以 sudo 與 systemd-run 執行檢查腳本，以及清理 — 本機 state 放在掛進容器的工作目錄、清理時先 terraform destroy 再刪控制端的實際操作

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

概念位置

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

可觀察訊號

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

偵測 drift 的主動方式是定期跑 terraform plan 但不 apply，把 diff 輸出當成 drift 偵測的報告。plan 只比對 state 裡有的資源：有人在主控台另外新增、不在 state 裡的資源（例如寫成獨立資源的一條防火牆規則），plan 照樣回報 No changes，範圍見 多台主機的維護清單：值的分層與合併的位置、用 Ansible 的 inventory 與範本產生每台的清單、由 Terraform 的輸出產生 inventory、跨主機執行的 exit code，以及單台清單的適用範圍〈清單裡要到主控台確認的項目與 terraform plan 的比對範圍〉（從比對機制推論，沒有實測）。Terraform Cloud 有內建的 drift detection 功能，定期比對 state 與雲端現實。

設計責任

Drift 出現之後，團隊先要判斷 Console 上那次手動修改是失誤還是有理由的修正，偵測、修正與預防的設計都從這個判斷出發：

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

鄰卡

• State — drift 是 state 與現實的落差
• IaC — drift 破壞 IaC 的 source of truth 地位
• Configuration Management（組態管理） — 主機內部的套件與設定檔跟宣告不一致，由組態管理工具處理

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 的地址空間在建立時定下、事後擴張受限，而網段一旦跟其他 VPC 或地端網路重疊，兩邊就無法建立 peering 或互連；規劃時先定的是：

• 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 決定「哪些資源能被外網碰到、哪些只能在內網存取」。在 AWS 上每個 subnet 綁定單一可用區，高可用設計通常是每種角色跨至少兩個可用區各開一個 subnet；Google Cloud 與 Oracle Cloud 的 subnet 可以跨區域內的可用區（Oracle Cloud 叫 regional subnet），見 Availability Zone（可用區）。公開與私有的區分在各家的實作也不同，Oracle Cloud 另用 subnet 的屬性禁止公開 IP、Google Cloud 沒有這個區分，見 網路：subnet、私有 IP、公開 IP 與防火牆規則。

可觀察訊號

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

設計責任

subnet 建立後 CIDR 無法修改、而且在 AWS 上綁定單一可用區，第一次規劃時的切法與分佈就決定了之後能放多少服務、能在哪一個可用區故障時繼續運作：

• 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 是封包抵達資源前的最後一道網路檢查：規則寫得太寬會把服務的埠暴露出去，寫成固定位址又會在節點換 IP 時失效。設計時在這兩種失效之間收斂的項目是：

• 引用方式：用 group 互相引用（推薦）vs 用 CIDR 限定範圍
• 開放範圍：只開需要的埠與來源，0.0.0.0/0 只給對外 LB
• 管理埠存取：SSH（22）改用 SSM Session Manager 這類不開入站 port 的做法，或只放行身分感知代理的位址段，從公網清單上拿掉；各種做法的選擇見伺服器管理通道的設計
• 與 NACL 的分工：security group 是主力（有狀態、group 引用），NACL 留給少數需要 subnet 層顯式 deny 的情境
• 規則數上限：一條規則只放一段來源時，放一份外部位址清單（例如只放行 CDN 回源的位址）要「段數 × 連接埠數」條，會撞到每個 group 的規則數上限；AWS 文件寫的預設是入站 60 條、IPv4 與 IPv6 分開算，Oracle Cloud 的 NSG 實測是入站加出站合計 120 條，見 Cloudflare 回源的實測紀錄：Oracle Cloud NSG 只放行 Cloudflare 位址與規則數上限、回源的來源位址、Authenticated Origin Pulls、Worker 偽造 CF-Connecting-IP 與 Tunnel 的出站連接埠 的〈公開子網路、只放行 Cloudflare 的 NSG 與它的規則數上限〉

鄰卡

• VPC — security group 依附的網路容器
• Subnet — security group 與 subnet 各守不同層級的邊界
• Bastion Host（跳板機） — 目的主機的入站規則以跳板機的 security group 當來源
• Identity-Aware Proxy（身分感知代理） — 管理 port 只放行代理位址段的做法
• 網路：subnet、私有 IP、公開 IP 與防火牆規則 — Oracle Cloud 與 Google Cloud 上對應網卡層規則的元件與合併方式

概念位置

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

傳統的 zonal NAT Gateway 綁定單一可用區，放在某個 public subnet 裡，實際生不生效由 private subnet 的 route table 預設路由決定。這帶來一個架構取捨：共享一個 NAT（成本低、出站方向有單點）還是每個可用區各放一個（成本高、出站與 subnet 冗餘對齊）。AWS 在 2025 年 11 月另外推出 regional 模式的 NAT Gateway：一個 NAT 依工作負載所在的可用區自動擴展，不需要放進 public subnet；新的可用區出現工作負載後，擴展到那一區可能要等上一段時間（AWS 公告寫的是最多 60 分鐘）。選擇時要先確認用的是哪一種模式，上面的單點取捨只適用於 zonal 模式。

GCP 的對應服務是 Cloud NAT，職責相同，結構不同：它建在 Cloud Router 上、以 region 為單位生效，不需要放進某個 subnet，也沒有可用區層級的單點取捨。管理通道改走代理之後要移除 VM 的外部 IP，出站就改由 Cloud NAT 承接，見伺服器管理通道的設計的〈移除公開 IP 之後的出站路徑〉。沒有外部 IP 的 VM 要存取 Google 自家的 API 時，subnet 開啟 Private Google Access 就能走內部路徑，作用與 AWS 的 VPC Endpoint 相近。

可觀察訊號

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

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

設計責任

zonal 模式下每多放一個 NAT Gateway 就多一筆固定月費，少放一個就讓某些可用區的出站依賴別區的 NAT，而經過 NAT 的每 GB 流量另外計費（這兩種費用是 AWS 的收法；Oracle Cloud 的價目表沒有 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）可以用平台原生的 IAM 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 聯合拿掉了 CI 環境裡的長期 access key，風險因此移到兩個位置：哪些 token 換得到 role，以及換到之後能做什麼。下面的設定分別收斂這兩個位置：

• 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" 判斷 — 環境差異沒有集中在參數值裡

設計責任

環境分離失效的典型形態是一次 terraform apply 改到了另一個環境的資源，以下的設計各自封住一條造成這種失效的路徑：

• 隔離層級：帳號級、目錄級、還是 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 的設計決定多半是在劃責任交界：運算實例歸 AWS 還是團隊管理、權限歸哪個 role、映像版本歸 infra code 還是 CI/CD，最後再依服務的負載型態選擴容指標：

• 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）簽發的 TLS 憑證，ALB 處理加解密，後端收到的是 HTTP 明文。憑證由 ACM 自動續期，IaC 用 DNS 驗證方式描述憑證 — 讓「憑證存在、續期、掛載」整條鏈都進版本控制。

可觀察訊號

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

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

設計責任

ALB 位於外部 client 與後端 target group 的交界：對 client 要保證連線加密、入口名稱穩定，對後端要判斷哪些 target 能接請求，設計決定分屬這兩個方向：

• 健康檢查參數：檢查路徑（用應用層的 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
• 流量入口層 — ALB 作為 L7 入口在責任鏈的位置、跟單機 nginx 的選擇條件

概念位置

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 建立失敗。

設計責任

VPC 建立之後，原本的 CIDR 區段改不掉，事後擴張只能追加 secondary 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 是其他所有資源的閘門，一個權限過寬的 role 等於把它碰得到的資源全部交給持有那份憑證的身分，設計時先劃清身分與權限的邊界，再排定之後收斂的節奏：

• 身分類型區分：人用 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 的預設設定可能跟預期不符。

設計責任

subnet 是 public 還是 private 由它關聯的 route table 決定，而沒有明確關聯的 subnet 會自動套用 main 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 會繼承給 OU 底下每個帳號與子 OU，連帳號管理員都越不過，所以策略選錯時整個 OU 的帳號一起受影響；第一個要定的是用 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 的完整副本與其中的敏感屬性，存取控制或版本保留一旦出錯，受影響的是整個 IaC 工作流程的依據；選擇時要定的是：自管還是託管（取決於團隊規模和維運餘裕）、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 只管哪些身分能取得這個 role，取得之後能做什麼由 role 的 IAM policy 另外限制，所以 trust policy 的條件全部圍繞 token 的 claim：允許哪些外部身分 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 一開始就啟用全部規則並設為 hard fail 的話，既有程式碼裡的舊寫法也會讓 CI 擋下與它們無關的 PR，所以引入時的設計集中在兩個設定：啟用哪些規則（全部 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 把運算實例交給 AWS 代管之後，團隊能調整的只剩 task 本身的規格與行為，設計集中在：task 的 vCPU / memory 規格（Fargate 只提供固定的幾種 vCPU 與 memory 組合）、是否混用 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。

設計責任

沒有 SSH 的主機上，備份、PHP 版本與排程多半只能從 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）。相對地 nginx 沒有對等機制、設定要集中寫在主設定檔。

可觀察訊號

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

設計責任

.htaccess 的規則分散在各目錄的隱藏檔裡、每次請求即時生效，站台的 URL 結構、存取限制與 PHP 設定可能只記錄在這些檔案裡；接手維運時要逐一找出的內容有：

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 用 Composer 安裝的 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）。

設計責任

同一項 PHP 設定可能同時寫在 php.ini、.user.ini 與 .htaccess 裡，接手維運時先用 phpinfo() 讀出每一項的目前值與來源，再對照下表確認是否符合業務需求：

.user.ini 的修改不需要重啟 Apache/nginx，但有快取時間（預設 300 秒，user_ini.cache_ttl）——改完後要等最多 5 分鐘才生效；它只由 CGI/FastCGI（含 PHP-FPM）讀取，mod_php 下的對應做法是 .htaccess 的 php_value。php.ini 的修改要重新載入讀它的那個程序：mod_php 是重載 Apache，PHP-FPM 是重載 PHP-FPM（web 伺服器不必動），見 mod_php。

鄰卡

• .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 改記錄，再等各地 resolver 快取的舊記錄過期，設計時的決定分別落在這兩段：誰管這個域名的 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
• 流量入口層 — DNS 作為責任鏈第一段（門牌、只在連線前查一次、不承載流量）的定位

概念位置

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 憑證過期會讓瀏覽器顯示安全警告、部分 client 直接拒絕連線，而續期是否能自動完成，取決於憑證的來源與驗證網域持有權的方式；設定時一併決定的是：憑證從哪裡來（ACM 免費但只能用在 AWS 服務上、Let’s Encrypt 免費且跨平台）、驗證方式（DNS 驗證適合自動化、email 驗證較手動）、是否需要多域名的 SAN 憑證（一張憑證涵蓋 example.com + *.example.com）、HTTP → HTTPS 的強制跳轉怎麼設。

鄰卡

• DNS — TLS 憑證的 DNS 驗證依賴 DNS record
• ALB — HTTPS listener 需要掛 TLS 憑證
• 流量入口層 — 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 裡，離職後應該移除。主機一多，逐台刪除就難以盤點，這時改用隨帳號收回的 OS Login 或會自動到期的 SSH Certificate（SSH 憑證），選擇條件見伺服器管理通道的設計的〈主機登入驗證的做法：SSH 金鑰怎麼發、怎麼收回〉。

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 時的檔案傳輸替代方案
• SSH Certificate（SSH 憑證） — 由 CA 簽發、會自動到期的 SSH 金鑰
• OS Login — GCP 上讓登入權限跟著帳號收回的做法
• Bastion Host（跳板機） — 只有一台主機對外開 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 可能讓備份停止、快取永不過期、報表不再更新，而且不會立刻有人發現；常見的資料庫備份工具見 mysqldump。

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 要隨著遷移——忘了搬等於停掉排程但沒人知道。

用 systemd 的主機上，同一類定期工作也可以寫成 systemd timer：多寫一個檔，換到的是關機期間錯過的執行開機後補跑、輸出進 journal、失敗有狀態可以接告警。

雲端替代品：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 把 Apache 分散在各目錄 .htaccess 的設定收回同一棵設定樹，每個站台的行為因此都要在這棵樹裡寫明：server block（類似 Apache 的 VirtualHost）怎麼組織、upstream 指向哪個 app server、靜態檔案的 root 路徑、TLS 憑證掛在哪裡、access log 和 error log 的路徑。設定改完跑 nginx -t 驗證語法後再 nginx -s reload。

鄰卡

• .htaccess — Apache 的分散設定，遷移到 nginx 時需要轉換
• ALB — 雲端環境裡承擔部分 nginx 職責
• Apache MPM — Apache 的並發模型，決定能不能搭配 mod_php
• PHP-FPM — nginx 用 fastcgi_pass 轉請求給它的 PHP 程序管理器
• 流量入口層 — nginx 作為單機 reverse proxy 在請求責任鏈的位置、以及跟雲端 ALB 的選擇條件

概念位置

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 持有無法重建的資料，下表的設定設錯時代價依項目不同：backup retention 與 deletion protection 設錯，損失的是救不回來的資料；instance class、engine version 與部分 parameter group 參數事後調整，代價是重開機或一段停機窗口。

跟自建 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 的持久性設計處理的是硬體與可用區故障；物件被覆寫或刪除、資料被公開存取、儲存成本隨時間累積這三類風險要靠 bucket 設定處理，下表的設定大多對應其中一類：

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
• Availability Zone（可用區）
• Instance Metadata Service（實例中繼資料服務）

概念位置

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
• TOML：只描述資料、沒有變數與函式的設定檔格式

概念位置

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 改名）。local_file 只改 file_permission 也會印 # forces replacement，實跑的輸出在 多台主機維護清單的實作紀錄：在容器上安裝 ansible-core 與 Terraform、由 Terraform 產生 inventory、用 Ansible 的範本部署每台的清單、以 sudo 與 systemd-run 執行檢查腳本，以及清理〈由 Terraform 產生 inventory：init、plan、apply 與 local_file 的檔案權限〉。

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

鄰卡

• State
• Drift
• IaC

概念位置

AMI 在 infra 系列裡有兩個角色。第一個是接手維運時的保險——對 VM（即 EC2 instance）建一個 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 是判斷「專案依賴了什麼、版本有沒有已知漏洞」的入口，執行環境仰賴 php.ini / .user.ini 的 CLI 設定。專案根目錄通常有三個 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 幫它面對外部）。reverse proxy 在流量入口責任鏈裡的位置、跟 DNS 與負載平衡層的交棒關係，見流量入口層。

可觀察訊號

接手時如果 server 上跑著 nginx 但應用程式用的是 PHP-FPM 或 Node.js，nginx 多半扮演 reverse proxy——它接 HTTP/HTTPS 請求、轉發給後端的 application server。設定檔裡的 proxy_pass（nginx）或 ProxyPass（Apache）就是 reverse proxy 的轉發規則，用在講 HTTP 的後端（Node.js、Python 的 gunicorn 這類）。PHP-FPM 只講 FastCGI，nginx 轉給它用的是 fastcgi_pass，Apache 用 mod_proxy_fcgi；用 proxy_pass 指向 PHP-FPM 的埠不會成功，見 FastCGI。

設計責任

reverse proxy 常承擔的功能：

鄰卡

• ALB：雲端的受管 reverse proxy + 負載平衡器
• nginx：最常見的 reverse proxy 軟體
• PHP-FPM：只講 FastCGI 的 PHP 後端，nginx 用 fastcgi_pass 而非 proxy_pass 轉給它

概念位置

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 把每次拉取的指標寫進本地時序資料庫，target 數量、拉取頻率與保留天數一起決定磁碟用量，告警也建立在同一份資料上；要定的設定是：scrape interval（多久拉一次；程式預設 1 分鐘，官方範例設定寫 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 也有自己的告警功能）、分享給團隊。只需要臨時查詢時，Prometheus 內建的網頁介面就夠。

設計責任

Grafana 本身不儲存資料，它的設計決定因此圍繞在怎麼連到外部資料源、畫面給誰看、出狀況時通知誰：dashboard 的組織（按服務、按環境、按角色）、資料源的連線設定、使用者權限（viewer / editor / admin）、告警通知管道（email / Slack / webhook）。告警規則放在 Grafana 還是留在 Prometheus 是一個取捨：放在 Grafana 時它停掉的期間沒有告警，換到的是能對 Prometheus 以外的資料來源告警、不寫 YAML 也能建規則，比較見 Prometheus 指標的視覺化工具。斷網環境裡 Grafana 的 plugin 需要離線安裝（grafana cli --pluginUrl <檔案位置> plugins install <plugin 名稱> 指向本地檔案）。

鄰卡

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

概念位置

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

連網環境通常用雲端的 secret manager（AWS Secrets Manager、GCP Secret Manager）。斷網環境沒有雲端服務可用、Vault 是 self-hosted 的替代方案。Vault 的存取控制模型呼應 IAM 的 policy 精神——差別在 Vault 管的是機密值、IAM 管的是雲端 API 操作權限。

可觀察訊號

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

設計責任

Vault 重新啟動後處於 sealed 狀態，解封之前任何服務都讀不到機密，所以 unseal 方式與 storage backend 決定 Vault 停機後多快能恢復，認證方式與 secret engine 決定哪個身分能取得哪一種機密。要定的是：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 帳號、SSH 依登入身分簽發短期 SSH 憑證）。

鄰卡

• IAM：Vault 的存取政策跟 IAM 的 policy 概念類似
• SSL/TLS：Vault 的 PKI engine 可以當內部 CA 簽發數位憑證
• SSH Certificate（SSH 憑證）：Vault 的 SSH secrets engine 簽發的就是這種憑證；只用 OpenSSH 自己簽發的流程見 OpenSSH 內建 CA 的 SSH 憑證導入

概念位置

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

可觀察訊號

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

設計責任

斷網環境裡每一次 image pull 都從 Harbor 拉，哪些 image 能被部署、誰能推送、舊 image 留多久，都取決於下面這些 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 就好。

設計責任

chart 的粒度一旦定下，各環境的 values file 與版本號都依附在它上面，事後拆分或合併 chart 要連同這些一起改，所以 Helm 的設計從粒度開始：chart 的粒度（一個 chart = 一個微服務 or 一整個平台）、values 的組織（per-environment values file）、chart 版本管理（chart version vs app version）、以及升級策略（helm upgrade --atomic 失敗自動回退）。

鄰卡

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

概念位置

動靜分離坐落在 reverse proxy 的路由職責裡，跟 TLS 終結、負載分散、健康檢查並列。它跟 nginx 的關係是實作面——nginx 用 try_files 走檔案、proxy_pass 轉後端，把兩類請求在設定裡分開。共享主機時代 Apache 加 mod_php 把動靜都吃在同一個 process、動靜分離是隱形預設；自管環境要明確劃出哪些路徑走檔案、哪些走後端。

可觀察訊號與例子

一個載入 50 個靜態資源、只有 1 個動態 API 呼叫的頁面，做了動靜分離後應用伺服器只需要處理那 1 個請求，其餘 50 個由 reverse proxy 直接回掉。判讀訊號：應用伺服器的 CPU 被大量靜態檔案請求佔用、或 access log 顯示 PHP / Node process 在回應 .css、.js——代表動靜沒有分離、算力花在不需要它的請求上。

判讀方式

動靜分離的邊界是「這個請求需不需要應用邏輯才能回應」。靜態資源在不同環境有不同的回應層：單機由 nginx 從檔案系統回、雲端可以再往外推到 CDN 在邊緣回。分離的層次越靠外、應用伺服器的負載越低，代價是快取失效的複雜度上升。它在入口責任鏈裡的定位、以及跟 CDN 邊緣回應的分層，在流量入口層展開。

概念位置

CGI 是「web 伺服器負責 HTTP、外部程式負責產生內容」這個分工的起點。後來的 FastCGI 保留了同一套參數名稱，只改掉程序壽命（程序常駐、處理很多請求），PHP 的實作是 PHP-FPM。.htaccess 時代的共享主機常用 CGI 加 suEXEC 讓每個站台以自己的帳號執行。

可觀察訊號與例子

• $_SERVER 的大寫鍵名：REQUEST_METHOD、QUERY_STRING、SCRIPT_FILENAME 來自 CGI 的 meta-variables，FastCGI 沿用了它們。
• 每個請求一個新 PID：PHP 以 php-cgi 被 CGI 呼叫時，每個請求的 getmypid() 都不同，OPcache 永遠命中不了。
• CVE-2012-1823：PHP 5.3.12 / 5.4.2 之前，以 CGI 方式執行的 php-cgi 可能把查詢字串當成命令列選項，只影響這種部署。

設計責任

接手 CGI 部署時，要知道它的每請求啟動成本與隔離方式；換成 PHP-FPM 時，用 pool 的執行帳號保留原本 suEXEC 提供的隔離。詳見 CGI。

概念位置

MPM 是 Apache 的並發模型，跟 nginx 的事件驅動模型是同一個問題的不同答案；它也跟 PHP 的執行方式互相限制：mod_php 把 PHP 放進 Apache 的程序裡，沒有以 ZTS 編譯時只能搭配 prefork；PHP 改由 PHP-FPM 在外面執行（Apache 用 mod_proxy_fcgi 轉送）時，Apache 就能用 event。

可觀察訊號與例子

• httpd -V 的 Server MPM：官方 httpd:2.4 是 event，php:8.5-apache 是 prefork（裝了 mod_php）。
• apache2ctl -M 列出 mpm_prefork_module：同時列出 php_module 時，就是 mod_php 加 prefork 的組合。
• 並發上限等於子程序上限：prefork 下 MaxRequestWorkers 就是能同時處理的連線數，慢客戶端與閒置的 keep-alive 連線都佔著一個子程序。

設計責任

從 mod_php 換到 PHP-FPM 時，可以順便把 MPM 換成 event，讓 Apache 用較少的資源處理大量連線。詳見 mod_php。

概念位置

管理通道拆成網路可達性、通道授權、主機登入驗證三層來看時（模型見伺服器管理通道的設計），身分感知代理同時承擔網路可達性與通道授權：sshd 只對代理可見，而能不能開通道由代理用 IdP 帳號判斷——這個判斷就是通道授權，指的是決定「這個人能不能打開通往主機的連線」，與登入主機時驗證 SSH 金鑰是兩回事。主機登入驗證在多數實作裡仍由主機上的 sshd 負責；Teleport 的節點這類實作用自己內建的 SSH 伺服器與代理簽發的憑證，主機登入驗證跟著換掉。由 sshd 負責時，金鑰的發放方式另見 OS Login 與 SSH Certificate（SSH 憑證）。

它與 Bastion Host（跳板機） 都讓內部主機不必各自對外，差別在對外接收連線的元件由誰維運、用什麼判斷身分：跳板機是自己維運的主機、用 SSH 金鑰判斷；身分感知代理是廠商提供或自己架設的代理服務、用 IdP 帳號判斷。它與一般反向代理的差別在轉送前多了一次身分驗證與授權。

常見的實作有 GCP 的 IAP（Identity-Aware Proxy，對 HTTPS 應用與 TCP 連線各有一種模式，TCP forwarding 的來源位址段是 35.235.240.0/20，到得了同一家雲端裡的主機，以及經 Cloud Interconnect 或 Cloud VPN 接進來、而且 Cloud Router 對地端通告了這段位址的地端主機）、Cloudflare Access、Teleport 的 proxy。Cloudflare Access 與 Teleport 用反向連線把流量送進主機，主機上的 connector 怎麼往外連、斷線時會怎樣見 Outbound Tunnel（出站隧道）。這個模式的公開源頭是 Google 2014 年起發表的 BeyondCorp 系列論文。

可觀察訊號

由代理連到內部 IP 的模式（GCP IAP）：

• 主機的入站規則只放行某一段固定的代理位址，沒有任何來源是 0.0.0.0/0 的管理 port 規則
• 主機上的認證紀錄裡，SSH 連線的來源 IP 全部落在代理的位址段，看不出是哪個人——要查人得看代理或 IdP 的 audit log

經由代理程式反向連線的模式（Cloudflare Tunnel、Teleport agent）：

• 主機上有一個常駐的代理程式（例如 cloudflared、teleport），主機的入站規則完全沒有管理 port
• 代理程式把連線轉送到 sshd 的實作（cloudflared），認證紀錄裡的 SSH 來源是 127.0.0.1 或代理程式所在的本機位址；Teleport 節點用自己的 SSH 伺服器，sshd 的紀錄裡不會出現這些連線

兩種模式共同的樣子是主機沒有公開 IP，管理員仍然用 ssh 或廠商 CLI 連得進去。

設計責任

導入身分感知代理之後，主機自己不再判斷連線者是誰，下面這些判斷移到代理與 IdP 上：

• IdP 帳號的安全強度：存取權限轉移到帳號上之後，帳號被釣魚等於通道被打開，所以 IdP 端要強制多因素驗證，管理員帳號優先用防釣魚的硬體金鑰或 Passkey
• 授權範圍：授權綁給負責維運的群組，並限定可以連的 port 與主機，避免整個組織的帳號都拿得到通道
• 代理的 session 長度：IdP 停用一個帳號之後，代理已經簽給他的 session 或憑證要到期或被撤銷才失效（Cloudflare Access 的 session 最長可以設到一個月，gcloud 在本機保存 refresh token），所以收回延遲的上限是代理端設定的 session 長度；處理離職或帳號外洩時另外在代理端撤銷 session。登入後留在本機的 token 檔可以被複製重放，不會再過一次多因素驗證，session 越短、或綁定裝置，被複製之後能用的時間越短
• 代理的可用性與延遲：所有位元組都經過代理轉送，代理服務中斷時管理通道一起中斷，大量傳檔也比直連慢；救援時的備用路徑見 Serial Console（序列主控台）
• 稽核紀錄的位置與開啟時機：主機端只看得到代理的位址，「誰在什麼時候連進哪台主機」要從代理或 IdP 的 audit log 取得。這份紀錄只記錄開啟之後的連線，事後要調查一次入侵時，開啟之前的連線查不回來，所以在切換到代理的同一天開啟，開啟之後實際連一次、查到這次連線的紀錄才算開對（見平常不動作的防護機制的部署驗證）

鄰卡

• Bastion Host（跳板機） — 同樣收斂對外入口，由自己維運的主機轉接
• Security Group — 放行代理位址段的那一條入站規則所在的位置；AWS 叫 security group，GCP 對應的是 VPC 防火牆規則
• Identity Provider — 代理用來確認帳號的系統
• GCP VM 的 SSH 與 RDP 管理通道 — GCP IAP 的連線路徑、IAM 授權範圍與切換順序；實際指令在 GCP VM 的 SSH 與 RDP 改走 IAP 的實測紀錄
• 伺服器管理通道的設計 — 從代理位址段連入與代理程式反向連線兩種送達方式，依主機分布的選擇條件

跳板機處理的是主機以 SSH 登入管理的情境：每台主機上跑著接受 SSH 連線的服務程式 sshd、預設監聽 22 port。只部署在 PaaS 或 serverless 平台、沒有任何可以 SSH 登入的主機時，平台自己的主控台與 CLI 就是管理入口，用不到跳板機。

概念位置

把管理通道拆成網路可達性、通道授權、主機登入驗證三層時（見伺服器管理通道的設計），跳板機是網路可達性的做法之一：它把「每台主機都對外開 22 port」收斂成「只有一台對外開」。它同時兼任通道授權——決定誰能打開通往主機的連線——判斷依據是跳板機上的 SSH 金鑰，或跳板機信任的 SSH CA 所簽的憑證；跳板機與目的主機接受同一把金鑰時，一把私鑰外洩就同時通過通道授權與主機登入驗證。

跳板機放在 public subnet，目的主機留在 private subnet，兩者之間的放行用 Security Group 的來源引用表達：目的主機的入站規則把來源寫成「跳板機所屬的那個 security group」而不是一個 IP，跳板機換了 IP 或多加一台，規則都不必改。

暴露面收斂成一台，但沒有消失：跳板機仍然對網際網路開著管理 port，它的 sshd 漏洞與金鑰管理就是整個環境的入口。不讓任何自管主機對外的做法是 Identity-Aware Proxy（身分感知代理），對外接收連線的那一層改由代理服務承擔。雲端廠商也提供受管的跳板服務（例如 Azure Bastion、Oracle Cloud 的 Bastion），主機的修補由廠商負責，連線方式與身分驗證依各家服務而定，位置介於自建跳板機與身分感知代理之間。Oracle Cloud 的 Bastion 建立時要指定一個目標 subnet（主機所在的 subnet，或主機所在 subnet 接受其流量的另一個 subnet），經由它登入的主機不需要公開 IP，誰能開工作階段由 IAM 政策決定，設定方式見 登入：SSH 金鑰、預設使用者、建立後加金鑰與不放金鑰時的登入服務 的〈不放金鑰時的登入服務〉。

可觀察訊號

• private subnet 主機的 security group 只允許來自某一個 security group（或某一台主機）的 22 port
• 管理員的 ~/.ssh/config 裡有 ProxyJump 設定，或團隊文件寫著「先連 bastion」

設計責任

自建跳板機時，整個環境對外的 SSH 暴露都集中在這一台上，所以下面這幾件事的標準比一般主機高：

• 跳板機的來源範圍：管理員有固定的對外 IP 時，跳板機的 22 port 只放行那幾個 IP；遠端工作、IP 會變動時，白名單縮不下來，跳板機的 22 port 實質上對全網開放，認證紀錄裡會持續出現來自陌生 IP 的失敗登入，它的 sshd 修補速度就是整個環境的暴露期。只放行管理員 IP 時，ISP 重新分配了那個 IP，管理員就連不進跳板機，舊 IP 的新使用者反而在放行範圍裡；這一類會在主機外面改變的設定怎麼定期比對，見 長期上線主機的維護項目：會累積的資料、定期讀的 log、對外入口的盤點、安全更新、會到期的設定與檢查間隔的推算〈會到期與會改變的外部設定〉
• 私鑰不落地：agent forwarding 是讓遠端主機借用管理員本機 ssh-agent 裡的私鑰去做下一段認證的功能（ssh -A 或設定檔的 ForwardAgent yes），開著它時，任何在跳板機上取得 root 的人都能借那把私鑰連到其他主機；把私鑰直接放上跳板機的後果相同。ProxyJump 讓第二段認證也在管理員電腦上完成，不需要 agent forwarding。這種從一台主機往其他主機擴散的攻擊見 Lateral Movement（橫向移動）
• 金鑰不共用、不可複製：跳板機與目的主機各用不同的金鑰或憑證，讓一把私鑰外洩只通過一層；目的主機的金鑰發放可以改用 SSH Certificate（SSH 憑證） 或 OS Login；跳板機與目的主機信任同一把 SSH CA 時，用不同的 principal 把兩層分開，做法見 OpenSSH 內建 CA 的 SSH 憑證導入。管理員的私鑰放在硬體安全金鑰裡（OpenSSH 8.2 起的 ed25519-sk）時，私鑰檔無法被複製走
• 修補與監控：跳板機要比其他主機更快套用 sshd 的安全更新，並保留連線紀錄
• 操作紀錄：外包人員登入正式環境、或稽核要求逐條指令留紀錄時，需要集中錄製管理員在目的主機上執行了什麼；所有管理連線都經過跳板機，所以它是放錄製工具的位置。這個屬性與廠商無關，一套設定涵蓋多雲與地端混用的環境。組織有 IdP 時，讓跳板機只接受 IdP 簽發的短期 SSH 憑證，錄製與隨帳號收回兩者都保留

鄰卡

• SSH — 跳板機轉接的協定與金鑰認證
• Identity-Aware Proxy（身分感知代理） — 改用代理服務承擔對外接收連線
• Serial Console（序列主控台） — 跳板機本身連不上時的備用登入路徑
• 伺服器管理通道的設計 — 存取者是組織成員、外部合作方、個人或機器時，跳板機與其他做法的選擇條件

概念位置

SSH 憑證處理的是登入主機用的金鑰怎麼發、怎麼失效——伺服器管理通道的設計把這一層叫主機登入驗證。它與另外兩種金鑰發放方式的差別在權限怎麼失效：

• 靜態 authorized_keys（見 SSH）：沒有到期時間，收回要逐台刪除
• 由中央服務決定可用的公鑰（見 OS Login）：帳號或角色移除，下一次登入就失敗
• SSH 憑證：憑證到期自動失效，離職或權限變更最晚在一個有效期之後生效

簽發服務通常接在 Identity Provider 後面：管理員用 IdP 帳號登入簽發服務，換到一張短期憑證。管理通道前面那一層的通道授權（決定誰能打開通往主機的連線，例如身分感知代理檢查 IdP 帳號）若也用同一個 IdP，兩層就共用同一個身分來源，停用一個帳號同時擋下兩層。HashiCorp Vault 的 SSH secrets engine 與 Teleport 都以這種方式運作。三種做法收回的都是下一次登入，已經建立的工作階段要另外在主機上中斷。

可觀察訊號

• 主機的 sshd_config 有 TrustedUserCAKeys，而 ~/.ssh/authorized_keys 是空的或不存在
• 管理員的 ~/.ssh/ 裡在金鑰對旁邊多了一個同名加 -cert.pub 結尾的檔（例如 id_ed25519-cert.pub），ssh 連線時會自動帶上它；用 ssh-keygen -L -f <cert-file> 讀得出它的有效期間與 principal
• 每天第一次 SSH 之前要先跑一個登入或簽發指令

設計責任

CA 私鑰取代了每台主機上的公鑰清單，所以導入 SSH 憑證時的決定都圍繞著 CA 與憑證內容：

• CA 私鑰的保管：CA 私鑰能簽出登入所有主機的憑證，它外洩的影響等於所有主機的所有金鑰一起外洩，所以放在 HashiCorp Vault 或硬體安全模組這類受控位置，不放在任何人的電腦上
• 有效期長度：有效期等於能接受的最晚收回延遲——離職或權限移除之後，那張憑證最多還能用一個有效期。延遲上限越短，有效期越短，管理員重新簽發也越頻繁；管理員手動簽發時常設成一個工作日左右，讓每天開工時簽一次；簽發由用戶端在連線時自動完成時（Teleport 的 tsh、smallstep 的 step ssh），有效期可以縮到幾小時以內，收回延遲跟著縮短
• principal 的對應：憑證列出的帳號名稱與主機上的帳號怎麼對應，決定一張憑證能登入哪些主機的哪些帳號。主機上只有一個共用帳號（例如雲端映像預設的 ubuntu）時，每張憑證的 principal 都是 ubuntu，主機端分不出是誰登入，要靠憑證的識別字串（簽發時的 -I）出現在 sshd 的認證紀錄裡來辨識人
• 提前撤銷：憑證還沒到期就要失效時（例如私鑰外洩），sshd 用 RevokedKeys 指向撤銷清單，這份清單要能派送到所有主機
• 主機憑證：同一個機制也能反過來簽主機的金鑰（HostCertificate），讓用戶端驗證主機身分。主機經常重建（autoscaling、重新部署）時，每次重建主機指紋都會變，用戶端會反覆看到指紋變更的警告而養成直接接受的習慣；改用主機憑證後用戶端只信任 CA，前提是用戶端的 known_hosts 已加入 @cert-authority 與 CA 公鑰

簽發的指令形式是 ssh-keygen -s <ca-private-key> -I <identity> -n <principals> -V <validity> <user-public-key>：-I 是寫進憑證、會出現在主機認證紀錄裡的識別字串（通常填 IdP 帳號），-n 是允許登入的帳號名稱、多個用逗號分隔，-V 是有效期間（+8h 表示從現在起八小時）。實際運作時由簽發服務代為執行，簽出的憑證寫在使用者公鑰旁邊的 *-cert.pub。

鄰卡

• SSH — 靜態金鑰認證與 authorized_keys
• OS Login — 另一種讓登入權限隨帳號收回的做法
• SSH Host Key 與 known_hosts（主機金鑰） — 主機憑證取代的逐台指紋確認
• OpenSSH 內建 CA 的 SSH 憑證導入 — 產生 CA、設定 sshd、簽發與撤銷的指令，以及 AuthorizedPrincipalsFile 讀取權限與 RevokedKeys 檔案不存在這兩個會讓所有人登不進去的設定
• Bastion Host（跳板機） — 跳板機與目的主機不共用金鑰時，目的主機這一段可以改用憑證
• 伺服器管理通道的設計 — 人員流動、主機數量與帳號系統不同時，三種金鑰發放方式的選擇條件

概念位置

OS Login 出現之前，GCP 把 SSH 公鑰交給 VM 的方式是 metadata 金鑰：公鑰寫在專案或 VM 的 metadata 的 ssh-keys 欄位，VM 上的 guest agent（GCP 映像預裝、負責把 metadata 套用到作業系統的常駐程式）讀出來寫進對應帳號的 authorized_keys。這些公鑰和 Google 帳號沒有連動，帳號停用後公鑰仍然留在 metadata 裡，運作方式等同 SSH 卡描述的靜態公鑰。

OS Login 改成每次登入時才向 Google 查詢，登入權限因此跟著帳號走。不分廠商來看，這是主機登入驗證（登入主機用的金鑰怎麼發、怎麼收回）裡「由中央服務決定可用的公鑰」的那一種，AWS 的 EC2 Instance Connect 屬於同一類，差別是它在連線前推送一把只在短時間內有效的公鑰；讓登入權限自動到期的另一種做法見 SSH Certificate（SSH 憑證）。

OS Login 常與 GCP 的 Identity-Aware Proxy（身分感知代理） 一起用。兩者都依 IAM 判斷，但檢查的是兩件事：IAP 的 IAM 權限決定是否允許開通道，OS Login 的 IAM 權限決定進入通道之後是否允許登入、是否允許使用 sudo。

可觀察訊號

• 專案或 VM 的 metadata 有 enable-oslogin=TRUE：專案層級用 gcloud compute project-info describe 查，輸出的 commonInstanceMetadata.items 裡列著專案層級的 metadata；VM 層級用 gcloud compute instances describe <instance-name> --zone=<zone> 查，看輸出的 metadata.items
• 登入 VM 之後的使用者名稱是由 Google 帳號位址轉成的名稱（例如 alice_example_com），不是管理員自己在 metadata 裡指定的名稱
• 專案 metadata 的 ssh-keys 欄位仍然有公鑰——啟用 OS Login 的 VM 不再讀它，但沒啟用的 VM 仍會讀，盤點時要一起清

設計責任

OS Login 啟用後，VM 只認 IAM 角色，metadata 裡的公鑰立即失效，所以啟用前要先把角色與順序排好：

• 啟用順序：先把登入角色授予每一位管理員與每一個要登入 VM 的服務帳號（CI、Ansible）、對一台 VM 啟用並連通，再做專案層級；順序反過來時，還沒拿到角色的管理員與自動化工具在啟用那一刻就登不進去
• 啟用範圍：專案層級啟用涵蓋專案內所有 VM，VM 層級的設定會蓋過專案層級；組織要新建的 VM 一律啟用時用 Organization Policy 的 compute.requireOsLogin，既有 VM 要另外盤點
• sudo 的授予：roles/compute.osAdminLogin 只給確實需要 root 權限的群組，其餘給 roles/compute.osLogin
• 服務帳號的附帶權限：VM 以服務帳號身分執行時，登入的使用者另外需要那個服務帳號的 roles/iam.serviceAccountUser。從主控台用預設值建立的 VM 會掛上 Compute Engine default service account，所以多數 VM 都落在這個情況；VM 掛的是哪個服務帳號，看 gcloud compute instances describe 輸出的 serviceAccounts[].email
• 組織外的帳號：外包人員用組織以外的 Google 帳號時，要在組織層級另外授予 roles/compute.osLoginExternalUser 才能登入
• 登入時的兩步驟驗證：metadata 設 enable-oslogin-2fa=TRUE 後，每一次 SSH 登入都要再過一次 Google 帳號的第二因素；還沒在 Google 帳號上設定第二因素的管理員會在啟用那一刻被擋在外面

鄰卡

• SSH — OS Login 取代的是靜態 authorized_keys 的金鑰發放方式
• IAM — OS Login 的登入權限由 IAM role 決定
• Identity-Aware Proxy（身分感知代理） — 常一起使用的通道授權層
• GCP VM 的 SSH 與 RDP 管理通道 — OS Login 與 metadata 金鑰的差別，以及啟用的順序為什麼這樣排
• GCP VM 的 SSH 與 RDP 改走 IAP 的實測紀錄 — 授予角色、單台先行啟用與還原的指令

概念位置

序列主控台與平時的管理通道設計方向相反：管理通道要隨時可用，救援入口平時關閉、只在需要時打開，因為它繞過了 Identity-Aware Proxy（身分感知代理） 或 Bastion Host（跳板機） 這些平時的控制點。管理通道的網路可達性、通道授權或主機登入驗證任何一層設定錯了（這三層的分法見伺服器管理通道的設計），序列主控台都還連得上，因為它不經過那三層的設定。它有自己的授權：雲端上是雲端帳號的 IAM 權限與開啟它的開關，登入時用主機上的本機帳號密碼，所以雲端 IAM 或開關設錯時，它一樣進不去。

不同環境的救援入口形態不同。地端實體伺服器用的是頻外管理控制器（BMC，out-of-band management，其他中文資料常寫作「帶外管理」）：IPMI、Dell iDRAC、HPE iLO 這類嵌在主機板上的管理控制器，有自己的網路埠，在作業系統沒開機時也能看主控台、重開機、掛載安裝媒體。VPS 服務商多半在網頁後台提供一個在瀏覽器裡顯示主機畫面的主控台（常叫 VNC console），用法與雲端的序列主控台相同：不經過主機的網路設定，用本機帳號密碼登入。

可觀察訊號

• SSH 連線逾時或被拒，而雲端的網頁管理介面或監控顯示主機仍在執行——網路設定、防火牆或 sshd 出錯時的典型樣貌
• 開機過程卡住（檔案系統檢查、/etc/fstab 寫錯）時，序列主控台看得到開機訊息，SSH 在那個階段還沒有啟動
• 雲端帳號或專案的設定裡，序列主控台存取是關閉的（GCP 預設關閉互動登入，用 metadata serial-port-enable=TRUE 對單一 VM 開啟；AWS 要在帳號層級先允許）

設計責任

救援入口在出事當下才用得到，而帳號、權限與演練在主機正常時準備最快，所以規劃時要先決定：

• 救援帳號：序列主控台用本機帳號密碼登入，而用金鑰登入的主機通常沒有設密碼的帳號，所以救援帳號要在主機正常時就建好。密碼逐台隨機產生、存放在受控的密碼庫，sshd 維持只收金鑰；這組密碼不隨 IdP 收回，持有它的人離開時要逐台輪替。沒有事先建帳號時，雲端 VM 還有要重開機或停機、因此比較慢的路（GCP 的 startup-script 每次開機以 root 執行；AWS 的 user-data 預設只在第一次開機執行，要改成每次開機執行的 cloud-init 格式；GCP、AWS 與 Oracle Cloud 都能把開機磁碟掛到另一台 VM 修改；官方另為 Oracle Linux 附了經由序列主控台開進維護模式、重設 opc 金鑰的範例），地端主機只能重開機進單人模式。不必重開機的路是業者在主機裡執行指令的服務：AWS 的 SSM Run Command 與 Oracle Cloud 的 Run Command，兩者都要主機上的代理程式在運作，代理程式停了或連不到業者的服務端點時用不上；Oracle Cloud 這幾個入口各自的前提見 登入：SSH 金鑰、預設使用者、建立後加金鑰與不放金鑰時的登入服務 的〈建立之後加金鑰與金鑰遺失時的入口〉
• 演練：建好救援帳號之後實際用序列主控台登入一次、確認 sudo 可用，再關回去。沒演練過的救援入口在出事當下才發現密碼不對或權限不足；平時不存在、事故時才開的權限叫 Break-Glass Access，事後回顧的做法在那張卡
• 開啟範圍與時機：平時保持關閉，救援時只對單一主機開啟，用完關回去；存取權限只授予持有救援責任的少數帳號（GCP 上開啟 metadata 與連線都需要 roles/compute.instanceAdmin.v1，而這也是一般 VM 管理會用到的角色，光靠它收不窄）。GCP 用 Organization Policy 的 compute.disableSerialPortAccess 在組織層級預設關閉時，只有能對專案解除這條政策的人開得了序列主控台，救援名單要包含這些人
• 頻外管理介面的網路：IPMI 這類控制器歷史上有多個認證弱點，它的網路埠接在獨立的管理網段，不接到一般網段或網際網路
• 操作紀錄：序列主控台的連線繞過了平時的稽核點與錄製位置，雲端廠商的 audit log 查得到誰在什麼時候開了主控台，查不到在裡面執行了什麼；有逐指令稽核要求時，救援時做了什麼要另外記錄

鄰卡

• SSH — 平時的管理通道，序列主控台在它斷掉時接手
• Identity-Aware Proxy（身分感知代理） — 平時的通道控制點，救援入口繞過它
• Bastion Host（跳板機） — 另一種平時的通道控制點
• GCP VM 的 SSH 與 RDP 改走 IAP 的實測紀錄 — 在 GCP 上建救援帳號、開啟與關閉 Serial Console 的指令
• Oracle Cloud 私有子網路 Ubuntu 主機的實測紀錄：套件來源的出站（NAT gateway、路由與 NSG）、序列主控台的連線，以及被回收之後的重建〈序列主控台：RSA 金鑰、建立連線、ProxyJump 設定與看到的開機輸出〉 — 在 Oracle Cloud 上建序列主控台連線、把官方的連線字串改寫成 ProxyJump 設定，以及連上之後看到的開機輸出

概念位置

MIG 把「一台 VM」換成「一份設定產生的一組 VM」：VM 隨時可能依 template 被重建或替換：recreate-instances 沿用原本的名稱、換一顆新的開機磁碟（實測一次時執行個體 ID 也沒變，gcloud 說明寫 ID 可能改變）；滾動更新的預設替換方式 substitute 建出新名稱、新 ID 的 VM；擴增則新建 VM。不論哪一種，只存在某一台開機磁碟上的修改都會在下一次重建時消失，要持久的設定一律寫進 template，改設定的方式是建一份新 template 再滾動更新。這是不可變基礎設施的做法：它適合 VM 本身沒有不能丟的狀態的工作負載；有狀態時用 stateful 設定保留指定的磁碟與 IP，或改成單獨管理的 VM。GKE 的 node pool 在底下也是 MIG，但那一組由 GKE 管理，設定改在 node pool 上。template 裡的 Network Tag（網路標籤） 決定防火牆規則套不套得到新建的 VM。

可觀察訊號

• VM 的 metadata 有 created-by 鍵，值是建立這台 VM 的 MIG 的資源路徑（VM 被移出 MIG 之後仍然留著，現在的成員以 gcloud compute instance-groups managed list-instances 為準）；名稱是 gke-...-grp 的 MIG 屬於 GKE 叢集
• 半夜自動修復之後，某台 VM 上手動加的 tag、metadata 或帳號不見了
• gcloud compute instance-groups managed list-instances <mig-name> 的 INSTANCE_TEMPLATE 欄顯示每台 VM 用的是哪一份 template

設計責任

管理通道、監控代理這類要在每台 VM 上都成立的設定寫進 template 或映像，不靠逐台指令。改 template 時先讀出現行 template 的完整設定逐項帶進新的一份，因為新 template 從預設值開始；先讓一台 VM 換新版驗證再整組更新，舊 template 留到新版驗證完。整組由 IaC 管理時，改動寫在程式碼裡，CLI 上的修改會在下一次套用時被改回。

鄰卡

• Network Tag（網路標籤） — template 裡決定防火牆規則套不套得到新 VM 的欄位
• Serial Console（序列主控台） — 單台 VM 的救援入口；MIG 裡多了依 template 重建這條路
• IaC — MIG 與 template 多半由 IaC 管理
• 管理通道的設定為什麼要寫在 template 見 GCP 上由 MIG 與 GKE 管理的 VM 的管理存取，建 template、滾動更新與重建的指令見 GCP 上 MIG 與 GKE 管理存取的實測紀錄

概念位置

tag 把「哪些 VM 要開這個 port」從防火牆規則裡拆出來，放到 VM 上：規則只寫一次，VM 加上 tag 就套用。代價是 tag 由誰都能改的 VM 屬性決定——有權限改 VM 的帳號加上一個 tag，那台 VM 就套用了那條規則；而一台 VM 被重建時，只有寫在 template 裡的 tag 會留下。這與 AWS 的 Security Group 方向相反：Security Group 是把 instance 掛進規則集合。要讓授權更嚴格時，防火牆規則改用 --target-service-accounts 依 VM 的服務帳號選，換服務帳號需要的權限比改 tag 高。

可觀察訊號

• gcloud compute instances describe <vm> --format="value(tags.items)" 列出這台 VM 的 tag
• 只放行 IAP 來源的規則存在、而某台 VM 經 IAP 連不上：先查這台 VM 有沒有那條規則的 target tag
• 由 Managed Instance Group（MIG） 自動重建或新建的 VM 少了手動加的 tag

設計責任

管理通道用的 tag（例如放行 IAP 來源連 22 port 的那一個）寫進 instance template 或 GKE node pool 的設定，不靠逐台 add-tags。改 template 或 node pool 的 tag 時，--tags 是整組指定，既有的 tag 要一起列進去。能改 VM tag 的權限等於能改那台 VM 套用哪些防火牆規則，授權時與防火牆規則的管理權一起考慮。

鄰卡

• Security Group — AWS 上用掛載而不是標籤決定規則套用範圍
• Managed Instance Group（MIG） — tag 寫在 template 裡才會留到重建後
• Identity-Aware Proxy（身分感知代理） — GCP 上放行 IAP 來源的防火牆規則用 tag 選 VM

概念位置

host key 擋的是中間人攻擊：有人攔截連線、冒充目標主機時，他出示的 host key 與 known_hosts 記的不同，ssh 會拒絕連線。這個保護的弱點在第一次連線：用戶端還沒有任何記錄，只能由使用者判斷指紋對不對，這種做法叫 TOFU（trust on first use，首次使用時信任），而多數人不會去核對指紋。主機重建時 host key 重新產生，ssh 看到的就是一把不同的金鑰。SSH Certificate（SSH 憑證） 的主機憑證把逐台信任換成信任一把主機 CA，用戶端在 known_hosts 用 @cert-authority 一行信任它。

可觀察訊號

• 第一次連線：The authenticity of host '...' can't be established. ED25519 key fingerprint is SHA256:...
• host key 與記錄不同：WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!，連線被拒，訊息會指出 known_hosts 裡衝突的那一行
• ssh-keyscan <host> 取得主機出示的公鑰；ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub 在主機上印出指紋，可以與用戶端看到的對照

設計責任

主機經常重建的環境裡，指紋變更警告會天天出現，管理員會被訓練成直接刪掉舊記錄、接受新的，而真正的中間人攻擊看起來一模一樣。這種環境改用主機憑證，或讓建立主機的流程把新的 host key 公鑰派送到用戶端的 /etc/ssh/ssh_known_hosts；不把 StrictHostKeyChecking no 當成長期做法。看到指紋變更而不確定主機是否重建過時，先從另一條路徑（雲端主控台、序列主控台）在主機上印出指紋核對，再更新記錄。

鄰卡

• SSH — host key 是 SSH 連線建立時的主機驗證
• SSH Certificate（SSH 憑證） — 主機憑證取代逐台確認指紋
• 實作見 OpenSSH 內建 CA 的 SSH 憑證導入

概念位置

服務帳號在 IAM 裡同時是一個身分、也是一個資源，權限也因此分成兩邊來設：

• 它是一個身分：它能做什麼。在 IAM 授予它角色，決定它能對哪些資源做什麼。例如一個依預算通知停用帳單的函式，它的服務帳號要有解除專案帳單連結的角色。
• 它是一個資源：誰能以它的身分行事。別的身分要「以它的身分行事」（把它掛到 VM 上、用它部署函式、用它的身分呼叫另一個服務），要對這個服務帳號本身持有角色。例如在啟用 OS Login 的 VM 上，登入一台掛著服務帳號的 VM 的人，要有那個服務帳號的 roles/iam.serviceAccountUser。

兩邊漏設時的症狀不同。「誰能以它的身分行事」那一邊漏設時，部署或掛載的那一步就被拒絕；「它能做什麼」那一邊漏設時，部署與元件狀態都顯示正常，要到程式實際呼叫 API 的那一刻請求才被拒絕。

程式取得服務帳號憑證的方式有兩種：在雲端裡執行的程式（VM、函式、容器）由平台自動提供短期憑證，不需要金鑰；在雲端外面的程式（CI、地端伺服器）可以下載一把長期金鑰，或改用 workload identity 以外部平台簽發的 token 換到短期憑證。長期金鑰外洩等於這個身分外洩，能用短期憑證時不發金鑰。

可觀察訊號

• IAM 綁定裡出現 serviceAccount: 開頭的成員：gcloud projects get-iam-policy <project-id> 列得出專案層級的綁定
• VM 掛著哪個服務帳號：gcloud compute instances describe <instance-name> --zone=<zone> 輸出的 serviceAccounts[].email；用主控台預設值建立的 VM 會掛上 Compute Engine 預設服務帳號（<project-number>-compute@developer.gserviceaccount.com），instance template 的 describe 對它顯示為 default
• 程式的錯誤訊息是 The caller does not have permission 或 403，而部署與狀態都顯示正常：服務帳號缺少這個 API 呼叫需要的權限，用 gcloud iam roles describe <role> 查它持有的角色裡有沒有那一項；錯誤訊息沒寫權限名稱時，API 參考文件裡那個方法的頁面列出它需要的權限（例如 projects.getBillingInfo 需要 resourcemanager.projects.get）

設計責任

• 一個用途一個服務帳號：每個程式或每類工作用自己的服務帳號，角色只給它需要的那幾個（least privilege）；共用預設服務帳號時，任何一個程式被入侵都拿得到其他程式的權限
• 查角色實際包含哪些權限：角色名稱看起來管的那件事，角色本身不一定涵蓋其中的每一個動作，gcloud iam roles describe <role> 列得出它的權限清單；例如 GCP 的 roles/billing.projectManager 只能建立與刪除專案的帳單連結，讀取帳單狀態要另外的權限
• 呼叫鏈上的每一段都要授權：由事件觸發的程式（Pub/Sub 推送、Eventarc 觸發器）有「觸發器以哪個身分呼叫程式」與「程式以哪個身分呼叫 API」兩段，兩段各自要有角色
• 設定完以實際觸發驗收：「它能做什麼」那一邊的缺漏在部署時看不出來，所以設定完要實際觸發一次它要做的事、看結果，而不是看部署的回傳值，做法見平常不動作的防護機制的部署驗證
• 「以它的身分行事」的權限也是權限：持有某個服務帳號的 roles/iam.serviceAccountUser 或可以產生它的 token 的人，等同持有那個服務帳號的全部角色，盤點權限時要一起算

鄰卡

• IAM — 服務帳號的角色由 IAM 授予
• Workload Identity — 雲端外的程式不發金鑰、以短期憑證取得服務帳號身分
• Least Privilege（最小權限） — 服務帳號的角色範圍原則
• OS Login — 登入掛著服務帳號的 VM 時另外需要 roles/iam.serviceAccountUser

概念位置

雲端資源的位置由大到小是區域、可用區、故障域。區域決定的是地理位置帶來的性質（延遲、出口 IP 的國家、資料受哪個國家的法規管轄，以及可選的機型；各項的說明在 位置：區域、可用區與故障域 的〈區域（region）：主機在哪個城市〉），可用區決定的是「同一個城市裡哪一棟」，作用在兩件事上：

• 高可用：同一個服務的多台主機分散在不同可用區，一棟資料中心停電或斷線時其他棟的主機繼續服務。只放在一個可用區的服務，那個可用區故障時整個服務停擺。
• 資源的搭配限制：主機、開機磁碟、區塊磁碟這類資源屬於某一個可用區，主機只能掛同一個可用區的磁碟；Subnet 在 AWS 上也綁在一個可用區，在 Google Cloud 與 Oracle Cloud 上可以跨可用區（Oracle Cloud 的 regional subnet）。

一個區域有幾個可用區依業者與區域而定。Oracle Cloud 的商用區域多數只有一個 AD，官方〈Regions and Availability Domains〉的區域表在 2026-10-24 列出有三個的是法蘭克福、倫敦、阿什本、芝加哥、鳳凰城，這份名單隨業者開新區域而變，選區時回到那張表看。只有一個可用區的區域做不到跨可用區的高可用，那時的做法見 Fault Domain（故障域） 的〈設計責任〉。

可觀察訊號

• 建立主機時錯誤訊息寫「in availability domain AD-1」「in zone asia-east1-b」這類位置：容量是按可用區分配的，換一個可用區可能就建得起來
• 從保留下來的開機磁碟重建主機時，可選的可用區只剩那顆磁碟所在的那一個
• Oracle Cloud 的 AD 完整名稱帶有 tenancy 專屬的前綴（例如 XXXX:AP-BATAM-1-AD-1），不同帳號看到的前綴不同，指令裡要用 oci iam availability-domain list 查到的完整名稱

設計責任

• 單一台主機：可用區只影響能否拿到容量，選建得起來的那一個即可
• 要做高可用的服務：至少兩個可用區各放一份，負載平衡器與資料庫的副本也要跨可用區；跨可用區的流量在 AWS 與 Google Cloud 另外計費，費率見各家價格頁的資料傳輸那一項
• 選區域時：服務需要跨可用區的高可用時，選有多個可用區的區域
• 判斷兩台主機會不會一起停：可用區是對整棟資料中心停電、斷線這一類失效分開的一層失效域；兩台主機在不同可用區，仍可能因為共用同一個區域、帳號或 DNS 而一起停，逐項列共用依賴的做法見 Failure Domain（失效域）

鄰卡

• Fault Domain（故障域） — 可用區內部更小一層的硬體隔離
• VPC — 虛擬網路跨可用區還是綁在單一可用區，依業者而定
• Subnet — AWS 的 subnet 綁在一個可用區，決定主機落在哪一棟
• 位置：區域、可用區與故障域 — 建立主機時這三層選項的取捨

概念位置

故障域提供的是反親和性（anti-affinity）：把幾台主機刻意放在不同的實體硬體上，讓一次硬體事件不會讓它們同時停擺。它比可用區小一層——可用區隔離的是整棟資料中心的電力與網路，故障域隔離的是同一棟裡的機櫃與實體主機。

Oracle Cloud 以「故障域」這個名稱讓使用者在建立主機時直接選；AWS 與 Google Cloud 沒有對應的欄位名稱，同一個效果用放置政策取得：AWS 的 placement group（spread 策略）、Google Cloud 的 spread placement policy，作用都是讓一組主機分散到不同的實體硬體上。AWS 要先停止主機才能換進或移出 placement group。Google Cloud 的 spread placement policy 指定了多個 availability domain（官方說明是彼此隔離的一組硬體）時，可以不停機就套用到既有的主機，而套用時主機可能被搬到另一個 availability domain，搬的方式依主機的維護政策是即時遷移或停止主機。

只有一台主機時，故障域沒有選擇的意義，那台主機總是只在一組硬體上。Oracle Cloud 建立頁的預設「讓 Oracle 選擇」會依當下容量挑一個，而手動指定會縮小可用的容量。

可觀察訊號

• 建立主機時收到 Out of host capacity：Oracle Cloud 的 Compute〈Known Issues〉頁列的處置之一是不指定 fault domain 再建一次，因為指定故障域等於只接受那一個故障域裡的硬體，可用容量跟著變小
• 同一個服務的兩台主機在主機詳細資訊裡顯示同一個 FAULT-DOMAIN-<N>：一次硬體維護可能同時重開兩台
• oci iam availability-domain list 只回傳一筆：這個區域只有一個可用區，跨可用區做不到，故障域是同一個區域內剩下的硬體隔離手段

設計責任

• 同一個服務兩台以上的主機：區域有多個可用區時先分到不同可用區，故障域用在同一個可用區之內；區域只有一個可用區時，分散到不同故障域。Oracle Cloud 允許建立之後再修改故障域
• 只有一個可用區的區域：高可用的設計從跨可用區改成跨故障域，並接受整個可用區故障時服務會停的風險，或另外跨區域
• 單一台主機：維持讓業者選

鄰卡

• Availability Zone（可用區） — 故障域上面那一層的隔離單位
• Managed Instance Group（MIG，代管執行個體群組） — 一組主機自動分散與修復的機制
• 位置：區域、可用區與故障域 — 建立主機時這三層選項的取捨

概念位置

開機流程依賴它：cloud-init 在主機第一次開機時從中繼資料服務讀出 SSH 公鑰寫進 authorized_keys、讀出初始化腳本並執行。業者的代理程式也從這裡讀主機的設定。

同一個特性也是它的風險：主機上任何能發 HTTP 請求的程式都讀得到它。網頁應用程式有 SSRF（server-side request forgery，伺服器端請求偽造）漏洞時，攻擊者可以讓應用程式替他去讀 169.254.169.254，取得主機的身分憑證，再拿那份憑證在雲端帳號裡以主機的權限行事。

第二版的存取方式（AWS 與 Oracle Cloud 叫 IMDSv2）要求請求帶上證明：AWS 要先用 PUT 請求取得一個 token、之後每個請求在標頭帶著它，Oracle Cloud 要每個請求帶 Authorization: Bearer Oracle 標頭並改打 /opc/v2 路徑。兩版可以並存，主機的設定改成只允許第二版之後，不帶證明的第一版請求才會被拒絕。多數 SSRF 漏洞只讓攻擊者控制網址、控制不了標頭，所以這一個要求就擋掉了大部分的攻擊路徑。Google Cloud 的中繼資料伺服器固定要求 Metadata-Flavor: Google 標頭，作用的方向相同：擋掉只能控制網址、帶不了標頭的請求；AWS 的 token 另外要先用 PUT 取得，擋的範圍更大一些。

可觀察訊號

• 建立頁上有「Require an authorization header」（Oracle Cloud）、「Metadata version: V2 only (token required)」（AWS）這類選項
• 主機上的舊程式或舊版工具讀不到中繼資料、請求回錯誤：它還在用第一版的請求方式
• 安全掃描報告指出某台主機允許 IMDSv1：那台主機上的應用程式一旦有 SSRF 漏洞，身分憑證就讀得到

設計責任

• 新主機：映像檔支援第二版時開啟強制要求。Oracle Cloud 官方列出支援的平台映像是 Oracle Linux 與 Oracle Autonomous Linux，其他平台映像（包括 Ubuntu）、多數自訂映像與多數市集映像不支援；自訂的 Linux 映像在 cloud-init 20.3 以上、Oracle Cloud Agent 0.0.19 以上時可能支援（官方給自訂映像的條件）。在不支援的映像上強制第二版，cloud-init 讀不到公鑰，主機會連不上。Oracle Cloud 上這個設定建立後可以在主機頁面改回兩版都允許、再重開，判斷與處置見 代理程式、中繼資料服務、初始化腳本、維護行為與標籤 的〈中繼資料服務與 Authorization header〉
• 既有主機改成只允許第二版：先確認主機上讀中繼資料的程式（代理程式、SDK、自己的腳本）都已支援第二版，再切換
• 主機的身分權限：主機被授權呼叫雲端 API 時（例如主機上的程式要寫物件儲存），業者經由中繼資料服務把代表主機身分的憑證交給主機上的程式——Oracle Cloud 叫 instance principal（權限由 dynamic group 加 policy 授予），AWS 是掛在主機上的 IAM role（經由 instance profile），Google Cloud 是掛在主機上的服務帳號。這份憑證帶著主機身分的全部權限，所以權限只給這台主機上的程式需要的那些

鄰卡

• Service Account（服務帳號） — 中繼資料服務發放的憑證代表的身分
• IAM — 決定那份憑證能做什麼
• 代理程式、中繼資料服務、初始化腳本、維護行為與標籤 — 建立主機時的中繼資料服務選項

概念位置

CDN 排在請求路徑的最前面，在源站的 Reverse Proxy 與應用之前，承擔的是邊緣的遞送、快取與過濾（WAF 規則、速率限制、依國家封鎖）。這些過濾只對經過 CDN 的請求作用：源站的位址一旦被知道，請求可以跳過 CDN 直接連源站，所以 CDN 後面的源站要另外在雲端的 Security Group 或主機防火牆上只放行 CDN 的位址。CDN 回源時用的是它自己機房的位址，經由 CDN 送來的請求，源站看到的連線來源因此是 CDN 的位址，使用者真正的位址放在 CDN 加上的 HTTP 標頭裡（Cloudflare 是 CF-Connecting-IP）。

可觀察訊號與例子

• 回應標頭帶著 CDN 的標記：Cloudflare 代理的網站回應帶 cf-ray 與 server: cloudflare。看到它代表這一次請求經過了 CDN，不代表所有訪客都經過：其他訪客的 DNS 快取可能還指向源站的舊位址。
• 源站的存取記錄裡全是同幾段位址：那是 CDN 機房的位址；要記錄使用者的位址，反向代理要設定成只信任來自 CDN 位址段的 CF-Connecting-IP（nginx 的 set_real_ip_from 加 real_ip_header）。這個設定擋得下不經 CDN 的直連偽造，擋不下從 CDN 位址送來的偽造：任何帳號的 Cloudflare Worker 都從 Cloudflare 的位址送出、標頭可以自己寫，實測見 Cloudflare 回源的實測紀錄：Oracle Cloud NSG 只放行 Cloudflare 位址與規則數上限、回源的來源位址、Authenticated Origin Pulls、Worker 偽造 CF-Connecting-IP 與 Tunnel 的出站連接埠。
• CDN 公佈的位址清單：Cloudflare 在 https://www.cloudflare.com/ips-v4 與 ips-v6 公佈回源用的位址段，2026-10-25 是 15 段 IPv4 與 7 段 IPv6；源站的防火牆規則就是拿這份清單寫的。

判讀方式

判斷一條請求經不經過 CDN，看的是使用者解析網域拿到的位址，而不是網站有沒有開 CDN：子網域沒有設成代理、或舊記錄還在快取裡時，那些請求直接到源站，CDN 上的規則管不到它們。CDN 的位址由所有客戶共用，只放行 CDN 位址擋得住不經過 CDN 的直連，擋不住別人用自己的 CDN 帳號指向這台源站；要分得出，要用 CDN 端的回源驗證（Cloudflare 的 Authenticated Origin Pulls 用自己上傳的憑證，或 Tunnel）。源站防火牆的位置、套用時機與 Docker 的陷阱見 CDN 後面的源站主機防火牆：只放行 CDN 來源的位置與套用時機、Docker 發佈連接埠的封包路徑、出站 DNS 的限制與地理封鎖。「origin protection」在快取的語境裡指的是快取未命中時保護源站的負載，見 Origin Protection，跟這裡的源站安全是兩件事。

概念位置

Linux 處理封包的框架叫 netfilter，它在封包流程上留了幾個固定位置（hook）讓規則掛上去。DNAT 掛在 prerouting 這個 hook：封包剛進主機、核心還沒決定路由之前就改寫（iptables 寫在 nat 表的 PREROUTING 鏈，nftables 寫在 type nat 的鏈；主機本機發出的連線則在 OUTPUT 那一段改寫）。改寫之後，核心依新的目的地決定路由：目的地是容器或另一台主機時，封包走轉送（forward）路徑送給另一個介面，不經過管主機本身入站連線的 input 路徑；改寫成主機本機的位址或連接埠時（iptables 的 REDIRECT、firewalld 不帶目的位址的 forward-port），封包仍走 input 路徑。

Docker 用 -p 8081:80 發佈連接埠時，IPv4 那一份屬於目的地改成容器的那一種：寫在 input 路徑上的主機防火牆規則（ufw、firewalld 的 zone）管不到它（容器網路沒開 IPv6 時，IPv6 那一份不經 DNAT，由主機上的 docker-proxy 程式（Userland Proxy）接收、走 input 路徑，見 ufw 主機上 Docker 發佈連接埠的實測紀錄：ufw 規則的效果、DOCKER-USER 規則的存續與 after.rules、IPv6 的 docker-proxy、compose 內建 DNS 的出站路徑），而轉送路徑上 Docker 與 firewalld 預設都放行經過位址轉換的連線（Docker 的 DOCKER-FORWARD 鏈、firewalld 的 ct status dnat accept），所以這些連接埠繞過了主機防火牆。雲端的 Security Group 在封包到達主機、還沒被改寫之前就比對完，不受這個改寫影響。

可觀察訊號與例子

• iptables -t nat -S DOCKER 看得到規則：-A DOCKER ! -i docker0 -p tcp -m tcp --dport 8081 -j DNAT --to-destination 172.17.0.2:80 就是 Docker 發佈 8081 時寫的那一條。
• 防火牆清單看不到、外面卻連得到的連接埠：firewall-cmd --list-all 與 ufw status 都沒有列 8081，從外面連照樣拿到容器的回應；查發佈的連接埠要用 docker ps 或 ss -ltnp。
• 規則比對不到改寫前的連接埠：寫在 FORWARD 鏈的 --dport 8081 比對不到任何封包，因為封包到那裡時目的連接埠已經是 80。

判讀方式

限制規則寫在 DNAT 之前還是之後，決定它看得到哪一個連接埠：之前（prerouting、優先序比 dstnat 小）看得到原本的目的連接埠，直接用它比對；之後（FORWARD 鏈、Docker 的 DOCKER-USER）看到的是改寫後的容器位址，要改用連線追蹤記下的原始值比對（iptables 的 -m conntrack --ctorigdstport 8081、nftables 的 ct original proto-dst 8081）。主機防火牆沒有放行、外面卻連得到的連接埠，多半是經過 DNAT 送給了容器或另一台主機，這時原因在規則的位置，不在規則的內容。Kubernetes 的 NodePort 在 kube-proxy 的 iptables 模式下也用 DNAT 送往 Pod，IPVS 模式的掛法不同，兩者都沒有在這個站上實測。Docker 的實測與各種限制寫法的比較見 源站防火牆只放行 Cloudflare 位址的實測紀錄：firewalld、Docker 發佈的連接埠、DOCKER-USER、nftables 表與出站 DNS。

概念位置

iptables 的 -m conntrack、-m state 與 nftables 的 ct 都在讀這張表。它也是 DNAT 與 SNAT（NAT Gateway 做的那一種）能運作的前提：核心在連線的第一個封包改寫位址時，把原本與改寫後的對應記進表裡，同一條連線之後的封包與回程封包都照這個對應改寫。規則要比對位址轉換之前的值時，讀的就是表裡記下的「原始方向」（original）。

可觀察訊號與例子

• 防火牆規則開頭的 ct state { established, related } accept：實測時 firewalld 的轉送鏈就以這一條起手，已經放行的連線之後的封包直接通過，規則只需要描述新連線。
• firewalld 的 ct status dnat accept：在 StrictForwardPorts=no（預設值）下，所有經過目的位址轉換的連線在任何 policy 之前就被接受，Docker 發佈的連接埠因此不受 firewalld policy 約束。
• DOCKER-USER 裡的 -m conntrack --ctorigdstport 8081 --ctdir ORIGINAL：封包的目的地已經改成容器的 80，用表裡記下的原始目的連接埠 8081 比對；--ctdir ORIGINAL 只比對發起方向的封包，回程封包不進這條規則。
• conntrack -L（套件 conntrack-tools）或 /proc/net/nf_conntrack：列出表裡每一條連線，一行裡有協定、TCP 階段、src=/dst=/sport=/dport= 兩組（第一組是原始方向，第二組是回程方向；兩組對不上就是經過了位址轉換），以及 ASSURED 這類旗標。

判讀方式

一條防火牆規則比對的是封包現在的欄位，或是表裡記下的原始值，兩者在位址轉換之後不同：寫在位址轉換之後的規則，要比對原本的位址或連接埠時要用 ctorig* 這類條件，用 --dport 只比對得到改寫後的值。規則改了卻像沒生效時，原因常在已經存在的連線：ESTABLISHED 的連線多半在規則前面就被放行，新規則只擋得到之後的新連線；要讓既有的連線也受新規則約束，用 conntrack -D（可加 -p tcp --dport <連接埠> 縮小範圍）刪掉表裡那幾條，連線方重新連線時才會被新規則比對。表的容量有上限（nf_conntrack_max），連線數很大的主機表滿時會丟掉新連線，核心記錄裡會出現 nf_conntrack: table full, dropping packet。Docker 發佈的連接埠怎麼用它限制來源，見 CDN 後面的源站主機防火牆：只放行 CDN 來源的位置與套用時機、Docker 發佈連接埠的封包路徑、出站 DNS 的限制與地理封鎖。

概念位置

兩個 network namespace 之間預設不通，要用 veth（成對的虛擬網路介面，從一端送進去的封包從另一端出來）一端放在 namespace 裡、一端放在主機上，再接到主機上的 bridge（Docker 的 docker0）或直接設路由。封包從 namespace 經 veth 進到主機時，跟從實體網卡進來的封包一樣經過主機的防火牆與 DNAT、由 conntrack（連線追蹤） 記錄。容器不一定各有一個：--network host 的容器直接用主機的 namespace，--network container:<名稱> 與 Kubernetes 同一個 Pod 裡的容器共用一個。

可觀察訊號與例子

• ip netns list 與 ip netns exec <名稱> <指令>：手動建的 namespace 用 ip netns add 建立，ip netns exec 讓一條指令跑在那個 namespace 裡。Docker 建的 namespace 放在 /var/run/docker/netns，不在 ip netns 讀的 /run/netns，所以列不出來；要進容器的 namespace，用 docker inspect -f '{{.State.Pid}}' <容器> 取得容器程序的 PID，再用 nsenter -t <PID> -n <指令> 執行。
• 主機上多出 veth 開頭的介面：容器每接一個 bridge 網路就有一條，另一端在容器的 namespace 裡（第一條叫 eth0，再接一個網路是 eth1）。
• 一台主機上模擬兩個來源位址：建兩個 namespace，各給一個位址（例如一個落在 Cloudflare 的位址段、一個落在範圍外），從各自的 namespace 連主機，就能驗證「只放行某些來源」的防火牆規則，不需要第二台主機。這個做法的完整指令見 源站防火牆只放行 Cloudflare 位址的實測紀錄：firewalld、Docker 發佈的連接埠、DOCKER-USER、nftables 表與出站 DNS 的〈用 network namespace 模擬 Cloudflare 與其他來源〉；ufw 主機上的版本，以及替兩個來源加 IPv6 位址的 ns_setup6，見 ufw 主機上 Docker 發佈連接埠的實測紀錄：ufw 規則的效果、DOCKER-USER 規則的存續與 after.rules、IPv6 的 docker-proxy、compose 內建 DNS 的出站路徑 的〈共用的函式與兩個測試來源〉。

判讀方式

一個程序連不到某個位址、或看到的介面跟預期不同時，原因常在它跑在哪個 network namespace：同一台主機上的 127.0.0.1 在每個 namespace 裡各指自己，容器裡連 127.0.0.1 連不到主機上的服務，容器裡的程式也綁不上主機的 LAN 位址（那個位址不在容器的 namespace 裡）。用 namespace 模擬來源做測試時，結果只驗證到防火牆依來源位址的判斷：封包從 veth 進來，firewalld 對沒有指派 zone 的 veth 套用預設 zone 的規則，主機的實體網卡在別的 zone 時，模擬的結果不代表真實流量；真實網路上的路由、雲端防火牆與上游服務（例如 CDN 實際用哪些位址回源）也不在測試範圍內。

概念位置

FORWARD 鏈的跳轉順序是 DOCKER-USER、Docker 自己的 DOCKER-FORWARD、然後才是 ufw 的 ufw-* 鏈；DOCKER-FORWARD 接受送往發佈連接埠的連線，所以寫在 ufw route 規則裡的限制輪不到這些封包，寫在 DOCKER-USER 的輪得到。封包到這條鏈時目的地已經是容器的位址與連接埠，限制發佈的連接埠要用 conntrack（連線追蹤） 記下的原始目的連接埠比對：

1iptables -I DOCKER-USER -p tcp -m conntrack --ctstate DNAT --ctorigdstport 443 --ctdir ORIGINAL ! -s 173.245.48.0/20 -j DROP

三個 conntrack 條件各管一件事：--ctorigdstport 443 比對位址轉換之前的連接埠；--ctdir ORIGINAL 只比對發起方向的封包，容器回覆的封包不拿來比對來源；--ctstate DNAT 只比對經過位址轉換的連線，也就是送往發佈連接埠的那些。少了最後一個時，容器自己往外連 443、同一台主機上容器之間連 80 的封包也進這條鏈、原始目的連接埠一樣是 443 或 80，一起被丟掉（2026-10-26 在 Ubuntu 24.04 與 Docker 29.9.2 上實測）。

這條鏈只存在 iptables 後端：Docker 改用 nftables 後端時沒有它（Docker 的〈firewall-nftables〉文件）。它也只管 IPv4 那一份發佈：容器網路沒開 IPv6 時，IPv6 那一份由主機上的 Userland Proxy（使用者空間的連接埠轉送程式） 接收，不經過轉送路徑。主機上同時裝了 Docker 與以 root 執行的 Podman 時，Podman 的轉送封包也經過 DOCKER-USER（實測）。

可觀察訊號與例子

• iptables -S FORWARD 的前兩行：-A FORWARD -j DOCKER-USER、-A FORWARD -j DOCKER-FORWARD。主機也裝了 Podman 時，最前面還有一條 -j NETAVARK_FORWARD。
• 規則加了、從外面量過擋得住，過一陣子又失效：防火牆重新載入或重開機清掉了它，iptables -S DOCKER-USER 只剩 -N DOCKER-USER 這一行。
• 加了限制之後容器呼叫外部 API 逾時：規則只比對原始目的連接埠，沒有 --ctstate DNAT，容器的出站連線也被丟掉。

判讀方式

DOCKER-USER 的弱點在規則的存續，用 iptables 指令加的規則只存在執行中的核心裡，各種情形下的結果不同（2026-10-25 到 26 日在 Ubuntu 24.04 的 ufw 0.36.2、Oracle Linux 10.2 的 firewalld 2.4.3 上實測）：

要讓規則留過重開機，ufw 主機把它寫進 /etc/ufw/after.rules，同一台主機上的 DOCKER-USER 規則都要寫在那裡；firewalld 主機上改用掛在位址轉換之前的自建 nftables 表，或把限制放在雲端防火牆。direct 設定是主機當下的狀態，之後裝的軟體可能再加進來，用組態管理工具定期 reload 的主機上，規則被清掉之後直連就重新開著而沒有告警。實測的指令、輸出與 after.rules 的整份清單寫法見 ufw 主機上 Docker 發佈連接埠的實測紀錄：ufw 規則的效果、DOCKER-USER 規則的存續與 after.rules、IPv6 的 docker-proxy、compose 內建 DNS 的出站路徑 與 源站防火牆只放行 Cloudflare 位址的實測紀錄：firewalld、Docker 發佈的連接埠、DOCKER-USER、nftables 表與出站 DNS；各種限制寫法的取捨見 CDN 後面的源站主機防火牆：只放行 CDN 來源的位置與套用時機、Docker 發佈連接埠的封包路徑、出站 DNS 的限制與地理封鎖 的〈Docker 發佈的連接埠：封包路徑與限制的寫法〉。

概念位置

連線的終點是主機上的一個程式，所以封包走的是 input 路徑（目的地是主機本身程式的那一條），主機防火牆的入站規則（ufw 的入站規則、firewalld 的 zone）管得到它，跟 DNAT 那一類正好相反。代價在容器看到的來源：容器收到的連線是轉送程式開的，來源位址是轉送程式那一端的位址，不是外面的真實來源。這跟 Reverse Proxy（反向代理） 換掉來源位址的道理相同，差別在反向代理常用 HTTP 標頭（X-Forwarded-For）把原本的來源帶過去，這幾個轉送程式在 TCP 這一層搬資料，什麼都不帶。

三個程式各在什麼時候出現：

• docker-proxy：以 root 執行的 Docker 用 -p 發佈時，主機上 IPv4 與 IPv6 各有一份；IPv4 那一份從外面來的封包在 prerouting 就被 DNAT 改寫、到不了它，IPv6 那一份在容器網路沒開 IPv6 時由它接收。Docker 的 userland-proxy 設成 false 時它不啟動，IPv6 那一份也就沒有發佈（2026-10-26 在 Docker 29.9.2 上實測）。
• rootlesskit：rootless Docker 的 dockerd 以一般使用者執行、不能改主機的 iptables，發佈的連接埠全部由它接聽。
• rootlessport：rootless Podman 的對應程式，網路由 slirp4netns（Podman 4）或 pasta（Podman 5 的預設）提供。

可觀察訊號與例子

• ss -ltnp 列出這幾個程式聽著發佈的連接埠，nat 表裡沒有對應的 DNAT：users:(("rootlesskit",pid=4085,fd=13)) 聽著 0.0.0.0:8083，iptables -t nat -S | grep -c 8083 回 0。
• 容器的存取紀錄只有閘道位址：2026-10-26 的實測裡，經由 docker-proxy 的 IPv6 連線與 rootless Docker 的連線，容器記到的來源都是 172.17.0.1；rootless Podman 4.9 記到的是 slirp4netns 那張 tap 介面的 10.0.2.100。
• 主機防火牆的入站規則對容器的連接埠有效：ufw 預設拒絕入站時兩個測試來源都連不到 rootless 容器的連接埠，加一條入站放行之後只有被放行的那個連得到。

判讀方式

判斷一個發佈的連接埠屬於哪一類，先查有沒有規則把它的目的地改寫掉，再看誰在聽：nft list ruleset | grep 'dport <連接埠>' 同時列得出經由 iptables-nft 寫的與原生 nftables 寫的改寫規則。查到改寫規則時是 DNAT 那一類，聽著連接埠的程式只是佔住它（Podman 的 conmon、docker-proxy 的 IPv4 那一份），不算數；查不到時，聽著的轉送程式才是接收者。查表是預測，最終以從範圍外的來源實際連一次為準。屬於這一類時，限制寫在主機防火牆的入站規則上就有效，而容器裡依來源位址做的判斷（存取紀錄、速率限制、只信任來自 CDN 位址段的 CF-Connecting-IP）都拿不到真正的來源；Docker 文件列的保留來源位址做法（RootlessKit v3 的 builtin 加 userland-proxy: false、slirp4netns 轉送方式、pasta 加 implicit）這個站上沒有實跑。實測見 Podman 與 rootless Docker 發佈連接埠的實測紀錄：rootful Podman 在 ufw 與 firewalld 上的轉送路徑、rootless Docker 與 rootless Podman 由主機程式接收的連接埠與容器看到的來源位址 與 ufw 主機上 Docker 發佈連接埠的實測紀錄：ufw 規則的效果、DOCKER-USER 規則的存續與 after.rules、IPv6 的 docker-proxy、compose 內建 DNS 的出站路徑 的〈IPv6 那一份發佈：docker-proxy 的接收路徑與 ufw 入站規則的效果〉。

概念位置

TOML 在設定檔格式裡的位置介於 JSON 與 YAML 之間：跟 JSON 一樣每個值的型別都由寫法明確決定，跟 YAML 一樣可以寫註解、適合人手動編輯。它只描述資料，需要變數、迴圈與條件來描述基礎設施時用的是 HCL 這類設定語言。它在本站被用來寫主機的維護清單，選它的理由與實測見 主機維護清單寫成 TOML：JSON、YAML、TOML 的取捨、TOML 1.0 與 1.1 的版本差異、清單的欄位設計與只讀檢查腳本；Python 打包設定裡的 TOML 用法見 6.1 pyproject.toml 完整指南。

可觀察訊號

需要讀懂 TOML 的情境包括：打開一個副檔名是 .toml 的設定檔、要判斷某個值會被程式讀成字串還是數字、在 JSON、YAML、TOML 之間選設定檔格式，以及解析器回報 TOMLDecodeError 這類錯誤、而同一份檔案在另一台機器上解析得過。

設計責任

TOML 的基本結構：

 1# 註解
 2name = "web-demo"          # 字串一定要加引號
 3port = 443                 # 整數
 4enabled = true             # 布林值只有 true 與 false
 5checked_at = 2026-10-26T06:21:00Z   # 有時區的日期時間，解析成帶時區的時間物件
 6
 7[host]                     # 表格（table）：底下的鍵屬於 host
 8provider = "oracle-cloud"
 9
10[[entrypoint]]             # 表格陣列（array of tables）：每出現一次就新增一筆
11port = 443
12exposure = "cdn-only"
13
14[[entrypoint]]
15port = 22
16exposure = "admin-only"

• [名稱]：表格（table），指一組鍵值，等於程式裡的一個物件，跟試算表的格子無關；底下的鍵到下一個表頭為止都屬於它。
• [[名稱]]：表格陣列，每出現一次就在陣列裡加一筆，適合同一種項目要列很多筆的清單（入口、檢查項目、步驟）。
• 型別由寫法決定："no" 是字串，不加引號的 no 不屬於任何型別，解析器報錯；YAML 1.1 的解析器（例如 PyYAML）把不加引號的 no 讀成 false（英文資料常稱為 Norway problem）、010 讀成 8。寫法剛好屬於另一個型別時，TOML 一樣照那個型別讀：不加引號的 1.10 是浮點數 1.1。所以版本號這類看起來像數字的字串要加引號。
• 日期與時間是原生型別：有時區的日期時間、沒有時區的日期時間、日期、時間各是一種型別，不必用字串存再自己解析。
• 巢狀的表格陣列：[[entrypoint.verify]] 屬於它上面最近的那一筆 [[entrypoint]]，讓每一筆項目各有自己的一組子項目。
• 寫在同一行的表格（inline table）：verify = { command = "...", expect_stdout = "ok" }，適合只有幾個欄位的子項目；TOML 1.0 要寫在一行內、結尾不能有逗號。
• 兩種字串：雙引號的基本字串處理反斜線跳脫（regex 的 \. 寫成 \\.），單引號的字面字串不處理任何跳脫（寫成 '\.'）。
• 數字的分隔：整數可以用底線分隔位數，1_073_741_824 等於 1073741824。

跟其他格式的差別：

版本對解析器的影響：1.1.0 新增的語法（寫在同一行的表格 inline table 可以跨行並在結尾加逗號、\xHH 與 \e 跳脫、時間可以省略秒）只有支援 1.1 的解析器讀得懂。Python 的標準函式庫 tomllib 在 3.11 加入時支援 1.0，3.15 起支援 1.1，3.10 以下沒有 tomllib、要另裝 tomli。同一份用了 1.1 語法的檔案，在 Python 3.15 解析得過，在 3.12 會報錯；版本對不上時的兩種結果與寫檔時的對策，見 主機維護清單寫成 TOML：JSON、YAML、TOML 的取捨、TOML 1.0 與 1.1 的版本差異、清單的欄位設計與只讀檢查腳本〈TOML 1.0 與 1.1 的差異與解析器的版本〉。tomllib 只能讀不能寫，要由程式寫出 TOML 時需要第三方套件。

鄰卡

• YAML
• HCL
• .env
• php.ini / .user.ini

概念位置

YAML 在設定檔格式裡的位置是巢狀深、層數多的設定：縮排一層就是一層結構，寫到第五、六層仍然不必重複上層的名字，這是 Kubernetes 與 CI 工具選它的理由，Helm 的 chart 參數檔 values.yaml 也是這個格式。付出的代價在型別：不加引號的值是什麼型別，由解析器實作的 YAML 版本決定，而一份檔案自己沒有辦法指定讀它的解析器。它跟 TOML、JSON 逐項比對的需求表與實測，見 主機維護清單寫成 TOML：JSON、YAML、TOML 的取捨、TOML 1.0 與 1.1 的版本差異、清單的欄位設計與只讀檢查腳本〈主機維護清單對檔案格式的需求：JSON、YAML、TOML 的比對〉。

可觀察訊號

需要讀懂 YAML 的情境包括：打開一個副檔名是 .yaml 或 .yml 的檔案、程式讀到的值跟檔案上寫的字不一樣（寫 no 讀成 false、寫 010 讀成 8）、同一份檔案在兩個工具裡讀出不同的結果，以及解析器回報 ScannerError 或 found character '\t' that cannot start any token 這類縮排錯誤。

設計責任

YAML 的基本結構：

 1# 註解
 2name: web-demo            # 對應表的一個鍵；不加引號的 web-demo 讀成字串
 3port: 443                 # 讀成整數
 4entrypoints:              # 值是一份清單
 5  - port: 443             # 清單的每一項以 "- " 開頭，項目本身可以是對應表
 6    exposure: cdn-only
 7  - port: 22
 8    exposure: admin-only
 9note: |                   # | 保留換行的多行字串
10  第一行
11  第二行

• 縮排就是結構：同一層的鍵左側對齊，子項目多縮排一層；縮排只能用空格，Tab 字元會讓解析器回報 ScannerError。
• 不加引號的值由解析器推測型別：這是 YAML 最常讓設定出錯的位置，見下面的版本差異。字串加上引號（"no"、'010'）就不會被推測。
• 重複的鍵不報錯：PyYAML 6.0.3 解析 a: 1 接著 a: 2，得到 {'a': 2}，前一個值被安靜地蓋掉；手動維護的長檔案裡重複一個鍵，前面那一筆設定就不生效。
• 錨點與別名：&名稱 標記一個節點、*名稱 引用它，用來在同一份檔案裡重用一段設定；讀的人要回頭找錨點才知道別名展開成什麼。
• 一個檔案可以有多份文件：--- 分隔多份文件，Kubernetes 常用這個寫法把多個資源放在同一個檔案裡。

版本決定型別的推測規則：YAML 1.1（2005 年）與 1.2（2009 年）對不加引號的值規則不同。同樣這五行：

1country: no
2mode: 010
3port_map: 22:22
4version: 1.10
5on: true

交給兩個 Python 解析器，結果是：

兩個解析器都沒有報錯。no 被讀成 false 這一種，英文資料常稱為 Norway problem（挪威的國家代碼 NO 變成布林值）。YAML 1.2 把布林值限定成 true 與 false 及其大小寫變體，所以 1.1 的幾個陷阱消失；1.10 在兩個版本都是合法的浮點數，所以版本號不論哪一版都要加引號。一份 YAML 檔被讀成哪一版，由讀它的程式選的解析器決定：PyYAML 至今實作 1.1；Go 的 gopkg.in/yaml.v3 依它的 README 以 1.2 為主，而解碼到布林型別的欄位時仍接受 1.1 的 yes、no、on、off（這一點照文件，沒有實跑），所以寫檔的人無法只看檔案判斷結果，跨工具共用的值一律加引號。這張表在 python:3.12-slim 容器裡以兩個套件的 safe_load 實跑。

鄰卡

• TOML
• HCL
• Helm

同名而所指不同的兩個詞：Linux 的孤兒程序（orphan process）是父程序先結束、被 PID 1 收養的程序；套件管理器的孤兒套件是當初作為相依被裝進來、而依賴它的套件已經移除的套件（pacman -Qtd、dnf autoremove 處理的對象）。本卡講的是雲端帳號裡的資源。

概念位置

孤兒資源的成因是建立與刪除的範圍不對稱：建立主機的精靈一次建出主機、開機磁碟、公開 IP，有時連網路一起建；刪除時每一項的去留各有預設，業者為了避免誤刪資料，常把磁碟（AWS 的 EBS 這類區塊磁碟）的預設設成保留（Oracle Cloud 終止主機時開機磁碟預設保留）。各家的預設與欄位名稱見 磁碟：開機磁碟與區塊磁碟的大小、效能、加密與去留〈刪除（終止）主機時開機磁碟的預設去留〉；暫停一台主機時逐項要決定保留或刪除的資源，見 服務暫停與恢復上線：只停服務、停止主機、終止主機到全部刪除各自保留的資源，暫停期間仍計費與仍被指向的資源，恢復前要查的漂移與恢復的順序〈暫停期間仍在計費的資源〉。帳單層看到的「被遺忘的資源」是同一件事，見 計費模式理解〈隱藏成本：帳單上的意外〉。

DNS 層有一個對應的情形：主機與 IP 都刪了，DNS 紀錄還指著那個位址，這是懸空 DNS 的成因，見 10.6 命名空間與網域的處置：續約、名稱保留與回收、懸空 DNS〈懸空 DNS 與子網域接管〉。孤兒資源的後果是多付錢與佔額度；懸空 DNS 的後果是業者把位址分給別的客戶之後，網域的流量送到別人的主機。

可觀察訊號

• 主機都刪了，帳單上的區塊儲存、公開 IP 或快照費用沒有歸零。
• 免費帳號建新主機時回報區塊儲存額度不足，而執行中的主機加起來沒有用到那麼多。Oracle Cloud 的付費帳戶在額度不足時，沒有設 compartment quota 的話照樣建好、不報錯（設了 quota 時超額的建立回 400），對應的訊號是區塊儲存的總用量（含付費磁碟的 total-storage-gb）大於掛在執行中主機上的磁碟合計；只看免費額度的用量會漏掉，因為有付費磁碟時它比總用量小（建立不被擋下是 2026-10-27 實測，見 Oracle Cloud 私有子網路 Ubuntu 主機的實測紀錄：套件來源的出站（NAT gateway、路由與 NSG）、序列主控台的連線，以及被回收之後的重建〈費用與額度：A1、開機磁碟與區塊儲存額度、出站流量與 NAT gateway〉）。
• 主控台的磁碟列表裡有狀態是「未掛載」的磁碟（AWS 的 EBS 叫 available），名稱裡帶著已經不存在的主機名。
• 公開 IP 列表裡有沒有附在任何主機上的保留 IP。

設計責任

孤兒資源的處理分在建立、刪除與盤點三個時間點：

• 建立時記下歸屬：替主機與它的附屬資源加上同一組標籤（專案名、用途、建立者），刪除主機之後依標籤查得出還剩哪些資源；沒有標籤的磁碟只能靠名稱與建立時間猜，猜錯就刪到還在用的資料。
• 刪除時逐項決定：終止主機的對話框裡，開機磁碟要不要一起刪是一個選項，選了保留就代表之後要回來處理它；保留 IP 與快照不在那個對話框裡，要另外到各自的列表刪。
• 定期盤點：依資源類型列出沒有附在任何主機上的項目，跟標籤比對；確認不再需要之後才刪，磁碟與快照刪了就救不回來，所以刪之前先確認裡面的資料有沒有另外的備份。
• 用 IaC 管理時：Infrastructure as Code (IaC) 的 State（IaC 狀態檔） 記著它建過的資源，terraform destroy 會連同附屬資源一起刪；在主控台手動建、沒有寫進狀態檔的資源不在它的範圍內，destroy 之後照樣留在帳號裡。主控台手動改過 IaC 建的資源，則是 Drift（設定漂移）。

鄰卡

• Deletion Protection
• EBS
• Drift（設定漂移）

同名而所指不同的兩個詞：軟體工程裡的軟體組態管理（software configuration management，SCM）指原始碼的版本控制、基線與變更控制；中國大陸工業控制業界的「組態」（组态软件）指在 SCADA 或 HMI 軟體裡設定畫面與點位。本卡講的是主機設定的管理工具。

概念位置

組態管理工具都有兩個部分：主機清冊，與每台主機要套用的內容。Ansible 把主機清冊叫 inventory（列出受管主機與分組的檔案），跟商業領域的存貨（inventory）同字而無關；要套用的內容寫在 playbook（依序列出要對哪些主機套用哪些模組的 YAML 檔）與 role（把一類主機要用的任務、範本與變數收成一個可重用的目錄）裡，這個 playbook 跟事故處理的 Playbook 同名而所指不同。inventory 把主機分成群組（web、db），變數依層次放在 group_vars/<群組>.yml 與 host_vars/<主機>.yml，一台主機最後拿到的值是各層合併的結果，合併時越具體的層越優先：host_vars 蓋過群組的值，子群組蓋過 all。一台主機同時屬於兩個同層的群組、而兩個群組給了同一個變數不同的值時，依群組名稱的字母順序，排在後面的蓋過前面的；要指定誰優先，在 inventory 檔本身替群組設 ansible_group_priority（預設 1，數字大的較晚合併而勝出），寫在 group_vars 檔裡沒有效果；優先順序只會讓其中一組勝出，兼任兩種角色的主機需要兩組值都生效時，要讓兩個角色用不同的變數名、在範本裡取聯集。這幾條用 ansible-core 2.17 實測過，ansible-inventory --host <主機> 印得出合併後的值，實測的檔案與輸出見 多台主機的維護清單：值的分層與合併的位置、用 Ansible 的 inventory 與範本產生每台的清單、由 Terraform 的輸出產生 inventory、跨主機執行的 exit code，以及單台清單的適用範圍。inventory 與 group_vars 是 YAML，所以 YAML 1.1 的隱式型別照樣作用：country: no 讀出來是布林值 false。

主機清冊可以手寫，也可以由 IaC 產生：Terraform 知道它建的每台主機的 IP 與角色，可以用 terraform output -json 輸出給別的工具讀，或用 local_file 這類資源直接寫出一份 inventory 檔。那份檔案是 Terraform 管理的一個資源，它的內容記在 Terraform 的 State（IaC 狀態檔） 裡，手動改了它，下一次 terraform plan 會要求重建、apply 會蓋掉手改的內容。由 local_file 寫出 inventory、經由 SSH 部署到兩台容器並執行檢查的實際操作，以及 file_permission 的預設值扣掉 umask 之後的實際權限，在 多台主機維護清單的實作紀錄：在容器上安裝 ansible-core 與 Terraform、由 Terraform 產生 inventory、用 Ansible 的範本部署每台的清單、以 sudo 與 systemd-run 執行檢查腳本，以及清理〈由 Terraform 產生 inventory：init、plan、apply 與 local_file 的檔案權限〉。雲端資源的實際狀態跟 IaC 記錄的不一致叫 Drift（設定漂移）；主機裡的套件與設定檔跟組態管理的宣告不一致，有人同樣叫它 configuration drift，比對的兩邊換成了組態管理的宣告與主機內部的狀態；組態管理工具在下一次套用時把主機帶回宣告的狀態，兩次套用之間有人登入手改的部分，在那之前一直存在。

Ansible 由執行指令的那台機器經由 SSH 連到每台主機，把要執行的模組送過去執行，主機上不必裝常駐的代理程式（agent）；Puppet 與 Chef 傳統上在每台主機跑一個代理程式，定期向伺服器拉取該套用的內容（Puppet 與 Chef 的運作方式取自兩者的文件，沒有實測）。Ansible 這種推送的做法由操作的人或排程決定什麼時候套用；代理程式拉取的做法讓主機自己定期回到宣告的狀態。

可觀察訊號

• repo 裡有 inventory.yml（或 hosts.ini）、group_vars/、host_vars/、playbook.yml、roles/ 這類目錄。
• 維護的人改一台主機的設定時，改的是 repo 裡的變數或範本，再對那一組主機執行一次，不登入主機手改。
• 同一個設定檔在每台主機上的內容只有主機名、IP、角色相關的幾行不同。

設計責任

• 每個值放在哪一層：所有主機都相同的放 all，依角色不同的放群組，只有一台不同的放 host_vars。同一個值在兩層都寫了時，讀檔的人要知道合併規則才知道哪一個生效；對哪一個值生效有疑問時，用 ansible-inventory --host 查合併後的值。
• 套用要能重複執行：每個步驟執行第二次時不改變結果（Idempotency），排程定期套用時才不會每次都重啟服務或重寫檔案。Ansible 的模組多半這樣設計，command 與 shell 模組例外：它們每次都執行、每次都回報 changed，要用 creates、removes 或 changed_when 寫出什麼情形下不必執行、什麼結果算有改變。
• 範本的語法與產出的格式分開：Ansible 的範本是 Jinja2，{{ }} 是它的替換語法；產出的檔案自己也用 {{ }} 時（例如另一支程式的變數替換），那一段要包在 {% raw %} 裡，否則 Jinja2 會先替換它。值寫進 TOML、JSON 這類有引號規則的格式時，用 to_json 過濾器輸出（含非 ASCII 字元時加 ensure_ascii=False），引號與反斜線才會被正確跳脫；直接輸出時，Python 的布林值寫成 False，字串不帶引號，含反斜線的字串陣列被寫成兩個反斜線，TOML 解析失敗或讀到被改掉的值。
• 主機清冊的唯一來源：主機由 IaC 建立時，inventory 由 IaC 的輸出產生，不另外手寫一份；兩份各自維護時，新增或刪除主機只改了其中一份，另一份就指著不存在的主機，或漏掉新的主機。

鄰卡

• Infrastructure as Code (IaC)
• Drift（設定漂移）
• YAML
• State（IaC 狀態檔）

概念位置

主機與網路設定之間隔著 VNIC 這一層，所以「這台主機的私有 IP 是多少」「這台主機套用了哪些網卡層的防火牆規則（Security Group 這一類）」查的都是它的 VNIC，不是主機本身。Oracle Cloud 的 CLI 也是這樣分工：oci compute instance list-vnics 列出主機的 VNIC 與私有 IP，掛上或拿掉 NSG 用的是 oci network vnic update --nsg-ids，而不是主機的指令。

建立主機時，業者同時替它建一張主要的 VNIC；主機被刪除時，這張 VNIC 也跟著刪除，上面的私有 IP 與防火牆規則的掛載關係一起消失。所以主機被刪除再重建時，新主機拿到的是一張新的 VNIC：私有 IP 多半換了一個，原本掛在舊 VNIC 上的 NSG 要重新掛上去；而 NSG 本身與它的規則屬於虛擬網路，不跟著主機消失。主機只是停止時，VNIC 與私有 IP 都留著。在 Oracle Cloud 上實際重建過一次的資源去留與重新掛 NSG 的指令，見 Oracle Cloud 私有子網路 Ubuntu 主機的實測紀錄：套件來源的出站（NAT gateway、路由與 NSG）、序列主控台的連線，以及被回收之後的重建〈被回收之後的重建：怎麼發現、留下與消失的資源、重建腳本〉。

一台主機可以另外掛第二張以上的 VNIC，接到另一個 subnet；那些額外的網卡依各家的規則可以單獨拿掉，主要的那一張跟主機一起建立、一起刪除。

可觀察訊號

• 主機重建之後，原本連得到網際網路的套件更新又逾時、而沒有任何錯誤訊息：新的 VNIC 沒有掛上原本的出站規則
• 剛建好的主機，列出 VNIC 的查詢一時回空值：主機還在建立，VNIC 的掛載紀錄還沒出現
• 同一個 subnet 裡兩台主機的防火牆行為不同：subnet 層的規則相同，差在各自 VNIC 上掛的 NSG 或 security group

設計責任

網卡層的規則只影響掛上它的那幾張 VNIC，subnet 層的規則影響整個 subnet，所以放規則的位置決定了影響範圍；而 VNIC 會隨主機重建而換新，所以：

• 規則放在哪一層：只給一台主機的放行（例如只有它需要的出站）放在網卡層，掛在它的 VNIC 上；整個 subnet 都需要的放在 subnet 層。兩層怎麼合併見 網路：subnet、私有 IP、公開 IP 與防火牆規則〈防火牆規則的位置與合併方式〉
• 重建時的重新掛載：用腳本或 IaC 重建主機時，把「掛上網卡層規則」寫成重建流程的一步，或在建立主機時就指定（Oracle Cloud 的 instance launch --nsg-ids），不靠人記得
• 整份替換：Oracle Cloud 的 vnic update --nsg-ids 用給的清單取代整份 NSG 清單，加一個 NSG 時要把原本掛著的那幾個一起寫進去

鄰卡

• Subnet（子網路） — VNIC 接在哪一個 subnet，決定它的私有 IP 範圍與 subnet 層的規則
• Security Group — 掛在網卡層的有狀態防火牆，Oracle Cloud 的對應是 NSG
• NAT Gateway — 沒有公開 IP 的 VNIC 往外連時經過的出口
• VPC（Virtual Private Cloud） — VNIC 所在的虛擬網路