前言

兩年前，我在 iThome 鐵人賽 (GitHub) 寫過一個從 DDD、Clean Architecture 到 Microservices 的 Todo 系統系列。當時的重點是把服務拆開、讓它們能協作；這次則接著問：服務寫完之後，團隊怎麼把它交付出去？

上一個系列的最後，我們把 Account、Todo、BFF 與 Web 組成了一套能在本機啟動的 Todo 微服務系統。docker compose up -d 後一排服務亮起來，當然值得開心。不過，假設明天要把「建立待辦事項偶爾逾時」的修正交給團隊測試，接下來該由誰做什麼？

把 image 傳給誰？Staging 的設定和本機不同時誰負責改？半夜有人手動調整副本數，下一次部署會不會覆蓋它？服務雖然成功啟動，使用者仍然失敗時，又要到哪裡找答案？微服務的開發告一段落後，這些問題才正式浮上檯面。

這個系列不會把平台工程說成某一套神奇產品，也不會假裝每個團隊都需要一個龐大的平台部門。我們會從上一系列的 Todo 微服務出發，把原本仰賴熟手經驗的交付工作，整理成團隊可以重複使用的路徑。

開始前需要知道什麼？

你不必先讀完前一個系列。後面的文章會把 Todo 系統當成一個已容器化的應用程式：它有幾個彼此呼叫的服務，也能用 Docker 在本機啟動。

希望能熟悉容器化，如 docker、Container Image 與 HTTP API，閱讀起來會比較順。

Kubernetes 不需要全盤了解，但建議至少知道 Pod、Deployment、Service 和 Namespace 在解決什麼問題。Day 02 會從宣告式 API 與 Controller 的運作方式開始補齊這個脈絡。

一個能跑的系統，為什麼還不算完成？

本機能跑解決了很重要的事情：服務可以被建置、容器可以互相連線、基本功能有地方驗證。但它還沒有回答「團隊如何反覆且可靠地交付」。當系統從兩個服務長到二十個服務，下面這些看似零碎的決定會開始互相纏住：

• 每個服務要有哪些 Kubernetes 資源、放在哪個 Namespace？
• Dev、Staging、Prod 的差異由誰維護，又如何避免設定逐漸分岔？
• 新 image 通過測試後，誰有權限讓它進入叢集？
• 發布後是 Healthy 還是只有「YAML 已套用」？失敗要回報到哪裡？
• 自助建立服務時，怎麼避免一份 YAML 就拿走過多權限或破壞叢集資源？

如果答案是一份 Wiki、幾段私訊指令，或找某位資深同事處理，那其實不是一個理想的流程，而是讓 Deploy 的管理與風險，都集中在少數人的手上。

平台工程要交付的是什麼？

平台工程（Platform Engineering） 的核心不是要求開發者學更多工具，而是把組織反覆驗證過的做法包裝成內部產品。這個產品有使用者、有介面、有預設值，也有清楚的限制。

以 Todo 系統為例，開發者真正想表達的通常是：

我要部署 todo-api。
它要使用這個已通過 CI 的 image、開放這個 port，
並且部署到屬於 Todo 團隊的環境。

開發者不應每次都從零決定 Deployment 的 label、Service selector、OpenTelemetry 設定、Argo CD 同步策略與 RBAC 權限。這些不是不重要；正因為重要且容易出錯，才更應該被平台設計成一致的預設值。

平台也不是把所有彈性拿走。好的規劃會把「服務擁有者應該決定的事情」和「平台應該一致提供的事情」分開：

系列最後要組成的控制流如下。這不是一開始就要全做完的架構圖；我們會每天補上一段，確認每個元件到底替交付流程解決了什麼問題。

系列會走過哪些階段？

我們預計會先打好 Kubernetes 與部署基礎，弄清楚服務進入叢集後，哪些資源負責執行、找服務和接外部流量。接著導入 GitOps，讓 Git 保存環境設定，並由 Argo CD 將已審查的變更同步到叢集。

服務上線後，光看 Deployment 存在還不夠。我們會用 Metrics、Logs、Traces 與 OpenTelemetry 建立觀測資料，讓團隊有辦法追查延遲與錯誤。再回到 CI，釐清程式碼測試、Container Image 與 GitOps 設定之間該怎麼交接。

這些基礎就緒後，才開始設計 IDP 接收服務需求，後端產生 Git 變更，Microservice CRD 和 Operator 將意圖展開成 Kubernetes 資源，狀態再回到開發者看得到的地方。

最後會補上自助服務需要的安全邊界：團隊的 Namespace 與 RBAC、資源進入叢集前的 Policy，以及服務之間的流量管理與 mTLS。每一段都先處理前一段留下的問題，不急著把所有工具一次塞進系統。

下一篇先從 Kubernetes 的宣告式 API 與 Reconcile Loop 開始。理解 Controller 如何持續讓實際狀態靠近目標狀態，後面的 GitOps 和 Operator 才不會只剩下名詞。