闖蕩新創 0001 | 有，又好像沒有
2026 年初，我從軟體大廠的資深工程師職位離職，加入新創擔任技術經理。對於技術、管理還矇矇懂懂，希望藉由這個系列的記錄，在多年後回頭檢視自己的成長。
加入第一個任務，是回頭檢視目前的系統。這個系統長期以來，在自動擴展上一直存在問題，導致在瞬間流量與長時間高流量時，系統無法有效負荷。
於是第一天我便跟既有開發維護合作，先把環境架設起來。此時，第一個問題便浮現了：過去這個系統是由一個工程師幾乎獨立開發，因此，在本地端上或者是雲端等 K8s 群集重現，居然無法建立！這之中不乏各個環境中，變數不同導致。
後續，我再深入細看 infra 時，才發現現在的環境建置上，有一個比較嚴重的問題需要立刻解決——我們各個環境的部署方式是分開維護的！簡單來說，雖然看上去環境切分成了「測試開發 (dev/test)」、「類生產 (stage)」與「生產環境 (production)」，但各個環境並不一致。當前透過 Jenkins 串的 CICD，分別由三條 pipeline 維護。
這是什麼意思呢？就代表我們在 dev, stage 上面做的測試或修復，很難保證不會在 production 上面重現。畢竟，三者就是獨立的流程。
環境切分似乎有，又好像沒有。
我很清楚，假如我們想要在 stage 上面做比較完整的 performance 測試，那勢必在那之前得先統一各個環境的部署程式與流程。所以，第一週安排接下來 release plan 的同時，我也同步在熟悉系統架構，並盡可能在不改動現行 codebase 的情況下，去統一流程。
目前三個環境的 Clusters 有些許不同，dev 環境長在我們自己架設的機器上，stage / production 則長在雲端。這之間最大的差別是，雲端上我們走的是 istio 來導入外部流量，而本地環境則透過 ingress。除此之外，我們 stage 的 infra 程式也很久沒更新了，之前的開發流程比較像是 dev 開發測試完，便直接部署 production，stage 只是偶爾拿來做效能測試時使用。
既然已經年久失修，我也就不打算去修他。我的如意算盤是，我們直接把現在 production 使用的 infra，移植到 stage 上。下一步再針對 stage 上的環境變數進行調整，在 stage 上把環境復現。
至於你說 dev 呢？正常來說，不是應該在 dev 測試沒問題再上 stage，最後才回到 production？但 dev 上工程師正在進行下一版 release 功能的開發，比較有效率的做法是由我們分頭進行，最後等開發到一個階段，再部署回 dev。
好，這下 migrate 流程確立了：
- 完成 stage infra 復現
- 統一 Jenkins pipeline，讓環境的部署方式一致
- 以一統的部署方式，部署 stage 確定改動無誤
- 以一統的部署方式，部署 production 確定改動無誤
- (optional) 把一統的 Jenkins 流程，migrate 到 gitlab CICD
- 以一統的部署方式，部署 dev 環境
第五步有一小部分是我的私心，但主要是 Jenkins 的 Groovy 語法沒有 Gitlab CICD Yaml 來的直觀，加上 Jenkins 的部署，並沒有寫在 codebase 中，因此沒有版本控制。我自己也不想要使用很多套軟體，希望 CICD 和 code repo 綁在一起，減少多個工具的使用，降低操作成本。
花了約一週，總算，我們的環境部署有初步的統一！接下來，就要來實際解決系統流量的問題了。
