許多團隊在談論「零停機發布（Zero-Downtime Deployment）」時，往往將焦點過度集中在負載平衡器上的權重調配或是容器的滾動更新（Rolling Update）。然而，在實際企業生產環境的諮詢輔導經驗中，高達七成以上的停機事故與嚴重回滾，根因其實並非無狀態服務的重啟失敗，而是資料庫綱要變更（Schema Migration）與程式碼版本不相容。
一、展開與收縮模式（Expand and Contract Pattern）
要達成真正的無中斷切換，資料庫變更必須遵循「擴展、相容、收縮」的三階段演進原則：
- 擴展階段（Expand）：新增欄位或新表，但不刪除或修改既有欄位。此時舊版本應用程式依然能正常讀寫，新部署版本亦能識別新欄位。
- 並存與同步階段（Transition & Dual-Write）：新舊版本服務同時在線上運作時，應用層需具備向下相容邏輯，或透過背景作業確保新舊資料格式的一致性。
- 收縮階段（Contract）：當所有流量皆已穩定轉移至新版本，且經由足夠的觀察窗口確認無異常後，才在下一個獨立的維護週期移除舊欄位或棄用架構。
二、金絲雀流量切換的關鍵觀測指標
在流量漸進式放量（1% -> 5% -> 25% -> 100%）過程中，工程團隊不能僅依賴 HTTP 500 回應率。我們建議顧問客戶建立專屬的發布守護指標清單：
- 特定業務錯誤率（Business Metric Delta）：如訂單結帳成功率、登入驗證延遲等，而非單純的基礎設施 CPU 指標。
- 資料庫連線池水位與慢查詢激增：新版本查詢計畫（Query Plan）是否引發全表掃描。
- 非同步隊列堆積深度：訊息消費者在版本更迭時是否發生序列化異常或死信隊列激增。
三、發布窗口與應變準備
即使具備了完善的自動化切換機制，發布前的確認清單仍是保障系統韌性的底線。在樞軸核心顧問的輔導框架中，我們要求每次重大發布皆需明確指定「決策時間點（Go/No-Go Checkpoint）」，避免在異常擴大時陷入猶豫不決的處境。