客戶是一家物流服務商，每天處理數萬筆訂單，晚間和促銷期間會出現尖峰，並對合作零售商承諾嚴格的 SLA。基礎架構在缺乏規劃下逐步擴張：分散的 VPS、留在「伺服器上」的設定，以及按照 wiki 說明手動部署。每次發布都得在夜間上線並造成停機；每次尖峰都伴隨訂單流失風險。一次新年前促銷事故中，平台停擺四小時，服務商還必須補償合作夥伴，因此前來尋求協助。
在不中斷業務的情況下遷移至可管理的基礎架構：
基礎架構即程式碼、自動化交付、容器化與編排、可觀測性，以及可預期的故障復原。創辦人這樣定義成功：「在上班時間部署、不停機，也不需要有人透過 SSH 操作」。
我們依循經驗驗證的順序進行：先導入容器和可重現的環境，再自動化交付，最後才加入具自動擴縮能力的編排。
- 稽核基礎架構：繪製服務與相依關係圖、測量尖峰負載型態，並列出最常造成事故的人工操作。
- 將服務容器化：統一建置方式、把設定移出程式碼並改用環境變數，建立彼此相同的 dev/stage/prod 環境。
- 使用 Terraform 將基礎架構寫成程式碼：從儲存庫部署環境，禁止在雲端服務商控制台手動修改。
- 建立 GitLab CI 流水線：自動執行測試並建置映像檔；stage 立即部署，prod 經審查後按鈕部署；一次操作即可回復。
- 遷移至支援自動擴縮的 Kubernetes：晚間和促銷尖峰由平台自動增加執行個體，不再需要緊急人工操作。
- 部署監控與告警，以延遲、錯誤、流量和資源飽和度等黃金訊號為核心，並建立值班與升級流程。
- 設定備份與災難復原：制定復原規範，並在 stage 演練故障、測量實際 MTTR。
專案最有價值的不是技術，而是責任方式的改變：基礎架構不再依賴「有 SSH 權限的人」。每次部署都能重現，每個環境都能從程式碼復原，任何故障都會在第一位客人傳訊息前出現在儀表板。如此一來，停機不再是災難，而是有明確手冊、復原時間可測量的日常事件。
專案的經濟效益由三部分組成：透過自動擴縮、不再持續預熱「尖峰」容量，基礎架構直接節省 32%；團隊節省原本用於夜間部署的工時；最重要的是，尖峰期間現在不再發生事故，營收得以保留。一家大型零售連鎖客戶正是在新基礎架構上的第一次促銷後續約。
| 指標 | 成果 |
|---|---|
| 版本部署 | 人工 3–4 小時 → 自動化 15 分鐘 |
| 發布頻率 | 每月 2–3 次 → 幾乎每天 |
| 平台可用率 | 97,8% → 99,95% |
| 尖峰負載 | 停機風險 → 無需人工介入的自動擴縮 |
指標取自案例原始資料。僅在來源有記錄時註明統計期間。
- 版本部署（原人工需 3–4 小時）
- 15分鐘
- 平台可用率（原為 97.8%）
- 99.95%
- 故障後的復原時間（原為 2–4 小時）
- 20–30分鐘
- 基礎架構成本
- −32%
版本部署時間，分鐘
數值越低越好復原時間（MTTR），分鐘
數值越低越好平台停機時間
數值越低越好圖表顯示區間上限（4 小時、30 分鐘）。停機率 = 100% − 可用率。
- 01提交程式碼
- 02測試
- 03映像檔建置
- 04預備環境立即
- 05正式環境審查後按鈕部署
下一階段的基礎架構發展方向：
- FinOps 實務：針對成本異常設定告警，並按團隊透明呈現費用。
- GitOps 作法：在儲存庫中描述 prod 狀態，所有變更只透過 pull request 進行。
- 多區域部署：複製關鍵服務，提升因應雲端服務商故障的韌性。
以前發布就是熬夜、咖啡和祈禱。現在只要按下按鈕，等十五分鐘。第一次在新基礎架構上平安度過促銷，全公司一起慶祝。
— 物流服務技術長