本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
透過現今可用的技術 AWS Application Migration Service，例如將 Windows Server、Linux 和其他以 x86 為基礎的作業系統及其工作負載移至 AWS ，相當簡單。不過，讓這些工作負載正常運作並大規模執行，會帶來一組不同的挑戰。本節旨在識別遷移考量事項，讓您能夠快速、安全且順暢地遷移 Microsoft 工作負載。
評估
雖然您可以以最少的規劃和自動化來「急衝力」較小的遷移 （例如涉及 100 個伺服器的遷移），但您無法使用此方法移動 500 個以上的伺服器。下列考量事項是成功大規模遷移的主要因素，您可以使用遷移就緒狀態評估 (MRA) 來識別您想要關注的考量領域。
企業架構
環境中的技術債務愈多，遷移就愈困難。擁有良好企業架構計劃的組織會努力將環境限制在目前和最新版本的軟體和系統 （通常稱為主要版本的 N 和 N -1 版本）。這不僅可以減少您必須考慮的案例數量，還可以利用較新版本的進階。例如，Windows Server 2012、Windows Server 2008 和較舊版本的 Windows Server，在 Windows Server 環境中自動化會比目前版本更困難。對於較舊和不支援的版本，授權也比較困難。
標準化和組態管理
環境標準化是另一個需要考慮的因素。具有以人工建置和維護之環境的組織，會被視為更像寵物。每個系統都是唯一的，而且與使用標準化映像、基礎設施做為程式碼 (IaC) 或持續整合和持續交付 (CI/CD) 管道建置相比，還有更多可能的組態組合。
例如，最佳實務是在遷移時使用 IaC 或 CI/CD 重建典型的 Web 伺服器，而不是手動遷移個別伺服器。這也是最佳實務，將所有持久性資料存放在資料庫、檔案共用或儲存庫等資料存放區中。如果系統不是使用 IaC 或 CI/CD 重建，則他們至少應該使用組態管理工具 （例如 Puppet、Chef 或 Ansible) 來標準化他們擁有的伺服器。
良好資料
良好的資料也是成功遷移的關鍵因素。有關目前伺服器及其中繼資料的準確資料對於自動化和規劃至關重要。缺乏良好的資料會增加規劃遷移時的難度。良好資料的範例包括準確清查伺服器、伺服器上的應用程式、伺服器上具有 版本的軟體、CPUs 數量、記憶體數量和磁碟數量。建議您擷取波浪規劃器規劃所需的任何資料，或您計劃用於自動化遷移程序的任何資料。
自動化
自動化對於大規模遷移至關重要。自動化的範例包括安裝代理程式、更新 .NET 或 PowerShell 等自動化所需的公用程式軟體版本、載入或更新 的 軟體， AWS 例如 AWS Systems Manager Agent (SSM Agent)、Amazon CloudWatch 代理程式，或執行 所需的其他備份或管理軟體 AWS。
詳細規劃
制定和管理詳細計劃對於大規模遷移也至關重要。您必須有明確定義的計劃，才能每週遷移 50 個伺服器數週。有效的計劃包括下列項目：
-
根據您的相依性和優先順序，使用波浪規劃將伺服器整理成波浪。
-
使用每週規劃 （從開始到切換） 與應用程式團隊通訊，並識別網路、DNS、防火牆和其他在切換期間必須處理的詳細資訊。
-
使用詳細的hour-to-hour（大約實際的切換） 來描述切換維護時段。
-
使用 go/no-go 條件來描述應用程式將被視為切換到來源位置， AWS 或必須失敗回來源位置的情況。
-
使用清理活動做為必須完成的後續活動。這些活動可能會在切換維護時段之外或 Hypercare 完成後進行。清除活動包括驗證備份和各種代理程式、從伺服器移除 Application Migration Service 代理程式，或移除來源伺服器和相關聯的資源。
調動
在動員階段，請務必盡可能探索組織的複雜性和變化，以便在遷移規劃期間加以考量。理想情況下，您可以避免在切換維護時段處理此類複雜性和變化，並防止任何容錯。
大規模遷移的挑戰
當應用程式或應用程式已切換到新的環境，且無法在遷移維護時段內滿足效能或功能需求時，就會發生遷移失敗。這會強制應用程式或應用程式失敗回其原始位置。此外，依賴該應用程式或應用程式的所有其他應用程式也需要容錯回復。失敗的遷移不僅會影響目前的波，還會影響未來的波，因為應用程式必須重新排程。
延遲敏感相依性
失敗遷移的主要原因是延遲敏感相依性。未能識別延遲敏感的相依性可能會導致效能問題，導致無法接受的回應時間或交易時間。
例如，應用程式通常會同時將其資料庫和應用程式伺服器移至雲端，因為它們會經常彼此通訊，而且當兩者位於相同的資料中心時，需要一毫秒以下的回應時間。僅將資料庫移至雲端可能會讓這些交易產生許多秒的延遲，進而對應用程式造成重大的效能影響。這也適用於彼此高度依賴且必須位於相同資料中心才能正常運作的應用程式。
因此，在規劃遷移時，了解和解決應用程式相依性至關重要。必須識別彼此相依的應用程式和服務，以便可以一起遷移。
IT 共享服務
工作負載在雲端後，它需要各種服務才能正常運作並安全地維護。這包括登陸區域、網路和安全周邊、身分驗證、修補、安全掃描器、IT 服務管理工具、備份、堡壘主機和其他資源。如果沒有這些服務，工作負載可能無法正常操作，並將被迫容錯移轉回原始位置。
組態更新
在大多數情況下，您必須在工作負載移至雲端之後，進行多項組態變更，工作負載才能正常運作。這些組態變更通常與工作負載的下列相依性相關聯：
-
防火牆規則
-
允許清單
-
DNS 記錄
-
連線字串
如果您未進行適當的組態更新，工作負載、其使用者及其相依系統可能無法彼此通訊。在中斷時段內解決這些問題是可能的，但目前變更可能會耗時，或需要無法及時滿足的變更記錄。
應用程式功能測試
大規模遷移的另一個挑戰是需要應用程式功能測試。這尤其重要，因為許多組織依賴應用程式團隊來識別延遲敏感的相依性、IT 共享服務或所需的組態更新。理想情況下，應用程式團隊會提供書面或自動化測試計劃，讓他們可以在切換維護時段執行，以驗證其應用程式是否完全正常運作，並具備可接受的效能。為了將切換維護時段保持在最低限度，測試應該可以在 30 分鐘內完成。
應用程式相依性探索的工具
判斷應用程式之間的相依性對於成功遷移至關重要，這對於偵測延遲敏感的相依性和連線組態項目都是如此。市場上有數種工具可用於探索相依性，例如 AWS Application Discovery Service
當您選擇應用程式相依性探索的工具時，請考慮下列事項：
-
持續時間 – 建議您執行足夠長的探索工具，以擷取應用程式特定的事件，例如已知峰值、月尾和其他事件。建議的最短時間為 30 天。
-
作用中 （以代理程式為基礎） – 作用中相依性探索工具通常內嵌在作業系統的核心中，並擷取所有交易。不過，這通常是最昂貴且耗時的方法。
-
被動 (無代理程式） – 被動相依性探索工具實作起來更便宜且速度更快，但有遺漏一些較少使用連線的風險。
-
機構知識 – 雖然應用程式探索工具提供更詳細且準確的資訊，但大多數組織都依賴其應用程式團隊及其機構知識來探索應用程式相依性。應用程式團隊通常了解對延遲敏感的相依性，但他們錯過一些詳細資訊並不常見，例如連線組態設定、防火牆規則或允許合作夥伴的清單需求。您可以使用機構知識來增強您的應用程式相依性探索，但我們建議您也考慮並減輕涉及的風險。例如，如果您只依賴應用程式團隊的知識，則可能會有缺少連線組態項目或延遲敏感相依性的風險。這可能會導致中斷或遷移失敗。若要降低此風險，我們建議您執行詳細的應用程式功能測試。
