本文可協助您規劃、設計及實作遷移至 Google Cloud的評估階段。探索您的工作負載和服務清單並對應其依附元件，有助於您瞭解必須遷移的項目和遷移順序。規劃及設計 Google Cloud遷移作業時，您必須先深入瞭解目前的環境，以及要遷移的工作負載。
本文是下列多部分系列文章的一部分，這些文章說明如何遷移至Google Cloud：
- 遷移至 Google Cloud：開始使用
- 遷移至 Google Cloud：評估及探索工作負載 (本文)
- 遷移至 Google Cloud：規劃及建立基礎
- 遷移至 Google Cloud：轉移大型資料集
- 遷移至 Google Cloud：部署工作負載
- Migrate to Google Cloud：從手動部署遷移至自動化容器化部署
- 遷移至 Google Cloud：將環境調整至最佳狀態
- 遷移至 Google Cloud：驗證遷移計畫的最佳做法
- 遷移至 Google Cloud：盡量降低成本
以下是遷移流程圖。
不管您打算從內部部署環境、私人託管環境或其他雲端服務供應商遷移至 GCP，或是正在評估遷移的可能性，並想瞭解評估階段的可能情況，本文都可助您一臂之力。
在評估階段，您必須確定將來源環境遷移至 Google Cloud時的需求和依附元件。
評估階段是您能否成功遷移的關鍵。您必須深入瞭解要遷移的工作負載、工作負載的要求和依附元件，以及您目前的環境。此外，您還必須知道要從何踏出第一步，以成功規劃並執行 Google Cloud遷移作業。
評估階段包含下列工作：
- 建立工作負載的完整清單。
- 根據工作負載的屬性和依附元件將其編目。
- 訓練並教導您的團隊使用 Google Cloud。
- 在 Google Cloud上建立實驗和概念驗證。
- 計算目標環境的總持有成本 (TCO)。
- 選擇工作負載的遷移策略。
- 選擇遷移工具。
- 定義遷移計畫和時程。
- 驗證遷移計畫。
建立工作負載清單
如要劃定遷移範圍，您必須先瞭解目前環境中的項目數量 (例如工作負載和硬體設備) 及其依附元件。建立清單是需要耗費大量心力的大工程，在沒有自動編目系統的情況下更是如此。如要建立鉅細靡遺的清單，您必須找來負責目前環境中各個工作負載以及環境本身的設計、規劃和營運事宜的團隊，並利用他們的專業知識。
這份清單不應僅限於工作負載，而至少要包含下列內容：
- 各項工作負載的依附元件，例如資料庫、訊息代理程式、設定儲存系統和其他元件。
- 支援工作負載基礎架構的服務，例如來源存放區、持續整合和持續部署 (CI/CD) 工具，以及構件存放區。
- 伺服器 (虛擬或實體) 和執行階段環境。
- 實體設備，例如網路裝置、防火牆和其他專用硬體。
編列這份清單時，您還應收集各個項目的相關資訊，包括：
- 原始碼位置，以及您是否能修改這個原始碼。
- 執行階段環境中工作負載的部署方法，例如您使用的是自動化部署管道還是手動部署管道。
- 網路限制或安全性要求。
- IP 位址規定。
- 您如何向用戶端公開工作負載。
- 任何軟體或硬體的授權要求。
- 工作負載如何驗證身分和存取權管理系統。
舉例來說，針對每個硬體設備，您應該要知道其詳細規格，例如名稱、供應商、技術，以及與清單中其他項目的相依性。例如：
- 名稱：NAS 設備
- 供應商和型號：供應商 Y，型號 Z
- 技術：NFS，iSCSI
- 依附元件：透過支援巨型封包的網路連線至 VM 運算硬體。
這份清單也應包含非技術性資訊，例如您是根據那些授權條款獲准使用各個項目，以及任何其他法規遵循要求。有些授權可讓您在雲端環境中部署工作負載，有些則明確禁止雲端部署行為。有些授權是根據使用中的 CPU 或通訊端數量指派的，而在透過雲端技術執行時，這些概念可能不適用。某些資料可能對儲存地理地區有所限制。最後，部分機密性質的工作負載可能需要單獨租用。
除了清單以外，針對所收集的資料提供視覺輔助也很有幫助。舉例來說，您可以提供依附元件圖表來凸顯值得關注的面向，例如有多少工作負載採自動化部署流程或採手動部署流程。
如何建立清單
建立工作負載清單的方法有很多種。如要踏出第一步，最快的方法是手動進行，但對於大型實際工作環境而言，這種做法恐怕窒礙難行。手動建立的清單中所含的資訊可能很快就會過時，這樣可能會導致遷移作業因未確認清單內容而失敗。
清單可不是建立完就好了。如果您目前的環境極為動態，您也應設法將清單建立和維護作業自動化，這樣最終才能隨時對環境中的所有項目有一致的掌握。如要瞭解如何建立工作負載的商品目錄，請參閱「Migration Center：開始資產探索」一文。
工作負載清單範例
以下是支援某電子商務應用程式的環境中所含項目的清單。這份清單包含工作負載、依附元件、支援多個工作負載的服務，以及硬體設備。
工作負載
針對環境中的每個工作負載，下表都特別列出了最重要的技術、其部署程序及其他要求。
| 名稱 | 原始碼位置 | 技術 | 部署程序 | 其他要求 | 依附元件 | 系統資源要求 |
|---|---|---|---|---|---|---|
| 行銷網站 | 企業存放區 | Angular 前端 | 自動 | 法務部門必須驗證內容 | 快取服務 | 5 個 CPU 核心 8 GB RAM |
| 後端 | 企業存放區 | Java 後端，Angular 前端 | 自動 | 無 | SQL 資料庫 | 4 個 CPU 核心 4 GB RAM |
| 電子商務工作負載 | 專屬工作負載 | 供應商 X 型號 Y 1.2.0 版 |
手動 | 客戶資料必須位於歐盟境內 | SQL 資料庫 | 10 個 CPU 核心 32 GB RAM |
| 企業資源規劃 (ERP) | 專屬工作負載 | 供應商 Z，型號 C，7.0 版 | 手動 | 無 | SQL 資料庫 | 10 個 CPU 核心 32 GB RAM |
| 無狀態微服務 | 企業存放區 | Java | 自動 | 無 | 快取服務 | 4 個 CPU 核心 8 GB RAM |
依附元件
下表是清單中所列工作負載的依附元件範例。這些依附元件是工作負載正常運作所需的必要條件。
| 名稱 | 技術 | 其他要求 | 依附元件 | 系統資源要求 |
|---|---|---|---|---|
| SQL 資料庫 | PostgreSQL | 客戶資料必須位於歐盟境內 | 備份和封存系統 | 30 個 CPU 核心 512 GB RAM |
支援的服務
您的環境中可能有支援多個工作負載的服務。這個電子商務範例包含下列服務：
| 名稱 | 技術 | 其他要求 | 依附元件 | 系統資源要求 |
|---|---|---|---|---|
| 原始碼存放區 | Git | 無 | 備份和封存系統 | 2 個 CPU 核心 4 GB RAM |
| 備份和封存系統 | 供應商 G，型號 H，2.3.0 版 | 根據法律規定，部分項目需要長期儲存空間 | 不適用 | 10 個 CPU 核心 8 GB RAM |
| 持續整合工具 | Jenkins | 不適用 | 原始碼存放區 構件存放區 備份和封存系統 |
32 個 CPU 核心 128 GB RAM |
| 成果存放區 | 供應商 A 型號 N 5.0.0 版 |
不適用 | 備份和封存系統 | 4 個 CPU 核心 8 GB RAM |
| 批次處理服務 | 在持續整合工具中執行的 Cron 工作 | 無 | 持續整合工具 | 4 個 CPU 核心 8 GB RAM |
| 快取服務 | Memcached Redis |
不適用 | 不適用 | 12 個 CPU 核心 50 GB RAM |
硬體
範例環境包含下列硬體設備：
| 名稱 | 技術 | 其他要求 | 依附元件 | 系統資源要求 |
|---|---|---|---|---|
| 防火牆 | 供應商 H 型號 V |
不適用 | 不適用 | 無 |
| 服務器 j 的執行個體 | 供應商 K 型號 B |
由於已不再受支援，因此必須停用 | 無 | 無 |
| NAS 設備 | 供應商 Y 型號 Z NFS iSCSI |
不適用 | 不適用 | 不適用 |
評估部署和作業流程
請務必清楚瞭解部署和作業程序的運作方式。這些程序是準備及維護實際工作環境和在其中執行的工作負載的做法中，不可或缺的部分。
您的部署和作業程序可能會建構工作負載運作所需的構件。因此，您應收集各個構件類型的相關資訊。例如，構件可以是作業系統套件、應用程式部署套件、作業系統映像檔、容器映像檔或其他項目。
除了定義構件類型之外，請考慮如何完成下列工作：
- 開發工作負載。評估開發團隊建構工作負載的程序。舉例來說，您的開發團隊如何設計、編寫程式碼及測試工作負載？
- 產生要在來源環境中部署的構件。如要在來源環境中部署工作負載，您可能會產生可部署的構件，例如容器映像檔或作業系統映像檔，或者您可能會透過安裝及設定軟體，自訂現有構件，例如第三方作業系統映像檔。收集您產生這些構件的相關資訊，有助於確保產生的構件適合在Google Cloud中部署。
儲存成果。如果您產生的構件儲存在來源環境的構件登錄中，就必須在 Google Cloud 環境中提供構件。您可以採用下列策略來達成這點：
- 建立環境之間的通訊管道：讓來源環境中的構件可從目標Google Cloud 環境存取。
- 重構構件建構程序：完成來源環境的次要重構，以便在來源環境和目標環境中儲存構件。這種方法會在您必須在目標 Google Cloud環境中實作構件建構程序之前，先建構構件存放區等基礎架構，以便支援遷移作業。您可以直接實作這項做法，也可以先建立溝通管道，再實作這項做法。
在來源和目標環境中都提供構件，可讓您專注於遷移作業，而無須在目標 Google Cloud 環境中實作構件建構程序。
掃描並簽署程式碼。在建構過程中，您可能會使用程式碼掃描功能來防範常見的安全漏洞和意外曝露的網路，並使用程式碼簽署功能，確保環境中只執行可信任的程式碼。
在來源環境中部署構件。產生可部署的構件後，您可能會在來源環境中部署這些構件。建議您評估每個部署程序。這項評估有助於確保您的部署程序與 Google Cloud相容。這也有助您瞭解最終重構程序所需的努力程度。舉例來說，如果您的部署程序只適用於來源環境，您可能需要重構這些程序，以便指定 Google Cloud 環境。
插入執行階段設定。您可能會為特定叢集、執行階段環境或工作負載部署作業，注入執行階段設定。設定可能會初始化環境變數和其他設定值，例如機密資料、憑證和金鑰。為確保您的執行階段設定注入程序可在 Google Cloud上運作，建議您評估如何設定在來源環境中執行的工作負載。
記錄、監控和分析。評估您用來監控來源環境健康狀態、感興趣的指標，以及如何使用這些程序提供的資料的記錄、監控和剖析程序。
驗證：評估您如何在來源環境中進行驗證。
佈建及設定資源。為準備來源環境，您可能已設計及實作佈建及設定資源的程序。舉例來說，您可能會使用 Terraform 搭配設定管理工具，在來源環境中佈建及設定資源。
評估基礎架構
評估部署和作業程序後，建議您評估在來源環境中支援工作負載的基礎架構。
如要評估基礎架構，請考量以下事項：
- 您如何在來源環境中整理資源。舉例來說，某些環境支援使用結構定義，將資源群組與其他資源分開，例如機構、專案和命名空間，藉此邏輯上分隔資源。
- 您如何將環境連結至其他環境，例如地端環境和其他雲端服務供應商。
將工作負載分類
完成清單後，您必須將工作負載分門別類，以便根據工作負載的複雜度和遷移至雲端的風險，決定遷移優先順序。
在目錄矩陣中，您應該要針對考量的各個環境評估標準，分別新增一個維度。選擇一組能涵蓋所有環境要求的標準，包括每個工作負載所需的系統資源。舉例來說，您可能想知道工作負載是否有任何依附元件，或其為無狀態或有狀態。在設計目錄矩陣時，請考慮到每新增一個標準，就要新增另一個維度代表該標準，這樣產生的矩陣可能難以視覺化呈現。如要解決這個問題，一個可能的方法是使用多個較小的矩陣，而非使用一個複雜的矩陣。
此外，您應該要在每個工作負載旁邊加上遷移複雜度指標，用來預估每項工作負載的遷移難度等級。這個指標的精細程度取決於您的環境。舉一個基本的例子，您可以有下列三種類別：易於遷移、難以遷移或無法遷移。如要完成這項活動，您需要清單中各項目的專家來預估該項目的遷移複雜度。每種業務都有不同的遷移複雜度影響因素。
目錄完成後，您還可以建立視覺效果和圖表，協助您和您的團隊快速評估重要指標。例如，繪製一份圖表來凸顯有依附元件的元件數量，或各個元件的遷移難度。
如要瞭解如何建立工作負載的商品目錄，請參閱「Migration Center：開始資產探索」。
工作負載目錄範例
以下是這個範例使用的評估標準，每個矩陣軸分別代表一個標準：
- 工作負載對業務的重要程度。
- 工作負載是否有依附元件，或是否為其他工作負載的依附元件。
- 工作負載的允許停機時間上限。
- 工作負載的遷移難度。
| 對業務的重要性 | 沒有依附元件或附屬項目 | 具有依附元件或附屬項目 | 允許的停機時間上限 | 難度 |
|---|---|---|---|---|
| 對任務至關重要 | 無狀態微服務 | 2 分鐘 | 容易 | |
| 企業資源規劃 | 24 小時 | 困難 | ||
| 電子商務工作負載 | 無停機時間 | 困難 | ||
| 硬體防火牆 | 無停機時間 | 無法遷移 | ||
| SQL 資料庫 | 10 分鐘 | 容易 | ||
| 原始碼存放區 | 12 小時 | 容易 | ||
| 對任務沒那麼重要 | 行銷網站 | 2 小時 | 容易 | |
| 備份與封存 | 24 小時 | 容易 | ||
| 批次處理服務 | 48 小時 | 容易 | ||
| 快取服務 | 30 分鐘 | 容易 | ||
| 後端 | 48 小時 | 困難 | ||
| 持續整合工具 | 24 小時 | 容易 | ||
| 成果存放區 | 30 分鐘 | 容易 |
您可以建立視覺效果和圖表，在目錄中視覺化呈現結果。以下是遷移難度圖表：
在上圖中，大部分的工作負載都易於遷移，其中三個難以遷移，而其中一個無法遷移。
協助機構瞭解 Google Cloud
如要充分利用 Google Cloud，貴機構必須開始瞭解貴商家可在 Google Cloud上使用的服務、產品和技術。您的員工可從Google Cloud 免費試用帳戶開始，這類帳戶提供抵免額，可協助他們動手實驗和學習。建立免費的測試和學習環境對於員工的學習體驗至關重要。
您有下列幾種訓練選項：
- 公開和開放式資源：您可以透過免費的實作研究室、系列影片、Cloud OnAir 網路研討會和 Cloud OnBoard 訓練活動，開始學習使用Google Cloud 。
- 深入課程：如要進一步瞭解Google Cloud 的運作方式，您可以參加 Google Cloud Skills Boost 的隨選課程或 Google Cloud Coursera 的專題訓練課程，後者有兩種參加方式，一種是在線上依個人步調參加，另一種是參加世界各地 Google 授權訓練合作夥伴舉辦的現場訓練。這些課程通常為期一天到數天。
- 依角色進行學習：您可以根據工程師在機構中的角色進行訓練。舉例來說，您可以訓練工作負載開發人員或基礎架構作業人員，充分利用 Google Cloud 服務。
您也可以透過各種不同層級的認證，證明工程師具備 Google Cloud 的相關知識：
- 副認證：Google Cloud 新手可以此為出發點，繼續取得其他專業認證，例如雲端助理工程師認證。
- 專業認證：如要評估自己從多年經驗中汲取的 Google Cloud 進階設計與實作技能，您可以取得專業雲端架構師或專業資料工程師等認證。
- Google Workspace 認證：您可以透過 Google Workspace 認證，證明自己具備使用 Google Workspace 工具協同合作的技能。
- Apigee 認證：您可以透過 API 工程師認證，證明自己有能力設計及開發完善、安全且可擴充的 API。
- Google 開發人員認證：您可以透過 Android 助理開發人員 (此認證正在更新) 和行動網路專家認證，證明自己具備開發技能。
除了訓練和認證之外，獲取 Google Cloud 相關經驗的最佳方式之一，就是開始使用這項產品打造企業概念驗證。
實驗和設計概念證明
為了展現 Google Cloud的價值和功用，建議您為工作負載目錄中的各個工作負載類別設計並發展一或多個概念驗證 (PoC)。實驗和測試可讓您驗證假設，並向企業領導者證明雲端的價值。
PoC 至少應包含下列項目：
- 完整的工作負載適用情況清單 (包括罕見情況和極端情況)。
- 各種適用情況的所有要求，例如效能、可擴充性和一致性要求、容錯移轉機制，以及網路要求。
- 可能要調查和測試的技術和產品清單。
您應該設計 PoC 和實驗來驗證清單中的所有適用情況。每項實驗都應有精確的驗證脈絡、範圍、預期輸出，以及可評估的業務影響。
舉例來說，如果某個受 CPU 限制的工作負載需要快速自動調度資源以滿足需求高峰，您可以執行實驗，檢驗某個區域是否能建立許多虛擬 CPU 核心，以及建立這些核心所需的時間。如果有顯著的額外優勢 (例如相較於目前的環境，新工作負載向上擴充時間減少了 95%)，表示這可為企業帶來立竿見影的效果。
如要比較內部部署資料庫和 Cloud SQL、Spanner、Firestore 或 Bigtable 的效能，您可以實作一個 PoC，其中相同企業邏輯使用不同資料庫。這個 PoC 可讓您以低風險的方式，根據多項基準和營運成本找出適合您工作負載的代管資料庫解決方案。
如要評估Google Cloud中 VM 佈建流程的效能，您可以使用 PerfKit Benchmarker 等第三方工具，並將 Google Cloud 與其他雲端供應商進行比較。除了回報尖峰效能的標準指標 (包括延遲時間、總處理量和完成所需時間)，您還可評估在雲端佈建資源所需的端對端時間。舉例來說，您可能想知道佈建許多 Kubernetes 叢集所需的時間和心力。PerfKit Benchmarker 是開放原始碼社群的心血結晶，由各研究人員、學術機構和公司 (包括 Google) 等超過 500 位參與者協力打造而成。
計算總擁有成本
清楚掌握新環境中所需的資源後，您可以建立總擁有成本模型，以便比較 GCP 的費用和目前環境的費用。 Google Cloud
建立這類成本模型時，不只要考量硬體和軟體的成本，還要考慮維持資料中心運作的所有營運成本，包括電力、散熱、維護和其他支援服務的費用。另外要考慮到Google Cloud 資源能夠彈性擴充，因此與較沒有彈性的內部部署資料中心相比，雲端環境通常較容易降低成本。
考慮雲端遷移作業時，一個經常被忽略的成本是雲端網路的使用費用。在資料中心，您只須付費一次即可購入網路基礎架構 (例如路由器和交換器) 並讓適當的網路線維持運作，進而使用網路的完整功能。在雲端環境中，您可能要基於許多因素支付網路使用費。如果是資料密集型工作負載，或會產生大量網路流量的工作負載，您可能得考慮新的架構和網路流程，以降低雲端環境的網路成本。
Google Cloud 也提供各種聰明的資源與成本調度選項。舉例來說，如要在 Compute Engine 中調整成適當規模，您可以在遷移期間使用 Migrate for Compute Engine，或在 VM 開始執行後進行調整，或是建構可自動調度資源的執行個體群組。這些選項可能會對服務運作成本有顯著影響，在計算總持有成本時應納入考量。
如要計算 Google Cloud 資源的總成本，您可以使用價格計算工具。
為工作負載選擇遷移策略
針對每個要遷移的工作負載，評估並選取最適合其用途的遷移策略。舉例來說，工作負載可能具有下列條件：
- 這些工作負載不允許任何停機或資料遺失情形，例如任務關鍵工作負載。針對這類工作負載，您可以選擇零停機或幾乎零停機的遷移策略。
- 可容許停機時間，例如次要或後端工作負載。針對這些工作負載，您可以選擇需要停機的遷移策略。
選擇遷移策略時，請考量到零停機和近乎零停機的遷移策略，通常比需要停機的遷移策略，在設計和實施上更為昂貴且複雜。
選擇遷移工具
為工作負載選擇遷移策略後，請查看並決定遷移工具。
市面上有許多遷移工具，每個工具都針對特定遷移用途進行最佳化。用途包括：
- 遷移策略
- 來源和目標環境
- 資料和工作負載大小
- 資料和工作負載變更的頻率
- 是否可使用代管服務進行遷移
為確保無縫遷移和切換，您可以使用應用程式部署模式、基礎架構協調作業，以及自訂遷移應用程式。不過，專門的工具 (稱為受管理的遷移服務) 可協助您將資料、工作負載，甚至整個基礎架構從一個環境移至另一個環境。這些功能可封裝複雜的遷移邏輯，並提供遷移監控功能。
定義遷移計畫和時程
您已對目前的環境有充分的瞭解，接著必須選擇應用程式的初始遷移順序，以完成您的遷移計畫。
- 將要遷移的工作負載和資料分組成批次 (在某些情況下也稱為衝刺階段)。
- 選擇要依照哪個順序遷移批次。
- 選擇要以何種順序遷移各批次內的工作負載。
建議您在遷移計畫中一併產生下列文件：
- 技術設計文件
- RACI 矩陣
- 時間表 (例如 T-Minus 計畫)
隨著您對 Google Cloud的使用經驗、遷移進度，以及對環境的瞭解程度增加，您可以執行下列操作：
- 精進要遷移的工作負載和資料分組。
- 增加遷移批次的大小。
- 更新遷移批次和批次內工作負載的順序。
- 更新批次的組合。
如要將工作負載和資料分組，以便分批遷移，並定義遷移順序，您必須根據多項條件評估工作負載，例如：
- 工作負載的業務價值。
- 與基礎架構的其他元件相比，工作負載是否採獨特的部署或執行方式。
- 負責開發、部署及維持工作負載運作的團隊。
- 工作負載的依附元件數量、類型和範圍。
- 要花多少心力進行重構，才能讓工作負載在新環境中運作。
- 工作負載的法規遵循和授權需求。
- 工作負載的可用性和可靠性需求。
您應該要先遷移能讓團隊獲得 Google Cloud相關知識和經驗的工作負載。讓團隊多加接觸雲端環境並汲取相關經驗，有助於降低在實際遷移階段中出錯的風險，並讓相關人員更輕鬆快速進行後續的遷移作業。因此，選擇適當的首批遷移項目是遷移能否成功的關鍵。
創造業務價值
選擇對業務沒那麼重要的工作負載可保護您的主要業務線，並在團隊學習雲端技術時，降低未發現的風險和錯誤對業務造成的影響。舉例來說，如果所選元件的電子商務工作負載主要金融交易邏輯是首批遷移項目，則遷移過程中發生的任何錯誤都可能會導致主要業務線受到影響。較好的選擇是先遷移支援工作負載的 SQL 資料庫 (暫存資料庫更佳)。
請避免選擇少用的負載。舉例來說，如果您選擇一年只有幾位使用者會用幾次的工作負載，雖然遷移風險很低，但無助於提升遷移動能，而且可能會難以偵測出問題並做出因應。
極端案例
您也應該要避免選擇極端案例，這樣才能找出適用於其他待遷移工作負載的模式。選擇首批遷移項目時的一個主要目標，是要透過機構中的常見模式汲取經驗，以便打造一個知識庫。日後遷移其他工作負載時，就能應用透過這些首批遷移項目學到的知識。
舉例來說，如果大部分的工作負載都是依據測試驅動式開發方法論設計，並使用 Python 程式設計語言進行開發，那麼如果您選擇使用 Java 程式設計語言開發且測試涵蓋率不高的作業負載，就無法發現任何可在遷移 Python 作業負載時套用的模式。
團隊
選擇首批遷移項目時，請留意各工作負載的負責團隊。首批遷移項目的負責團隊應該要充滿幹勁，積極想試用 GCP 及其服務。 Google Cloud 此外，企業領導階層應該要為首批遷移項目負責團隊訂立明確的目標，並在整個過程中主動設法提供協助和支持。
舉例來說，建議您選擇總公司裡曾實作過DevOps等現代開發做法，並對網站穩定性工程等領域有相關經驗的高績效團隊。如果這個團隊還有由上對下發號施令的領導階層，並對每個工作負載遷移作業都訂有明確目標，那就再適合不過。
依附元件
此外，您應該要專注在依附元件數量最少的工作負載 (無論依附元件是其他工作負載或服務)。如果您對 Google Cloud的使用經驗有限，遷移無依附元件的工作負載會比較簡單。
如果您必須選擇依賴其他元件的工作負載，請挑選與依附元件的連結較鬆散的工作負載。如果工作負載在最終無法使用其依附元件時也仍可運作，就能更順利地遷移至目標環境。舉例來說，如果工作負載是使用訊息代理程式進行通訊、或可離線運作，或可容忍無法使用基礎架構其他元件的情形，就屬於連結鬆散的工作負載。
雖然有遷移有狀態工作負載資料的策略，但無狀態工作負載幾乎不必遷移任何資料。遷移無狀態工作負載可能比較簡單，因為您不必擔心在目前環境和目標環境中各有一部分資料的過渡階段。舉例來說，無狀態微服務不需要任何本機有狀態資料，因此適合做為首批遷移項目。
重構
首批遷移項目應只需經過最低限度的重構，這樣您就能專注在遷移作業本身和 Google Cloud上，而不是花費大量心力變更程式碼和工作負載的設定。重構應著重可讓工作負載在目標環境中運作的必要變更，而非對工作負載進行革新和最佳化 (這類作業是在後期遷移階段進行)。
舉例來說，只需變更設定的工作負載很適合做為首批遷移項目，因為您不必對程式碼集進行任何變更，並可使用現有成果。
授權和法規遵循
在選擇首批遷移項目的過程中，授權也扮演重要的角色，因為某些工作負載適用的授權條款可能會影響遷移作業。例如，某些授權明確禁止在雲端環境中執行工作負載。
檢查授權條款時，別忘了法規遵循要求，因為部分工作負載可能有單獨租用要求。基於上述原因，您應該選擇授權和法規遵循限制最少的工作負載做為首批遷移項目。
舉例來說，您的客戶可能具有選擇資料儲存地區的法定權利，或客戶的資料可能受限於特定地區。
可用性和穩定性
如果應用程式可承受轉換期造成的停機時間，就很適合做為首批遷移項目。如果您選擇的工作負載有嚴格的可用性要求，就必須實作 Y (寫入和讀取) 等零停機時間資料遷移策略，或開發資料存取微服務。這種做法雖然可行，但會使團隊必須花時間實作這類策略，而無法專心獲得必要的 Google Cloud相關經驗。
舉例來說，相較於使用者用於完成交易的電子商務網站客戶專用工作負載，批次處理引擎的可用性要求允許其承受較長的停機時間。
驗證遷移計畫
建議您在採取行動開始遷移計畫前，先驗證其可行性。詳情請參閱「驗證遷移計畫的最佳做法」。
後續步驟
- 瞭解如何規劃遷移作業並在 Google Cloud上建立基礎。
- 瞭解何時應尋求遷移作業相關協助。
- 如需更多參考架構、圖表和最佳做法，請瀏覽 雲端架構中心。
貢獻者
作者：Marco Ferrari | 雲端解決方案架構師