云迁移之5R方法优秀实践总结

译文精选
作者：陈峻 2022-04-19 10:17:20

云计算

云原生

混合云本从云迁移的5R方法出发，着眼改进企业文化、实施智能变更以及可观察性与监控三个方面，讨论方便企业进行云迁移的各项优秀实践。

译者 | 陈峻

策划 | 云昭

近年来，云迁移（Cloud migration）这个术语频频出现在大多数企业的IT话题中。最初，该术语仅代表了将服务从本地基础架构的服务器上，迁移到AWS EC2之类的云基础架构上的相关实践。如今，云迁移的概念已拓展为：包括迁移到托管数据库、API网关以及可能需要AWS、或Azure来处理某些负载上。当然，如果贵企业属于金融或公共事业部门的话，则需要迁移到私有云、或是满足特殊监管要求的公有云。

下面，我将从改进企业文化、实施智能变更以及可观测性与监控三个方面，和大家讨论企业进行云迁移的各项优秀实践与原则。通过将这些指导原则应用于企业的云迁移工作中，可以帮助大家避免出现目的不清或低效的窘境，从而能够有组织地通过工具，来稳健地完成迁移工作。

在深入探讨优秀实践之前，让我们首先谈谈在云迁移过程中，通常会被用到的不同方法。

云迁移方法之5个R

由于云端环境存在着多样性、业务需求的复杂性以及行业细分领域的差别性，因此目前尚没有一种放之四海皆准的云迁移指导方案。不过，传统企业往往可以借鉴并采取如下5个R中的一种方法，去实践：

Rehost（重新托管）：这是一种传统的搬家式（lift-and-shift）迁移方法。例如，应用程序原本在本地的VM（虚拟机）中运行，现在你需要将它重新部署到云服务环境中运行的VM上。
Refactor（重构）：它与rehost类似，不同之处在于多了一个诸如：搬起、调整和迁移的中点步骤（midpoint step）。
Revise（修订）：这是rehost和refactor的结合。它通常包括重大的应用更改，以更好地利用目标云环境的各项功能。
Rebuild（重建）：它比Revise方法更进一步，在某些情况下，可能需要通过完全重建应用，以更好地利用云环境的各项功能。
Replace（替换）：通过这种方法，企业会删除掉了本地维护的某项功能，并使用第三方措施予以替代。

现在，让我们把这些方法运用到云端服务的场景中：

Rehost：可以将那些运行在本地虚拟机中的应用程序，重新部署到运行在多个云服务中的虚拟机上。
Refactor：可以通过中点步骤，对每个云服务目标进行调整。
Revise：通过对应用程序进行重大的更改，以利用每个云服务目标的功能。
Rebuild：通过完全重建应用程序，以利用多个云服务目标的功能。
Replace：可以利用多个潜在的第三方云服务选项，来替代本地应用的部分功能。

可见，上面提到的多个云服务、专业化的用例以及各种行业的法规，都会快速增加云端迁移的复杂性。对此，企业应当遵循如下三个关键性的实践原则，来理顺和简化云迁移工作。

1、改进企业文化

有过企业管理经验的人都知道，最困难却又是最有价值的实践之一莫过于企业文化的改进。一般来说，可以从“由谁负责技术资产的哪些部分”开始整理，并在尝试云端迁移之前，明确如下方面：

（1）确定责任

我们可以将RACI矩阵（请参见下图）技术运用到给定的组件或域上。在迁移期间，它将能够清楚地表明谁负有责任（responsible）、谁将提供记录（accountable）、谁可以提供咨询（consulted）、谁只需被通知（informed）将发生的各种更改即可。由于云服务加快了服务和产品的转化速度，因此你的企业与团队应当适应此类变化，而变化所对应的角色也就显得非常重要了。

（2）跟踪指标

文化改进的另一个组成部分是确定关键性指标，并将这些指标记录下来。有人可能会担心此举会暴露出运营效率低下等问题。不过，根据短板原理，一旦存在运营的不衡量，就无法提高整体水平。因此，我们有必要在各个层面进行指标的跟踪。例如：从应用团队的角度出发，围绕并跟踪网络和存储延迟的指标。而对于更高的管理级别，我们需要简洁清楚地定义与说明服务级别目标（service level objectives，SLO）的组成部分，并尽可能让更多的团队知晓并遵守此类标准化的复合性SLO。你也许会说，我们何不用服务水平协议（service level agreements，SLA）来强制保证合同的执行呢？其实，相比SLA，SLO更可以帮助你个组织，了解当前应用的性能与可靠性是如何影响到客户以及整体业务的。

（3）有效地回答任何有关业务的问题

我们可以将编程的思想延伸到业务上，提高现有业务的可观察性和监控能力。例如，如果团队成员需要通过复制和粘贴PromQL的查询，来响应有关某个业务影响的问题，那么你应该将其视为改进的机会。虽然它可能牵扯到广泛而复杂的方面，但是在大多数情况下，你以通过将数据存储与灵活的可视化系统相结合，并有选择地针对不同级别的查询予以开发，来实现系统的开放性和可观察性，并最终达到快速、准确地回答业务问题。

2、实施智能化变更

变更管理往往给人的印象是严厉而刻板，变更管理委员会通常只会说“不”。而这显然不是“智能化变更”的体现。

智能变更是一种使用技术门控（technical gating），而不是流程门控的云迁移方法。换句话说，我们需要通过自动化流程来实施保护，其中包括：端到端测试、持续集成以及分布式跟踪的证明等。而那些技术门控所无法涵盖的部分（或需要大量工作才能实现的部分）应当被放置到迁移列表的低优先级的位置。

通常，我们需要为更小或更简单的工作负载创建技术门控，以便为更复杂的、遵循相似流程的其他部分铺平道路。同时，我们可以通过迭代式地完成每个部分，直至达到足够的正确性和功能性水平，以实现云端迁移工作的可重复性。

3、可观测性和监控

如前所述，在迁移之前，提供系统和应用程序的可观察性（如果它们尚不具备的话），以便在此基础上开展各项监控工作，对于验证云端迁移工作的成败也是至关重要的。例如，根据是否可与数据库建立连接，你能判断其是处于启动还是关闭状态。而只有当你以查看到利用率指标、查询用时以及活动连接计数等参数指标时，才算是真正获取了数据库的可观察性。而有了可观察性，你可以进一步问出如下问题：

我能够根据监控数据获得相应的警报吗？

我的基础设施可以基于监控进行自我修复吗？

我需要多长时间才能根据监控数据找到对应系统和应用的问题根源？

从本质上说，可监控性是云端迁移在决策期间的根据。没有它，云端迁移就会像是在“黑暗球场中投球”一样。

相应地，我们也需要有一个统一的管理平台，来追溯迁移团队所做的每一次更改、部署以及对系统和应用环境所造成的影响。据此，一旦在云迁移期间发生了任何问题，我们都能够通过其可观察性和监控，及时发现并按需回滚或处置。

写在最后

实际上，业界还有着许多关于轻松实现云端迁移的优秀实践，并且具体到各个操作细节的相关介绍书籍。不过，上述三个实践是从源头上，为你大家供了如何成功开展云端迁移的“谁”、“什么”、“为什么”的思路。当然，常言道“与其坐而论道,不如起而行之”，你我们以谨慎地选用一个成熟的云服务供应商，采用诸如Lightstep之类，针对企业构建的云原生SRE工具，实现迁移过程中的可观察观、监控以及事件响应等关键性平台服务。