【51CTO.com快译】如今，随着技术迭代的不断加深，许多企业都将目光从传统的数据中心，投向了蓬勃发展的云端服务。许多企业的CIO也都将云服务，视为成功实现数字化改造的关键性平台。籍此，他们能够将当前的业务系统迁移到云端，以提供现代化的应用服务。
另外，就成本而言，企业希望通过不同的协作、敏捷性的流程、以及创新的业务模型，以低成本的方式，从云端解决方案中获取服务的灵活性，进而把握新的商机，提高竞争优势。可以说，无论是在哪个领域，更好的客户体验、更灵活的移动访问方式、以及更安全的低成本服务，都会给企业带来莫大的好处。
在实践中，为了制定恰当的云端迁移策略，我们需要从如下基本问题出发，考量是否能够满足企业的总体运营目标：
- 哪些应用程序、流程、乃至基础架构会被迁移到云端?
- 迁移的目标是什么?
- 谁拥有主动权，IT还是业务?
- 资金来源：资本支出、运营成本、还是转嫁到第三方?
- 要迁移到哪种云类型：私有云、公共云还是混合云?
- 如何迁移到云端?
当然，虽然许多企业在应用上都有云迁移的需求，但是并非所有的应用都适合被迁移过去。
无法迁移到云端的挑战?
即使在现在，以政府、银行和保险业为核心的企业仍然会犹豫：是否有必要从完全的本地架构转移出去，是否会失去对数据的全面控制，云服务是否会与现有的基础架构(尤其是核心应用程序)难以集成。这些顾虑都可能会妨碍企业对于新的业务机会的把握。
另外，阻碍将业务应用迁移到云端的其他因素还包括：数据中心本地应用的运维和支持成本的增加，数据存储和分析能力的不足，安全风险的上升，面对新生威胁的防护不足，以及在实现应用扩展的移动性、与对新兴技术支持方面的能力受限。
下面，我们来一起讨论一下，那些能够让企业成功实现高效云端迁移的优秀实践。
云迁移的内外部驱动力
由于整个迁移过程会产生一定的成本，因此我们需要事先发掘云迁移的内、外部驱动力，例如：
- 需要整合那些冗余的IT资源、以及退役或残留的应用软件，减少数据中心的占地面积、并提高计算的整合能力;
- 通过应用程序的更新换代，以满足基于行业的技术标准和软件的业务目标;
- 通过对IT领域采取最低投资和最高回报的策略，以实现按需扩展IT资源、以及按需付费的目的;
- 根据市场需求提高业务绩效，灵活应对不断变化的业务需求，以最小的变化和投资，达到业务系统的灵活性;
- 根据业务资源的预算，降低IT资源的总体拥有成本。
为了预估应用程序在云迁移中涉及到的工作负载，企业应事先确定有哪些应用、流程和数据需要被迁移，以及目标云端环境的类型(公有云、私有云、还是混合云)。
许多组织都会选择以增量的方式开展应用的迁移。也就是说，他们会选择那些提供信息服务、拥有客户数据及敏感信息最少的应用程序入手。由于风险最低，也就方便了实施方根据实际情况弹性地进行决策的调整。
云迁移优秀实践
除了上面介绍到的增量迁移这一基本原则，我们还可以参考如下方面：
小步试错
第一种优秀实践就是“试错设计”。为了证明迁移概念的可行性，我们可以从整体的应用中选取一个较小的服务，来予以迁移验证。其中，我们可以通过测试工作的负载、估计应用迁移所需要的资源(包括：存储的大小、所需的虚拟机数量、网络的带宽、以及安全相关的控制要求)，来评估迁移后的应用与原始服务质量之间的差距，进而不断地改进当前的迁移计划。当然，我们也需要根据业务方对于云迁移后的详细需求，来判断云平台对于应用所存在的兼容性问题。这就是Proofs Of Concept(POC)在此环节所发挥的作用。
标注移动组
我们将那些可以被迁移到云端的应用称为移动组(Move Group)。这是一个逻辑分组，该组内的所有应用可以在同一个预设的时间段内被迁移到云端。
分组的好处在于：我们既可以让多个移动组并行开始迁移，也可以让一个移动组紧接在另一个移动组完成之后马上启动。当然，您还可以根据业务或技术的短期、长期目标，实时调整不同的迁移方式。如下六种方法被称为“6个R”(请详见https://dzone.com/articles/the-rs-of-migration)：
- 重新托管(Re-hosting)：您可以使用自动化工具或手动的方式，来直接迁移(Lift-and-Shift)各种应用程序。
- 重新平台化(Re-platforming)：启用新的平台、并修改底层基础设施。不过现有的程序架构仍保持不变。
- 替换(Replace)：直接转移到其他类型的平台(推荐是SaaS平台)上。
- 重新架构(Re-architecting)：使用云平台的原生功能，重新设计应用程序与基础架构。
- 退役(Retire)：直接“退役”掉应用程序，另起炉灶。
- 保留(Retain)：继续在当前的状态下使用应用程序。
多云环境
此步骤有助于确定应用程序将在单个云环境中运行、还是在多个云服务环境里被执行。就单个云提供商而言，我们很容易锁定之;而如果涉及到向不同的云提供商迁移的话，就需要多方协调努力了。具体模型包括如下三种：
- 单云环境中的应用：即，一整类应用程序都运行在同一个云提供商处，而其他类型的应用则运行在别处云提供商那里。该模型的好处是：企业可以灵活地增加新的业务。
- 将应用程序拆分到多个云提供商处：即，单个应用的一部分运行在某一个云提供商处，而另一部分则运行在别处云提供商那里。该模型的好处是：企业可以利用每个云提供商的各自优势。
- 云不可知(Cloud-agnostic)类应用：即，此类应用可以运行在任意云提供商上。因此，该应用既可以同时运行在多个云提供商处，又能够被拆分到多处。显然，该模型给企业提供了将负载从一个云提供商，迁移到另一个云提供商的灵活性。
自动化
自动化提供了在无需任何停机时间的前提下，以代码的形式构建基础架构、以及自动化部署应用程序的能力。因此企业希望在多个应用程序的迁移过程中，以自动化的可重复模式，减少迁移时间，提供更好的一致性。同时，企业内部的团队之间也能相互传授那些自动化优先的流程，进而能够更好地从云端迁移中获益。为了利用远程交付来安排与监视各项作业，企业可以采用迁移工厂(migration factory)的模式，来降低劳动力的成本与时间、以及云迁移所需的现场专业服务。此外，企业也可以有目的性地去检索那些可用于支持基于云许可(cloud-based licensing)模型的各种软件工具集。
数据迁移
在开始从生产环境向云端迁移之前，企业需要对有待迁移的数据进行完整的评估。企业可以直接将本地数据集发送到云提供商处，以便由他们负责上传到云端;然后在现有的数据中心中仍然保留既有的主机应用，仅将调用关系指向那些被迁移到云端的数据而已。这通常是针对大量零散数据的优选迁移方案。同时，为了给数据制定适当的归档与备份策略，企业可以参照这样一种优选实践，即：尽可能地将动态数据接近计算资源，而将静态数据尽可能地接近用户侧。业界往往是通过传统的缓存技术来实现此目的。
监控与治理
为了构建满足企业实际需求的云应用服务，企业内部需要由多个跨职能部门的团队，来负责开发和管理企业的云端战略、以及各种实践。同时，企业应该采用敏捷(Agile)的方法，在整个迁移过程持续进行学习与改进，进而在“小步快跑”中实现大规模的云端迁移。
在许多企业中，他们都会设立系统迁移架构师的岗位，来专门负责规划和领导迁移的各方面工作。在具体实践中，他们的核心职责包括：定义迁移成功所需的必要重构条件，设计数据迁移的相关策略，根据云解决方案来定义需求，以及确定迁移工作的优先级和切换的模式。通过与企业中其他业务部门的协作，他能够顺利地稳步推进云转移的顺利完成。此外，由运营、开发和设计部门所组成的云迁移团队，需要通过持续学习和相互培训的方式，开发出各种自动化的模板，进而对云应用的架构进行不断的设计与改进。
总结
如今，企业上云已是大势所趋、势不可挡。各类企业需要通过将原有的应用程序移植到云端，来降低运营成本，缩短产品的交付时间，增加增值收入，挖掘创新资源，进而将自身的注意力集中在核心业务上。综上所述，我们基于业界各类企业的云端迁移经验，为您总结了如下十一条优秀实践建议：
- 选择正确的云提供商。
- 使用正确的迁移工具。
- 转变为敏捷的操作模式。
- 通过可扩展性和高可用性，来最大化生产率。
- 尽量将开发和测试环境移植到云端。
- 始终将企业核心功能迁移到私有云中，而将非核心服务迁移到公共云中。
- 如有可能，应采用混合云的模型。
- 将现有架构转换为可扩展的、基于动态API的交互式模型。
- 将云原生能力赋能给各种应用程序，通过转换，实时输出可操作性的数据。
- 通过驱动高水平的自动化，来减少项目和运营的各项成本。
- 引入掌握熟练知识和技能的人员。
原文标题：Best Practices for Effective Cloud Migration，作者: Dr. Gopala Krishna Behara
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
