本文档可帮助您规划、设计和实现向 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 培训和指导您的团队。
- 针对 Google Cloud 构建实验和概念验证。
- 计算目标环境的总拥有成本 (TCO)。
- 选择您首先要迁移的工作负载。
构建您的应用清单
如需确定迁移范围，您必须先了解当前环境中存在多少项目（例如应用和硬件设备）及其依赖项。构建清单是一项非常重要的任务，需要花费大量的精力，尤其是在您没有任何自动编目系统的情况下。如需构建全面的清单，您需要借助于各个团队的专业技能，这些团队负责当前环境本身以及环境中每一项工作负载的设计、部署和操作。
清单不应仅局限于应用，它应至少包含以下内容：
- 每个应用的依赖项，例如数据库、消息代理、配置存储系统和其他组件。
- 支持应用基础架构的服务，例如源代码库、持续集成 (CI) 工具和软件工件代码库。
- 虚拟服务器或物理服务器和运行时环境。
- 物理设备，例如网络设备、防火墙和其他专用硬件。
编写此清单时，您还应该收集有关每个单项的信息，包括：
- 源代码位置以及是否可以修改此源代码。
- 运行时环境中工作负载的部署方法，例如，是采用自动部署流水线还是手动部署。
- 网络限制或安全要求。
- IP 地址要求。
- 您如何将工作负载公开给客户端。
- 任何软件或硬件的许可要求。
- 工作负载如何针对身份和访问权限管理系统进行身份验证。
例如，您应该了解每个硬件设备的详细规格，例如其名称、供应商、技术以及对清单中其他项目的依赖项。例如：
- 名称：NAS 设备
- 供应商和型号：供应商 Y，模型 Z
- 技术：NFS 和 iSCSI
- 依赖项：使用巨型帧与虚拟机计算硬件进行网络连接。
该清单还应包括非技术信息，例如，您可以使用的每个项目的具体许可条款以及任何其他合规性要求。尽管有些许可允许您在云环境中部署应用，但其他许可则明确禁止云部署。某些许可是根据使用中的 CPU 或套接字的数量分配的，这些概念在使用云技术运行时可能不适用。您的某些数据可能对存储的地理区域存在限制。最后，某些敏感的工作负载可能需要使用单租户方式。
清单可以直观地解释您收集的数据，这非常有用。例如，您可以提供依赖关系图和表来突出显示感兴趣的方面，例如在自动或手动部署流程中如何分布应用。
如何构建清单
构建应用清单有很多不同方法。尽管开始构建最快的方法是手动构建，但是对于大型生产环境而言，这种方法可能会很困难。手动构建的清单中的信息可能很快过时，而由于基于错误的假设，迁移可能会失败。
构建清单并不是一次性的工作。如果您当前的环境是高度动态的，那么您还应该花费大量精力进行自动化清单的创建和维护，以使最终环境中所有项目的视图在任何给定时间均保持一致。 如需了解如何构建应用清单，请参阅迁移中心：启动资产发现。
此外，Google 还与多家公司达成合作，帮助您完成迁移过程。如需了解详情，请参阅寻求帮助。
应用清单示例
此示例是支持电子商务应用的环境的清单。清单中包括应用、依赖项、支持多个应用的服务以及硬件设备。
应用
下表重点介绍了环境中的每个应用最重要的技术、部署过程和其他要求。
| 名称 | 源代码位置 | 技术 | 部署过程 | 其他要求 | 依赖项 | 系统资源需求 |
|---|---|---|---|---|---|---|
| 营销网站 | 公司代码库 | 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，以及它们如何帮助您缩小迁移范围和风险。例如，您可以重构工件构建流程，以便在迁移过程中将工件存储在来源环境和 Google Cloud 中。通过在这两种环境中使用工件，您可以专注于将工作负载和数据从来源环境迁移到 Google Cloud，而无需在迁移过程开始时在目标 Google Cloud 环境中实现工件构建流程。
评估您的基础架构
在评估部署和操作流程后，我们建议您评估当前支持来源环境中的工作负载的基础架构。
如需评估该基础架构，请考虑以下事项：
- 您预配工作负载所需的资源（例如基础架构即代码）的过程。
- 您组织来源环境中的资源的方式。例如，某些环境使用将资源组（例如组织和项目）隔离开来的构造支持资源之间的逻辑分离。
- 如何将环境连接到其他环境（例如本地环境和其他云服务商）。
对应用进行分类
完成清单构建后，您需要将应用分为不同的类别。此分类可以帮助您根据迁移到 GCP 的应用的复杂性和风险来确定其优先级。
对于您要在环境中考虑的每个评估标准，目录矩阵都应具有一个维度。选择一组涵盖您环境的所有要求的标准，包括每个应用需要的系统资源。例如，您可能想知道某个应用是否具有任何依赖项，或者它是无状态的还是有状态的。在设计目录矩阵时，您应考虑为每个添加的标准另行添加一个用于表示的维度。这样生成的矩阵可能难以可视化。一个可能的解决方案是使用多个较小的矩阵，而不是单个复杂的矩阵。
另外，在每个应用旁边，您应添加一个迁移复杂性指示器。该指示器会估计每个应用迁移的难度等级。指示器的粒度取决于您的环境。举个基本的例子，您可能有 3 个类别：容易迁移、难以迁移或无法迁移。要完成这一活动，您需要专家为清单中的每个项目估算其迁移的复杂性。每个企业造成迁移复杂性的因素都是不同的。
目录完成后，您还可以构建可视化内容和图表来帮助您和您的团队快速评估感兴趣的指标。例如，绘制图形以突出显示有多少个组件具有依赖项或者每个组件的迁移难度。
如需了解如何构建应用清单，请参阅迁移中心：启动资产发现。
应用目录示例
此示例使用了以下评估标准，每个矩阵轴应用一个评估标准：
- 应用对业务的重要性。
- 一个应用是否具有依赖项，或者是否作为其他应用的依赖项。
- 应用的允许停机时间上限。
- 应用的迁移难度。
| 对业务的重要性 | 没有依赖项或从属项 | 有依赖项或从属项 | 允许的停机时间上限 | 难度 |
|---|---|---|---|---|
| 任务关键型 | 无状态微服务 | 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 服务。
您还可以通过不同级别的各种认证来证明您的工程师对 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 资源的总费用，您可以使用价格计算器。
选择先迁移的应用
现在您已经详细了解了您当前的环境，接下来需要选择要迁移的应用的初始顺序来完成迁移计划。在您拥有了 Google Cloud 使用经验并了解您的环境和应用之后，您可以在迁移过程中优化此顺序。
先迁移的应用是可使您的团队积累 Google Cloud 相关知识和经验的应用。在您的团队拥有更多的云资源和经验后，就可降低在迁移阶段出现问题的风险，并使后续迁移更加轻松快捷。因此，选择合适的“先驱”对于成功迁移至关重要。您可以选择一个应用，也可以将多个应用矩阵中的多个应用添加到“先驱”列表。
确定“先驱”的工作很复杂，但是您可以参考以下一些标准：
- 应用的业务价值。
- 与其他基础架构相比，应用是否能以独特的方式部署或运行。
- 负责开发、部署和运营应用的团队。
- 应用依赖项的数量、类型和范围。
- 使应用在新环境中工作的重构工作量。
- 应用的合规性和许可要求。
- 应用的可用性和可靠性要求。
为企业带来的价值
选择非任务关键型的应用可以保护您的主要业务线不受到迁移影响，并在您的团队学习云技术时降低未发现的风险和错误对业务的影响。例如，如果您选择将电子商务应用的主要财务交易逻辑作为“先驱”组件进行迁移，则在迁移过程中发生的任何错误都可能对您的主要业务线产生影响。对于“先驱”组件，支持应用的 SQL 数据库或者模拟环境数据库是更好的选择。
您应该避免选择很少使用的应用。例如，如果您选择的应用每年仅被少数用户使用几次，虽然迁移该应用的风险很低，但它不会带来多少益处，并且可能难以检测和响应问题。
边缘用例
您还应避免边缘用例，以便发现适用于其他应用的迁移模式。选择“先驱”的主要目标是获得组织中常见模式的经验，以便建立知识库。您可以在后续迁移未来的应用时重新应用在迁移这些“先驱”应用过程中学到的知识。
例如，如果您的大多数应用是按照测试驱动开发方法设计的，并使用 Python 编程语言开发的，那么倘若选择测试覆盖范围小且使用 Java 编程语言开发的应用，则没法发现可在迁移 Python 应用时运用的任何模式。
团队
在选择“先驱”应用时，请注意负责每个应用的团队。负责“先驱”应用的团队要有很强的上进心，而且渴望试用 Google Cloud 及其服务。此外，业务领导者要为“先驱”团队制定明确的目标，并在整个过程中积极赞助和支持他们。
例如，一个很好的候选“先驱”团队是在总部工作、表现优良且具有落实现代化开发实践（如 DevOps）和网站可靠性工程的丰富经验的团队。如果该团队还拥有自上而下的领导层支持者，并且在每次应用迁移过程中都制定了明确的目标，他们将是非常出色的候选团队。
依赖项
另外，您要专注于最不依赖其他应用或服务的应用。如果您的 Google Cloud 经验有限，那么迁移没有依赖项的应用将更加容易。
如果必须选择依赖于其他组件的应用，请选择与依赖项松散耦合的应用。如果某个应用已经针对其依赖项最终将不可用进行了设计，那么在将应用迁移到目标环境时，可以减少麻烦。例如，松散耦合的候选应用可以是通过使用消息代理进行通信的应用，或者是离线使用的应用，或者是经过专门设计可承受其余基础架构不可用的应用。
尽管有一些迁移有状态应用数据的策略，无状态应用很少需要进行数据迁移。无状态应用的迁移更容易一些，因为您无需担心临时阶段。在该阶段，部分数据位于当前环境中，另一部分位于目标环境中。例如，无状态微服务是很好的候选“先驱”，因为它们不依赖任何本地有状态数据。
重构工作量
“先驱”需要的重构工作量应该是最少的，因此您可以专注于迁移本身和 Google Cloud，无需花费大量精力来更改应用的代码和配置。重构的重点应该是进行必要的更改，让您的应用能够在目标环境中运行，而不是将重心放在现代化和优化应用方面，这两项任务将在后续迁移阶段中进行。
例如，只需要更改配置的应用可以作为一个很好的“先驱”，因为您无需对代码库实施任何更改，并且可以使用现有的工件。
许可与合规性
应用的许可在选择“先驱”时也需要考虑，因为您的某些应用许可的条款可能会影响迁移。例如，某些许可明确禁止在云环境中运行应用。
在检查许可条款时，请不要忘记合规性要求，因为您可能对某些应用有单租户要求。出于这些原因，您应选择许可和合规性限制最少的应用作为“先驱”。
例如，您的客户可能有合法权利选择存储其数据的地区，或者客户的数据可能仅限于特定地区。
可用性和可靠性
好的“先驱”不受切换时段造成的停机时间的影响。如果选择对可用性有严格要求的应用作为“先驱”，则必须实施零停机时间数据迁移策略（例如 Y [写入和读取]），或者开发数据访问微服务。虽然可采用这种方法，但这会导致您的团队没法专心获得必要的 Google Cloud 经验，因为他们必须花时间实施此类策略。
例如，与用户在其中最终完成交易的电子商务网站上面向客户的应用相比，批处理引擎的可用性要求可以承受更长的停机时间。
后续步骤
- 了解如何在 Google Cloud 上规划迁移和构建基础。
- 了解如何寻求迁移帮助。
- 探索有关 Google Cloud 的参考架构、图表和最佳实践。查看我们的 Cloud Architecture Center。