[infra] Infra Core & CI/CD：基礎設施流程化與交付治理

「我 SSH 上去改一下設定就好」——這句話是基礎設施災難的起點。手動改的東西沒有版本、沒有審核、出事沒辦法回退。IaC 和 CI/CD 不是因為潮流，是因為你的手動操作遲早會出事。

先講結論

把基礎設施當程式碼管理（IaC）、用 pipeline 自動化交付（CI/CD）、讓 Git 成為唯一真相來源（GitOps）。做到這三件事，你的基礎設施就是可重現、可回退、可追蹤的產品，而不是「只有那個人知道怎麼弄」的黑箱。

IaC：State 管理才是重點

大家都知道 Terraform 好用，但很多人忽略了最關鍵的部分：state。

Terraform state 是 IaC 的心臟。它記錄「現實世界長什麼樣子」。State 放在本地？那你跟同事同時 apply 就會互相覆蓋。State 沒有 lock？兩個 pipeline 同時跑就是災難。

terraform {
  backend "s3" {
    bucket         = "infra-tfstate"
    key            = "prod/vpc.tfstate"
    region         = "ap-northeast-1"
    dynamodb_table = "tfstate-lock"
    encrypt        = true
  }
}

Remote backend + state lock，這是最低要求。沒有這個，你的 IaC 只是「比較好看的腳本」。

Pipeline：先測試，再驗證，才部署

CI/CD 不是「自動部署」這麼簡單。它是一個品質閘門。

name: infra-ci
on:
  push:
    paths:
      - "infra/**"
 
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - run: terraform fmt -check
      - run: terraform validate
      - run: terraform plan -out tfplan

terraform plan 是你的安全網。它告訴你「如果你 apply，會發生什麼」。我見過有人把 plan 跳過直接 apply，然後把 prod 的 VPC 刪掉。那天整個團隊的臉色很精彩。

GitOps：Git 就是真相

GitOps 的核心很簡單：Git repo 裡的東西 = 實際環境的狀態。所有改動走 PR、有審核、有紀錄。自動化 agent（Argo CD、Flux）負責把 Git 的狀態同步到環境。

比起「某個人 SSH 上去改了什麼」，GitOps 讓你永遠可以回答：現在跑的是什麼版本、誰批准的、什麼時候改的。

Drift Detection：你改了，但忘了同步

有人手動在 AWS console 改了 security group，但 Terraform code 沒更新。下次 apply 的時候——啪，手動改的東西全部被覆蓋。

做法：定期跑 terraform plan，有差異就告警。更理想的做法是禁止手動改動，所有變更都走 PR。

環境分層和部署策略

dev、staging、prod 要有獨立資源、獨立權限、獨立監控。不要共用。我看過 staging 和 prod 共用同一個 DB，有人在 staging 跑 migration 結果把 prod 資料改了。

部署策略的選擇：藍綠部署適合「要嘛全切、要嘛全退」的場景；金絲雀適合「先讓 5% 流量試試水溫」。選哪個取決於你的風險容忍度和回退速度。

交付指標：不量化就無法改善

DORA 四大指標：Lead time（從 commit 到上線多久）、Deploy frequency（多常部署）、Change failure rate（部署失敗率）、MTTR（故障恢復時間）。

不用每個都追蹤。但至少知道你的 lead time 是 1 小時還是 1 週——差距很大，改善方向也完全不同。

---

手動操作就像用記憶力管帳。小額沒問題，但金額一大、筆數一多，你一定會記錯。IaC 和 CI/CD 就是你的帳本和自動轉帳。