发现现有工作负荷清单

本节适用于在非 Azure 环境中运行现有 IT 工作负荷（在本地或其他云端）需要迁移到 Azure 的组织。 全面的工作负荷清单是此类组织的坚实云采用计划的基础。 如果不知道系统是否存在或理解其特征，则无法决定如何迁移系统。 云采用计划必须包括发现所有工作负载、收集有关每个工作负荷的关键数据以及确定迁移优先级的步骤。

发现工作负荷清单

技术资产的完整清单构成了云采用计划的基础。 清单可识别环境中的所有系统、应用程序和基础结构组件。 需要此清单来确定哪种 云迁移策略 最合适。

1. 定义每个工作负荷及其边界。 工作负荷是支持一个或多个业务流程的 IT 组件集合，例如服务器、虚拟机（VM）、云服务、应用程序、代码、数据或设备。 需要定义每个工作负载，以了解其业务价值和技术占用情况。 这种清晰度有助于确定迁移和现代化工作的优先级。 使用网络流量监视和依赖项映射工具识别工作负荷边界并可视化组件之间的关系。

2. 使用自动发现工具。Azure Migrate 为本地和云环境提供免费发现功能。 此工具会自动标识服务器、应用程序及其相互依赖性。 必须使用自动发现来加速库存创建并减少手动错误。 如果 Azure Migrate 不完全支持环境，请使用扩展 Azure Migrate 功能的工具（如 Dr Migrate 或 CloudPilot ）。

3. 在所有环境中包括所有组件。 您的清单必须在所有平台上捕获基础设施和应用程序组件。 需要包括来自 Azure、AWS、Google Cloud 和其他提供商的服务器、VM、应用程序、数据库、通信模式、集成、标识和云服务。 此全面视图可确保在规划或迁移期间不会忽略任何关键资产。

4. 如果无法实现自动化，请使用手动发现。 某些环境因安全策略或技术限制而限制自动发现工具。 使用 Azure Migrate 导入模板 在受限环境中手动记录资产。 手动文档可确保捕获自动化工具无法访问的资产。

按业务价值和可行性确定工作负荷的优先级

长存货清单可能让人感到压力。 该计划应包括一种方法，用于确定哪些工作负载优先处理云采用工作。 并非所有工作负荷都同样重要或同样适合立即迁移，因此请使用优先顺序框架。

1. 按业务关键性排序。 根据工作负荷对业务运营、收入或客户体验的关键程度进行排名。 通常，一些工作负荷是任务关键型（如果工作负荷下降，主要业务损失），而另一些工作负荷则不太关键。 高业务价值系统可能是高优先级，以确保它们受益于云可伸缩性或复原能力，或者如果迁移它们的风险过高，有时优先级较低。

2. 估计云就绪情况。 根据你的已有了解，快速、高层次地评估每个工作负荷准备就绪的程度以进行云迁移。 稍后会进行详细的技术评估，但目前，请考虑技术复杂性、旧组件和已知风险等因素。 部分工作负载可能是易实现的目标，部分则需大量重构。 可以优先考虑更简单的工作负荷来构建势头，或选择适度复杂的高价值系统，以最大程度地提高早期成功率。

3. 请注意依赖项。 在此阶段，使用现有知识评估高级别的依赖项。 稍后会完成完全依赖关系映射，但目前确定与其他工作负载紧密耦合的工作负载。 可能需要一起迁移具有许多连接的系统，以避免中断。 在某些情况下，低优先级工作负荷可能需要提前移动，因为高优先级系统依赖于它。 使用此见解将相关工作负荷分组到逻辑迁移波中。

4. 考虑战略一致性。 如果某些工作负荷是战略计划的关键，您可能会优先考虑它们以便更快推进。 相反，即将被淘汰或替换的工作负载不应优先迁移。

5. 创建一个优先级待办事项列表。 此积压可以是一个带有类别的列表或表格，例如“第1波：工作负载A、B、C。第2波：工作负载D、E。”请确保与利益相关者一起验证此排序。 业务和 IT 所有者应审查并同意顺序有意义。 你希望得到他们的认可，避免将来的反对意见。 例如，如果你在没有他们参与的情况下将部门的关键应用安排在最后，他们可能会表示反对。 根据反馈调整计划，以平衡技术逻辑与业务需求。

收集每个工作负荷的业务详细信息

对于每个识别出的工作负荷，该计划应记录关键业务背景和需求。 此信息将指导迁移策略（下一部分），并确保决策符合业务需求。 需要记录的重要细节

1. 所有者与利益相关者：从业务角度（如 CRM 的销售副总裁）和 IT 角度（应用负责人、基础设施负责人）记录谁“拥有”该工作负载。 列出必须参与规划其移动的所有利益干系人。

2. 业务功能和关键性：记录工作负荷的作用，以及它的重要性。 记录其用途的简短说明，并对其关键级别（高/中/低）进行分类。 关键性通常与可以容忍多少停机时间联系在一起。

3. 数据敏感度和符合性：请注意系统处理的数据分类（公共、内部、机密、高度机密）。 记录适用于此工作负荷的符合性要求（PCI、HIPAA、GDPR）。 例如，如果某个区域需要数据驻留，则影响其云体系结构。

4. 作约束：记录特定的维护时段、停电期（高流量时段）和运行时间要求。 记录任何此类约束，因为它们会影响迁移计划和目标体系结构（高可用性需求）。

5. 预计的时间线或截止时间：如果有迁移此工作负荷的期望时间线，请注明。 例如，你可能有合同续约或数据中心租约即将结束。 这些因素会纳入总体路线图时间安排。

有关示例，请参阅 迁移采用计划。

Azure 发现和评估工具和资源

后续步骤