本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# Windows 環境探索
透過目前可用的技術 AWS Application Migration Service，例如將 Windows Server、Linux 和其他以 x86 為基礎的作業系統及其工作負載移至 AWS ，相當簡單。不過，讓這些工作負載正常運作並大規模執行，會帶來一組不同的挑戰。本節旨在識別遷移考量事項，讓您能夠快速、安全且順暢地遷移 Microsoft 工作負載。
## 評估
雖然您可以用最少的規劃和自動化來「暴力破解」較小的遷移 （例如涉及 100 個伺服器的遷移），但您無法使用此方法移動 500 個以上的伺服器。下列考量事項是成功大規模遷移的主要因素，您可以使用[遷移準備度評估 (MRA)](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-migration/assessment-phase.html) 來識別您想要關注的考量領域。
### 企業架構
環境中的技術負債越大，遷移就越困難。擁有良好企業架構計劃的組織努力將環境限制在目前和最新版本的軟體和系統 （通常稱為主要版本的 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 代理程式 (SSM 代理程式）、Amazon CloudWatch 代理程式，或執行 所需的其他備份或管理軟體 AWS。
### 詳細規劃
制定和管理詳細計劃對於大規模遷移也至關重要。您必須有明確定義的計劃，才能在幾週內每週遷移 50 部伺服器。有效的計劃包括下列項目：
+ 根據您的相依性和優先順序，使用**波浪規劃**將伺服器整理成波浪。
+ 使用**每週規劃 **（從上到切換） 與應用程式團隊通訊，並識別在切換期間必須處理的網路、DNS、防火牆和其他詳細資訊。
+ 使用詳細的**hour-to-hour**（大約實際切換） 來描述切換維護時段。
+ 使用** go/no-go 條件**來描述應用程式將被視為切換到來源位置， AWS 或必須失敗回來源位置的情況。
+ 使用**清除活動**做為必須完成的後續活動。這些活動可能會在切換維護時段之外或完成 [Hypercare](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-governance-playbook/managing-large-migration.html#hypercare-period) 之後進行。清除活動包括驗證備份和各種代理程式、從伺服器移除 Application Migration Service 代理程式，或移除來源伺服器和相關聯的資源。
## 調動
在調動階段，請務必探索組織盡可能多的複雜性和變化，以便在遷移規劃期間加以考量。理想情況下，您可以避免在切換維護時段處理這類複雜性和變化，並防止任何容錯。
### 大規模遷移的挑戰
當應用程式或應用程式已切換到其新環境，且無法在遷移維護時段內滿足效能或功能需求時，就會發生遷移失敗。這會強制應用程式或應用程式容錯移轉回其原始位置。此外，依賴該應用程式或應用程式的所有其他應用程式也需要容錯回復。失敗的遷移不僅會影響目前的波動，還會影響未來的波動，因為應用程式必須重新排程。
### 延遲敏感相依性
失敗遷移的主要原因是對延遲敏感的相依性。如果無法識別對延遲敏感的相依性，可能會導致效能問題，導致無法接受的回應時間或交易時間。
例如，應用程式通常會同時將其資料庫和應用程式伺服器移至雲端，因為他們經常彼此通訊，而且當兩者位於相同的資料中心時，需要不到一毫秒的回應時間。僅將資料庫移至雲端可能會在這些交易中引入許多秒的延遲，對應用程式造成顯著的效能影響。這也適用於彼此高度相依且必須位於相同資料中心才能充分執行的應用程式。
因此，在規劃遷移時，了解和解決應用程式相依性至關重要。必須識別彼此相依的應用程式和服務，才能一起遷移。
### IT 共用服務
工作負載在雲端後，它需要各種服務才能正常運作並安全地維護。這包括登陸區域、網路和安全周邊、身分驗證、修補、安全掃描器、IT 服務管理工具、備份、堡壘主機和其他資源。如果沒有這些服務，工作負載可能無法正常運作，並被迫容錯移轉回原始位置。
### 組態更新
在大多數情況下，您必須在工作負載移至雲端之後，進行數個組態變更，工作負載才能正常運作。這些組態變更通常與工作負載的下列相依性相關聯：
+ 防火牆規則
+ 允許清單
+ DNS 記錄
+ 連線字串
如果您未進行適當的組態更新，工作負載、其使用者及其相依系統可能無法彼此通訊。您可以在中斷時段內解決這些問題，但目前變更可能會耗時，或需要無法及時滿足的變更記錄。
### 應用程式功能測試
大規模遷移的另一個挑戰是需要應用程式功能測試。這尤其重要，因為許多組織依賴應用程式團隊來識別延遲敏感的相依性、IT 共用服務或所需的組態更新。理想情況下，應用程式團隊會提供書面或自動化測試計畫，讓他們可以在切換維護時段執行，以驗證其應用程式是否正常運作，並具有可接受的效能。為了將切換維護時段保持在最低限度，測試應該能夠在 30 分鐘內完成。
### 應用程式相依性探索的工具
判斷應用程式之間的相依性對於成功遷移至關重要，這兩者都用於偵測延遲敏感的相依性和連線組態項目。市場上有數種工具可用於探索相依性，例如[AWS Transform 探索工具](https://docs.aws.amazon.com/transform/latest/userguide/discovery-tool.html) （代理程式型工具） 和 [Cloudamize](https://cloudamize.com/en/) （代理程式型工具）。
當您選擇應用程式相依性探索的工具時，請考慮下列事項：
+ **持續時間** – 我們建議您執行足夠長的探索工具來擷取應用程式特定的事件，例如已知峰值、月尾和其他事件。建議的最短時間為 30 天。
+ **作用中 （代理程式型）** – 作用中相依性探索工具通常內嵌在作業系統的核心中，並擷取所有交易。不過，這通常是最昂貴且耗時的方法。
+ **被動 **(**無代理**程式） – 被動相依性探索工具實作起來更便宜且更快速，但缺少一些較少使用連線的風險。
+ **機構知識** – 雖然應用程式探索工具提供更詳細且準確的資訊，但大多數組織依賴其應用程式團隊及其機構知識來探索應用程式相依性。應用程式團隊通常了解對延遲敏感的相依性，但他們錯過一些詳細資訊並不常見，例如連線組態設定、防火牆規則或允許合作夥伴的清單要求。您可以使用機構知識來增強應用程式相依性探索，但我們建議您也考慮並減輕涉及的風險。例如，如果您只依賴應用程式團隊的知識，則可能會有遺漏連線組態項目或延遲敏感相依性的風險。這可能會導致中斷或遷移失敗。為了降低此風險，我們建議您執行詳細的應用程式功能測試。