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

Last reviewed 2025-05-05 UTC

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

如果您打算從內部部署環境、私人代管環境或其他雲端服務供應商遷移至 Google Cloud，如果您正在評估遷移的可能性，並想瞭解遷移的預期情況，本文件也能提供實用的參考資料。

本文是下列多部分系列文章之一，探討如何遷移至Google Cloud：

評估

全面評估工作負載和環境，有助於深入瞭解工作負載和環境。瞭解這些事項有助於盡量降低遷移至 Google Cloud期間和之後發生問題的風險。

進行完整評估

請先評估工作負載和環境，再繼續進行評估階段後的步驟。如要進行完整評估，請考慮以下經常遭到忽略的項目：

  • 清查：請確保要遷移的工作負載清單為最新版本，並完成評估。舉例來說，請考量評估的來源資料是否夠新且可靠，以及資料中可能存在哪些缺口。

  • 停機時間：找出可處理停機時間的工作負載。請判斷這些停機時間的發生時機和持續時間，盡量減少中斷情況，例如在深夜或週末。如果工作負載可容許停機，遷移作業會比停機時間為零或接近零的工作負載簡單。如要完成零停機遷移，您必須為要遷移的每個工作負載設計及實作備援機制。您也需要協調這些多餘的執行個體。

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

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

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

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

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

瞭解工作負載在特殊情況下的行為，有助於確保工作負載不會暴露在無法復原的狀況下。在評估過程中，請收集工作負載支援的故障模式及其影響，以及工作負載可自動復原的故障模式，並找出需要您介入的故障模式。舉例來說，您可以先思考可能發生的故障模式，例如：

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

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

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

評估資料處理管道

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

  • 資源大小是否適合遷移？
  • 遷移工作負載所需資料需要多少時間？
  • 目標環境是否能容納所有資料？
  • 當工作負載必須因應需求或資料量在特定時間範圍內暴增時，會出現什麼情況？
  • 如果工作負載產生的資料量或需求量突然暴增，是否會造成負面影響，例如延遲時間變長或回應延遲？
  • 工作負載啟動後，是否需要一段時間才能達到預期效能水準？

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

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

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

遷移作業可能包含您無法套用及部署變更的工作負載，例如預先存在且現成的軟體。在這種情況下，請重構遷移計畫，考慮額外的工作量，以減輕遷移這些工作負載後可能發生的問題。

評估網路基礎架構

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

為避免遷移期間發生問題，請務必評估網路基礎架構，並判斷基礎架構可支援的遷移程度。舉例來說，您可以先考慮有關負載平衡基礎架構的問題，例如：

  • 重新設定負載平衡器會有什麼影響？
  • 更新設定後，需要多久才會生效？
  • 如果更新設定前流量突然暴增，零停機時間遷移作業會發生什麼情況？

考量負載平衡基礎架構相關問題後，接下來請思考 DNS 基礎架構相關問題，例如：

  • 您應更新哪些 DNS 記錄，將其指向目標環境？又該何時更新？
  • 哪些用戶端正在使用這些 DNS 記錄？
  • 您打算更新的 DNS 記錄，其存留時間 (TTL) 設定為何？
  • 執行遷移作業前，能否將 DNS 記錄的存留時間設為最短秒數？
  • 您的 DNS 用戶端和中介程式是否會採用您打算更新的 DNS 記錄 TTL？舉例來說，您的應用程式是否具有用戶端 DNS 快取，會忽略您為遷移作業設定的 TTL？請注意，DNS 解析涉及多個快取層。建議使用 Google 公用 DNS，避免發生網際網路服務供應商 (ISP) DNS 問題。
  • DNS 用戶端是否會採用 DNS 記錄的存留時間來更新？舉例來說，您的應用程式是否具有用戶端 DNS 快取功能，會忽略您為遷移作業設定的 TTL？
  • 完成遷移作業後，您是否仍偵測到導向來源環境的流量？

考慮建立概念驗證

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

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

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

如要調查感興趣的下列領域，請考慮建立 POC：

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

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

規劃遷移作業

妥善規劃遷移作業有助於避免遷移期間和之後發生問題。此外，規劃也有助於避免處理意料之外的工作。

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

在遷移過程中，您執行的遷移計畫步驟可能會導致意料之外的問題。為確保您能從這些問題中復原，請為遷移計畫的每個步驟準備復原策略。為避免在服務中斷期間浪費時間，請採取下列行動：

  • 定期檢查及測試各項復原策略，確保復原策略正常運作。
  • 為每個遷移步驟設定允許的最長執行時間。超過允許的執行時間後，團隊就會開始回溯遷移步驟。

即使您已為遷移計畫的每個步驟準備好回溯策略，部分步驟仍可能造成中斷。即使回溯，可能造成中斷的步驟仍可能導致某種損失，例如資料遺失。評估遷移計畫中可能造成中斷的步驟。

如果您自動執行遷移計畫的任何步驟，請確保已預先規劃每個自動化步驟的程序，以防自動化作業失敗。與復原策略相同，請定期檢查並測試每個預先規劃的程序。

如果您在遷移過程中設定了通訊管道，請佈建備用管道，以確保不會無法存取環境，並在發生故障時用於復原。舉例來說，如果您要設定合作夥伴互連，在遷移期間也可以透過公用網際網路設定備份存取權，以防在佈建和設定期間發生任何問題。

規劃如何翻新及調整工作負載

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

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

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

規劃漸進式推出和部署

為減少遷移期間可能發生的問題，請避免大規模變更，並設計遷移計畫，逐步部署變更。舉例來說，您可以規劃逐步部署和設定變更。

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

提醒開發與營運團隊

為減少遷移期間可能發生的問題所造成的影響，請通知負責遷移任何工作負載的團隊。同時提醒負責來源和目標環境基礎架構的團隊。

如果您的團隊位於不同時區，且採用「追日」作業模式，請確保符合下列條件：

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

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

在評估過程中，您可能已使用目標環境來代管實驗和概念驗證。遷移前，請先從目標環境的正式版區域中，移除您在這些實驗和概念驗證期間建立的所有資源。

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

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

定義安全淘汰來源環境的條件

為避免無限期執行兩個環境而產生費用，請定義安全淘汰來源環境的條件，例如：

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

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

遷移完成後，請全面更新生產作業執行手冊、支援文件和監控資訊主頁。您可能需要對說明文件進行下列變更：

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

作業

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

監控環境

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

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

Google Cloud Observability 支援整合式監控、記錄和快訊功能，可供Google Cloud 環境使用。

由於工作負載及其依附元件會跨越多個環境，您可能需要考慮為不同環境使用多種監控和快訊工具。請考慮遷移支援工作負載的監控和警告政策時機。舉例來說，如果來源環境設定為在特定伺服器關閉時發出快訊，當您刻意關閉該伺服器時，系統就會觸發快訊。系統預期會觸發快訊，但這類行為沒有幫助。在遷移過程中，您需要持續調整來源環境的快訊，並重新設定目標環境的快訊。

管理遷移作業

如要管理遷移作業，請查看遷移作業的成效，收集相關資訊，以便在遷移作業完成後進行回顧。收集資訊後，您可以使用這些資訊分析遷移成效，並準備環境潛在改善項目的資料點。

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

  • 遷移計畫的每個步驟各需多少時間？
  • 遷移計畫中是否有任何步驟的完成時間超出預期？
  • 是否缺少任何步驟或檢查？
  • 遷移期間是否發生任何不良事件？

後續步驟

貢獻者

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

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