技術觀點

技術為加速大型遷移提供了良好的基礎。例如，Cloud Migration Factory 解決方案專注於如何提供end-to-end自動化。本節探討使用 技術來達成所需規模和速度的一些最佳實務，並與範圍、策略和時間表保持一致。

首要原則是盡可能查看自動化領域。如果您的範圍內有數千部伺服器，手動執行任務可能是一項昂貴且耗時的工作。

若要執行遷移，通常會使用數種工具，例如：

• 探索

• 遷移實作

• 組態管理資料庫 (CMDB)

• 庫存試算表

• 專案管理

這些工具會在遷移的不同階段使用，從評估到調動，再到實作。這些工具的選擇取決於業務目標和時間表。

規劃遷移階段之後，下一步是確保遷移團隊具備使用所需工具的技能。如果團隊缺乏技能或經驗，請規劃有針對性的培訓，以增加技能集。如果可能，請建立事件，讓團隊可以在安全的環境中獲得遷移工具的經驗。例如，團隊是否可以遷移沙坑或實驗室伺服器來體驗工具？ 或者，初始開發工作負載是否可以用於學習目的？

自動化、追蹤和工具整合

在本節中：

• 自動化遷移探索以減少所需的時間

• 自動化重複性任務

• 自動化追蹤和報告以加速決策

• 探索可促進遷移的工具

自動化遷移探索以減少所需的時間

大多數大型遷移計劃從了解遷移的範圍 （必須遷移的範圍） 和制定策略 （遷移的方式） 開始。探索是其中的重要層面。擷取必要的中繼資料點，以形成遷移策略決策樹。若要快速遷移工作負載，您必須識別所需的遷移中繼資料並將其匯入實作程序，例如遷移工廠。一種完全自動化的機制，可擷取、轉換、載入 (ETL) 遷移中繼資料，大幅減少探索程序中涉及的時間和工作量。

一位客戶為其遷移工廠開發了全自動化的資料輸入程序。具有所有遷移中繼資料的遷移浪潮計劃託管和維護在 Microsoft SharePoint 上的試算表中。對來源進行變更時，會啟動 AWS Lambda 函數，以在無需手動介入的情況下將資料載入遷移工廠。這個自動化的資料輸入程序有助於客戶減少手動工作、盡量減少人為錯誤，並加快速度。他們能夠將超過 1，000 個伺服器遷移至 AWS。

自動化重複性任務

在遷移實作階段，許多小型程序必須經常重複。例如，使用 AWS Application Migration Service (MGN) 時，您必須在遷移範圍內的每個伺服器上安裝代理程式。

建置符合您特定業務和技術需求的遷移工廠，是實現成功進行大型遷移所需的效率和速度最有效的方式。遷移工廠提供整合和協調架構，使用標準化資料集來加速遷移。識別所有任務後，請花時間自動化所有可以自動化的手動任務，以及規範性的 Runbook。

Cloud Migration Factory 解決方案是其中的範例。Cloud Migration Factory 旨在提供遷移自動化基礎，讓您可以自動化組織特有的層面。例如，您可能想要在 CMDB 中更新旗標，以強調現場部署伺服器現在可以停用。在此案例中，您可以建立自動化，在遷移波結束時執行此任務。Cloud Migration Factory 有一個集中式中繼資料存放區，其中包含所有波浪、應用程式和伺服器中繼資料。自動化指令碼可以連線至 Cloud Migration Factory，以取得該波中的伺服器清單，並相應地執行任何動作。Cloud Migration Factory 支援 AWS Application Migration Service。

自動化追蹤和報告以加速決策

我們建議您建置自動化遷移報告儀表板來追蹤和報告即時資料，包括程式的關鍵效能指標 KPIs)。遷移專案涉及來自整個組織的利益相關者，包括下列項目：

• 應用程式團隊

• 測試人員

• 解除委任團隊

• 架構師

• 基礎設施團隊

• 領導

若要執行其角色，這些利益相關者需要即時資料。例如，網路團隊必須知道即將發生的遷移波，以了解對內部部署資源與 之間共用連線的影響 AWS。領導團隊想要了解遷移完成的程度。擁有可靠、自動化的資料即時饋送可防止通訊錯誤，並提供可做出決策的基礎。

一位大型醫療保健客戶正在努力結束資料中心的出口，且截止日期即將到來。鑑於規模和複雜性，最初花了大量時間在追蹤和溝通利益相關者之間的遷移狀態。遷移團隊後來使用 Amazon QuickSight 建置自動化儀表板，以視覺化資料，大幅簡化追蹤和通訊，同時提高遷移速度。

探索可促進遷移的工具

為您的遷移選擇正確的工具並不容易，特別是如果您組織中沒有人之前管理過大型遷移。

建議您花時間選擇合適的工具以支援遷移。此探勘可能涉及授權成本，但當您考慮更廣泛的計畫時，它可以提供成本效益。或者，您可能會發現內嵌在組織中的工具可提供類似的結果。例如，您可能已在資產中部署應用程式效能監控工具，以提供豐富的探索資訊。

由於缺乏熟悉度，技術客戶最初在遷移期間不願意執行自動探索工具。因此，SI AWS 合作夥伴必須為每個應用程式執行 5 到 10 小時的會議，以手動探索資產，包括伺服器名稱、作業系統版本和相依性。據估計，如果已使用探索工具，探索工作可能會減少超過 1，000 小時。

先決條件和遷移後驗證

在本節中：

• 在遷移前階段期間建置登陸區域

• 概述先決條件活動

• 實作遷移後檢查以持續改進

在遷移前階段期間建置登陸區域

我們建議您提前建置 AWS 目標環境或登陸區域，而不是在遷移波段期間建置目標虛擬私有雲端 (VPCs) 和子網路。建置架構良好的登陸區域是遷移的先決條件。登陸區域應包含監控、控管、操作和安全控制。

在遷移之前建置和驗證登陸區域，可最大限度地減少在新環境中執行工作負載所帶來的不確定性。建立登陸區域後，利益相關者可以專注於遷移工作負載，而不必擔心帳戶或 VPC 層級管理的層面。

概述先決條件活動

除了登陸區域之外，請務必在遷移之前調整其他技術先決條件，特別是具有較長前置時間的程序。例如，進行必要的防火牆變更，以允許從內部部署複寫資料 AWS。及早溝通技術先決條件有助於準備和配置所需的資源。因為尚未符合先決條件，所以遷移至停滯的情況很常見。這不僅會影響進行中的遷移波，還可能會在問題正在修復時推回所有未來遷移的日期。

旨在執行大量遷移的金融服務公司 AWS，目標是要清空數個資料中心。不過，其頻寬在內部部署和 之間可用 AWS ，不足以達到預期的速度。不幸的是，增加頻寬需要新的連線，而且前置時間為三個月。這表示前三個月的遷移速度受到限制。

實作遷移後檢查以持續改進

最後，請記得實作遷移後驗證，例如操作整合、成本最佳化，以及控管和合規檢查。遷移後驗證包括評估先前遷移的工作負載，以探索應套用到未來波浪的技術經驗。

此外，這是實作成本控制操作的絕佳機會。例如，在遷移期間，您可能會決定將 AWS 執行個體的大小與現場部署資產相符，以減少效能測試的需求。現在測試不再位於資料中心關閉關鍵路徑上，您可以使用 Amazon CloudWatch 來評估執行個體使用率，並判斷較小大小的執行個體是否合適。

為了說明此階段的重要性，一個大型技術客戶正在執行大型遷移，但最初不包含遷移後驗證。遷移超過 100 個伺服器後，他們發現 AWS Systems Manager 客服人員 (SSM 客服人員） 未正確設定。所有先前遷移的伺服器都必須修復，且遷移會停滯。客戶也發現執行個體的大小是初始預估的五倍，因此他們在每個遷移波結束時實作了成本檢查點。