遷移至 Google Cloud：驗證遷移計畫的最佳做法

Last reviewed 2025-05-05 UTC

本文說明驗證工作負載遷移至 Google Cloud計畫的最佳做法。本文並未列出驗證遷移計畫的所有可能最佳做法，也不保證一定能成功。而是協助您激發討論，探討遷移計畫的潛在變更和改善。

如果您打算從地端部署環境、私人託管環境或其他雲端服務供應商遷移至 Google Cloud，這份文件會很有幫助。如果您正在評估遷移機會，並想瞭解遷移後的樣貌，這份文件也很有幫助。

本文件是遷移至Google Cloud的多部分系列文章之一：

評估

完整評估工作負載和環境，有助於確保您深入瞭解工作負載和環境。瞭解這些資訊，有助於盡可能降低遷移至 Google Cloud期間和之後發生問題的風險。

進行完整評估

在繼續執行評估階段後的步驟之前，請先完成工作負載和環境評估。為進行完整評估，請考量下列常遭忽略的項目：

  • 盤點：確認要遷移的工作負載清單為最新版本，且您已完成評估。舉例來說，請考量評估作業的來源資料是否最新且可靠，以及資料可能存在哪些落差。

  • 停機時間：找出可處理停機時間的工作負載。決定停機時間和持續時間，盡可能減少干擾，例如在深夜或週末進行。在停機時間為零或接近零的情況下遷移工作負載，比在可承受停機時間的情況下遷移工作負載更困難。如要完成零停機時間遷移，您必須為要遷移的每個工作負載設計並實作備援機制。您也需要協調這些備援執行個體。

    評估工作負載可容忍的停機時間時，請評估零停機時間遷移的業務效益是否大於增加的遷移複雜度。請盡可能避免為工作負載建立零停機時間需求。

  • 叢集和備援：評估哪些工作負載支援叢集和備援。如果工作負載支援叢集和備援，您可以部署該工作負載的多個執行個體，甚至可以跨不同環境 (例如來源環境和目標環境) 部署。叢集和備援部署作業可能會簡化遷移作業，因為這些工作負載會彼此協調，且干預有限。

  • 設定更新：評估如何更新工作負載設定。舉例來說，請思考如何為要遷移的各個工作負載提供設定更新。這項考量對於遷移作業的成功至關重要，因為您可能需要在將工作負載遷移至目標環境時，更新工作負載的設定。

  • 產生多份評估報告：在評估階段，產生多份評估報告可能有助於考量不同情境。舉例來說，您可以產生報表，考量工作負載的不同負載設定檔，例如尖峰和離峰時間。

評估工作負載支援的故障模式

瞭解工作負載在異常情況下的行為，有助於確保工作負載不會暴露在無法復原的條件下。在評估過程中，請收集故障模式及其影響的相關資訊，瞭解工作負載支援哪些故障模式、可自動從哪些故障模式復原，以及哪些故障模式需要您介入處理。舉例來說，您可以先思考可能發生的故障模式，例如：

  • 如果工作負載與網路中斷連線，會發生什麼情況？
  • 工作負載停止後，能否從中斷處繼續執行？
  • 如果工作負載或其依附元件的效能不足，會發生什麼情況？
  • 如果架構中有兩個工作負載具有相同 ID，會發生什麼情況？
  • 如果排定的工作未執行，會怎麼樣？
  • 如果兩個工作負載處理同一則訊息，會發生什麼情況？

遷移計畫本身也可能導致不支援的失敗模式。判斷遷移計畫是否包含取決於特定條件是否成功的步驟，以及是否包含未滿足條件時的應變措施。如果方案包含這類條件，可能表示方案本身或個別元件在遷移期間會失敗。

評估這些故障模式及其影響後，請在非關鍵環境中驗證您的發現，方法是模擬故障並插入模擬這些故障模式的錯誤。舉例來說，如果工作負載設計為在網路連線能力中斷後自動復原，請強制中斷連線能力，然後再還原連線能力，藉此驗證自動復原功能。

評估資料處理管道

工作負載評估應能回答下列問題：

  • 資源是否已調整為適合遷移的大小？
  • 遷移工作負載所需的資料需要多少時間？
  • 目標環境是否能容納所有資料？
  • 當工作負載必須因應需求激增，或在指定時間範圍內產生的資料量激增時，會如何運作？
  • 如果需求或工作負載產生的資料量激增，是否會產生任何負面影響，例如延遲時間增加或回應延遲？
  • 工作負載啟動後，是否需要時間才能達到預期的效能水準？

這項評估的結果通常是工作負載滿足的需求模型，以及工作負載在指定時間範圍內產生的資料。收集資料點來產生這類模型時，請考量尖峰和離峰時間範圍內的資料點可能會有顯著差異。如要進一步瞭解監控方式和監控項目，請參閱《網站可靠性工程》一書中的「服務水準目標」一節。

確認您可以更新及部署要遷移的各項工作負載

在遷移期間，您可能需要更新部分要遷移的工作負載。例如，您可能需要部署問題修正，或復原造成問題的近期變更。針對要遷移的每項工作負載，請確保您可以套用及部署變更。舉例來說，如果您要遷移的工作負載有原始碼，請確保您可以存取該原始碼，並視需要建構、封裝及部署原始碼。

遷移作業可能包含無法套用及部署變更的工作負載，例如預先存在和現成的軟體。在這種情況下，請重構遷移計畫，考量是否需要投入額外心力，緩解遷移這些工作負載後可能發生的問題。

評估網路基礎架構

功能正常的網路基礎架構是遷移作業的基礎。您可以將網路基礎架構做為遷移工具的一部分。舉例來說，您可以根據遷移計畫，使用負載平衡器和 DNS 伺服器來導向流量。

為避免在遷移期間發生問題，請務必評估網路基礎架構，以及其支援遷移作業的程度。舉例來說，您可以先思考負載平衡基礎架構的相關問題，例如：

  • 重新設定負載平衡器會有什麼影響？
  • 更新後的設定需要多久才會生效？
  • 在不停機的情況下遷移時，如果更新後的設定尚未就緒，流量就突然暴增，會發生什麼情況？

思考負載平衡基礎架構的問題後，接著請思考 DNS 基礎架構的問題，例如：

  • 您應該更新哪些 DNS 記錄，將其指向目標環境？何時應該更新？
  • 哪些用戶端正在使用這些 DNS 記錄？
  • 您打算更新的 DNS 記錄，其存留時間 (TTL) 是如何設定的？
  • 您可以在執行遷移作業前，將 DNS 記錄 TTL 設為最小值 (以秒為單位) 嗎？
  • DNS 用戶端和中介端是否會遵循您要更新的 DNS 記錄存留時間？舉例來說，您的應用程式是否具有用戶端 DNS 快取，會忽略您為遷移作業設定的存留時間？請注意，DNS 解析涉及多層快取。建議使用 Google 公用 DNS，避免 ISP DNS 問題。
  • DNS 用戶端是否會遵循要更新的 DNS 記錄存留時間？舉例來說，您的應用程式是否具有用戶端 DNS 快取，會忽略您為遷移作業設定的存留時間？
  • 完成遷移後，您是否偵測到導向來源環境的流量？

考慮建立概念驗證

概念驗證 (POC) 是指對預定遷移專案進行小規模的初步實作。在全面實作前，先驗證專案的可行性、功能和潛在效益。概念驗證可協助您判斷遷移工作負載是否在目標環境中正常運作。

首先，請定義 POC 的範圍和具體成功標準。成效標準可包括完整目標工作負載相容性、最短遷移停機時間，以及特定效能需求等指標。

找出成功標準後，請測試及驗證概念驗證。在遷移計畫文件中，記錄您的發現、遇到的挑戰，以及這些挑戰的任何潛在解決方案。

如要調查下列感興趣的領域，建議您建立概念驗證：

  • 驗證遷移可行性：確認應用程式、工作負載和資料在 Google Cloud中正常運作。
  • 預估停機時間並規劃復原作業：評估遷移工作負載和移轉資料所需的停機時間。驗證復原情境。
  • 調整遷移計畫：在全面遷移前，請考量下列事項，調整計畫：
    • 找出最佳遷移方法。
    • 找出需要現代化或重構的工作負載。
    • 找出遷移作業的潛在風險或問題。
    • 測試遷移作業。
  • 執行安全性和法規遵循驗證：確保遷移作業的安全政策、Identity and Access Management (IAM) 角色和法規遵循要求符合組織需求。
  • 建立信心並取得利害關係人支持：確保利害關係人滿意。成功的概念驗證可向領導團隊和技術團隊展現具體效益，讓利害關係人對遷移計畫更有信心。
  • 預估成本和最佳化可能性：預估遷移相關成本。探索最佳化可能性，例如測試不同的目標環境大小和遷移工具。

反覆測試多個概念驗證。調整目標工作負載和遷移計畫，直到建立符合成功條件的概念驗證。

規劃遷移作業

詳盡規劃遷移作業，有助於避免在遷移期間和之後發生問題。規劃也有助於避免處理非預期工作的精力。

為遷移計畫的每個步驟制定復原策略

在遷移期間，您執行的任何遷移計畫步驟都可能導致非預期的問題。為確保您能從這些問題中復原，請為遷移計畫的每個步驟準備復原策略。為避免在服務中斷期間浪費時間，請按照下列步驟操作：

  • 定期檢查及測試各項復原策略，確保策略有效。
  • 設定每個遷移步驟的執行時間上限。超過允許的執行時間後，團隊就會開始復原遷移步驟。

即使您已為遷移計畫的每個步驟準備好復原策略，其中某些步驟仍可能造成干擾。即使復原，可能造成干擾的步驟仍會導致某種損失，例如資料遺失。評估遷移計畫中哪些步驟可能造成干擾。

如果您將遷移計畫的任何步驟自動化，請務必為每個自動化步驟預先規劃程序，以防自動化失敗。與復原策略一樣，請定期審查及測試每項預先規劃的程序。

如果您在遷移過程中設定通訊管道，為確保不會遭到環境鎖定，請佈建備份管道，以便在發生故障時復原。舉例來說，如果您要設定 Partner Interconnect，也可以在遷移期間透過公開網際網路設定備份存取權，以防在佈建和設定期間發生任何問題。

規劃翻新及調整工作負載

規劃遷移至 Google Cloud時，請注意，遷移及整合工作負載需要時間，而且可能會遇到挑戰。建議您建立總覽文件，說明工作負載的一般架構，包括下列主題的相關資訊：

  • 對外部系統和第三方中介軟體的依賴，例如儲存空間、訊息和託管。
  • 驗證及授權工作負載的機制。
  • 與 IAM 整合的程序。
  • 執行階段環境的需求條件。
  • 與儲存層選項互動，例如 Cloud Storage 和Google Cloud 資料庫。
  • 資料移轉量和頻寬需求。
  • 您在遷移期間可能對應用程式程式碼進行的變更。
  • 與 Google Cloud Observability 整合的選項。

您可能需要翻新工作負載，例如整合Google Cloud 程式庫，以進行驗證、授權、儲存和觀測。翻新舊版程式庫可能需要付出一些心力。請預留足夠時間，徹底測試工作負載。

規劃漸進式推出和部署

為縮小遷移期間可能發生的問題範圍，請避免大規模變更，並設計遷移計畫，逐步部署變更。例如，規劃逐步部署和設定變更。

如果您打算逐步推出，為了降低因套用變更而導致非預期問題的風險，請盡量減少變更的數量和規模。在第一次小規模推出中找出並解決問題後，您就可以在後續推出中進行更大規模的類似變更。

通知開發和營運團隊

為減少遷移期間可能發生的問題，請通知負責遷移任何工作負載的團隊。此外，也請通知負責來源和目標環境基礎架構的團隊。

如果團隊在不同時區工作，且您採用接力式作業模式，請確保下列事項：

  • 團隊應妥善涵蓋這些時區，並涵蓋多個連續班次，因為他們可能無法在單一班次內解決問題。
  • 您的團隊已準備好收集可能遇到的問題詳細資訊。這份集合可讓下一班的工程師完整瞭解上一班的工作內容和原因。
  • 團隊中的特定人員負責任何指定班次。

從目標正式環境中移除概念驗證資源

在評估過程中，您可能已使用目標環境託管實驗和概念驗證。在遷移之前，請從目標環境的產品領域中，移除您在這些實驗和概念驗證期間建立的所有資源。

在遷移期間，您可以將資源保留在目標環境的非正式環境區域，因為這些資源可能有助於收集遷移期間可能發生的任何問題資訊。舉例來說，如要診斷遷移後影響正式環境工作負載的問題，您可以比較正式環境工作負載的設定和資料記錄，以及概念驗證和實驗的設定和資料記錄。

完成遷移並確認目標環境正常運作後，即可刪除目標環境非正式環境區域中的資源。

定義安全停用來源環境的條件

為避免無限期執行兩個環境的成本，請定義必須符合哪些條件，才能安全地淘汰來源環境，例如：

  • 所有工作負載 (包括備份、高可用性和災難復原機制) 都已成功遷移至目標環境。
  • 遷移至目標環境的資料一致、可存取且可用。
  • 遷移資料的準確性和完整性符合定義的標準。
  • 留在來源環境中的資源，並非遷移範圍外工作負載的依附元件。
  • 工作負載在目標環境中的效能符合服務水準協議目標。
  • 監控系統回報，來源環境中沒有任何網路流量應導向目標環境。
  • 工作負載在目標環境中順利執行一段時間 (由您定義) 後，您確信不再需要復原至來源環境。

規劃更新所有文件和資訊主頁

完成遷移後，請全面更新正式環境作業手冊、支援文件和監控資訊主頁。您可能需要對文件進行的變更包括下列項目：

  • 架構圖：更新架構圖，反映 Google Cloud 架構，尤其是翻新及重構工作負載時。
  • 連線和驗證：更新驗證方式 (例如 IAM) 和網路設定的說明文件，以反映 Google Cloud 架構。
  • 安全性：更新說明Google Cloud 安全性功能的說明文件，包括靜態和傳輸中資料加密，以及以 IAM 為基礎的存取控管。
  • 維護和擴充：更新正式環境作業指南，說明代管服務維護期間、垂直和水平擴充程序，以及效能最佳化的最佳做法。
  • 高可用性和容錯移轉：更新說明文件，說明高可用性設定、區域和可用區同步考量，以及容錯移轉機制。
  • 備份與復原：更新備份與復原程序，使其與 Google Cloud 和備份和災難復原 (DR) 服務支援的程序一致。這些程序包括自動備份、時間點復原可能性，以及匯出和匯入程序。
  • 災難復原：更新災難復原計畫和程序，使其與 Google Cloud 的災難復原功能保持一致，然後測試更新後的程序。
  • 監控和記錄：將 Google Cloud Observability 整合至監控資訊主頁和警告系統。更新 Cloud Quotas 說明文件，並指定如何解讀記錄、指標和警告。

作業

為了在遷移期間有效管理來源環境和目標環境，您也需要設計作業程序。

監控環境

如要觀察來源和目標環境的行為，並在發生問題時協助診斷，請設定下列項目：

  • 監控系統，用於收集對您的情境有用的指標。
  • 記錄系統，用於觀察工作負載和環境其他元件執行的作業流程。
  • 在問題發生前發出警告的警示系統。

Google Cloud Observability 支援Google Cloud 環境的整合式監控、記錄和警告功能。

由於工作負載及其依附元件會跨越多個環境，您可能需要考慮針對不同環境使用多個監控和警告工具。請考量遷移支援工作負載的監控和警告政策的時間點。舉例來說，如果來源環境設為在特定伺服器停機時發出警告，則當您刻意關閉該伺服器時，就會觸發警告。警告觸發條件符合預期，但行為不具實用性。在遷移過程中，您需要持續調整來源環境的警告，並為目標環境重新設定警告。

管理遷移作業

如要管理遷移作業，請查看遷移作業的成效，收集可在遷移作業完成後用於回顧的資訊。收集資訊後，您可以使用這些資訊分析遷移成效，並準備資料點，瞭解環境有哪些潛在改善空間。

舉例來說，如要開始規劃管理遷移作業，請思考下列問題：

  • 遷移計畫的每個步驟需要多少時間？
  • 遷移計畫中是否有任何步驟花費的時間比預期長？
  • 是否有任何遺漏的步驟或檢查？
  • 遷移期間是否發生任何不良事件？

後續步驟

貢獻者

作者：Marco Ferrari | 雲端解決方案架構師

其他貢獻者：Alex Cârciu | 解決方案架構師