搬站的風險控管與回退計畫

搬站的核心原則：永遠要能回去

再周全的規劃都可能出意外。真正的風險控管不是「保證不出錯」，而是「出錯時能快速回到原狀」。

所以規劃搬遷時，回退計畫應該與執行計畫同時準備。

回退的前提條件

要能回退，必須滿足三件事：

1. 舊環境還在且可運作——不要提前退租或刪除
2. 知道怎麼切回去——並且有人能執行
3. 切換期間的新資料能處理——這是最容易被忽略的

第三項的問題

如果切換後有訂單、會員註冊、表單詢問進到新環境，回退到舊環境時這些資料會消失。

所以回退不是單純的「切回去」，而是要處理這段期間的資料。

舊環境要保留多久

換網域為什麼要保留最久

因為舊網址的轉址必須持續運作。 搜尋引擎需要時間更新索引，外部網站的連結也不會立刻更新。

舊網域若在轉址完成前過期，那些流量就永久失去了。

切換時機的選擇

優先考量

• 流量最低的時段——通常是深夜或假日
• 業務最不繁忙的期間——避開檔期、活動、報稅期
• 有人可以處理的時候——不要在無人待命時切換

避開的時機

• 連續假期前一天——出問題時找不到人處理
• 促銷活動期間
• 負責人休假期間
• 週五下班前——這是很常見的錯誤，出問題就是整個週末

建議選在「還有一整個工作日可以處理」的時間點，例如週二或週三的早上。

切換前的最後檢查

1. 新環境完整測試通過——用修改本機設定的方式先行驗證
2. 憑證已在新環境安裝完成
3. 備份已完成且驗證可還原
4. DNS 的存活時間已提前調低
5. 回退步驟已寫下來
6. 相關人員已通知

第二項最常被漏掉——切換後才發現沒有憑證，訪客會看到明顯的安全警告。

測試方式見主機搬遷的完整流程。

雙軌並存期的資料處理

DNS 擴散期間，部分訪客連到新環境、部分連到舊環境。這代表新資料可能分散在兩邊。

依網站類型的處理方式

唯讀或維護模式的做法

切換前把舊環境設為不接受新資料：

• 顯示維護中的訊息
• 或關閉表單、購物車、註冊功能
• 並提供預計恢復的時間

短暫的維護公告，比事後追查遺失的訂單容易得多。

回退的判斷標準

什麼情況該回退、什麼情況該繼續修？建議事先訂好標準：

應該立即回退

• 核心功能完全無法運作——網站打不開、無法下單
• 資料明顯錯誤或遺失
• 問題原因不明且無法在合理時間內解決
• 持續造成營業損失

可以繼續修正

• 版面小問題
• 次要功能異常
• 原因明確且修正時間可估

訂一個時間上限

建議事先約定：「如果 N 小時內無法解決，就先回退。」

沒有這個標準時，很容易陷入「再試一下就好」的狀態，結果拖了一整天。

回退的執行步驟

1. 把 DNS 改回舊環境
2. 確認舊環境正常運作
3. 處理新環境產生的資料——匯出並補回舊環境
4. 對外說明（若有影響）
5. 記錄問題的原因——這是下次的依據

回退不是失敗，是風險控管的正常結果。 帶著問題硬撐上線，代價通常更高。

切換後的觀察期

當天

• 各項功能再測一次
• 從外部信箱測試表單通知
• 確認憑證正常
• 查看錯誤日誌
• 確認外部串接正常——金流、物流、發票

第一週

• 確認排程工作有正常執行
• 確認備份機制運作中
• 觀察錯誤日誌的趨勢
• 詢問各部門有無異常
• 檢查搜尋引擎的收錄狀況

第一個月

• 比對流量與搬遷前的基準
• 確認沒有大量的錯誤頁面
• 確認轉址都正常運作

五種最常見的搬站災難

一、測試環境的封鎖設定被帶到正式站

最嚴重也最常見。 網站一切正常，但搜尋引擎完全不收錄，可能兩三個月後才發現，那時流量已經歸零。

切換後第一件事就是檢查這個設定。 見搜尋引擎怎麼抓取與收錄網站。

二、排程工作沒有設定

自動備份、資料同步、定時發布全部靜默停止。

三、郵件設定不完整

表單通知信全部進垃圾桶——因為新主機是新的寄信來源，沒有納入寄件驗證。

見郵件的 DNS 設定。

四、外部串接的白名單沒更新

金流或 API 服務商設定了允許的來源位址，換主機後位址改變，串接就失效了。

五、憑證未先安裝

切換後出現安全警告，訪客直接離開。

把搬遷寫成專案

規模較大的搬遷建議明確安排：

• 負責人與各項工作的分工
• 時程與各階段的檢查點
• 驗收標準
• 回退的判斷標準與步驟
• 切換當天的待命人員

把回退計畫寫進文件，而不是「出事再說」。

驗收的原則見網站驗收怎麼做。

各服務商與廠商的作業方式差異很大，本文說明的是盤點與風險控管的原則。實際的交接內容與流程，建議以合約約定為準並逐項確認。