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

非淡泊无以明志,非宁静无以致远。这篇文章主要讲述云迁移之5R方法优秀实践总结相关的知识,希望能为你提供帮助。

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

文章图片

引言:本从云迁移的5R方法出发,着眼改进企业文化、实施智能变更以及可观察性与监控三个方面,讨论方便企业进行云迁移的各项优秀实践。
近年来,云迁移(Cloud migration)这个术语频频出现在大多数企业的IT话题中。最初,该术语仅代表了将服务从本地基础架构的服务器上,迁移到AWS EC2之类的云基础架构上的相关实践。如今,云迁移的概念已拓展为:包括迁移到托管数据库、API网关以及可能需要AWS、或Azure来处理某些负载上。当然,如果贵企业属于金融或公共事业部门的话,则需要迁移到私有云、或是满足特殊监管要求的公有云。
下面,我将从改进企业文化、实施智能变更以及可观测性与监控三个方面,和大家讨论企业进行云迁移的各项优秀实践与原则。通过将这些指导原则应用于企业的云迁移工作中,可以帮助大家避免出现目的不清或低效的窘境,从而能够有组织地通过工具,来稳健地完成迁移工作。
在深入探讨优秀实践之前,让我们首先谈谈在云迁移过程中,通常会被用到的不同方法。
PART 01
云迁移方法之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)将发生的各种更改即可。由于云服务加快了服务和产品的转化速度,因此你的企业与团队应当适应此类变化,而变化所对应的角色也就显得非常重要了。
云迁移之5R方法优秀实践总结

文章图片

(2)跟踪指标
文化改进的另一个组成部分是确定关键性指标,并将这些指标记录下来。有人可能会担心此举会暴露出运营效率低下等问题。不过,根据短板原理,一旦存在运营的不衡量,就无法提高整体水平。因此,我们有必要在各个层面进行指标的跟踪。例如:从应用团队的角度出发,围绕并跟踪网络和存储延迟的指标。而对于更高的管理级别,我们需要简洁清楚地定义与说明服务级别目标(service level objectives,SLO)的组成部分,并尽可能让更多的团队知晓并遵守此类标准化的复合性SLO。你也许会说,我们何不用服务水平协议(service level agreements,SLA)来强制保证合同的执行呢?其实,相比SLA,SLO更可以帮助你个组织,了解当前应用的性能与可靠性是如何影响到客户以及整体业务的。
(3)有效地回答任何有关业务的问题
我们可以将编程的思想延伸到业务上,提高现有业务的可观察性和监控能力。例如,如果团队成员需要通过复制和粘贴PromQL的查询,来响应有关某个业务影响的问题,那么你应该将其视为改进的机会。虽然它可能牵扯到广泛而复杂的方面,但是在大多数情况下,你以通过将数据存储与灵活的可视化系统相结合,并有选择地针对不同级别的查询予以开发,来实现系统的开放性和可观察性,并最终达到快速、准确地回答业务问题。
2、实施智能化变更
变更管理往往给人的印象是严厉而刻板,变更管理委员会通常只会说“不”。而这显然不是“智能化变更”的体现。智能变更是一种使用技术门控(technical gating),而不是流程门控的云迁移方法。换句话说,我们需要通过自动化流程来实施保护,其中包括:端到端测试、持续集成以及分布式跟踪的证明等。而那些技术门控所无法涵盖的部分(或需要大量工作才能实现的部分)应当被放置到迁移列表的低优先级的位置。
通常,我们需要为更小或更简单的工作负载创建技术门控,以便为更复杂的、遵循相似流程的其他部分铺平道路。同时,我们可以通过迭代式地完成每个部分,直至达到足够的正确性和功能性水平,以实现云端迁移工作的可重复性。
3、可观测性和监控
如前所述,在迁移之前,提供系统和应用程序的可观察性(如果它们尚不具备的话),以便在此基础上开展各项监控工作,对于验证云端迁移工作的成败也是至关重要的。例如,根据是否可与数据库建立连接,你能判断其是处于启动还是关闭状态。而只有当你以查看到利用率指标、查询用时以及活动连接计数等参数指标时,才算是真正获取了数据库的可观察性。而有了可观察性,你可以进一步问出如下问题:
  • 我能够根据监控数据获得相应的警报吗?
  • 我的基础设施可以基于监控进行自我修复吗?
  • 我需要多长时间才能根据监控数据找到对应系统和应用的问题根源?
从本质上说,可监控性是云端迁移在决策期间的根据。没有它,云端迁移就会像是在“黑暗球场中投球”一样。
相应地,我们也需要有一个统一的管理平台,来追溯迁移团队所做的每一次更改、部署以及对系统和应用环境所造成的影响。据此,一旦在云迁移期间发生了任何问题,我们都能够通过其可观察性和监控,及时发现并按需回滚或处置。
PART 02
写在最后 
实际上,业界还有着许多关于轻松实现云端迁移的优秀实践,并且具体到各个操作细节的相关介绍书籍。不过,上述三个实践是从源头上,为你大家供了如何成功开展云端迁移的“谁”、“什么”、“为什么”的思路。当然,常言道“与其坐而论道,不如起而行之”,你我们以谨慎地选用一个成熟的云服务供应商,采用诸如Lightstep之类,针对企业构建的云原生SRE工具,实现迁移过程中的可观察观、监控以及事件响应等关键性平台服务。
【云迁移之5R方法优秀实践总结】原文链接:https://dzone.com/articles/3-best-practices-to-make-cloud-migration-easier

    推荐阅读