迁移到 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 的授权对 IT 部门的支持程度。
  • 扩缩。您使用云原生服务的程度，以及您目前落实的操作自动化的程度。
  • 安全。保护您的当前环境免遭未经授权和不当访问侵害的能力。

根据框架，您在每个主题中应处于下列三个阶段之一：

  • 战术。尚无一致的计划能涵盖您目前所有单独的工作负载。您最感兴趣的是快速获得投资回报并使您的 IT 组织几乎不受干扰。
  • 战略。已有计划开发单个工作负载，同时着眼于未来的扩缩需求。您感兴趣的是中期目标，即简化操作，使其比当前更高效。
  • 转型。云操作运行顺畅，您使用从运行过程中收集到的数据来改进您的 IT 业务。您注重长期目标，试图将 IT 部门打造成组织中的创新引擎之一。

根据这三个阶段评估上面四个主题时，会得到云成熟度量表。在每个主题中，您都能看到从在需要时采用新技术转为在整个组织中更有战略性地运用这些技术时会发生什么情况 - 这一转型意味着为您的团队提供更深入、更全面、更一致的培训。

迁移路径

请务必记住迁移是一段旅程。您与您的现有基础架构和环境位于 A 点，并希望到达 B 点。为了从 A 到 B，您可以选择上述任何选项。

下图说明了此旅程的路径。

迁移路径包含四个阶段。

迁移包含 4 个阶段：

  • 评估。在此阶段，您将对现有环境进行全面评估和发现，以便了解应用和环境库存、确定应用依赖项和需求、计算总拥有成本并建立应用性能基准。
  • 规划。在此阶段，您将为工作负载创建基本的云基础架构，并规划移动应用的方式。该项规划包括身份管理、组织和项目结构、网络连接、应用排序和优先迁移战略的制定。
  • 设计。在此阶段，您将设计、实施和执行将工作负载迁移到 Google Cloud 的部署过程。您可能还需要优化云基础架构来满足新的需求。
  • 优化。在此阶段，您将开始充分利用云原生技术和功能，以扩展业务在性能、可伸缩性、灾难恢复、费用和培训等方面的潜力，并为应用打开机器学习和人工智能集成的大门。

迁移阶段 1：评估

在评估阶段，您将收集有关要迁移的工作负载及其当前运行时环境的信息。

调查情况

成功迁移的关键是了解当前环境中存在哪些应用 - 存在哪些数据库、消息代理、数据仓库和网络设备，并了解每个应用的依赖项。您需要列出所有机器、硬件规格、操作系统和许可证，还要列出它们各自使用的应用和服务。

目录应用

调查情况后，您可构建目录矩阵，从而根据迁移到 Google Cloud 的复杂性和风险将应用归类整理。

下表是一个示例目录矩阵。

没有依赖项或从属项 有依赖项或从属项
任务关键型
  • 无状态微服务（中等）
  • ERP（困难）
  • OLTP 数据库（困难）
  • 电子商务应用（困难）
  • 数据仓库（困难）
  • 防火墙设备（禁止）
非任务关键型
  • 营销网站（简单）
  • 备份和归档（简单）
  • 开发和测试环境（简单）
  • 批处理（简单）
  • 后台（困难）
  • 数据分析（困难）

此目录矩阵示例包含两个维度的评估标准。您的应用可能需要更多维度或存在其他注意事项。请创建矩阵，将您的环境的所有独特要求都包含在内。

在组织中讲解 Google Cloud

在评估阶段，您的组织需要开始了解 Google Cloud。您需要对软件和网络工程师进行培训和认证，让他们了解云如何工作、他们可使用哪些 Google Cloud 产品，以及他们可在 Google Cloud 上使用哪种框架、API 和库来部署工作负载。

试验和设计概念验证

在评估阶段，还有一个重要部分是选择概念验证 (PoC) 并加以实现，或者使用 Google Cloud 产品进行试验来验证用例或任何不确定的部分。

请参考以下用例：

在每项实验中，都要衡量对业务的影响，例如下述各项之一：

  • 如果您发现与当前环境相比，在 Google Cloud 上启动 5 万个虚拟 CPU 核心所需的时间减少了 95%，这会在一定程度上缩短产品的上市时间。加快启动还能减少关键业务线的停机时间，从而影响灾难恢复环境的设置时间。
  • 如果您能够获得全球可用且始终在线的灾难恢复计划，就能提高应用的可靠性。
  • 如果您使用云扩缩技术，则可以在资源需求较低时缩减资源并根据需求增加资源，从而降低服务的总费用。

计算总拥有成本

通过构建总拥有成本模型，您可将 Google Cloud 上产生的费用与您的当前费用进行比较。Google Cloud 价格计算器等工具可为您提供帮助，您也可以使用我们的一些合作伙伴产品。不要忘了在本地或在您自己的数据中心运行所产生的运营费用 - 电费、制冷费、维护费用，以及影响总拥有成本的其他支持服务所产生的费用。

选择要先迁移的工作负载

为了做好迁移准备，您需要确定具备可能使其成为“先驱”的特性的应用。您只能选择一个，或在“先驱”列表中包含多个应用。通过这些首批迁移项，您的团队能在云环境中运行和测试应用 - 在这里，团队能专注于迁移而不是应用的复杂性。首先处理不太复杂的应用可降低您的初始风险，因为稍后您可以运用团队学到的新知识来处理更难迁移的应用。

确定首批迁移项可能比较复杂，但合适的候选对象通常满足下面多项工作负载标准：

  • 并非任务关键型，使主要业务线不受到迁移影响，因为您的团队还没有丰富的云技术使用经验。
  • 不是极端情形用例，这样较容易将同一模式应用于您要迁移的其他工作负载。
  • 可用于构建知识库。
  • 由积极性高、渴望在 Google Cloud 上运行的团队提供支持。
  • 由迁移其他工作负载的中心团队进行迁移。迁移第一个工作负载可让该团队拥有更多经验，这在未来的工作负载迁移中必定非常有用。
  • 依赖项少的工作负载（例如无状态工作负载）更容易迁移，因为它们可在不影响其他工作负载或对配置进行最少更改的情况下进行迁移。
  • 需要最低限度的应用更改或重构。
  • 不需要移动大量数据。
  • 没有严格的合规要求。
  • 不需要第三方专有许可证，因为某些提供商不针对云提供其产品许可，或者可能需要更改许可类型。
  • 不受切换时段造成的停机时间的影响。例如，您可以从当前数据库导出数据，然后在计划的维护期间将其导入 Google Cloud 上的数据库实例。同步两个数据库实例来实现零停机时间迁移要更加复杂。

迁移阶段 2：规划

在此阶段，您需要预配和配置将在 Google Cloud 上支持您的工作负载的云基础架构和服务。建立关键配置和服务的基础是一个循序渐进的过程。在建立规则、管理和设置时，请务必留出空间供稍后更改。不要做出将您限定在一种操作方式的决策。如果您稍后需要更改内容，则需要有支持这些更改的选项。

如需规划迁移，您需要执行以下操作：

  • 建立用户和服务身份。
  • 设计资源组织。
  • 针对资源访问定义群组和角色。
  • 设计网络拓扑并建立连接。

建立身份

在 Google Cloud 中，您可选择以下身份类型：

  • Google 帐号。通常属于与 Google Cloud 进行交互的单个用户的帐号。
  • 服务帐号。通常属于应用或服务而非用户的帐号。
  • Google 群组。Google 帐号的指定集合。
  • Google Workspace 网域。一个虚拟组，其中包含在组织的 Google Workspace 帐号中创建的所有 Google 帐号。
  • Cloud Identity 网域。这些网域与 Google Workspace 网域类似，但它们无权访问 Google Workspace 应用。

如需了解详情，请参阅每种身份类型。

例如，您可以将 Google Cloud 与 Active Directory 联合，在混合环境中建立一致的身份验证和授权机制。

设计资源组织

为应用建立所需的身份之后，您可以向这些身份授予对应用所使用资源（例如项目、文件夹或存储分区）的权限。您可通过向每个身份分配角色来完成此操作。一个角色对应一组权限。权限是可对资源执行的一组操作。

为了避免重复相同的配置步骤，您可以按不同类型的结构来整理资源。这些结构按层次结构进行整理：

  • 组织是资源层次结构的根，表示真实的组织（例如公司）。组织可以包含文件夹和项目。组织管理员可以授予对该组织中所含全部资源的权限。
  • 文件夹是项目之间的另外一层隔离，可被视为组织中的子组织。文件夹可以包含其他文件夹和项目。管理员可通过文件夹委托管理员权限。
  • 项目是基本级层组织实体，必须通过它才能访问其他 Google Cloud 资源。您部署和使用的每个资源实例都包含在项目中。

由于资源从父节点继承权限，因此可以避免对父节点相同的资源重复相同的配置步骤。如需详细了解身份和访问权限管理 (IAM) 继承机制，请参阅 Resource Manager 文档的政策继承部分。

组织、文件夹和项目都是资源，如同其他所有 Google Cloud 资源一样支持一组操作。您可如同与任何其他 Google Cloud 资源交互一样与这些资源进行交互。例如，您可以使用 Resource Manager API 自动创建层次结构。您可以根据需要对资源层次结构进行整理。每个层次结构的根节点始终是一个组织。下面的部分介绍了您可以在组织中实现的层次结构类型。每种层次结构类型的特点都在于其实现复杂性和灵活性。

面向环境的层次结构

在面向环境的层次结构中，您有一个组织，其中每个环境都有一个文件夹。

下图展示了面向环境的层次结构示例。

面向环境的层次结构的架构。

存在多个环境，分别是开发、质量保证和生产。 在每个环境中，都部署了相同的两个应用（My app 1 和 My app 2）的多个实例。

此层次结构只有三个级层，易于实现，但是如果您必须部署由多个环境共享的服务，则可能带来挑战。

面向功能的层次结构

在面向功能的层次结构中，您有一个组织，其中信息技术和管理等每个业务功能都包含一个文件夹。 每个业务功能文件夹可以包含多个环境文件夹。

下图展示了面向功能的层次结构示例。

面向功能的层次结构的架构。

此层次结构中存在多个业务功能，分别是应用、管理和信息技术。您可以部署多个 My app 实例，还可部署 Jira 和网站等共享服务。

与面向环境的层次结构相比，此选项更加灵活，它提供了相同的环境隔离，同时还允许部署共享服务。另一方面，相较于面向环境的层次结构，面向功能的层次结构管理起来更为复杂，而且它不按业务部门（例如零售或财务）将访问权限分离开来。

面向精细访问权限的层次结构

在面向精细访问权限的层次结构中，您有一个组织，其中零售或财务等每个业务部门都包含一个文件夹。每个业务部门文件夹都可针对每项业务功能包含一个文件夹。而每个业务功能文件夹都可针对每个环境包含一个文件夹。

下图展示了面向精细访问权限的层次结构的示例。

面向访问权限的层次结构的架构。

在此层次结构中，存在多个业务部门、多个业务功能和环境。您可以部署 My app 1 和 My app 2 应用的多个实例，还可部署一个共享服务 Net host。

此层次结构是最灵活、可扩展性最强的选项。另一方面，您需要花费更多精力来管理结构、角色和权限。与其他选项相比，其项目数量更多，因此网络拓扑结构也可能复杂得多。

针对资源访问定义群组和角色

您需要设置群组和角色，以设置访问资源所必需的权限。在 Google Cloud 中，您可以向组织中的资源委派管理员权限。您至少需要以下角色：

  • 一名组织管理员，负责定义 IAM 政策以及组织和其资源的层次结构。
  • 一名网络管理员，负责创建和配置网络、子网及网络设备，例如 Cloud Router、Cloud VPN 和 Cloud Load Balancing。 此外，该用户还负责与安全管理员协作，共同维护防火墙规则。
  • 一名安全管理员，负责为组织及其资源建立政策和限制条件、为项目配置新的 IAM 角色，并保证日志和资源可供查看。
  • 一名帐单管理员，负责配置结算帐号并监控整个组织的资源使用情况和支出情况。

设计网络拓扑并建立连接

规划阶段的最后一步是设置从现有环境到 Google Cloud 的网络拓扑和连接。

创建项目并建立身份后，您应至少创建一个 Virtual Private Cloud (VPC) 网络。通过 VPC，您可以拥有跨多个区域的专用全球寻址空间。区域间通信不使用公共互联网。您可以创建 VPC 来隔离应用的各个部分，也可拥有一个跨多个项目的共享 VPC。设置 VPC 后，还应使用 Cloud Logging 配置网络流日志记录和防火墙规则日志记录。如需详细了解 VPC 及其设置方法，请参阅 VPC 设计的最佳做法与参考架构。

Google Cloud 提供了许多混合连接选项，用于将现有环境连接到 Google Cloud 项目：

  • 公共互联网
  • Cloud VPN
  • 对等互连
  • Cloud Interconnect

通过公共互联网连接简单又实惠，这是因为它采用了弹性基础架构，而后者使用了 Google 现有的边缘网络。 另一方面，此基础架构并非私有也非专用。此选项是否安全取决于在每个连接上交换数据的应用。因此，建议不要使用此类型的连接来发送未加密的流量。

Cloud VPN 使用 IPSec 隧道将现有网络扩展到 Google Cloud。流量经过加密，通过公共互联网在两个网络之间传输。虽然 Cloud VPN 需要进行额外配置，并且可能会影响连接的吞吐量，但如果您不在应用级层加密流量，且需要访问私有 Google Cloud 资源，则它通常是最佳选项。

通过对等互连，您可以通过专用通道建立与 Google 网络的连接。 有两种对等互连类型：

  • 通过直接对等互连，您可以在您的网络与 Google 边缘网络之间建立直接对等互连。如果您不需要访问 Google Cloud 上的私有资源，而且符合 Google 的对等互连要求，则这是一个不错的选项。此选项没有任何服务等级协议 (SLA)，但借助它，您可通过 Cloud VPN 的公共互联网访问来削减出站流量费用。
  • 通过运营商对等互连，您可以使用服务提供商管理的企业级网络服务连接到 Google 的网络。虽然 Google 未针对此连接选项提供任何 SLA，但它可能涵盖在服务提供商的 SLA 中。在评估此选项的价格时，您应同时考虑到 Google Cloud 出站流量费用和服务提供商费用。

Cloud Interconnect 通过高度可用的连接，将您的现有网络扩展到 Google 的网络。默认情况下，它不提供任何加密通道，因此如果您想使用此选项，建议您在应用级层加密敏感流量。有下面两种 Cloud Interconnect 选项可供选择：

  • 专用互连提供至少 10 Gbps 的高带宽私有连接，但需要在对接网点中使用路由设备。换言之，您必须在其中一个接入点 (PoP) 连接到 Google。Google 为专用互连连接提供了端到端 SLA，并根据专用带宽和附件数量向您收费。
  • 合作伙伴互连使您无需在 Google 对接网点中配置路由设备，即可使用由服务提供商管理的专用高带宽私有连接。Google 为 Google 与服务提供商之间的连接提供 SLA。服务提供商可能会为您与他们之间的连接提供 SLA。合作伙伴互连根据连接容量和通过互连的出站流量进行收费。此外，服务提供商还可能向您收取服务费用。

迁移阶段 3：部署

在为 Google Cloud 环境创建基础后，就可开始部署工作负载了。您可以实现部署过程，并在迁移期间对其进行优化。在迁移过程中，您可能需要重新访问环境基础。随着您对新的云环境、平台、服务和工具越来越熟练，可能会出现新的需求。

在为工作负载设计部署过程时，应考虑所需的自动化和灵活性程度。从完全手动的过程到完全自动的简化过程，有多种类型的部署过程供您选择。

完全手动的部署

通过完全手动的预配、配置和部署，您可以快速地使用平台和工具进行试验，但它也容易出错，通常没有记录且不可重复。出于这些原因，建议除非别无选择，否则请勿使用完全手动的部署。例如，您可以使用 Google Cloud 控制台手动创建资源（比如 Compute Engine 实例），并手动运行命令来部署工作负载。

配置管理工具

通过配置管理 (CM) 工具，您能够以自动化、可重复且受控的方式配置环境。您可以使用 CM 工具配置环境并部署工作负载。虽然此过程优于完全手动的部署，但它通常没有功能来实现复杂部署的功能，例如无停机时间的部署或蓝绿部署。 一些 CM 工具可让您实现自己的部署逻辑，并可用于模拟这些缺失的功能。但是，将 CM 工具用作部署工具可能让部署过程更复杂，而且可能比专用部署工具链更难管理和维护。 设计、构建和维护自定义部署解决方案可能会给运营团队带来巨大的额外负担。

容器编排

如果您已在容器化方面进行了投资，则您可更进一步，使用 Google Kubernetes Engine (GKE) 等服务来编排工作负载。通过使用 Kubernetes 编排容器，您不必担心底层基础架构和部署逻辑。

部署自动化

通过实现自动化工件生产和部署过程（例如持续集成和持续交付 (CI/CD) 流水线），您可以自动创建和部署工件。您可将此过程完全自动化，甚至可根据需要插入手动批准步骤。

基础架构即代码

虽然您可以通过实现 CI/CD 流水线自动执行部署过程，但您也可为基础架构采用类似的过程。通过定义基础架构即代码，您可以自动预配运行工作负载所需的全部资源。通过此类过程，可更容易观察到您的基础架构，其可重复性也更高。您还可以对基础架构应用测试驱动开发方法。另一方面，您需要投入时间和精力来实现基础架构即代码过程，因此请在规划迁移时考虑到这一点。

Terraform 和 Deployment Manager 等工具可帮助您在 Google Cloud 上实现基础架构即代码。

迁移阶段 4：优化

部署工作负载后，就可开始优化您的目标环境了。在此优化阶段，下列跨区域活动可以帮助您优化此环境：

  • 建立并培训团队。
  • 监控所有内容。
  • 自动处理各项内容。
  • 将所有内容标准化。
  • 使用托管服务而非自行管理服务。
  • 针对性能和可伸缩性进行优化。
  • 降低成本。

建立并培训团队

在规划迁移时，您可对开发和运营团队进行培训，以充分利用新的云环境。通过有效的培训，这些团队不仅能提高效率，还能选择最适合作业的云原生工具和服务。培训机会有助于留住技术人才，还可帮助工程师充分利用 Google Cloud 的各项优势。

在此阶段，您还可以审核管理这些团队的业务流程。如果您在这些流程中发现任何效率低下的情况或者不必要的负担，可通过培训对其进行优化和改进。

监控所有内容

监控是确保环境中的各项内容按预期正常运行并改进环境、实践和流程的关键。

在将环境公开给生产流量之前，建议您设计并实现一个监控系统，用它来定义对评估环境及其组件（包括工作负载）的正确运行至关重要的指标。例如，如果要部署容器化基础架构，可以通过 Prometheus 实现白盒监控系统。或者，您可以使用 Cloud Logging 和 Cloud Functions 来监控 IoT 设备。

同时建议您设置与 Cloud Monitoring 提醒类似的提醒系统，让您主动应对而非被动抵御。您需要针对关键错误和条件设置提醒，但您还需要设置警告，以便在潜在干扰情况影响用户之前及时更正。

Cloud Logging 日志的保留期有限，因此您随后可导出 Cloud Monitoring 指标日志进行长期存储；您也可根据从此类日志中提取的指标进行数据分析，深入了解您环境的表现并开始规划改进。

自动处理各项内容

手动操作很可能出错，而且也很耗时。 大多数情况下，您可以自动执行部署、机密交换和配置更新等关键活动。自动化可节省费用和时间，并降低风险。团队不必在重复性任务上花费精力，因此也变得更有效率。 使用 Cloud Composer 实现基础架构自动化是 Google Cloud 自动化功能的一个示例。

将所有内容标准化

在 Google Cloud 上预配目标环境时，应当力求在代码中捕获尽可能多的方面。通过实现基础架构即代码和政策即代码等过程，您能够使环境完全可审计和可重复。您还可在代码以外的其他方面应用测试驱动开发方法，从而就您计划应用于环境的修改获取即时反馈。

使用托管服务而非自行管理服务

Google Cloud 拥有一系列服务和产品，您无需管理任何底层服务器或基础架构即可使用。在优化阶段，您可扩展工作负载以使用此类服务，也可用这些服务替换现有的工作负载。

下面是托管服务的几个示例：

  • 使用 Cloud SQL for MySQL，而不是管理自己的 MySQL 集群。
  • 使用 AutoML 对图片进行标记和分类，而不是部署和维护自己的机器学习模型。
  • 在 GKE 上部署工作负载，而不是使用自行管理的 Kubernetes 集群，或者甚至将虚拟机迁移到容器并在 GKE 上运行。
  • 使用 App Engine 进行无服务器网站托管。

针对性能和可伸缩性进行优化

移到云端的优势之一是可以访问资源。您可以支持现有资源、在需要时添加更多资源，还能以可扩缩的方式删除不需要的资源。

与本地部署相比，您拥有更多优化性能的选项：

降低费用

Google Cloud 提供了大量工具和价格选项，可帮助降低费用。

例如，如果您预配了 Compute Engine 实例，则可以对这些实例应用大小建议。

为减少费用，您可分析结算报告，以研究支出趋势并确定您最常使用的 Google Cloud 产品。您甚至可以将结算数据导出到 BigQuery 或文件中进行分析。

为进一步降低您的费用，Google Cloud 提供了持续使用折扣等功能，可向您的 Compute Engine 帐单应用自动折扣。您还可以购买承诺使用合约来换取 Compute Engine 实例的折扣价。对于 BigQuery，您还可以注册享有固定价格。此外，Google Cloud 自动扩缩功能可根据客户端请求缩减资源，从而帮助降低费用。您可以通过优化 Cloud Monitoring 和 Cloud Logging 的使用情况来降低监控和日志记录费用。

寻求帮助

Google Cloud 提供了各种选项和资源，方便您获取必要的帮助和支持，以充分利用 Google Cloud 服务。

自助资源

如果您不需要专属支持，可使用以下自助资源：

技术合作伙伴

Google Cloud 已与多家公司合作，让您能够使用他们的产品。有些产品可能是免费提供的，因此请咨询相关公司和您的 Google Cloud 客户经理。

这些产品包括以下几项：

系统集成商

Google Cloud 合作伙伴不仅包括产品和技术公司，还包括可以提供直接操作帮助的系统集成商。在合作伙伴列表中，您可以找到专门从事云迁移的系统集成商列表。

Google Cloud 专业服务

我们的专业服务团队随时恭候，帮助您充分利用在 Google Cloud 中的投资。

Cloud Plan and Foundations：获取迁移方面的帮助

专业服务为您提供帮助，使用我们的 Cloud Plan and Foundations 产品进行迁移规划并在生产环境中部署工作负载。从建立 Google Cloud 基础，到针对您独特的工作负载需求进行平台优化以及部署工作负载，这些专家在将工作负载迁移到生产环境的各个阶段为您的团队提供指导。

Cloud Plan and Foundations 的目标是：

  • 建立 Google Cloud 基础。
  • 创建设计文档。
  • 规划部署和迁移活动。
  • 将工作负载部署到生产环境中。
  • 跟踪问题和风险。

专业服务专家将指导您的团队完成以下活动和可交付成果：

  1. 举办技术启动研讨会。
  2. 构建技术设计文档。
  3. 制定迁移计划。
  4. 制定程序章程。
  5. 提供项目管理。
  6. 提供技术专业知识。

Cloud Sprint：加快向 Google Cloud 的迁移

Cloud Sprint 是一个强化的动手实践研讨会，可加快应用向 Google Cloud 的迁移。在此研讨会中，Google Cloud 专业服务专家通过互动讨论、白板会议和审核要迁移到 Google Cloud 的目标应用，为您的一个团队提供指导。在 Cloud Sprint 期间，专业服务专家会与您的团队成员协作，让他们通过所需的部署活动获得云解决方案的第一手经验，帮助您了解未来 Google Cloud 迁移的后续步骤。

培训：培养团队的技能

Google Cloud 专业服务可根据团队的需要，提供相关的实践培训。

后续步骤