這個專案的核心是一套系統，由多個技術棧組成，包含：APISIX、OPA、金絲雀部署、Prometheus、Rego、Python ⋯⋯等。這些技術棧的使用方式在網路上可以找到詳細的教學。這裡我想把系列文章聚焦在一個比較少人寫的部分：當你要把好幾個獨立的工具串成一個能自動運作的系統時，資料要怎麼在它們之間流動、誰觸發誰、串接時會卡在哪裡、怎麼排查。這是我自己在實作過程中，花最多時間摸索，並且覺得相當有收穫的部分，因此想把這個過程完整記錄下來並且分享出去。
我實作了幾個功能：
我是一個 SRE 工程師，用 GitOps 的方式工作。
我參加 2026/4/23 由 iThome 舉辦的 Observability Day，在那天都聽 Track A 議程。Duran Hsieh 分享的「金絲雀部署的可觀察性實踐」給我一個很棒的啟發：這個可以讓 QA 的工作變得更輕鬆，而且不用等到全部上版之後才知道有什麼地方爆雷。即使開發週期有多層不同環境（例如，開發環境、測試環境...一直到產線環境）可以對代碼層層過濾，在服務上到產線之前，加入「自動化金絲雀」仍然十分有用，因為有些問題需要在產線環境才會出現。如果能先把一小部分流量導入金絲雀，並依據觀察結果逐步增加流量，或者直接停止金絲雀，這樣可以很好限制「爆炸半徑」的範圍。
這樣的專案很適合有一個快速佈署的版本，不論是用來分享或者是自己開發測試，都可以使用。所以我就以「自動化金絲雀晉升與退版」＋「可觀察性」為主軸，實作一個「精簡版」的 POC 專案。
讓我能把「自動化晉升與退版」的流程實作出來的關鍵，是雷N（也是當天 Track A 議程的主講人之一）寫的《OpenTelemetry 入門指南：建立全面可觀察性架構》這本書。我參考了裡面 OTel 在傳遞 HTTP header 的細節，知道怎麼追蹤進入不同版本服務的數據流，進而完成整個自動化晉升與退版的判斷機制。沒有這本書打底，這個專案很可能卡在「觀察到金絲雀版本的健康狀況」這一步，做不到後面「自動化」的部分。
每一天都會列出工項，為了讓讀者可以用自己習慣的技術棧替換掉特定的主題的技術棧，我盡量確保這些技術棧本身也是「去耦化」。
代碼放在 GitHub 上面。包含 5 個 repo：
代碼是 Day30 完成之後的 最終版。會在 30 天寫完之後上傳。
我原本的計劃是讓讀者可以每一天做一個進度，執行之後發現這樣的工作量已經 超過專案本身。維護成本極高，出錯率也大幅上升。
我會在每天的內容裡，把重要的代碼片段列出來說明。git 裡的內容會更多，因為代碼在這 30 天內持續累積。
infra repo 裡放的是 Terragrunt，可以在 Google Cloud Platform 佈署所需的 infra 架構。
每天的文章會聚焦在「這個環節怎麼跟前後串起來」；比較詳細的操作與佈署方式，我另外整理放在各個 repo 的 README.md 裡，方便真的動手做同樣專案的讀者查閱，也讓每天的文章保持在可以一次讀完的篇幅。
iThome鐵人賽
看影片追技術