系統重構不停機策略：怎麼在不影響營運下換掉 10 年老系統？

為什麼老系統重構這麼難？

用了 8–10 年的客製化系統通常有三個共同特徵：原始開發者已離職、文件不完整、架構耦合到沒人敢動。但業務又持續成長，效能、安全、UX 都跟不上。最危險的選擇是「重新從零開發然後上線那一天切換」，這幾乎都會失敗。山葵組客製化系統服務 在多次重構案例中累積了「不停機更替」方法論，本文為你拆解 4 大策略。

策略 1：Strangler Fig（絞殺者模式）

由 Martin Fowler 提出，核心是「在舊系統外圍逐步建構新系統，把流量一個模組一個模組導過去」。例如先把「用戶註冊」抽到新系統，舊系統的此功能廢棄；再做「訂單查詢」… 半年後舊系統像被榕樹纏死的老樹，自然下線。風險最低、最適合大型企業系統。

策略 2：藍綠部署（Blue-Green）

同時跑兩套完整環境：藍（舊）、綠（新）。先讓新環境跑得跟舊一樣，再用 DNS / Load Balancer 一鍵切換流量。出問題立刻切回。適合「整體框架升級」（如 PHP 5 → 8、Vue 2 → 3、Laravel 跳大版本）。需準備兩倍硬體。

策略 3：雙寫（Dual Write）+ 漸進切讀

適用於資料庫架構大改（MySQL → PostgreSQL、單體 DB → 微服務 DB）。流程：先讓所有寫入同時寫到新舊兩個 DB，跑 1–2 週驗證資料一致；接著讀取流量先導 5% 到新 DB，逐步拉到 100%；最後關閉舊 DB 寫入。重點是「每天比對資料差異」並有完整 rollback 機制。

策略 4：Feature Flag + 灰度

對於前端介面、API 行為的改動，用 Feature Flag（LaunchDarkly、Unleash、自建）控管。新功能先開給內部員工 → 5% 用戶 → 25% → 100%。任何環節數據異常立刻關閉開關。不需上線新版本就能回滾，是現代軟體交付的關鍵能力。

重構前必做的 5 件事

一、需求凍結期：和業務協議「3 個月內不加新需求」，否則重構永遠停不下來。二、自動化測試：補完關鍵流程的整合測試，這是不停機的命脈。三、可觀測性：先導入 Log、Metric、Tracing，沒監控不要動。四、資料盤點：哪些表被誰用、有多少 dead code。五、Runbook：每個切換步驟都有書面 rollback 流程。

常見失敗陷阱

一、太樂觀的時程：重構通常比預估慢 50–100%，建議多預留 1.5 倍時間。二、沒有業務 Champion：純 IT 專案常被砍預算。三、追求一次到位：Big Bang 切換是最大殺手。四、忽略訓練：新系統再好，使用者抗拒就會回到舊流程。五、沒有量化指標：說不清楚「重構帶來什麼」，下次提案就被擋。

結論：重構是策略，不是工程

老系統重構不是技術問題，是治理問題。需要老闆背書、業務參與、IT 執行三方同步。山葵組建議用 12–18 個月的階段性計畫，搭配 Strangler Fig + Feature Flag 為主軸，把風險拆到最小。想討論你的老系統重構路線圖？歡迎到 聯絡山葵組。更多客製化系統實戰文章請見 山葵組部落格。系統重構老系統客製化系統不停機