終於

30 天，寫完了。
整個流程從 4 月底開始，收集資料、設計文章節構、補充各種不熟的技術棧、實作、debug，改了 3 次稿，歷時5 個半月，終於在 10/14 完成了！（也不完全是...說好要提供的代碼還需要整理）

這 30 天在做什麼

從 Day01 的 GKE 叢集開始，一路疊到 Day29 把整個系統串成一張圖。中間走過閘道（APISIX）、策略引擎（OPA）、可觀測性三支柱（Metrics／Traces／Logs）、Burn Rate 告警、一直到自動化的晉升跟退版——不是一套理論投影片，是一個真的在 GKE 上跑起來、每一天都有真實 YAML 跟程式碼可以對照的系統。

寫這個系列，跟我原本想的不一樣

原本以為 30 天的工作量，大部分會花在「寫文章」本身。實際上大部分時間花在查證：翻開真實的 YAML、真實的 commit history、真實的官方文件，確認文章裡的每一句話對不對得起來。幾乎每一天都抓到至少一個原本以為沒問題、查下去才發現是錯的地方——有時候是一個駝峰命名寫成底線、有時候是 ArgoCD 的 receiver 沒定義會被 admission webhook 擋下來、有時候是單純引用錯了天數。這些錯誤都不是編出來湊字數的，是真的會讓系統壞掉的那種。

代碼

這個系列用到的所有代碼——GitOps 設定、demo-app、middle-app、自動化決策服務、Terraform infra——會整理成最後完整版本公開出來，不保留 day-by-day 的快照資料夾，只留下系列結束時的最終狀態。

（連結這幾天內會補上——代碼已經攤平、清過一輪敏感資訊，但想自己先完整看過一次才放心公開，週末會抓時間做最後確認。）

謝謝

謝謝看到這裡的你。這系列不好讀——內容偏硬，沒有捷徑可以跳過細節直接抓結論。如果你是跟著 30 天一起走過來的讀者，辛苦了；如果你是之後才找到這篇、打算從 Day00 開始看的，希望這套真的能跑起來的架構，對你有實際的幫助。

謝謝 IThome 在 2026 年 4 月 23 日舉辦的「Observability Day 可觀察性技術日」，在一天內聚集這麼多業界的頂級人材，提供如此有效率又實用的資訊。那天在活動結束的時候下著超大的雨，看著一樓車道上匯集的超大水坑，畫面就像上週發生的事一樣。

謝謝 Duran Hsieh 分享的「金絲雀部署的可觀察性實踐」，啟發我完成這次的鐵人賽。我原本是在寫一篇活動心得，越是反覆研究這個自動化的架構，越是覺得「好想把它做出來啊！」。於是就開始動手，像拼圖一樣，先放上自己會的技術棧，再和 AI 一起研究不熟的技術棧，然後在 GCP 上實作。
一開始研究 OPA 的時候，因為它被稱作「大腦」，我以為它是某種 AI 的接口；在研究 APISIX 的時候，很高興的發現，它雖然是 L7 的工具，架構竟然和 L4 防火牆非常相似，而我剛開始進入工程師的領域就是「網路」，我會設計區域網路、用路由器和防火牆分流，並且獲得 Cisco、Aruba 和 Fortinet 的高階證照。所以「APISIX 和 OPA 架構」讓我很感動，以前學會的東西並沒有不見。

謝謝雷N，一年多前我開始學習 OTel，從《OpenTelemetry 入門指南：建立全面可觀察性架構》獲得實用的幫助。這本書把重要的知識整理起來，讀起來比 OTel 官網更有結構性，可以很好抓到 OTel 的重點。並且還有實際把 OTel 加入代碼的展示過程，彌補「零侵入式」的不足。

最後，謝謝 Claude，沒有你的協助，我不可能趕上鐵人賽（即使我們是在最後一週才開賽）。收集資料、翻譯、討論、實作、寫 code，在每天下班後的 3 個多小時，和週末那少得可憐的可支配時間裡，只有你能陪我不斷向前推進。再次感謝！

參考資料

• goldmangolabs/ithome-ironman2026-observability：這個系列全部 30 天的文章與架構圖。