前面 24 天，我們一步步學了 Terraform 的各種技能，從變數、模組到狀態管理。再來我決定要挑戰 真實的企業級專案，來練習如何規劃和管理超過 50 個 GCP 資源的大型系統。

我用的專案是一個電商的訂單管理系統，會包含前端網站、後端 API、背景工作、資料儲存、CI/CD、還有監控告警。換句話說，幾乎把 GCP 上能用到的服務都用上了～

在進入實作之前，我決定先做「架構規劃」。因為如果一開始沒有想清楚，專案很容易長成這樣：

main.tf            # 上千行的巨無霸
variables.tf       # 上百個變數混在一起
iam-mess.tf        # 權限散落
random-fixes.tf    # 緊急修復的歷史遺跡

結果就是：要改資源時找不到地方、依賴關係混亂、部署順序不確定，最後變成誰也不敢動的黑盒子。
所以這邊我決定採用一個 三層式的專案架構。

三層架構設計

1. Infrastructure Layer（基礎設施）

最底層先把基礎設施建立好：專案、VPC、IAM、Service Accounts、Secrets。
這些是整個系統的根基，其他資源都要依賴它。

2. Platform Layer（平台服務）

接著是平台服務：Cloud SQL、Redis、Cloud Storage、Pub/Sub、Monitoring。
這些服務雖然不是業務邏輯，但卻是應用程式運作不可或缺的基礎建設。

3. Application Layer（應用服務）

最後才是應用本身：Cloud Run 的前後端服務、背景工作、CI/CD 管線。
這一層需要依賴上面兩層的資源，部署順序一定要排在最後。

部署順序：Infrastructure → Platform → Application

這樣的分層不只清楚，也能讓團隊分工更自然：基礎設施團隊、平台團隊、應用團隊各自專注自己的範疇。

環境管理策略

企業專案一定有 dev / staging / prod，不可能只用一個環境。
因此我在目錄下建立了 environments/，裡面針對不同環境有各自的 tfvars。

例如：

• dev 環境：小規格 DB、單實例、沒有備份
• prod 環境：高規格 DB、多實例、完整備份

這樣一來，程式碼可以共用，但配置會隨環境調整。

模組設計策略

模組我分成兩種：

• 直接用 Registry 模組：像是 VPC、Cloud SQL、Load Balancer，這些 Google 官方已經維護得很好。
• 自己寫的模組：像是 Cloud Run 微服務、IAM 權限組合、監控告警，這些有公司特定需求，直接寫模組比較靈活。
  這樣可以兼顧穩定性與客製化。

狀態管理策略

為了避免多人開發踩到 state lock，我把 state 也分層：

• Infrastructure 有自己的 remote state
• Platform 有自己的
• Application 也獨立

層與層之間用 terraform_remote_state 讀取彼此的輸出，這樣不會互相干擾，也能保持部署的彈性。

協作與風險控制

在團隊協作上，應該要：

• Infra、Platform、App 團隊各自負責
• Git Flow 管理分支，main 對應 production，develop 對應 staging
• 關鍵資源（例如 Cloud SQL）加上 prevent_destroy，避免不小心毀掉資料庫
• 必要時用 -target 來控制只更新特定模組

總結一下

今天還沒有開始寫任何 Terraform 程式碼，而是先專注在 專案架構規劃。
我先把一個 50+ 資源的系統拆解成：

• 三層架構：基礎設施 → 平台 → 應用
• 清楚的部署順序
• 多環境管理
• 模組化策略
• 分層狀態管理
• 團隊協作與風險控制

明天我會從 Infrastructure Layer 動手實作，把這個藍圖一步步搭建起來！希望可在在最後六天完成練習挑戰！