本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 技術觀點
技術為加速大型遷移提供了良好的基礎。例如，Cloud Migration Factory 解決方案著重於如何為遷移提供end-to-end自動化。本節探討使用 技術實現所需規模和速度的一些最佳實務，並與範圍、策略和時間表保持一致。
總體原則是盡可能查看自動化領域。如果您的範圍內有數千部伺服器，手動執行任務可能是一項昂貴且耗時的工作。
若要執行遷移，通常會使用數種工具，如下所示：
+ 探索
+ 遷移實作
+ 組態管理資料庫 (CMDB)
+ 庫存試算表
+ 專案管理
這些工具用於不同的遷移階段，從評估到調動到實作。這些工具的選擇取決於業務目標和時間表。
規劃遷移階段之後，下一步是確保遷移團隊具備使用所需工具的技能。如果團隊缺乏技能或經驗，請規劃目標式訓練來提升技能集。如果可能，請建立事件，讓團隊可以在安全的環境中獲得遷移工具的經驗。例如，團隊是否可以遷移沙坑或實驗室伺服器來體驗工具？ 或者，初始開發工作負載是否可以用於學習目的？
## 自動化、追蹤和工具整合
**Contents**
+ [自動化遷移探索，以減少所需的時間](#discovery)
+ [自動化重複性任務](#repeating)
+ [自動化追蹤和報告以加速決策](#decision)
+ [探索可促進遷移的工具](#tooling)
### 自動化遷移探索，以減少所需的時間
大多數大型遷移計劃從了解遷移的範圍 （必須遷移的內容） 和制定策略 （遷移的方式） 開始。探索是其中的重要層面。擷取必要的中繼資料點，以形成遷移策略決策樹。若要逐步遷移工作負載，您必須識別所需的遷移中繼資料並將其匯入實作程序，例如遷移工廠。一種完全自動化的機制，可擷取、轉換、載入 (ETL) 遷移中繼資料可大幅減少探索程序所涉及的時間和工作量。
一位客戶為其遷移工廠開發了全自動化的資料輸入程序。具有所有遷移中繼資料的遷移波動計畫託管和維護在 Microsoft SharePoint 上的試算表中。對來源進行變更時，會啟動 AWS Lambda 函數，以在無需手動介入的情況下將資料載入遷移工廠。這種自動化的資料輸入程序有助於客戶減少手動工作、盡量減少人為錯誤，並加快速度。他們能夠將超過 1，000 個伺服器遷移至 AWS。
### 自動化重複性任務
在遷移實作階段，許多小型程序必須經常重複。例如，使用 AWS Application Migration Service (MGN) 時，您必須在遷移範圍內的每個伺服器上安裝 代理程式。
建置符合您特定業務和技術需求的遷移工廠，是實現成功進行大型遷移所需的效率和速度最有效的方式。遷移工廠提供整合和協同運作架構，使用標準化資料集來加速遷移。識別所有任務後，請花時間自動化所有可自動化的手動任務，以及規範性的 Runbook。
[Cloud Migration Factory](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-factory-cloudendure/welcome.html) 解決方案是其中的範例。Cloud Migration Factory 旨在提供遷移自動化基礎，您可以在其上自動化組織特有的層面。例如，您可能想要更新 CMDB 中的旗標，以強調現場部署伺服器現在可以停用。在此案例中，您可以建立在遷移波結束時執行此任務的自動化。Cloud Migration Factory 有一個集中式中繼資料存放區，其中包含所有波動、應用程式和伺服器中繼資料。自動化指令碼可以連線至 Cloud Migration Factory，以取得該波中的伺服器清單，並相應地執行任何動作。Cloud Migration Factory 支援 [AWS Application Migration Service](https://docs.aws.amazon.com/mgn/latest/ug/what-is-application-migration-service.html)。
### 自動化追蹤和報告以加速決策
我們建議您建置自動化遷移報告儀表板來追蹤和報告即時資料，包括程式的關鍵效能指標 (KPIs)。遷移專案涉及整個組織的利益相關者，包括下列項目：
+ 應用程式團隊
+ 測試人員
+ 解除委任團隊
+ 架構師
+ 基礎設施團隊
+ 領導
若要執行其角色，這些利益相關者需要即時資料。例如，網路團隊必須知道即將發生的遷移波紋，以了解對內部部署資源與 之間共用連線的影響 AWS。領導團隊想要了解遷移完成的程度。擁有可靠、自動化的資料即時饋送可防止通訊錯誤，並提供做出決策的基礎。
一位大型醫療保健客戶正在努力結束資料中心，且截止日期即將到來。考慮到規模和複雜性，最初花費大量時間在追蹤和溝通利益相關者之間的遷移狀態。遷移團隊稍後使用 [Amazon Quick Sight](https://docs.aws.amazon.com/quicksuite/latest/userguide/quick-bi.html) 建置自動化儀表板來視覺化資料，大幅簡化追蹤和通訊，同時提高遷移速度。
### 探索可促進遷移的工具
為您的遷移選擇正確的工具並不容易，特別是如果您組織中沒有人之前管理過大型遷移。
建議您花時間選擇合適的工具以支援遷移。此探勘可能涉及授權成本，但當您考慮更廣泛的計畫時，它可以提供成本效益。或者，您可能會發現內嵌在組織中的工具可提供類似的結果。例如，您可能已在資產中部署應用程式效能監控工具，以提供豐富的探索資訊。
由於缺乏熟悉度，技術客戶最初不願意在遷移期間執行自動探索工具。因此，SI AWS 合作夥伴必須為每個應用程式執行 5-10 小時的會議，以手動探索資產，包括伺服器名稱、作業系統版本和相依性。據估計，如果已使用探索工具，探索工作可能會減少超過 1，000 小時。
## 先決條件和遷移後驗證
**Contents**
+ [在遷移前階段建置登陸區域](#landing-zone)
+ [概述先決條件活動](#outline)
+ [實作遷移後檢查以持續改進](#post-checks)
### 在遷移前階段建置登陸區域
我們建議您事先建置 AWS 目標環境或登陸區域，而不是在遷移波動期間建置目標虛擬私有雲端 (VPCs) 和子網路。建置架構良好的登陸區域是遷移的先決條件。登陸區域應包含監控、控管、操作和安全控制。
在遷移之前建置和驗證登陸區域，可最大限度地減少在新環境中執行工作負載所帶來的不確定性。建立登陸區域後，利益相關者可以專注於遷移工作負載，而無需擔心帳戶或 VPC 層級管理的層面。
### 概述先決條件活動
除了登陸區域之外，請務必在遷移之前調整其他技術先決條件，尤其是前置時間較長的程序。例如，進行必要的防火牆變更，以允許資料從內部部署複寫到 AWS。及早溝通技術先決條件有助於準備和配置所需的資源。因為尚未符合先決條件，所以遷移至停滯的情況很常見。這不僅會影響進行中的遷移波動，還可能會在問題正在修復時推回所有未來遷移的日期。
一家金融服務公司，旨在執行大規模遷移至 AWS，目標是清空數個資料中心。不過，其頻寬在內部部署和 之間可用 AWS ，不足以達到預期的速度。不幸的是，增加頻寬需要新的連線，而且前置時間為三個月。這表示遷移速度在前三個月受到限制。
### 實作遷移後檢查以持續改進
最後，請記得實作遷移後驗證，例如操作整合、成本最佳化，以及控管和合規檢查。遷移後驗證包括評估先前遷移的工作負載，以找出學到應套用至未來波紋的技術經驗。
此外，這是實作成本控制操作的絕佳機會。例如，在遷移期間，您可能會決定將 AWS 執行個體的大小與現場部署資產相符，以減少效能測試的需求。現在，測試不再位於資料中心關閉關鍵路徑上，您可以使用 Amazon CloudWatch 來評估執行個體使用率，並判斷較小大小的執行個體是否合適。
為了說明此階段的重要性，大型技術客戶正在執行大型遷移，但最初不包含遷移後驗證。遷移超過 100 個伺服器之後，他們發現 AWS Systems Manager 代理程式 (SSM 代理程式） 未正確設定。所有先前遷移的伺服器都必須修復，且遷移會停止。客戶也發現執行個體的大小是初始預估的五倍，因此他們在每個遷移波結束時實作了成本檢查點。