你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
在迁移之前修正资产
在迁移评估过程中，团队会确定任何可能造成资产与所选云提供商不兼容的配置。 修正是迁移过程中检查点，可用于解决任何不兼容问题。
本文介绍一些常见的修正任务，并帮助你确定修正是否是明智的投资。
修正类型
需要在整个部署中规划两种主要类型的修正活动。
- 基于评估活动的结果
- 需要完成的修正活动，以允许副本 (replica)和部署。
- 你在评估阶段确定工作负荷评估中的这些修正活动。 必须执行这些任务，以确保可以在云中正确副本 (replica)和暂存工作负荷。
- 这主要集中在要迁移的源服务器上。
- 基于测试活动的结果
跟踪修正活动
在整个迭代过程中，可以通过评估或测试来识别工作负载的修正任务。 需要将这些任务跟踪为项目活动，以确保它们已完成。
虽然小型迁移波可以使用电子表格跟踪项目，但具有许多修正任务的较大波会生成多个项目。 可以使用 Azure DevOps 等工具创建和确定工作项的优先级，并逐步完成特定阶段，以帮助横向扩展。即使没有将 Azure DevOps 用于其他工作，也可以使用它对修正问题进行会审，并组织迁移过程的任务。
创建这些任务时，应确保将它们连接到它们受影响的工作负荷。 这样，就可以评估修正任务可能会延迟哪些工作负荷。 然后，可以按工作负荷优先级确定工作优先级。
某些问题可能会影响多个工作负荷。 这些通常是主机的项目、广泛的配置或整个登陆区域的问题。 这些问题应是第一个优先进行修正的问题。
常见修正任务
技术债务是公司环境的健康预期部分。 适合本地环境的体系结构决策可能不适合云平台。 在这两种情况下，可能都需要通过常见修正任务来准备要迁移的资产。 下面是几个示例：
- 次要主机升级：有时需要在副本 (replica)之前升级过时的主机。
- 次要来宾操作系统升级：可能需要在副本 (replica)之前修补或升级操作系统。
- 服务级别协议（SLA）修改：备份和恢复过程在云平台中发生了显著变化。 可能需要修改已迁移资产的备份过程，以确保它们继续在云中实现必要的 SLA。
- 应用程序配置更改：迁移的应用程序可能需要调整变量，例如依赖资产的网络路径、服务帐户更改或对依赖 IP 地址的更新。
- 网络路径的细微更改：需要修改路由模式，以将用户流量正确路由到新资产。 这不是到新资产的生产路由，而是一般允许正确路由到资产的配置。
大规模修正任务
正确维护、修补和更新数据中心时，无需进行修正。 修正丰富的环境往往在大型企业中很常见。 这可以包括大型 IT 缩减、旧托管服务和获取丰富的环境的组织。 在上述每个环境中，修正包括大部分迁移工作。 以下修正任务可能会频繁发生或对迁移速度或一致性产生负面影响。 如果发生这种情况，可将修正分为并行工作，团队类似于云采用和云治理。
- 频繁的主机升级：升级多个主机以完成工作负荷的迁移可能会延迟迁移团队。 隔离受影响的应用程序并解决修正步骤，然后再在任何计划版本中包括受影响的应用程序。
- 频繁的来宾操作系统升级：大型企业通常具有在过时版本的 Linux 或 Windows 上运行的服务器。 除了运行过时操作系统的安全风险之外，还存在防止迁移受影响工作负荷的不兼容问题。 当多个虚拟机（VM）需要操作系统修正时，请尝试将这些工作分离为并行迭代。 迁移工具可以在迁移过程中完成某些升级，例如 Azure Migrate 和现代化中的 Windows Server 升级 功能。
解决大规模修正问题
由于针对较小工作负荷的修正可能很简单，因此为初始迁移波选择较小的工作负荷。 随着迁移工作的成熟以及你开始处理更大的工作负载，修正可能很耗时且成本高昂。 例如，针对涉及超过 5,000 个 VM 的资产池的 Windows Server 2003 迁移的修正工作可能会延迟数月的迁移。 需要此类大规模修正后，可能需要更改迁移受影响工作负荷的计划。 在这种情况下，使修正工作价值最大化的现代化活动可能更高效和高效。
可以使用以下问题来帮助指导决策：
- 是否已在迁移积压工作 (backlog) 中标识并标注了所有受修正影响的工作负荷？
- 对于不受影响的工作负荷，迁移是否会产生类似的投资回报（ROI）？
- 是否可以根据原始迁移时间线修正受影响的资产？ 时间线更改对 ROI 有什么影响？
- 能否经济地与迁移工作并行进行资产修正？
如果未回答上述问题，请考虑以下现代化方法：
- 容器化：某些资产可以托管在容器化环境中，而无需修正。 这可能会产生不太有利的性能，并且无法解决安全性或合规性问题。
- 自动化：根据工作负载和修正要求，使用 DevOps 方法将部署脚本编写到新资产可能更具盈利性。
- 重新生成：当修正成本和业务价值同样高时，工作负荷非常适合重新生成或重新架构。