工作 1：執行初始探索並驗證移轉策略

在大型移轉專案中進行產品組合評估的第一步，是瞭解您目前擁有的資訊、業務和技術驅動因素，以及已做出的任何移轉策略決策。產品組合評估的結果是持續將移轉中繼資料、波動計劃和移轉策略饋送至移轉工作流。根據收集的資訊，您可以分析差距並決定後續步驟。如果您已經完成分析和工作，則可以略過此教戰手冊中的某些章節。此工作包含下列步驟：

• 步驟 1：驗證探索資料

• 步驟 2：識別業務和技術驅動因素

• 步驟 3：驗證移轉策略

• 步驟 4：驗證移轉模式

步驟 1：驗證探索資料

在動員階段，您可能已完成初始產品組合評估，如果是，您可以在遷移階段重複使用該探索資料。如果沒有，請不要擔心。本教戰手冊將引導您瞭解支援大型移轉所需的內容。

大型遷移通常有很多數據。例如，您有：

• 來源伺服器、應用程式和資料庫的中繼資料

• 組態管理資料庫 (CMDB) 中有關您 IT 產品組合的資訊

• 來自探索工具的資料，可協助您更好地瞭解目前的狀態和相依性

• 目標 AWS 資源的中繼資料

關於中繼資料的類型

以下是支援大型移轉所需的三種主要中繼資料類型：

• 來源組合中繼資料 — 來源組合中繼資料是關於來源伺服器、應用程式和資料庫的中繼資料。您可以從現有的 CMDB、探索工具，甚至應用程式擁有者取得中繼資料。您可以在這裡找到此中繼資料類型的完整清單，以下是一些範例：

  • 伺服器名稱

  • 伺服器 IP 位址

  • 伺服器作業系統 (OS)

  • 伺服器儲存、CPU、記憶體，以及每秒輸入/輸出作業 (IOPS)

  • 應用程式名稱

  • 應用程式擁

  • pplication-to-application 依賴關係

  • 業務單位

  • 一個pplication-to-server 映射

  • 一個pplication-to-database 映射

  • 資料庫類型和大小

  • 存儲類型和大小

  • 依賴元數據

  • 效能和使用情況資料

• 目標環境中繼資料 — 這是一種中繼資料類型，可協助您將伺服器移轉至目標環境。您需要做出有關目標環境的決策。您可以從探索工具取得部分這些中繼資料。以下是此中繼資料類型的一些範例：

  • 目標子網路

  • 目標安全性群組

  • 目標例項類型

  • 目標 AWS Identity and Access Management (IAM) 角色

  • 目標 IP 位址

  • 目標 AWS 帳號 ID

  • 目標 AWS 區域

  • 目標 AWS 服務

  • 目標應用架構設計

• Wave 規劃中繼資料 — Wave 規劃中繼資料是可協助您管理移轉的中繼資料類型。以下是此中繼資料類型的範例：

  • 波形識別碼

  • 波開始時間

  • 波形切換時間

  • 波所有者

  • 波動至應用程式/伺服器/資料庫/移動群組對應

驗證您的探索資料

在做出任何決策之前，了解您當前的發現數據非常重要。在遷移的這個階段，您可能沒有所有資訊。此教戰手冊可協助您定義中繼資料需求，並協助您有效率地收集中繼資料。請問自己以下問題，以確定目前有哪些中繼資料可用，以及它可能位於何處：

• 您是否使用任何工具進行移轉評估，例如移轉評估員？

• 您是否在環境中部署了任何探索工具，例如 AWS Application Discovery Service Flexera One 雲端移轉與現代化？

• 您是否擁有針對您 IT 組合提供最多 up-to-date 資訊的 CMDB？

• 您是否已在調動階段完成初步的投資組合評估？

• 您是否完成了最初的波浪計劃？

• 您是否已完成初始目標環境設計？

• 每種元數據類型的來源是什麼？

• 您可以存取所有中繼資料嗎？

• 您如何訪問所有元數據？

• 您是否記錄了訪問元數據的過程？

步驟 2：識別業務和技術驅動因素

在考慮每個應用程式的高階移轉策略和模式時，業務和技術驅動因素至關重要。您必須瞭解移轉專屬的驅動程式。驗證移轉策略和定義應用程式對應規則時，您可以使用這些業務和技術驅動程式。

常見的業務驅動

業務驅動因素是您在規劃大型移轉時必須考慮的業務目標或限制的因素，例如合約到期、快速成長或預算。以下是常見的業務驅動因素：

• 退出資料中心 — 您需要盡快遷移到雲端。例如，資料中心合約即將到期。

• 降低營運成本和風險 — 您希望降低營運內部部署環境的相關成本或風險。

• 靈活性 — 您需要移至雲端作為策略方向，才能為企業 future 的變化做好準備。

• 發展業務 — 您需要能夠快速加速開發和創新或適應快速增長。

• 智慧地使用資料 — 您想要利用雲端型人工智慧、機器學習和物聯網 (IoT) 的優勢，這些技術可以預測公司的成長並提供客戶行為的見解。

• 改善安全性和合規性 — 您需要利用 AWS 雲端基礎架構內建的法規遵循計劃，或者您想要利用軟體式安全工具來警告您資料可能受到威脅。

• 資源可用性 — 資源有限或內部經驗有限，可能會導致您選擇移動應用程式而不需要修改的策略。

常見的技術驅動

技術驅動因素是您在規劃大型移轉時必須考慮的技術目標或限制的因素，例如目前的架構。以下是常見的技術驅動因素：

• 硬體或軟體 end-of-support — 您的硬體或軟體即將結束時，您必須重新整理，因為廠商已不再支援該硬體或軟體。

• 技術整合 — 您可以存取全球基礎架構，讓您能夠快速且策略地擴充應用程式。您可以利用隨時準備好的全球服務和基礎架構，快速走向全球。

• 儲存和運算限制 — 您的資料中心沒有容量容量容納更多儲存空間或伺服器，您需要尋找其他擴充空間。

• 可擴充性和備援需求 — 您的應用程式過去經歷了停機時間，而您想要使用雲端來改善復原點目標 (RPO) 和復原時間目標 (RTO)。

• 現代化應用程式架構 — 您想要利用雲端並將應用程式變更為雲端原生。

• 改善效能 — 您的應用程式效能在尖峰季節不佳，您想要自動擴充和縮減以符合需求。

更新工作簿

1. 在產品組合教戰手冊範本中，開啟應用程式優先順序的 Runbook 範本 (Microsoft Word 格式)。

2. 在 [商業和技術驅動程式] 區段中，記錄您為大型移轉專案識別的驅動程式。

3. 保存您的應用程序優先級 runbook。

步驟 3：驗證移轉策略

選取移轉策略對於大型移轉至關重要。您必須確認選取的移轉策略是否符合組織期望、限制和需求。如需有關可用移轉策略的詳細資訊，請參閱AWS 大型移轉指南。

您可能已在動員階段或初始產品組合評估期間選取移轉策略。在此步驟中，您會使用業務和技術驅動程式來選取和驗證產品組合的移轉策略。

您的移轉策略可能會隨著您繼續評估產品組合並開始移轉而改變。在此階段，目標是瞭解您的產品組合在每個移轉策略中的一般分佈情況。選取移轉策略對於下一個步驟非常重要，因為驗證詳細的移轉模式。

選取並驗證移轉策略

評估產品組合並選取移轉策略，如下所示：

1. 檢閱您在上一步中識別的所有技術和業務驅動因素，並根據您的業務需求排定驅動程式的優先順序。

2. 將每個業務和技術驅動程式對應至移轉策略。下表為範例。

   優先順序	業務或技術驅動程式	遷移策略
   1	按指定日期退出資料中心	重新裝載盡可能多的應用程式，並且只有在無法重新裝載時才重新平台和重構。
   2	降低營運成本和風險	若要加速移轉，請盡可能多地重新裝載應用程式。
   3	硬體或軟體 end-of-support	重新裝載雲端中不支援較新硬體和軟體的支援應用程式和重新平台應用程式。
   4	資源可用性	將主機重新裝載到 AWS Managed Services (AMS) 以減少營運開銷。

3. 藉由權衡每個業務和技術驅動因素，並在高層級評估您的產品組合，估計應如何在每個移轉策略之間分配應用程式。通常會看到驅動程序之間的衝突。項目利益相關者需要共同努力並做出最終決定以解決衝突。下列範例說明如何將產品組合散佈至每個移轉策略：

   • 重新託管 — 60%

   • 重新平台 — 15%

   • 退休人員 — 10%

   • 保留 — 5%

   • 回購 — 5%

   • 重構 — 5%

在您為產品組合選取高階移轉策略之前，請勿繼續進行移轉。

更新工作簿

1. 打開您的應用程序優先級手冊。

2. 在移轉策略區段中，記錄應用程式工作負載如何在七種移轉策略中分配。例如：

   • 重新託管 — 60%

   • 重新平台 — 15%

   • 退休人員 — 10%

   • 保留 — 5%

   • 回購 — 5%

   • 重構 — 5%

3. 保存您的應用程序優先級 runbook。

步驟 4：驗證移轉模式

關於移轉模式

移轉模式是一項可重複的移轉任務，詳細說明移轉策略、移轉目的地以及所使用的移轉應用程式或服務。一個例子是重新託管到 Amazon Elastic Compute Cloud (Amazon EC2) 使用 AWS Application Migration Service. 常見移轉模式中經常參考下列 AWS 服務和解決方案：

• AWS 容器

• 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	重新主持	使用應用程式遷移服務或雲端移轉工廠重新託管至 Amazon EC2
2	平台重建	使用和重新平台到 Amazon AWS DMS RDS AWS SCT
3	平台重建	使用重新平台到 Amazon EC2 AWS CloudFormation 注意 CloudFormation 範本會在中建置新的基礎結構 AWS 雲端。
4	平台重建	使用或重新平台到 Amazon E AWS DataSync FS AWS Transfer Family
5	平台重建	使用應用程序容器重新平台到 Amazon ECS AWS
6	平台重建	使用模擬器將大型主機或中型伺服器重新平台到 Amazon EC2
7	平台重建	在 Amazon EC2 上從視窗重新平台到 Linux
8	淘汰	淘汰應用程式
9	保留	保留在內部部署
10	回購	回購及升級至軟體 SaaS
11	重構或重新建築	重新架構應用程式

更新工作簿

此時，您可以在組合層級定義模式。稍後在本教戰手冊中，您會將每個應用程式對應至其對應的移轉模式。

1. 打開您的應用程序優先級手冊。

2. 在「移轉模式」區段中，記錄您已識別並驗證的移轉模式。為每個模式指派一個唯一的 ID，並記下該模式的移轉策略。

3. 保存您的應用程序優先級 runbook。

請注意，移轉模式可能會隨著您的進度而變更。您可以在稍後變更移轉策略和模式，因為您找到新資訊、變更工作負載的範圍，甚至決定使用新 AWS 服務。

任務退出條件

如果您尚未從高階產品組合的角度確定移轉策略和模式，我們強烈建議您先與技術團隊合作，在繼續下一項工作之前定義它們。產品組合評估和波浪規劃取決於瞭解移轉策略和模式。在繼續之前，您不需要擁有完整的移轉模式清單。您可以隨時添加新模式並調整策略。

完成下列工作後，請繼續執行下一項工作：

• 您可以存取並瞭解最新的探索資料。

• 您已識別移轉的業務和技術驅動因素。

• 您已根據業務和技術驅動因素，選擇並驗證了移轉策略。

• 您已選取並驗證移轉模式。

• 您已在應用程式優先順序 runbook 中記錄下列內容：

  • 業務和技術驅動因素

  • 移轉策略

  • 移轉模式