搬上 Google Cloud 前，先把遷移計畫排清楚

公司說「把系統搬上雲」時，最容易先討論要用哪個工具。但真正讓切換卡住的，常是大家以為知道、其實沒寫下來的事：某支夜間批次還在連舊資料庫、授權綁在實體主機上，或客服系統停寫後根本沒人知道要怎麼恢復。

所以這篇先從盤點與決策談起，再看 Migrate to Virtual Machines、Database Migration Service 等工具。最後用一份簡化的切換清單，把「成功」和「退回去」都說清楚。

先盤點，不要從 VM 數量開始猜

假設客服系統有三台 Web VM、兩台應用 VM 和一台 MySQL。只知道「六台主機」還不能排遷移順序：客服登入可能依賴地端身分系統，MySQL 可能每天把報表送到別的部門，還可能有一支沒記在架構圖上的排程會改資料。

每個工作負載至少要留下這些資訊：

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

Google 的遷移評估指引同樣把資產清單、相依性、團隊準備和 TCO 放在選工具之前。盤點完最好畫一張「誰連誰」的圖，並找實際維運的人核對；只從監控或資產平台匯出清單，通常看不見所有手動作業。

6R 是逐個系統做的決定

6R 不是六個都要試，也不是全公司只能選一個。同一批系統裡，客服系統也許先原樣搬，報表服務順手換成受管資料庫，沒人使用的舊入口則可以直接下線。

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

例如機房租約快到期，某個老系統雖然值得重構，眼前卻沒有足夠時間。可以先評估 Rehost，保住切換期限，再把重構另列一個有驗收標準的專案。相反地，如果系統明年就退役，現在投入搬遷費用可能沒有意義。這兩種決定都比「所有東西一起 Lift-and-Shift」有根據。

比成本時，兩邊要用同一把尺

「雲端 VM 月費」不能直接跟「機房伺服器的採購價」比較。前者是持續支出，後者可能已折舊，也可能下個月就得汰換。先選一段相同的比較期間，列出兩邊要達到的效能、備援和復原目標，再算總持有成本（TCO）。

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

同樣是 100 TB 資料，常讀的交易資料和幾乎不讀的備份，搬法與日後費用都不同。先拿現況用量與候選架構到 Google Cloud Pricing Calculator估價；若已有資產盤點資料，也可參考 Migration Center 的 TCO 報告。工具產生的是依假設計算的估價，簽約條件、人力、實際流量與切換風險仍得補進去。

估價表要保留輸入條件和日期。系統上線後，才能把實際帳單拆到服務與 SKU，查出差異是流量比預期高、規格開太大，還是測試環境忘了關。

工具要對準遷移的東西

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

資料量大不代表 Transfer Appliance 一定比較快。要把可用頻寬算出來，再和設備交付、複製、運送及匯入的時間比較；官方也提供線上傳輸模式，不能只把它理解成「把硬碟寄去 Google」。

名稱也對一下：Migrate to Virtual Machines 的舊名是 Migrate for Compute Engine，舊的 4.x 版已於 2024-04-30 終止支援；舊教材或題庫出現舊名時，對應的就是現在這個產品。

搬 VM：先 Test Clone，再談 Cutover

Migrate to Virtual Machines 可以持續複寫來源 VM，建立 test clone，在不切斷原服務的情況下先檢查目標 VM 能否啟動、能否連到應用和資料庫。測試通過，才安排正式 cutover。它能幫你搬 VM，卻不會自動判斷哪支批次作業要改連，或替你完成業務驗收。

回退也不是按一下「Undo」。依官方的 VM cutover 流程，回到來源可能要重新啟動舊 VM、把流量導回去，並處理新 VM 上已產生的資料。這件事必須在正式切換前演練，尤其是有寫入的系統。

搬資料庫：用 MySQL 說明最後一段路

MySQL 搬到 Cloud SQL 時，可以先用 DMS 做初始載入，再持續複寫變更。這能把大量資料傳輸放在服務還正常運作的時候，但不代表切換可以完全不停寫。以官方 MySQL Promote 步驟為例：

1. 確認來源版本、權限、網路連線與目標規格支援；先做測試遷移。
2. 觀察複寫延遲，驗證筆數、關鍵資料和應用查詢結果，不只看工作狀態顯示「執行中」。
3. 切換時停止來源寫入，等延遲歸零，再 Promote 目標並讓應用改連。
4. 驗證目標讀寫、錯誤率與資料一致性。來源先保留，何時退役由觀察期與資料保留規定決定。

Promote 後，目標成了可寫的主庫；如果新環境已經接收寫入，直接把 DNS 或連線字串改回舊庫可能會遺失這段資料。回退計畫得先定義「何時還能直接回切」與「何時需要停寫、匯回資料或另做恢復」，不能只寫一句「出事就回舊環境」。DMS 支援的同構、異構路徑和目標版本也會變，實作前按當前支援表核對。

先小範圍驗證，再安排正式波次

POC 用來回答一個具體疑問，例如舊版程式能否在目標 VM 啟動、資料庫延遲能否落在切換窗口內。Pilot 則挑一套有代表性、但影響可控的系統，把網路、權限、監控、備份、使用者驗收和回退都演練一次。正式環境再依相依性和風險分批切換。

不要把「POC 兩週、Pilot 四週、每週搬十套」當成通用時程。比較可靠的做法，是替每一波設 Go／No-Go 條件：測試有沒有通過、資料是否追平、誰可以批准切換、失敗時最多等多久才回退。Google 的遷移計畫驗證指引也要求估算停機、測試回退及檢查安全與成本假設。

以下是一份客服系統的簡化 Runbook。表中的檢查項目要依實際架構調整，停機與驗證時間則由團隊演練後填入。

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

這份表還少不了三個數字：可接受停機時間、可接受資料損失量、每個步驟的最長等待時間。這些得由業務要求和演練結果決定，不能從別人的案例拿一組漂亮的分鐘數套上去。

搬完不等於結束

剛切換後要特別留意三件事。費用方面，對照原估價與 Billing Reports，找出多出來的 SKU，而不是先買折扣。安全方面，查 IAM 是否仍保留臨時高權限、公開入口是否符合原設計、備份與稽核是否正常。維運方面，讓內部團隊自己跑一次部署、告警處理和還原演練，確認不是只有顧問知道系統怎麼運作。

準備 ACE 情境題時也可以照這個順序想：先辨認要搬的是 VM、資料庫還是檔案；再看停機與頻寬限制；最後問切換失敗怎麼退。工具名稱是答案的一部分，資料一致性、相依性和驗收條件才是遷移計畫能否成立的關鍵。

下一課 ACE-302：GCP 帳單怎麼看？從用量找出能省的地方 會接著看費用變化、折扣與閒置資源。