本文档可帮助您规划、设计和实现向 Google Cloud 迁移的评估阶段。通过发现工作负载和服务清单并映射它们的依赖项，可以帮助您确定需要迁移的内容和迁移顺序。在计划和设计向 Google Cloud 的迁移时，您首先需要深入了解您当前的环境以及需要迁移的工作负载。
本文档是关于迁移到 Google Cloud 的以下系列文章中的一篇：
- 迁移到 Google Cloud：使用入门
- 迁移到 Google Cloud：评估和发现您的工作负载（本文档）
- 迁移到 Google Cloud：规划和构建您的基础
- 迁移到 Google Cloud：转移您的大型数据集
- 迁移到 Google Cloud：部署您的工作负载
- 迁移到 Google Cloud：从手动部署迁移到自动容器化部署
- 迁移到 Google Cloud：优化您的环境
- 迁移到 Google Cloud：验证迁移计划的最佳实践
- 迁移到 Google Cloud：最大限度地降低费用
下图说明了迁移过程的路径。
如果您计划从本地环境、私有托管环境或其他云提供商迁移，或者您要评估迁移机会并希望探索其具体操作，那么本文档非常有用。
在评估阶段，您需要确定从来源环境迁移到 Google Cloud 的要求和依赖项。
评估阶段对于成功迁移而言至关重要。您需要深入了解需要迁移的工作负载，它们的要求和依赖项以及您当前的环境。您需要清楚自己的起点，这样才能成功地计划和执行 Google Cloud 迁移。
评估阶段包括以下任务：
- 构建一个完整的工作负载清单。
- 根据工作负载的属性和依赖项对工作负载进行分类。
- 为您的团队开展 Google Cloud 培训和指导
- 在 Google Cloud 上构建实验和概念验证。
- 计算目标环境的总拥有成本 (TCO)。
- 为工作负载选择迁移策略。
- 选择迁移工具。
- 定义迁移计划和时间表。
- 验证迁移计划。
构建工作负载清单
如需确定迁移范围，您必须先了解当前环境中存在多少项目（例如工作负载和硬件设备）及其依赖项。构建清单是一项非常重要的任务，需要花费大量的精力，尤其是在您没有任何自动编目系统的情况下。如需构建全面的清单，您需要借助于各个团队的专业技能，这些团队负责当前环境本身以及环境中每一项工作负载的设计、部署和操作。
清单不应仅局限于工作负载，它应至少包含以下内容：
- 每个工作负载的依赖项，例如数据库、消息代理、配置存储系统和其他组件。
- 支持工作负载基础架构的服务，例如源代码库、持续集成和持续部署 (CI/CD) 工具以及工件代码库。
- 虚拟服务器或物理服务器和运行时环境。
- 物理设备，例如网络设备、防火墙和其他专用硬件。
编写此清单时，您还应该收集有关每个单项的信息，包括：
- 源代码位置以及是否可以修改此源代码。
- 运行时环境中工作负载的部署方法，例如，是采用自动部署流水线还是手动部署。
- 网络限制或安全要求。
- IP 地址要求。
- 如何将工作负载公开给客户端。
- 任何软件或硬件的许可要求。
- 工作负载如何对您的身份和访问权限管理系统进行身份验证。
例如，您应该了解每个硬件设备的详细规格，例如其名称、供应商、技术以及对清单中其他项目的依赖项。例如：
- 名称：NAS 设备
- 供应商和型号：供应商 Y，模型 Z
- 技术：NFS 和 iSCSI
- 依赖项：使用巨型帧与虚拟机计算硬件进行网络连接。
该清单还应包括非技术信息，例如，您可以使用的每个项目的具体许可条款以及任何其他合规性要求。尽管有些许可允许您在云环境中部署工作负载，但其他许可则明确禁止云部署。某些许可是根据使用中的 CPU 或套接字的数量分配的，这些概念在使用云技术运行时可能不适用。您的某些数据可能对存储的地理区域存在限制。最后，某些敏感的工作负载可能需要使用单租户方式。
清单可以直观地解释您收集的数据，这非常有用。例如，您可以提供依赖关系图和表来突出显示感兴趣的方面，例如在自动或手动部署流程中如何分布工作负载。
如何构建清单
您可以通过不同的方法来构建工作负载清单。尽管开始构建的最快方法是手动构建，但是对于大型生产环境而言，这种方法可能会很困难。手动构建的清单中的信息可能很快过时，并且由于您未确认清单的内容，迁移可能会失败。
构建清单并不是一次性的工作。如果您当前的环境是高度动态的，那么您还应该花费大量精力进行自动化清单的创建和维护，以使最终环境中所有项目的视图在任何给定时间均保持一致。 如需了解如何构建工作负载清单，请参阅 Migration Center：启动资产发现。
工作负载清单示例
此示例是支持电子商务应用的环境的清单。清单中包括工作负载、依赖项、支持多个工作负载的服务以及硬件设备。
工作负载
下表重点介绍了环境中的每个工作负载最重要的技术、部署过程和其他要求。
| 名称 | 源代码位置 | 技术 | 部署过程 | 其他要求 | 依赖项 | 系统资源需求 |
|---|---|---|---|---|---|---|
| 营销网站 | 公司代码库 | Angular 前端 | 自动 | 法律部门必须对内容进行验证 | 缓存服务 | 5 个 CPU 核心 8 GB RAM |
| 后台 | 公司代码库 | Java 后端、Angular 前端 | 自动 | 不适用 | SQL 数据库 | 4 个 CPU 核心 4 GB RAM |
| 电子商务工作负载 | 专有工作负载 | 供应商 X 模型 Y 版本 1.2.0 |
手动 | 客户数据必须位于欧盟内部 | SQL 数据库 | 10 个 CPU 核心 32 GB RAM |
| 企业资源规划 (ERP) | 专有工作负载 | 供应商 Z、模型 C、版本 7.0 | 手动 | 不适用 | SQL 数据库 | 10 个 CPU 核心 32 GB RAM |
| 无状态微服务 | 公司代码库 | Java | 自动 | 不适用 | 缓存服务 | 4 个 CPU 核心 8 GB RAM |
依赖项
下表是清单中列出的工作负载的依赖项的示例。这些依赖项是工作负载正常运行所必需的。
| 名称 | 技术 | 其他要求 | 依赖项 | 系统资源需求 |
|---|---|---|---|---|
| SQL 数据库 | PostgreSQL | 客户数据必须位于欧盟内部 | 备份和归档系统 | 30 个 CPU 核心 512 GB RAM |
辅助性服务
您的环境中可能有支持多个工作负载的服务。在此电子商务示例中，有以下服务：
| 名称 | 技术 | 其他要求 | 依赖项 | 系统资源需求 |
|---|---|---|---|---|
| 源代码库 | Git | 不适用 | 备份和归档系统 | 2 个 CPU 核心 4 GB RAM |
| 备份和归档系统 | 供应商 G、模型 H、版本 2.3.0 | 根据法律规定，某些项目需要长期保存 | 不适用 | 10 个 CPU 核心 8 GB RAM |
| 持续集成工具 | Jenkins | 不适用 | 源代码库 制品库 备份和归档系统 |
32 个 CPU 核心 128 GB RAM |
| 软件工件代码库 | 供应商 A 模型 N 版本 5.0.0 |
不适用 | 备份和归档系统 | 4 个 CPU 核心 8 GB RAM |
| 批处理服务 | 在持续集成工具中运行的 Cron 作业 | 不适用 | 持续集成工具 | 4 个 CPU 核心 8 GB RAM |
| 缓存服务 | Memcached Redis |
不适用 | 不适用 | 12 个 CPU 核心 50 GB RAM |
硬件
此示例环境的硬件设备如下：
| 名称 | 技术 | 其他要求 | 依赖项 | 系统资源需求 |
|---|---|---|---|---|
| 防火墙 | 供应商 H 模型 V |
不适用 | 不适用 | 不适用 |
| 服务器 j 的实例 | 供应商 K 模型 B |
已不再受到支持，因此必须停用 | 不适用 | 不适用 |
| NAS 设备 | 供应商 Y 模型 Z NFS iSCSI |
不适用 | 不适用 | 不适用 |
评估您的部署和运营流程
请务必清楚了解部署和运营流程的工作原理。这些流程是准备和维护生产环境以及在其中运行的工作负载的实践的基本组成部分。
部署和运营流程可能会构建工作负载正常运行所需的工件。因此，您应该收集有关每种工件类型的信息。例如，工件可以是操作系统软件包、应用部署包、操作系统映像、容器映像或其他类型。
除了工件类型之外，请考虑如何完成以下任务：
- 开发工作负载。评估开发团队为构建工作负载而制定的流程。例如，您的开发团队如何设计、编写和测试工作负载？
- 生成您在来源环境中部署的工件。为了在来源环境中部署工作负载，您可能会生成可部署的工件（例如容器映像或操作系统映像），或者您可能会通过安装和配置软件来自定义现有工件（例如第三方操作系统映像）。收集有关如何生成这些工件的信息有助于确保生成的工件适合在 Google Cloud 中部署。
存储工件。如果您生成存储在来源环境的 Artifact Registry 中的工件，则需要在 Google Cloud 环境中提供这些工件。为此，您可以使用以下策略：
- 在环境之间建立通信通道：使来源环境中的工件可从目标 Google Cloud 环境进行访问。
- 重构工件构建流程：完成来源环境的小幅度重构，以便在来源环境和目标环境中存储工件。此方法通过在目标 Google Cloud 环境中实现工件构建流程之前先构建工件制品库等基础架构来支持迁移。您可以直接实现此方法，也可以在上述先建立通信通道方法的基础上进行构建。
通过在来源环境和目标环境中均提供工件，您可以专注于迁移，而无需在迁移过程中在目标 Google Cloud 环境中实现工件构建流程。
扫描代码并签名。在工件构建流程中，您可能会使用代码扫描来帮助防范常见漏洞和意外的网络泄露，并使用代码签名来帮助确保只有受信任的代码在您的环境中运行。
在来源环境中部署工件。生成可部署的工件后，您可能会将其部署到来源环境中。建议您评估每个部署流程。评估有助于确保您的部署流程与 Google Cloud 兼容。它还有助于您了解最终重构流程所需的工作量。例如，如果部署流程仅适用于来源环境，则可能需要重构它们，从而以您的 Google Cloud 环境为目标。
注入运行时配置。您可能会注入特定集群、运行时环境或工作负载部署的运行时配置。该配置可能会初始化环境变量和其他配置值，例如 Secret、凭据和密钥。为帮助确保运行时配置注入过程在 Google Cloud 上正常运行，建议您评估如何配置在来源环境中运行的工作负载。
日志记录、监控和剖析。评估您实施来监控来源环境的健康、相关指标以及您如何使用这些流程提供的数据的日志记录、监控和剖析流程。
集群身份验证。评估您如何向来源环境进行身份验证。
预配和配置您的资源。为了准备来源环境，您可能设计并实现了预配和配置资源的流程。例如，您可能会使用 Terraform 以及配置管理工具在来源环境中预配和配置资源。
评估您的基础设施
评估部署和运营流程后，我们建议您评估在来源环境中支持工作负载的基础设施。
如需评估该基础设施，请考虑以下事项：
- 您如何在来源环境中组织资源。例如，某些环境支持使用将资源组彼此隔离的构造（例如组织、项目和命名空间）在资源之间实现逻辑隔离。
- 您如何将某个环境连接到其他环境（例如本地环境）和其他云服务提供商。
对工作负载进行分类
完成清单构建后，您需要按不同的类别组织工作负载。此分类可以帮助您根据迁移到云的工作负载的复杂性和风险来确定其优先级。
对于您要在环境中考虑的每个评估标准，目录矩阵都应具有一个维度。选择一组涵盖您环境的所有要求的标准，包括每个工作负载需要的系统资源。例如，您可能想知道某个工作负载是否具有任何依赖项，或者它是无状态的还是有状态的。在设计目录矩阵时，您应考虑为每个添加的标准另行添加一个用于表示的维度。这样生成的矩阵可能难以可视化。一个可能的解决方案是使用多个较小的矩阵，而不是单个复杂的矩阵。
另外，在每个工作负载旁边，您应添加一个迁移复杂性指示器。该指示器用以估计每个工作负载迁移的难度等级。指示器的类别粒度取决于您的环境。举个基本的例子，您可能有 3 个类别：易于迁移、难以迁移或无法迁移。要完成这一活动，您需要专家为清单中的每个项目估算其迁移的复杂性。每个企业造成迁移复杂性的因素都是不同的。
目录完成后，您还可以构建可视化内容和图表来帮助您和您的团队快速评估感兴趣的指标。例如，绘制图形以突出显示有多少个组件具有依赖项或者每个组件的迁移难度。
如需了解如何构建工作负载清单，请参阅 Migration Center：启动资产发现。
工作负载目录示例
此示例使用了以下评估标准，每个矩阵轴应用一个评估标准：
- 工作负载对业务的重要性。
- 工作负载是否具有依赖项，或者是否作为其他工作负载的依赖项。
- 工作负载允许的最长停机时间。
- 工作负载的迁移难度。
| 对业务的重要性 | 没有依赖项或从属项 | 有依赖项或从属项 | 允许的最长停机时间 | 难度 |
|---|---|---|---|---|
| 任务关键型 | 无状态微服务 | 2 分钟 | 简单 | |
| ERP | 24 小时 | 困难 | ||
| 电子商务工作负载 | 无停机时间 | 困难 | ||
| 硬件防火墙 | 无停机时间 | 无法迁移 | ||
| SQL 数据库 | 10 分钟 | 简单 | ||
| 源代码库 | 12 小时 | 简单 | ||
| 非任务关键型 | 营销网站 | 2 小时 | 简单 | |
| 备份和归档 | 24 小时 | 简单 | ||
| 批处理服务 | 48 小时 | 简单 | ||
| 缓存服务 | 30 分钟 | 简单 | ||
| 后台 | 48 小时 | 困难 | ||
| 持续集成工具 | 24 小时 | 简单 | ||
| 软件工件代码库 | 30 分钟 | 简单 |
如需在目录中直观呈现结果，可以构建可视化内容和图表。下表突出显示了迁移难度：
在上图中，大多数工作负载易于迁移，三个工作负载难以移动，一个工作负载无法移动。
在组织中讲解 Google Cloud
如果要做到充分利用 Google Cloud，您的组织需要开始学习你们可在 Google Cloud 上使用的服务、产品和技术。您的员工可使用包含赠金的 Google Cloud 免费试用账号进行实验和学习。创建一个免费的测试和学习环境对于员工的学习体验至关重要。
您可以考虑以下几种培训方案：
- 公共和开放资源：您可以通过免费的动手实验、视频系列、Cloud OnAir 在线讲座和 Cloud OnBoard 培训活动开始学习 Google Cloud。
- 深入的课程：如果您想更深入地了解 Google Cloud 的工作原理，您可以按自己的进度在线参加 Google Cloud Skills Boost 自助式培训课程或 Coursera 的 Google Cloud 专业培训，您也可以参加我们全球授权培训伙伴提供的课堂培训。这些课程通常需要一到几天。
- 基于角色的学习路径：您可以根据工程师在组织中的角色对其进行培训。例如，您可以培训工作负载开发者或基础设施运维人员，指导他们如何充分利用 Google Cloud 服务。
您还可以通过不同级别的各种认证来certify您的工程师对 Google Cloud 的了解程度：
- 助理认证：Google Cloud 新手进行专业认证的基础，例如 Associate Cloud Engineer 认证。
- 专业认证：如果您要凭借多年经验评估 Google Cloud 的高级设计和实施技能，则您可以获取认证，例如 Professional Cloud Architect 或 Professional Data Engineer。
- Google Workspace 认证：您可以通过 Google Workspace 认证来演示使用 Google Workspace 工具进行协作的技能。
- Apigee 认证：您可以通过 Apigee 认证的 API 工程师认证，证明自己设计和开发强大、安全且可扩缩 API 的能力。
- Google Developers 认证：您可以通过 Associate Android Developer（正在更新此认证）和 Mobile Web Specialist 认证，证明自己的开发技能。
除了培训和认证，获得 Google Cloud 经验的最佳方法之一就是开始使用该产品来构建业务概念验证。
试验和设计概念验证
如需展示 Google Cloud 的价值和效率，请考虑为工作负载目录中每个类别的工作负载设计和开发一个或多个概念验证 (PoC)。通过实验和测试，您可以验证假设并向企业领导者展示云的价值。
您的 PoC 应至少包括以下内容：
- 工作负载支持的应用场景的完整列表，包括不常见的应用场景和特殊场景。
- 各个应用场景的所有要求，例如性能、可伸缩性和一致性要求、故障切换机制以及网络要求。
- 您需要调查和测试的技术和产品的潜在清单。
您应该设计 PoC 和实验来验证清单中的所有用例。每个实验都应具有精确的有效性上下文、范围、预期输出以及可衡量的业务影响。
例如，如果您需要快速扩缩一个受 CPU 约束的工作负载来满足峰值需求，您可以运行一个实验来验证某可用区内能否创建多个虚拟 CPU 核心以及操作所用时长。如果您体验到增值明显，例如新工作负载扩容耗时与当前环境相比减少了 95%，那么此实验就可证明该设计具有即时的业务价值。
如果您想将本地数据库的性能与 Cloud SQL、Spanner、Firestore 或 Bigtable 的性能进行比较，您可以实施一个 PoC，让同一业务逻辑使用不同的数据库。此 PoC 帮助您以较低的风险从多个拥有不同基准和运营费用的产品中找出适合您的工作负载的代管式数据库解决方案。
如果您需要在 Google Cloud 中评估虚拟机预配过程的性能，您可以使用第三方工具（例如 PerfKit Benchmarker），并将 Google Cloud 与其他云服务商进行比较。除了报告峰值性能的标准指标（包括延迟时间、吞吐量和完成时间）以外，您还可以衡量端到端的云资源预配时间。例如，您可能想了解预配多个 Kubernetes 集群需要多长时间和多少工作量。PerfKit Benchmarker 是一项开源社区工作，参与者达 500 多名，例如研究人员、学术机构和包括 Google 在内的公司。
计算总拥有成本
如果您清楚了解新环境中所需的资源，就可以构建总拥有成本模型，将 Google Cloud 上产生的费用与您的当前环境产生的费用进行比较。
构建此成本模型时，您不仅应考虑硬件和软件的费用，还应考虑运行您的数据中心所需的所有运营成本，例如电源、散热、维护和其他支持服务。得益于 Google Cloud 资源的弹性可扩缩性，与欠缺灵活性的本地数据中心相比 Google Cloud 产品通常更容易降低费用。
在考虑云迁移时，使用云网络产生的费用通常会被忽略。在数据中心中，购买网络基础架构（例如路由器和交换机），然后运行适当的网络布线时产生的费用是一次性费用，之后您可以使用网络的全部容量。在云环境中，您可以通过多种方式为网络使用量付费。对于数据密集型工作负载或产生大量网络流量的工作负载，您可能需要考虑新的架构和网络流来降低云端的网络费用。
Google Cloud 还提供了各种选项，帮助您智能地扩缩资源和费用。例如，在 Compute Engine 中，您可以在使用 Migrate for Compute Engine 进行迁移期间、或在虚拟机已运行后、或在构建自动扩缩实例组时进行合理调整。这些选项可能会极大地影响正在运行的服务的费用，因此应探讨它们，计算总拥有成本 (TCO)。
如需计算 Google Cloud 资源的总费用，您可以使用价格计算器。
为工作负载选择迁移策略
对于要迁移的每个工作负载，请评估并选择最适合其应用场景的迁移策略。例如，您的工作负载可能具有以下条件：
- 它们无法容忍任何停机时间或数据丢失，例如任务关键型工作负载。对于这些工作负载，您可以选择零停机时间或接近零停机时间的迁移策略。
- 它们可以容忍停机时间，例如辅助或后端工作负载。对于这些工作负载，您可以选择需要停机时间的迁移策略。
当您选择迁移策略时，请考虑与需要停机时间的迁移策略相比，零停机时间和接近零停机时间的迁移策略的设计和实施通常更昂贵且更复杂。
选择迁移工具
为工作负载选择迁移策略后，请查看并确定迁移工具。
您可以使用许多迁移工具，每个工具都针对特定迁移应用场景进行了优化。应用场景可能包括：
- 迁移策略
- 来源环境和目标环境
- 数据和工作负载大小
- 数据和工作负载更改的频率
- 是否可以使用托管式服务进行迁移
如需确保无缝迁移和切换，您可以使用应用部署模式、基础架构编排和自定义迁移应用。不过，名为“托管式迁移服务”的专用工具可以简化将数据、工作负载甚至整个基础架构从一个环境迁移到另一个环境的过程。借助这些功能，它们可以封装复杂的迁移逻辑并提供迁移监控功能。
定义迁移计划和时间表
现在您已经详细了解了您当前的环境，接下来需要通过以下方式完成迁移计划：
- 将要迁移的工作负载和数据分组为批次（在某些上下文中也称为 Sprint）。
- 选择迁移批次的顺序。
- 选择在每个批次中迁移工作负载的顺序。
在迁移计划中，我们还建议您生成以下文档：
- 技术设计文档
- RACI 矩阵
- 时间表（例如倒计时计划）
随着您获得 Google Cloud 方面的经验、迁移发展势头以及对您环境的了解，您可以执行以下操作：
- 优化要迁移的工作负载和数据的分组。
- 增加迁移批次的大小。
- 更新批次和批次内工作负载的迁移顺序。
- 更新批次的组成部分。
如需将要迁移的工作负载和数据分组为批次，并定义迁移顺序，您需要根据多种标准评估工作负载，例如：
- 工作负载的业务价值。
- 与基础架构的其余部分相比，工作负载是否能以独特的方式部署或运行。
- 负责开发、部署和运营工作负载的团队。
- 工作负载依赖项的数量、类型和范围。
- 使工作负载在新环境中工作的重构工作量。
- 工作负载的合规性和许可要求。
- 工作负载的可用性和可靠性要求。
先迁移的工作负载是可使您的团队积累 Google Cloud 相关知识和经验的工作负载。在您的团队拥有更多的云资源和经验后，就可降低在迁移阶段出现问题的风险，并使后续迁移更加轻松快捷。因此，选择合适的“先驱”对于成功迁移至关重要。
为企业带来的价值
选择非任务关键型的工作负载可以保护您的主要业务线不受到迁移影响，并在您的团队学习云技术时降低未发现的风险和错误对业务的影响。例如，如果您选择将电子商务工作负载的主要财务交易逻辑作为“先驱”组件进行迁移，则在迁移过程中发生的任何错误都可能对您的主要业务线产生影响。对于“先驱”组件，支持工作负载的 SQL 数据库或者暂存数据库是更好的选择。
您应该避免很少使用的工作负载。例如，如果您选择的工作负载每年仅被少数用户使用几次，虽然迁移该工作负载的风险很低，但它不会带来多少益处，并且可能难以检测和响应问题。
边缘用例
您还应避免边缘场景，以便发现适用于其他工作负载的迁移模式。选择“先驱”的主要目标是获得组织中常见模式的经验，以便建立知识库。您可以在后续迁移未来的工作负载时应用在迁移这些“先驱”工作负载过程中学到的知识。
例如，如果您的大多数工作负载是按照测试驱动型开发方法设计的，并使用 Python 编程语言开发的，那么倘若选择测试覆盖范围小且使用 Java 编程语言开发的工作负载，则无法发现可在迁移 Python 工作负载时应用的任何模式。
团队
在选择“先驱”时，请注意负责每个工作负载的团队。负责“先驱”工作负载的团队应有上进心，并渴望试用 Google Cloud 及其服务。此外，业务领导者要为“先驱”团队制定明确的目标，并在整个过程中积极赞助和支持他们。
例如，一个很好的候选“先驱”团队是在总部工作、表现优良且具有落实现代化开发实践（如 DevOps）和网站可靠性工程的丰富经验的团队。如果该团队还拥有自上而下的领导层支持者，并且在每次工作负载迁移过程中都制定了明确的目标，他们将是非常出色的候选团队。
依赖项
此外，您要专注于最不依赖其他工作负载或服务的工作负载。如果您的 Google Cloud 经验有限，那么迁移没有依赖项的工作负载将更加容易。
如果必须选择依赖于其他组件的工作负载，请选择与依赖项松散耦合的工作负载。如果某个工作负载已经针对其依赖项最终将不可用进行了设计，那么在将工作负载迁移到目标环境时，可以减少麻烦。例如，松散耦合的候选工作负载可以是通过使用消息代理进行通信的工作负载，或者是离线使用的工作负载，或者是经过专门设计可容忍其余基础架构不可用的工作负载。
尽管有一些迁移有状态工作负载数据的策略，无状态工作负载很少需要进行数据迁移。无状态工作负载的迁移更容易一些，因为您无需担心临时阶段。在该阶段，部分数据位于当前环境中，另一部分位于目标环境中。例如，无状态微服务是很好的候选“先驱”，因为它们不依赖任何本地有状态数据。
重构工作量
“先驱”需要的重构工作量应该是最少的，因此您可以专注于迁移本身和 Google Cloud，无需花费大量精力来更改工作负载的代码和配置。重构的重点应该是进行必要的更改，让您的工作负载能够在目标环境中运行，而不是将重心放在现代化和优化工作负载方面，这两项任务将在后续迁移阶段中进行。
例如，只需要更改配置的工作负载可以作为一个很好的“先驱”，因为您无需对代码库实施任何更改，并且可以使用现有的工件。
许可与合规性
工作负载的许可在选择“先驱”时也需要考虑，因为您的某些工作负载许可的条款可能会影响迁移。例如，某些许可明确禁止在云环境中运行工作负载。
在检查许可条款时，请不要忘记合规性要求，因为您可能对某些工作负载有单租户要求。出于这些原因，您应选择许可和合规性限制最少的工作负载作为“先驱”。
例如，您的客户可能有合法权利选择存储其数据的区域，或者客户的数据可能仅限于特定区域。
可用性和可靠性
好的“先驱”不受切换时段造成的停机时间的影响。如果选择对可用性有严格要求的工作负载，则必须实施零停机时间数据迁移策略（例如 Y [写入和读取]），或者开发数据访问微服务。虽然可采用这种方法，但这会导致您的团队没法专心获得必要的 Google Cloud 经验，因为他们必须花时间实施此类策略。
例如，与用户在其中最终完成交易的电子商务网站上面向客户的工作负载相比，批处理引擎的可用性要求可以容忍更长的停机时间。
验证迁移计划
在采取行动开始实施迁移计划之前，我们建议您先验证其可行性。如需了解详情，请参阅用于验证迁移计划的最佳实践。
后续步骤
- 了解如何在 Google Cloud 上规划迁移并构建基础。
- 了解何时寻求迁移帮助。
- 如需查看更多参考架构、图表和最佳实践，请浏览 Cloud 架构中心。
贡献者
作者：Marco Ferrari | 云解决方案架构师