技术视角

技术为加快大型迁移提供了坚实的基础。例如，云迁移工厂解决方案侧重于如何为迁移提供 end-to-end自动化。本节探讨了使用技术实现所需规模和速度的一些最佳实践，这些做法与范围、策略和时间表保持一致。

首要原则是尽可能考虑自动化领域。如果您的范围内有数千台服务器，则手动执行任务可能既昂贵又耗时。

要执行迁移，通常会使用多种工具，例如：

• Discovery

• 迁移实施

• 配置管理数据库 (CMDB)

• 库存电子表格

• 项目管理

这些工具用于迁移的不同阶段，从评估到动员再到实施。这些工具的选择取决于业务目标和时间表。

计划好迁移阶段后，下一步是确保迁移团队具备使用所需工具的技能。如果一支队伍缺乏技能或经验，请计划有针对性的训练以提高技能组合。如果可能，请创建活动，让团队可以在安全的环境中获得迁移工具的使用经验。例如，是否有沙坑或实验室服务器可供团队迁移以体验这些工具？ 或者，将初始开发工作负载用于学习目的是否可以接受？

自动化、跟踪和工具集成

本节内容：

• 自动发现迁移以缩短所需的时间

• 自动执行重复性任务

• 自动跟踪和报告以加快决策制定

• 探索可以促进迁移的工具

自动发现迁移以缩短所需的时间

大多数大型迁移计划首先要了解迁移的范围（必须迁移什么）并制定策略（如何迁移）。发现是其中的一个重要方面。捕获所需的元数据点以形成迁移策略决策树。要快速迁移工作负载，您必须识别所需的迁移元数据并将其导入到实施流程（例如迁移工厂）中。提取、转换、加载 (ETL) 迁移元数据的全自动机制大大减少了发现过程所涉及的时间和工作量。

一位客户为其迁移工厂开发了全自动数据采集流程。包含所有迁移元数据的迁移浪潮计划已在 Microsoft 的电子表格中托管和维护 SharePoint。当对源进行更改时，系统会启动一项 AWS Lambda 功能，无需人工干预即可将数据加载到迁移工厂。这种自动数据采集过程帮助客户减少了手动工作，最大限度地减少了人为错误，并加快了速度。他们能够将 1,000 多台服务器迁移到 AWS。

自动执行重复性任务

在迁移实施阶段，必须经常重复许多小过程。例如，使用 AWS Application Migration Service (MGN) 时，必须在迁移范围内的每台服务器上安装代理。

要实现成功进行大规模迁移所需的效率和速度，最有效的方法是建立符合您特定业务和技术要求的迁移工厂。迁移工厂提供了一个集成和编排框架，该框架使用标准化数据集来加速迁移。确定所有任务后，花时间自动执行所有可以自动执行的手动任务，这些任务可以与规范的运行手册一起自动化。

云迁移工厂解决方案就是一个例子。Cloud Migration Factory 旨在提供迁移自动化基础，在此基础上，您可以自动执行组织特有的各个方面。例如，您可能需要更新 CMDB 中的一个标志，以突出显示本地服务器现在可以停用。在这种情况下，您可以创建一个自动化，在迁移浪潮结束时执行此任务。Cloud Migration Factory 有一个集中的元数据存储，其中包含所有浪潮、应用程序和服务器元数据。自动化脚本可以连接到云迁移工厂，以获取该浪潮中的服务器列表并相应地执行任何操作。云迁移工厂支持AWS Application Migration Service。

自动跟踪和报告以加快决策制定

我们建议构建自动迁移报告仪表板来跟踪和报告实时数据，包括该计划的关键绩效指标 (KPIs)。迁移项目涉及整个组织的利益相关者，包括：

• 应用程序小组

• 测试人员

• 退役小组

• 建筑师

• 基础设施团队

• 领导力

为了履行职责，这些利益相关者需要实时数据。例如，网络团队必须了解即将到来的迁移浪潮，才能了解对本地资源和之间共享连接的影响 AWS。领导团队希望了解迁移已完成的程度。拥有可靠、自动化的实时数据馈送可防止沟通不畅，并为做出决策提供依据。

一家大型医疗保健客户正在努力退出数据中心，最后期限即将到来。考虑到迁移的规模和复杂性，最初花费了大量时间来跟踪和沟通利益相关者之间的迁移状态。迁移团队后来使用 Amazon QuickSight 构建了可视化数据的自动控制面板，从而大大简化了跟踪和通信，同时提高了迁移速度。

探索可以促进迁移的工具

为迁移选择合适的工具并不容易，尤其是在组织中以前没有人管理过大规模迁移的情况下。

我们建议花点时间选择合适的工具来支持迁移。这种探索可能涉及许可成本，但是当你考虑更广泛的计划时，它可以带来成本效益。或者，您可能会发现组织中嵌入的工具可以提供类似的结果。例如，您可能已经在您的资产中部署了应用程序性能监控工具，这些工具可以提供丰富的发现信息。

由于不熟悉，技术客户最初不愿在迁移期间运行自动发现工具。因此，SI AWS 合作伙伴必须为每个应用程序召开 510 小时的会议才能手动发现资产，包括服务器名称、操作系统版本和依赖关系。据估计，如果使用发现工具，发现工作量本可以减少1,000多小时。

先决条件和迁移后验证

本节内容：

• 在迁移前阶段建造 landing zone

• 概述必备活动

• 实施迁移后检查以实现持续改进

在迁移前阶段建造 landing zone

我们建议提前构建 AWS 目标环境或 landing zone，而不是在迁移浪潮中构建目标虚拟私有云 (VPCs) 和子网。建造精心设计的着陆区是迁移的先决条件。landing zone 应包括监控、治理、操作和安全控制。

在迁移之前构建和验证 landing zone 可以最大限度地减少在新环境中运行工作负载所带来的不确定性。Landing zone 到位后，利益相关者可以专注于迁移工作负载，而不必担心在账户或 VPC 级别管理的各个方面。

概述必备活动

除了 landing zone 之外，在迁移之前还必须调整其他技术先决条件，尤其是交货时间较长的流程。例如，对防火墙进行必要的更改，以允许将数据从本地复制到 AWS。尽早沟通技术先决条件有助于准备和分配所需的资源。由于未满足先决条件，迁移通常会停滞不前。这不仅会影响正在进行的迁移浪潮，还可能会在问题得到修复的同时推迟所有未来迁移的日期。

一家金融服务公司打算向其进行大规模迁移 AWS，目标是腾出几个数据中心。但是，他们在本地之间可用的带宽 AWS 不足以达到他们预期的速度。不幸的是，增加带宽需要新的连接，而且交货时间为三个月。这意味着在最初的三个月中，迁移速度受到限制。

实施迁移后检查以实现持续改进

最后，请记住实施迁移后验证，例如运营集成、成本优化以及治理和合规性检查。迁移后验证包括评估先前迁移的工作负载，以发现应应用于未来浪潮的技术经验教训。

此外，这是实施成本控制操作的绝佳机会。例如，在迁移过程中，您可能会决定将 AWS 实例的大小与您的本地资产相匹配，以减少对性能测试的需求。现在，测试不再是数据中心关闭的关键路径，您可以使用 Amazon CloudWatch 来评估实例利用率并确定较小规模的实例是否合适。

为了说明这一阶段的重要性，一家大型技术客户正在执行大规模迁移，但最初并未包括迁移后的验证。在迁移 100 多台服务器后，他们发现 AWS Systems Manager 代理（SSM 代理）配置不正确。之前迁移的所有服务器都必须进行修复，迁移停滞不前。客户还发现实例的大小是最初估计值的五倍，因此他们在每个迁移浪潮结束时都实施了成本检查点。