本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 任務 1：執行初始探索並驗證遷移策略
大型遷移專案中產品組合評估的第一步是了解您目前擁有的資訊、業務和技術驅動因素，以及任何已經做出的遷移策略決策。產品組合評估的結果是持續將遷移中繼資料、波動計畫和遷移策略饋送至遷移工作流程。根據所收集的資訊，您可以分析差距並決定後續步驟。如果您已完成分析和任務，可以略過本程序手冊中的部分章節。此任務包含下列步驟：
+ [步驟 1：驗證探索資料](#discovery-1)
+ [步驟 2：識別業務和技術驅動因素](#discovery-2)
+ [步驟 3：驗證遷移策略](#discovery-3)
+ [步驟 4：驗證遷移模式](#discovery-4)
## 步驟 1：驗證探索資料
在調動階段，您可能已完成初始產品組合評估，如果是，您可以在遷移階段重複使用該探索資料。如果沒有，請不要擔心。此手冊將引導您完成支援大型遷移所需的內容。
大型遷移通常有許多資料。例如，您有：
+ 來源伺服器、應用程式和資料庫的相關中繼資料
+ 來自組態管理資料庫 (CMDB) 的 IT 產品組合相關資訊
+ 探索工具中的資料，可協助您進一步了解目前的狀態和相依性
+ 目標 AWS 資源的中繼資料
### 關於中繼資料的類型
以下是支援大型遷移所需的三種主要中繼資料類型：
+ **來源產品組合中繼資料** – 來源產品組合中繼資料是有關來源伺服器、應用程式和資料庫的中繼資料。您可以從現有的 CMDB、探索工具，甚至從應用程式擁有者取得中繼資料。您可以在此處找到此中繼資料類型的完整清單，以下是一些範例：
+ 伺服器名稱
+ 伺服器 IP 地址
+ 伺服器作業系統 (OS)
+ 伺服器儲存、CPU、記憶體和每秒輸入/輸出操作 (IOPS)
+ Application name (應用程式名稱)
+ 應用程式擁有者
+ Application-to-application相依性
+ 業務單位
+ Application-to-server映射
+ Application-to-database映射
+ 資料庫類型和大小
+ 儲存類型和大小
+ 相依性中繼資料
+ 效能和用量資料
+ **目標環境中繼資料** – 這是中繼資料類型，可協助您將伺服器遷移至目標環境。您需要對目標環境做出決策。您可以從探索工具取得一些中繼資料。以下是此中繼資料類型的一些範例：
+ 目標子網路
+ 目標安全群組
+ 目標執行個體類型
+ Target AWS Identity and Access Management (IAM) 角色
+ 目標 IP 地址
+ 目標 AWS 帳戶 ID
+ 目標 AWS 區域
+ 目標 AWS 服務
+ 目標應用程式架構設計
+ **波規劃中繼資料** – 波規劃中繼資料是可協助您管理遷移的中繼資料類型。以下是此中繼資料類型的範例：
+ Wave ID
+ 波開始時間
+ 波切換時間
+ Wave 擁有者
+ Wave to application/server/database/move 群組映射
### 驗證您的探索資料
在做出任何決策之前，請務必了解您目前的探索資料。您在遷移的這個階段可能沒有所有資訊。此手冊可協助您定義中繼資料需求，並協助您有效率地收集中繼資料。詢問自己下列問題，以識別目前可用的中繼資料，以及中繼資料可能位於何處：
+ 您是否使用任何工具來執行遷移評估，例如遷移評估器？
+ 您是否已在您的環境中部署任何探索工具，例如 Flexera One Cloud Migration 和 Modernization？
+ 您的 CMDB 是否有 IT 產品組合up-to-date？
+ 您是否已完成調動階段的初始產品組合評估？
+ 您是否已完成初始波動規劃？
+ 您是否已完成初始目標環境設計？
+ 每個中繼資料類型的來源為何？
+ 您是否有權存取所有中繼資料？
+ 如何存取所有中繼資料？
+ 您是否已記錄存取中繼資料的程序？
## 步驟 2：識別業務和技術驅動因素
在考慮每個應用程式的高階遷移策略和模式時，業務和技術驅動因素至關重要。您必須了解遷移特有的驅動程式。驗證遷移策略和定義應用程式映射規則時，您可以使用這些商業和技術驅動程式。
### 常見業務驅動因素
*業務驅動因素*是與業務目標或限制相關的因素，您在規劃大型遷移時必須考慮這些因素，例如合約即將到期、快速成長或預算。以下是常見的業務驅動因素：
+ **退出資料中心** – 您需要盡快遷移至雲端。例如，資料中心合約即將到期。
+ **降低營運成本和風險** – 您想要降低與操作內部部署環境相關的成本或風險。
+ **彈性** – 您需要將雲端作為策略方向，以便為業務未來的變革做好準備。
+ **業務成長** – 您需要能夠快速加速開發和創新，或適應快速成長。
+ 以**智慧方式使用資料** – 您想要利用雲端式人工智慧、機器學習和物聯網 (IoT) 來預測公司的成長並提供客戶行為的洞見。
+ **改善安全性和合規性** – 您需要利用已內建在 AWS 雲端基礎設施中的合規計劃，或您想要利用以軟體為基礎的安全工具，以警告您對資料的可能威脅。
+ **資源可用性** – 資源有限或內部經驗有限，可能會導致您選擇在不修改的情況下移動應用程式的策略。
### 常見的技術驅動程式
*技術驅動程式*是與技術目標或限制相關的因素，您在規劃大型遷移時必須考慮這些因素，例如目前的架構。以下是常見的技術驅動因素：
+ **硬體或軟體end-of-support** – 您的硬體或軟體生命週期即將結束，您需要重新整理它，因為廠商不再支援它。
+ **技術整合** – 您可以存取 全球基礎設施，讓您能夠快速且策略性地擴展應用程式。您可以使用準備好供您點選的 全球服務和基礎設施，快速進行全球化。
+ **儲存和運算限制 ** – 您的資料中心沒有容納更多儲存或伺服器的容量，您需要尋找另一個要擴展的地方。
+ **可擴展性和彈性需求 ** – 您的應用程式在過去經歷過停機時間，而且您想要使用雲端來改善復原點目標 (RPO) 和復原時間目標 (RTO)。
+ **現代化應用程式架構 ** – 您想要利用雲端，並將應用程式變更為雲端原生。
+ **改善效能 ** – 在尖峰季節，您的應用程式效能不佳，您想要自動擴展和縮減以符合需求。
### 更新 Runbook
1. 在[產品組合手冊範本](samples/portfolio-playbook-templates.zip)中，開啟*應用程式優先順序的 Runbook 範本* (Microsoft Word 格式）。
1. 在*商業和技術驅動程式*區段中，記錄您為大型遷移專案識別的驅動程式。
1. 儲存您的應用程式優先順序 Runbook。
## 步驟 3：驗證遷移策略
選取遷移策略對大型遷移至關重要。您必須驗證您選擇的遷移策略是否符合組織期望、限制和要求。如需可用遷移策略的詳細資訊，請參閱 [AWS 大型遷移指南](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/)。
您可能已在調動階段或在初始產品組合評估期間選取遷移策略。在此步驟中，您會使用業務和技術驅動程式來選取和驗證產品組合的遷移策略。
隨著您繼續評估產品組合並開始遷移，遷移策略可能會變更。在此階段，目標是了解產品組合對每個遷移策略的一般分佈。選取遷移策略對於下一個步驟至關重要，可驗證詳細的遷移模式。
### 選取並驗證遷移策略
評估產品組合並選取遷移策略，如下所示：
1. 檢閱您在上一個步驟中識別的所有技術和業務驅動因素，並根據業務需求排定驅動因素的優先順序。
1. 將每個業務和技術驅動程式映射到遷移策略。下表為範例。
****
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/large-migration-portfolio-playbook/discovery.html)
1. 透過權衡每個業務和技術驅動因素，並在高層級評估您的產品組合，估計應用程式應如何分佈在每個遷移策略中。常見的情況是查看驅動程式之間的衝突。專案利益相關者需要一起合作，並做出最終決策來解決衝突。以下是如何將產品組合分配至每個遷移策略的範例：
+ Rehost – 60%
+ Replatform – 15%
+ 淘汰 – 10%
+ 保留 – 5%
+ 回購 – 5%
+ 重構 – 5%
在您為產品組合選取高階遷移策略之前，請勿繼續遷移。
### 更新 Runbook
1. 開啟您的應用程式優先順序 Runbook。
1. 在*遷移策略*區段中，記錄應用程式工作負載在七種遷移策略中的分佈方式。例如：
+ Rehost – 60%
+ Replatform – 15%
+ 淘汰 – 10%
+ 保留 – 5%
+ 回購 – 5%
+ 重構 – 5%
1. 儲存您的應用程式優先順序 Runbook。
## 步驟 4：驗證遷移模式
### 關於遷移模式
*遷移模式*是可重複的遷移任務，詳細說明遷移策略、遷移目的地，以及使用的遷移應用程式或服務。例如，*使用 將 重新託管至 Amazon Elastic Compute Cloud (Amazon EC2) AWS Application Migration Service*。以下 AWS 服務和解決方案經常以常見的遷移模式參考：
+ AWS App2Container
+ AWS Application Migration Service (AWS MGN)
+ AWS CloudFormation
+ AWS Database Migration Service (AWS DMS)
+ AWS DataSync
+ Amazon Elastic Compute Cloud (Amazon EC2)
+ Amazon Elastic Container Service (Amazon ECS)
+ Amazon Elastic File System (Amazon EFS)
+ AWS 雲端遷移工廠解決方案
+ Amazon Relational Database Service (Amazon RDS)
+ AWS Schema Conversion Tool (AWS SCT)
+ AWS Transfer Family
與選擇遷移策略類似，您可能已經在早期階段識別遷移模式。不過，您必須驗證它們，並確保模式已定義和記錄。下表列出常見的遷移策略和模式。
****
| ID | 策略 | 模式 |
| --- | --- | --- |
| 1 | 重新託管 | 使用 Application Migration Service 或 Cloud Migration Factory 重新託管至 Amazon EC2 |
| 2 | 平台重建 | 使用 AWS DMS 和 將格式轉換為 Amazon RDS AWS SCT |
| 3 | 平台重建 | 使用 將格式轉換為 Amazon EC2 CloudFormation CloudFormation 範本會在 中建立新的基礎設施 AWS 雲端。 |
| 4 | 平台重建 | 使用 AWS DataSync 或 將格式轉換為 Amazon EFS AWS Transfer Family |
| 5 | 平台重建 | 使用 AWS App2Container 將格式轉換為 Amazon ECS |
| 6 | 平台重建 | 使用模擬器將大型主機或中階伺服器複寫至 Amazon EC2 |
| 7 | 平台重建 | Amazon EC2 上的從 Windows 到 Linux 的 Replatform |
| 8 | 淘汰 | 淘汰應用程式 |
| 9 | 保留 | 保留現場部署 |
| 10 | 重新購買 | 重新購買和升級至 SaaS |
| 11 | 重構或重新架構 | 重新建構應用程式 |
### 更新 Runbook
此時，您會在產品組合層級定義模式。在本程序手冊稍後，您會將每個應用程式對應至其對應的遷移模式。
1. 開啟您的應用程式優先順序 Runbook。
1. 在*遷移模式*區段中，記錄您已識別和驗證的遷移模式。為每個模式指派唯一的 ID，並記下模式的遷移策略。
1. 儲存您的應用程式優先順序 Runbook。
請注意，遷移模式可能會隨著您的進度而變更。您可以在稍後找到新資訊、變更工作負載範圍，甚至決定使用新 AWS 服務時，變更遷移策略和模式。
## 任務結束條件
如果您尚未從高階產品組合的角度識別遷移策略和模式，強烈建議您與技術團隊合作來定義這些策略和模式，然後再繼續進行下一個任務。產品組合評估和波動規劃取決於了解遷移策略和模式。在繼續之前，您不需要擁有完整的遷移模式清單。您可以新增模式，並隨需調整策略。
當您完成以下項目時，請繼續下一個任務：
+ 您可以存取最新的探索資料並加以了解。
+ 您已識別遷移的業務和技術驅動因素。
+ 您已根據您的業務和技術驅動因素選擇並驗證遷移策略。
+ 您已選取並驗證遷移模式。
+ 您已在應用程式優先順序 Runbook 中記錄下列項目：
+ 商業和技術驅動程式
+ 遷移策略
+ 遷移模式