視窗環境探索

有了現今可用的技術，例如應用程式遷移服務、將 Windows 伺服器、Linux 和其他 x86 型作業系統及其工作負載移至 AWS，就相當簡單。不過，讓這些工作負載能夠正常運作並大規模執行，卻帶來了不同的挑戰。本節旨在識別可讓您快速、安全且順暢地移轉 Microsoft 工作負載的移轉考量。

評估

雖然您可以在最小規劃和自動化的情況下「暴力」較小的移轉 (例如涉及 100 部伺服器的移轉)，但是您無法使用此方法移動 500 台以上的伺服器。下列考量是成功進行大規模移轉的主要因素，您可以使用移轉準備程度評估 (MRA)確定您要關注的考慮領域。

企業架構

環境中的技術債務越多，遷移就越困難。擁有健全企業架構方案的組織會努力將環境限制在目前和最新版本的軟體和系統 (通常稱為 N 和 N -1 版本的主要版本)。這不僅減少了您必須考慮的案例數量，而且還可以利用更新版本的進步功能。例如，視窗伺服器 2012 年、視窗伺服器 2008 年和較舊版本的視窗伺服器在 Windows 伺服器環境中比更多目前的版本更難以自動化。對於舊版和不受支持的版本，授權也更加困難。

標準化與組態管理

環境的標準化是另一個要考慮的因素。擁有手工構建和維護環境的組織被認為更像是寵物。每個系統都是獨一無二的，而且與使用標準化映像、基礎結構即程式碼 (IaC) 或持續整合與持續交付 (CI/CD) 管線相比，可能有更多的組態組合。

例如，在遷移時使用 IaC 或 CI/CD 重建典型 Web 服務器是最佳實踐，而不是手動遷移個別服務器。最佳做法是將所有持續性資料儲存在資料存放區中，例如資料庫、檔案共用或存放庫。如果系統不是使用 IaC 或 CI/CD 重建，他們至少應該使用配置管理工具（例如 Puppet，廚師或 Ansible）來標準化他們擁有的服務器。

良好的數據

良好的資料也是成功移轉的關鍵因素。關於目前伺服器及其中繼資料的準確資料對於自動化和規劃至關重要。缺乏良好的資料會增加規劃移轉時的難度。良好資料的範例包括準確的伺服器清查、伺服器上的應用程式、含版本之伺服器上的軟體、CPU 數量、記憶體容量和磁碟數量。我們建議您擷取波浪規劃人員在規劃時所需的任何資料，或是您打算在自動化移轉程序中使用的任何資料。

 自動化

自動化對於大規模移轉至關重要。自動化的範例包括安裝代理程式、更新自動化所需公用程式的軟體版本，例如 .NET 或PowerShell，載入或更新 AWS 的軟體，例如 AWS 系統管理員代理程式 (SSM 代理程式)、亞馬遜CloudWatch在 AWS 中執行所需的代理程式或其他備份或管理軟體。

詳細規劃

制定和管理詳細計劃對於大規模移轉也很重要。您必須制定明確定義的計劃，以便每週遷移 50 部伺服器，持續數週。一個有效的計劃包括以下內容：

• 使用波浪規劃根據您的依賴關係和優先級將服務器組織成浪潮。

• 使用每週計劃(導致切換) 與應用程式團隊通訊，並識別在切換期間必須解決的網路、DNS、防火牆及其他詳細資料。

• 使用詳細， hour-to-hour規劃（在實際切換周圍）以描述切換維護窗口。

• 使用不走標準說明在什麼情況下，應用程式會被視為切斷到 AWS，或者必須失敗回到來源位置。

• 使用清理活動作為必須完成的跟進活動。這些活動可能發生在切換維護視窗之外或完成之後過度護理。清理活動包括驗證備份和各種代理程式、從伺服器移除應用程式移轉服務代理程式，或移除來源伺服器和相關聯的資源。

動員

在動員階段，重要的是盡可能多地探索組織的複雜性和變化，以便在移轉規劃期間將其納入考量。理想情況下，您可以避免在切換維護期間處理此類複雜性和變化，並防止任何錯誤回復。

大規模移轉的挑戰

當應用程式切換至新環境時，就會發生移轉失敗，而且無法在移轉維護時段內滿足效能或功能需求。這會強制應用程式或應用程式故障回到其原始位置。此外，依賴該應用程式或應用程式的所有其他應用程式也需要故障回復。因為必須重新排程應用程式，因此失敗的移轉不僅會影響目前的浪潮，還會影響未來的波浪。

延遲敏感的依賴關係

遷移失敗的主要原因是延遲敏感的依賴關係。未能識別對延遲敏感的依賴關係可能會導致性能問題導致無法接受的響應時間或交易時間。例如，應用程式通常會同時將其資料庫和應用程式伺服器移至雲端，因為它們彼此頻繁通訊，而且當兩者都位於同一個資料中心時，它們需要低於一毫秒的回應時間。只將資料庫移至雲端可能會對這些交易造成數秒的延遲，進而對應用程式造成重大的效能影響。這也適用於彼此嚴重依賴的應用程式，而且必須位於同一個資料中心才能充分執行。

因此，在規劃移轉時，瞭解和解決應用程式相依性至關重要。必須識別彼此相依的應用程式和服務，以便它們可以一起移轉。

IT 共享服務

當工作負載位於雲端之後，它需要各種服務才能正常運作和維護。這包括著陸區域、網路和安全性周邊、驗證、修補、安全性掃描器、IT 服務管理工具、備份、防禦主機和其他資源。如果沒有這些服務，工作負載可能無法正常運作，並會強制故障返回其原始位置。

組態更新

在大多數情況下，您必須對工作負載進行多項設定變更，才能在該工作負載移至雲端後正常運作。這些組態變更通常與工作負載的下列相依性相關聯：

• 防火牆規則

• 允許清單

• DNS 記錄

• 連接字串

如果您沒有進行適當的組態更新，則工作負載、其使用者及其相依系統可能無法彼此通訊。可以在中斷時段內解決這些問題，但此時的變更可能非常耗時，或需要無法及時滿足的變更記錄。

應用功能測試

大規模移轉的另一個挑戰是需要進行應用程式功能測試。這特別重要，因為許多組織依賴應用程式團隊來識別延遲敏感的相依性、IT 共用服務或需要的組態更新。理想情況下，應用程式小組會提供撰寫或自動化的測試計劃，以便在切換維護時段期間執行，以驗證其應用程式是否完全正常運作且效能可接受。為了將切換維護時間保持在最低限度，測試應該能夠在 30 分鐘內完成。

應用程式相依性探索工具

判斷應用程式之間的相依性對於成功移轉至關重要，無論是偵測延遲敏感的相依性和連線設定項目。市場上有幾種用於發現依賴關係的工具，例如應用探索服務(代理程式和無代理程式工具) 和混濁(代理程式型工具)。

當您選擇探索應用程式相依性的工具時，請考慮下列事項：

• 期限— 我們建議您執行探索工具足夠長的時間來擷取應用程式特定事件，例如已知尖峰、月底和其他事件。建議的最低限度為 30 天。

• 作用中 (代理程式)— 主動依賴發現工具通常嵌入在操作系統的內核中，並捕獲所有事務。但是，這通常是最昂貴和最耗時的方法。

• 被動 (無代理程式)-被動依賴發現工具要便宜得多，實現速度更快，但可能會丟失一些較少使用的連接。

• 制度知識— 雖然應用程式探索工具提供更詳細、更準確的資訊，但大多數組織依賴其應用程式團隊及其機構知識來探索應用程式相依性。應用程式團隊通常對延遲敏感的相依性有所了解，但是他們會錯過某些詳細資料，例如連線組態設定、防火牆規則或允許合作夥伴的清單要求並不罕見。您可以使用機構知識來增強您的應用程式相依性探索，但我們建議您也考慮並降低所涉及的風險。例如，如果您僅依賴應用程式團隊的知識，就有遺漏連線組態項目或延遲敏感相依性的風險。這可能會導致中斷或移轉失敗。為了減輕此風險，我們建議您進行詳細的應用程式功能測試。