欢迎再次阅读 Google Cloud 采用和迁移系列 的最新一期。在上一期，我们讨论了如何让租户更轻松地使用我们的 Google Cloud 资源：

• 构建项目工厂
• 创建自助租户创建流程
• 为租户提供清晰的文档和支持，以及指导

在这里，我将分享一些关于如何扩大你的组织向云端迁移并使用资源的规模的实用建议。和这个系列中的许多建议一样，本文中的建议不仅适用于谷歌云，也适用于任何其他云。

高效地完成云端迁移

我将提到：

• 迁移二难：如何在集中式核心迁移工厂活动和分散给租户/应用团队的活动之间找到正确的平衡。
• 集中化能力：CCoE和迁移工厂。
• 一些关键制品，你的CCoE需要提供和维护，包括原则、设计指南、设计模板和检查表、决策树、可重用的蓝图和经过验证的解决方案库。
• 如何提供集中培训和指导。
• 如何简化架构治理流程。
• 简化迁移的工具（V2V，V2C，数据库迁移，Google迁移中心…）
• 迁移计划建议。

集中还是联合？

对于那些正在迁移大量工作负载的企业来说，这里就面临一个挑战：

为了大规模地处理这些迁移，我们需要将迁移活动——无论是设计还是执行——分配给应用团队。但是在迁移项目中，有许多迁移活动需要在多个团队间重复执行，不过每个应用团队只会执行一次这些活动。一个很好的例子是：将专有数据库模式（例如现有的 Oracle 数据库：）转换成一种可迁移到 Cloud SQL PostgreSQL 的 ANSI 标准模式。

花费大量时间和精力训练所有应用团队去完成这些一次性任务通常没有意义。在很多情况下，培训的时间甚至和活动本身所需的时间一样长！

所以我们得确定一下吧：

• 哪些迁移活动将会集中到我们核心迁移工厂团队(s)？
• 哪些迁移任务将被分发到我们应用层面的团队？

这里有一些指导帮你做决定：

优化迁移流程

1. 如果流程仅由应用团队执行一次，且没有价值去教会应用团队如何执行该流程，那么就将其集中处理。 例如：数据库转换；以及从遗留解决方案迁移到谷歌云解决方案的任何仅针对每个租户的一次性迁移。
2. 如果流程涉及繁重的工作（toil），但这种繁重工作能帮助教育应用团队熟悉我们的目标环境（即谷歌云服务），则将其分发。 例如：创建迁移设计文档；以及为应用/租户拥有的基础设施构建Terraform。
3. 有些迁移活动可能处于中间地带。 例如：修复遗留的Java代码。这不是一次性活动。应用团队应该定期修复遗留代码。在这种情况下，我们要确保修复过程尽可能顺畅。应用团队需要承担起责任，但在很多时候，让核心工厂团队给予应用团队指导和支持（例如，针对特定的代码运行时或框架）是有意义的——并且在每个修复周期中提供实地支持。

现在你已经对哪些步骤将被分散化以及哪些将被集中化有了更好的了解，你可以确保你已经在你的组织中建立了必要的集中功能，并且已经到位。有两个关键的集中化功能能够帮助加速迁移。

1. 云计算卓越中心（CCoE）
2. 迁移中心

在这篇文章中，我将重点讨论CCoE（云能力卓越中心）如何在大规模迁移中加速云迁移。

CCoE 的主要职责

我之前写过关于组织变革、能力提升、技能提升和云中心的文章。在这篇文章中，我谈到了CCoE是什么，为什么需要，谁应该参与其中，如何建立它以及它的关键职能。回顾一下，关键职能有：

• 推动并传播组织的云战略。
  • 拥有并演进云原则。
  • 定义并拥有可重复的云蓝图。
  • 拥有云最佳实践和标准。
  • 提供云咨询服务。
  • 提供云教育。
  • 拥有并交付云架构治理。
  • 大规模优化云使用。
  • 提供常规且相关的云通信。

但现在我想谈谈CCoE可以拥有和管理的一些关键内容，以加快大规模迁移。具体包括：

• 简洁的解决方案设计/迁移设计模板
• 指引性决策树
• 可复用的云蓝图/模式
• 存储常见问题解决方案的验证库
• 云设计和迁移指导培训
• 持续的设计支持和改进
• 云架构管理

我们一个个来看看这些吧……

编写解决方案设计文档通常是由与特定应用的解决方案/云架构师负责的。这样做的目的是确保我们记录下架构中重要的部分，以便我们能够确信。

• 我们正在搭建合适的目标架构。
• 设计满足了诸如性能、扩展性、可用性、安全性和恢复性等非功能需求。
• 该方案契合我们整体的商业和云战略。
• 该方案符合我们的原则和标准。
• 我们对所做技术决策有清晰记录的理由。

目标是团队产出架构设计文档，而不是详细或低级的设计文档。我之前写过一篇文章叫做“架构文档：如何划定界限” (Architecture Documentation: Where to Draw the Line)，这篇文章说明了好的架构设计文档应该包含哪些内容，帮助你区分哪些是架构层面的考虑，哪些不是。我建议你看看这篇文章。

我们希望设计文档简洁，并帮助我们分散的架构团队能够快速高效地创建它们。CCoE 可以通过提供一个模板来帮助他们实现这一点，这个模板定义了需要包含的内容，同时还通过预先填充所有应用中都可能通用的答案，以简化我们的云迁移过程。

考虑到这一点，这里有一些推荐的标题。

• 完成指导，供文档作者参考使用。
• 文档历史/签字确认。
• 迁移理由——即我们为什么要迁移此应用程序。许多内容可以重复使用模板。
• 应用程序概述——这个应用程序是用来做什么的？它为什么对我们有用？
• 范围与阶段性计划——即在这个阶段我们要做什么？哪些内容要留待后续阶段完成？
• 有哪些非功能性或架构上重要的需求或标准？例如…用户数量、地理分布、可用性和运营时间、恢复点目标（RPO）和恢复时间目标（RTO）、数据类型/数据分类/PII、数据量、数据保留等。
• 设计决策——我们选择了哪些技术？它们如何帮助我们满足这些架构需求？这是一个战术性决策还是战略性决策？是否会引入任何必须在未来偿还的技术负债？关键的是：我们能否参考现有的文档来简化决策制定和记录的过程？（稍后详细介绍！）
• 技术架构：现状、目标架构以及任何中间状态。这里我们将绘制和记录所有有趣的内容……用户和客户端应用程序、上游和下游应用程序及集成、身份验证和授权、VPC和本地部署、计算解决方案、数据库和存储、ETL组件、API和网关等。我们能否利用现有的蓝图或模式来完成此工作？
• 数据管理和维护——在数据生命周期中，我们将如何处理数据？我们需要将其归档在某个地方吗？我们是否会通过某种维护过程来删除数据？请记住，这是一份架构文档，因此我们不需要提供细节；例如，我们可以在目标数据库中使用基于日期的分区，并在所需的天数后删除分区即可。
• 高可用性和灾难恢复（DR）。请考虑以下因素：是否提供了区域级别的高可用性？或许考虑跨区域？当不使用固有的高可用性服务时，我们将使用什么样的故障转移方法？我们是否会在出现故障事件时按需实例化？并且我们是否使用IaC以快速且可重复的方式完成此操作？
• 备份与恢复——请记住，这通常不是关于恢复时间目标（RTO）或提供灾难恢复能力。而是关于能够将我们的数据恢复到已知的历史状态。例如，考虑一下我们意外删除了一大批记录的情况。（并且请记住：如果我们通过某种复制机制来实现高可用性，则这种删除会立即被复制！）
• 可操作性和SRE —我们如何监控系统健康状况并如何应对系统降级？我们的关键用户路径（CUJ）是什么，我们可以构建哪些SLI来与它们对齐？当我们SLO被突破时，我们是否会触发警报，警报将发送到何处？我们是否有记录的错误预算策略？
• 停用——我们可以关闭什么，什么时候关闭？在我们能够这样做之前，是否有任何其他的前提条件必须满足？这很重要，因为云迁移将增加TCO，如果你不能关闭旧系统及其托管组件。

决策树（决策树模型）

它们其实只是哎，流程图！

在这里，目的是帮助应用程序团队从组织批准的技术中挑选最适合其需求的技术，从组织批准使用的技术中。在许多组织中，可用的 Google Cloud 选项相较于 Google Cloud 提供的所有产品，可能受到较大限制。这种情况在像银行业这样的受高度监管行业中尤为常见。

为什么这样做？

1. 每一棵决策树将会预先考虑多种因素，如性能、可用性、可操作性、成本、可重用性及战略一致性。
2. 遵从迁移的架构师不需要对所有可用的产品都成为专家。因此在技术选择上节省了大量时间和精力。因此设计可以更快地完成。
3. 它避免了重复发明轮子。当多个应用程序需要类似组件或服务时，没有必要让每个团队都努力去找到相同的解决方案。
4. 它在整个系统范围内保持一致性。由于应用程序团队最终会选择相同的方式来处理类似的情况，我们最终会得到一个差异较小的资产库。我们得到更一致的技术来解决重复的问题。最终我们的资产库会变得更简单。
5. 架构师将无法选择未经批准的产品或服务，除非提供充分的解释。
6. 它简化了设计文档流程。当设计决策可以与决策树的结果保持一致时，通常这就是所需的所有依据。这就像说，“我的依据是：我正在使用事先批准的解决方案。”
7. 它简化了架构治理。架构设计委员会不需要浪费时间对与决策树结果相关的设计决策进行详细审查。相反，他们可以集中时间审查那些不相关的决定。

需要经常做出决定的事情，还有引导应用团队选择更合适的技术方案。

你可能找到或发现候选 decision trees（决策树）。

• 通过经常听到关于同一设计决策挑战的讨论，比如在架构治理领域。
• 基于应用团队对同一个问题往往提出不同的解决方案。
• 通过发现应用团队不断选择旧技术（这会增加技术债务/成本），或者总是选择未经批准的技术。后者可能表明组织的战略不够明确，或者组织可能需要迅速考虑某种技术。

请考虑：

• 你的决策树的范围。例如，他们只会提供在（比如说）Google Cloud中有效的解决方案吗？
• 他们应该只提供在你组织中经过筛选和批准的技术。
• 他们应该提供与你已确立的云消费原则一致的技术。例如，他们通常会引导团队远离需要商业许可的那些技术；或需要大量手动管理的那些技术；或无法以自动化方式部署的那些技术等。
• 他们应该非常有主张（比如，通过决策树中的每条路径都导向一个确切的答案，而不是一组可能的答案）！目标是帮助应用团队选择正确的技术并减少应用环境的复杂性。

这里有几个关于决策树的例子，在企业采用云技术时通常很有用。

• 数据库选择。 即“我的应用程序需要一个或多个数据库。哪个是最合适的？”这样一个决策树应指导应用程序架构师在关系型/SQL与NoSQL之间进行选择。它还应在事务型与分析型之间进行指导。它还应指导应用程序架构师考虑其他非功能性需求，如可扩展性、延迟、可用性、数据摄入速率等。典型答案可能包括Cloud SQL PostgreSQL、AlloyDB、BigQuery、Spanner、Datastore和Memorystore。

• 非结构化存储选择。 即“我需要存储一些非结构化数据。哪个是最合适的？”这里决策树将指导应用程序架构师在块存储、文件存储和对象存储使用案例之间进行选择。这些数据仅需本地使用，还是需要共享？是否需要支持多并发写入？延迟和吞吐量要求是什么？我们将保留数据多久？数据会被访问的频率是多少？是否需要用于归档目的？答案可能包括持久性磁盘存储（用于块存储）、Filestore（用于共享NFS）和Google Cloud Storage（用于对象存储）。我们也可以推荐使用Fuse将GCS暴露为文件的选项。

• 数据管道：转换。 即“我的应用程序需要获取批处理和流处理数据，进行转换，并将其存储在BigQuery和GCS存储桶中。哪个是最合适的？”这里你可能会根据流处理与批处理的需求、是否需要迁移现有的Hadoop或Spark生态系统、转换是否轻量级且事件驱动型，还是复杂且需要数据工程框架、以及数据工程团队可用的技能来指导应用程序架构师。你还可以建议在哪些场景下临时性与持久性平台最为合适。答案可能包括：Cloud Functions、Dataproc和Dataflow。

• 编排与调度。 我们是否只是想在特定时间运行任务，使用类似cron的调度？我们是否希望集中管理它们？我们是否有需要协调分布式任务队列的需求？我们是否希望以集中方式协调多个服务，维护工作流状态并进行集中日志记录？或者我们是否希望使用纯事件驱动的服务编排？我们是否有复杂的ETL流程，需要额外的代码逻辑并能够连接多个上游和下游端点？答案可能包括：Cloud Scheduler、Cloud Tasks、Cloud Workflows、Pub/Sub和Cloud Composer。

• 计算选择。 即“我的应用程序需要托管应用x。哪个是最合适的？”我们是在构建自己的应用程序，还是部署现成的解决方案？现成的解决方案是否限制我们只能运行虚拟机？这是一个轻量级的进程，可以在事件触发时运行吗？我们可以对其进行容器化吗？如果是，这是一个无状态的应用程序吗？我们是否有运行多个服务的需求，并且需要一种控制所有服务部署的方法？我们是否有复杂的升级/推出/回滚选项需求？答案可能包括：GCE、Cloud Functions、Cloud Run和Google Kubernetes Engine (GKE)。

相比之下，明确的决策树帮助我们为特定用例选择单一产品，而可重用的模式则提供了一种经验证的方法来组合多种技术以实现目标。同样，这些模式将仅使用筛选并批准的技术选择。目标是为应用程序团队提供一致的方式实现可重复的目标，使用一套共同的工具。

比如可能包括：

• 数据摄取和处理管道，使用诸如GCS、Dataproc或Dataflow等技术，并使用BigQuery作为分析数据库的一部分。
• 面向外部的Web应用，带有关系数据库，使用诸如Google外部负载均衡器与Cloud Armor和Cloud CDN、Google Cloud Run以及GKE，以及Cloud SQL（PostgreSQL）等技术。

数据摄入和ETL（提取、转换、加载）方案

这是我最喜欢的一个！我们的目标是建立一个单一的仓库，让组织能够集合针对反复出现的问题的验证过的实施方案。我们不应该对此过度设计。

它应该做到：

• 问题是什么？ 例如，这可能是某些可以重复执行的Dataproc作业，或者从本地应用程序中反复导入数据的需求，或者一种常见的数据转换实现方式。也可能是实施SLO警报策略的一种标准方法，或者将这些警报推送到企业系统（如ServiceNow或Slack）中。或者是一个提供可重用OAuth流程的Cloud Run边车实现方案。
• 我们是如何解决这个问题的？ 简要说明解决方案，不超过一两句话。
• 采用这种方法的应用程序名称 实现了这种方法的应用程序名称。
• 解决方案或迁移设计的链接 使用这种方法的解决方案或迁移设计的链接。
• 其他有用资源的链接 包括相关代码（例如存放在git仓库中的代码）的链接，以及相关的实施文档和指导链接。
• 联系人。 这里我们希望包括一两个了解该解决方案的人的名字。这样当团队在仓库中看到他们的问题，但不确定该解决方案是否适用于他们时，可以联系他们。这都是关于协作的。
• 这种方法的现状。 该解决方案是否已部署到生产环境？如果已在生产环境中部署，则这意味着该方法已满足组织内的所有治理和控制要求。

你可以将这个物品视为轻量级模式库。

以下是一些建议来创建和维护此仓库：

我们需要它成为一个简单的参考工具，让应用团队可以快速查找或搜索他们的问题。

我们需要能从大家那里集思广益，找到解决办法。

那我们该怎么做到呢？可以尝试几种方法，这些方法也可以结合起来使用。

1. 在架构治理过程中，CCoE 可以识别反复出现的问题，并从提交的应用程序中识别和提取好的解决方案。
2. 通过定期的设计审查会，CCoE 可以识别常见的问题和好的解决方案。
3. 应用团队或其他团队和部门可以直接提出。

当有好的解决方案出现时，我们希望它们能够快速且无痛地整合到代码库中。CCoE 位置很好，能够理解方案是否可重复、合理、成本效益高、实际可行，并且与战略一致。因此，CCoE 可以批准任何来自 CCoE 之外的解决方案提案。

记住，我们不希望重复有问题的解决方案。比如说，我们不希望解决方案增加了额外的技术债务，或者使用了未批准的服务，或者进一步恶化组织的安全状况。

集中化的即用型答案如果没有被大家知晓就毫无用处。因此，CCoE需要确保积极宣传其存在，并传达更新内容。这可以通过发送新闻通讯、在Slack或Teams频道上发布，或通过嵌入到培训材料中来实现这些目标。

这里的目标是给应用程序团队（尤其是联邦架构师）：

• 组织的整个过程的指导，包括云设计和构建过程中所需的任何治理和合规步骤。
• 在参与迁移流程之前需要完成的先决条件。
• 查找关键工件的指南，比如前面提到的模板、决策树和模式。
• 具体的“优秀示例”。即参考设计和实施方案，涵盖一系列常见的解决方案类型。这样一来，他们不必从零开始设计。可以找到一个已经实现了类似目标的设计方案。
• 何处寻求帮助。

这匹马没喝水

我发现仅仅编写文档并期待每个人都遵循它是不够的。我强烈建议这样做，设立强制性培训来讲解这些材料。

建立您的CCoE（中央职能团队）作为提供建议和最佳实践的平台。为了让这个功能顺利启动，我建议设立定期的设计社区交流会。这些会议对所有参与迁移设计和架构阶段的人员开放。

为什么这么做？

.zh: CCoE 支持的良性循环机制

• 它允许尽早沟通。希望应用团队在流程早期就展示他们的设计方案和迁移挑战。与其等到设计完成后才发现他们的方案不被接受，不如让他们尽早与你沟通。最终，与 CCoE 早期接触意味着迁移会更顺利、更快、更一致、成本更低。
• 它允许共享常见问题和解决方案。这可以促进识别反复出现的问题，并支持创建和共享通用解决方案的良性反馈循环。记住：CCoE 需要对反复出现的挑战及其最佳解决方案保持中央可见性。
• 它允许社区共同回答问题。不仅靠 CCoE 提供答案，整个迁移社区都能为此贡献力量，更准确地说是“共享答案”。
• 它有助于提升整个社区的能力。
• 它建立对 CCoE 的信任。希望成为受信任的顾问，帮助迁移成功，而不仅仅是执行检查表的治理角色。

就像所有的治理一样，架构治理也是一种必要的麻烦。你需要恰到好处的架构治理以确保：

• 相关方已经适当参与并进行了咨询。​
• 理由已经被充分记录并理解。​
• 解决方案遵循战略、政策和原则。​
• 权衡和风险已经被妥善处理。​
• 技术债务正在持续管理中。​
• 冲突已经被解决。​
• 共同挑战被收集和汇总，以便提供可重复使用的解决方案。​
• 可重复使用的解决方案组件被收集以利于整个项目。​
• 解决方案已由有权批准的小组正式批准通过，例如解决方案设计权威、迁移权威或架构评审委员会。

然而，如果架构治理做得不好，会成为您迁移计划的瓶颈。本文中的很多建议可以帮助您优化治理流程。

比如说：

• 如果解决方案设计文档中的设计决策完全符合现有的决策树路径，则可以确定该解决方案使用的是公司内“经过审核和批准”的技术，并且该技术适用于当前解决方案。因此：我们不必在架构治理中花时间审查这一决定。
• 相反，如果一个设计决策不符合任何决策树，那么该决策需要仔细审查。
• 如果一个解决方案基于现有的已发布的蓝图，则可以合理地确定该解决方案将更加稳健，并符合公司的首选模式。

总之：你需要管理，但希望管理尽可能轻量化。建立一个可重复的操作手册，说明你将如何管理迁移设计的过程，但寻找机会简化流程，例如，通过减少对符合决策树推荐的设计决策的审查。

我们谈到：

• 应该集中化哪些类型的迁移活动，以及哪些应该采用分散管理。
• CCoE 应该拥有和管理的各种资源，以提高大规模迁移的速度。
• 如何收集常见的问题和可重复使用的解决方案。
• 如何建立 CCoE 设计社区，并利用该社区促进迁移项目的持续改进。
• 如何简化架构治理，减少治理成为瓶颈的可能性。

接下来，我们会看看如何通过使用迁移工厂和工具来加快迁移过程。

• 架构文档：界限如何设定
• 建立您的云策略
• 云采用和云消费原则和实践
• 组织变革、能力提升、技能提升和Cloud Center of Excellence (CCoE)
• Google云采用：SRE (站点可靠性工程)，以及SLI/SLO/SLA的最佳实践

• 请分享给那些你认为会对这个感兴趣的人。这可能会帮助到他们，真的也帮助了我！
• 请给我 点个赞！你知道你可以最多点50次，对吧？只要按住按钮就可以了！
• 欢迎在下方 留言 💬。
• 关注我 并订阅，这样你就不会错过我的内容。去我的个人页面，点击关注、订阅、分享等图标：

点击关注并一键订阅

• 系列概述及结构
• 上一篇：启用您的消费者和租户，以及项目工厂
• 下一篇：大规模迁移执行加速及迁移工厂