云迁移周期4个阶段多条问题检索

摘要：不过，根据近期的一份调查问卷表示，在所有的参与者之中，只有的组织对于他们的云迁移体验感到非常满意。在本文中，我们将探索整个云迁移周期中的四个阶段。可以肯定的是，云迁移是一项不会真正结束的任务。

软件组织正在快速地实施云技术，但迁移始终是一个无法回避的挑战。哪些部分是需要你密切留意的？哪些应用程序更适合于进行迁移？如何对应用程序进行重构以适用于云端？经历了这一转变的先行者为我们留下了什么启示？在这一系列文章中，你将从那些在帮助企业成功地迁移至云环境方面富有经验的专家那里获得实用的建议。这一领域应得到高度关注，我们希望你也能够参与这方面的讨论。

如果你正准备将应用程序搬到公有云环境，那么你正赶上了这一波潮流。根据451 Research的调查显示，在2015年整个IT界有46%的成本都是针对非本地环境的系统，并且这一数字在今后三年内有望攀上50%[1]。企业仍然将节约成本视为购买云服务的主要原因，但越来越多的组织开始将“尽早推向市场”、“更好的可用性”以及“建立新的收益流”等战略目标作为云实施的主要动力。不过，根据近期的一份调查问卷表示，在所有的参与者之中，只有27%的组织对于他们的云迁移体验感到非常满意。如何将云服务引入你的IT环境，并且成功地将应用与数据迁移到新的环境，这方面显然还存在着很大的讨论空间。

在本文中，我们将探索整个云迁移周期中的四个阶段。可以肯定的是，（云）迁移是一项不会“真正”结束的任务。随着你不断地引入新的服务以解决新的业务问题，这一过程会不断地重新启动，只是其技术与目的可能会有所不同。以下这份清单也许能够帮助你踏上这一旅程，但重要的是定义一份属于你自己的清单，以适应于你的特定情况。

第一阶段：评估

没有一种云服务能够适用于所有组织，许多组织一上来就试图确定一个推荐的云环境，却并不了解这一选择是否与组织的成熟度、文化以及应用组合相匹配。那么，有哪些问题是你和这些潜在的提供商需要首先解答的呢？

1.你是否适用于这个云环境？云服务的提供商多如繁星，并非其中每一个都适合你的特定需求。有些云环境能够在几秒钟之内创建几千台虚拟服务器，如果你的组织正好需要这样的能力，那自然是一个好的选择。有些云环境能够提供服务周到、并且质量上乘的托管服务，但这些服务未必与你的运维模式相匹配。你需要考虑对你的组织来说哪些因素是最重要的，并且积极地尝试一些在成本允许范围之内的云提供商。请避免盲目地选择某个特定云领域中的“领先者”，这一选择可能会无意间对于你成功地交付服务带来负面的影响。

2.你对于运行能力的需求是怎样的？根据你希望迁移的应用的类型的不同，能够选择的提供商也有所不同。你的应用程序组合是否由大量现代的、适应云的应用程序组成，能够充分利用大量廉价的、临时的服务器或容器？你是否需要一个增长速度相对缓慢的池，但它能为你提供几百个持久的计算资源？仔细考虑你的应用特性，确保所选择的提供商能够满足你对于运算能力、存储能力以及网络吞吐需求的上限。

3.实际的成本是多少？“云成本”并不是在价格表上可以一目了然得出的数字。确保你对实际应用场景进行了建模，并且考虑对于跨区域分发、存储备份、带宽消耗、API调用等需求的针对性收费。此外，别忘了将项目上线、支持计划以及创建新环境（例如性能测试与预发布环境）等这些在本地系统中不存在的成本也列为考虑因素。

4.应用的“缺陷”在何处，这些缺陷在迁移后是否依然存在？在经过对云提供商的首轮评估后，你可能已经建立了一个已预见的、或是实际存在的缺陷列表。因此，你应当与提供商进行交流，以寻找 a) 是否有一些未来的计划能够弥补这些缺陷，或者 b) 是否有些可行的临时方案能够弥补这些缺陷。一种可能的临时方案是对于引起这种缺陷的基础设施或是应用模式进行重构，让其更好地适应云提供商提定义的模型。

5.你现有的工具能否适应这一环境？如果你在同一家公司已经待了一段时间，那么很可能已经习惯于某些现有的工具（及流程）了。如果你无法轻易地让你的工具运行在所选择的云环境中，请确保这个供应商所支持的工具集能够取代你现有的工具，而不会使你感到不快。

第二阶段：计划

恭喜你，你已经为一个特定的业务领域选择了一个云提供商。但现在才是最困难的部分：对迁移进行计划！在设定这一迁移策略时，有哪些东西是你需要着重考虑的呢？

6.这次迁移包括的应用、功能和环境是怎样的？在理想的情况下，较好不要将最复杂的、对业务影响较大的应用放在第一次云迁移的计划中。但不管怎样，请确保你为所有的应用列出一份详细的清单，并指出其中最适合你迁移到云环境的选择（无论是策略上还是战术上）。

7.整个应用程序架构的结构是怎样的？你的应用程序架构很可能会在云环境中产生变化。云服务器、数据服务和网络与本地环境的行为相比都有所不同，因此你可能要对你的引用架构以及部署流程进行一些改进，让它们能够适合这个全新的世界。

8.新的环境可能会带来哪些性能瓶颈？迁移到云环境就能够保证让应用程序的性能得到飞跃性的提高？绝非如此。如果你将一个一体性应用放到云端，并将它的各个部分分布到多个云服务中，这种方式可能会引入意外的延迟。而如果你的应用程序还与未迁移到云环境中的本地系统有所交集，由于两者之间的远距离连接，也有可能会导致性能问题。云服务器提供了多种不同类型及能力的系统，请确保为你的应用程序选择必要的CPU、内存和磁盘能力，以满足甚至超过之前的性能水平。

9.你的混合式集成计划是什么？如果你认为能够一次性将整个应用组合都迁移到云端，这种想法是不切实际的，甚至可能永远不会发生。你需要将云环境视为你的现有环境的一种逻辑延伸，在此基础上再考虑如何将现有的数据、网络以及认证扩展到云端。

10.你是否已经确定了第一批应用者？云迁移过程或许会产生破坏性，因此重要的是在组织中找到合适的人，他们非常乐于帮助你定义新的标准，并在这次重要的转换过程中为整个组织提供指导。

11.用户如何访问这一环境？你的同事大概已经有许多要记住的密码了，如果你还要引入一整套全新的复杂的证书，用以访问一系列关键的云服务，那是他们不想看到的。可以研究一下你的云提供商所提供的单点登录（SSO）机制，对于任何打算采用云服务的项目，都将这一点作为一个前期设计的考虑因素。

12.你如何对员工进行培训？让你的整个团队深入地了解新的云服务是非常重要的。你还要考虑到所有的受众（例如项目经理、开发者、架构师、系统管理员等等），并制订一些培训资料，帮助员工适应新的云环境。

13.为了充分利用新的服务，需要对内部流程进行哪些改变？现有的硬件申请、变更管理、测试以及部署等已确定的过程或许在使用云服务时会产生某种变化。如果你打算在这个更敏捷、自服务的环境中照搬现有的流程，可能会失去你原本计划进行云迁移时所构想的各种优点。因此，对于必须改变的部分，需要进行一次坦诚的评估。

14.你如何将新的代码、数据和配置部署到新的环境？新的云服务未必能够配合现有的系统管理工具，如果你正在使用现代配置管理工具，例如Chef或Ansible，或许有某种扩展能够让它在你的目的云环境中无缝地运行。请确保你对于部署和配置流程进行一次全面的模拟，并确定需要改进的地方。

15.在迁移后对服务进行运维的计划是什么？迁移只是应用在新的云环境中运行的起步，如果需要进一步的改动，又该如何处理？如果发生了某种问题，如何进行问题诊断？你会使用何处监控工具用于分析关键性能指标？仔细观察在云环境中应用请求的整个生命周期，考虑所有可能的调整与维护操作。

16.你是否设计了某种接入策略？如果你的应用程序用户能够忍受在迁移过程带来的较长的停机时间，那么你或许能够继续使用某种简单但具有破坏性的接入计划。但如果你希望将停机时间降至较低，那么你必须考虑应用某些策略，在你搭建新环境的同时与主环境始终保持同步，直到将所有访问都转移至新的实例为止。

17.整个财务流程如何进行？没错，你很可能需要为云存储付费，那么怎样处理这部分费用呢？是计划对每个使用云资源的业务部门分别收费，还是选择从共用资金中抽取一部分进行全额支付？请确保你已经仔细地考虑了整个付费流程，在支付的同时记得获取发票。

18.你是否已经进行了一次小规模的试用，并已对以上关注点建立了相应的计划？无论如何，不要仅仅进行了一些书面原型设计就开始进入迁移过程。你需要进行实际操作，在目标云平台上搭建应用程序并进行试用。在试用过程中熟悉整个环境的界面、功能以及各种限制，以这种方式获得实践性的知识。

第三阶段：迁移

在经过了适当的前期计划之后，迁移过程本身应当是波澜不惊的。可以肯定的是，在实际的迁移过程进行时，总是会出现各种意想不到的情况。但如果你已经能够解答以上这些问题，那么你的团队应当有能力处理那些意外情况。

19.你如何将应用及数据分布在云环境中？有许多方法能够将你的应用及数据保存在云端。对于中型应用来说，你可以选择使用简单的copy命令，通过网络连接传递数据。但对于大型数据集来说，这可能会让你的云提供商为此收取大量的带宽费用，还会延长数据转移时间。在这些情况下，可以采取一些更好的方式。 (a) 将数据压缩后拷贝到目标云环境中的某个存储位置，之后再将其转移到最终的目的地。(b) 将物理数据磁盘转移至云提供商处（前提是这个云环境支持这种操作）。

20.在传输过程中设置了哪些安全控制手段？在迁移过程中，你可能会用到预发布服务器或临时对象存储库。请确保你已经完整地考虑了数据与访问安全方面的问题，尤其是敏感的数据。

迁移虚拟机。将完整的VM进行迁移是一种将应用迁移至云端的方式，但根据这些VM如何在本地环境网络中设置的情况，有可能会发生意料之外的副作用，例如这些VM所在的域、它们所用的磁盘类型，以及其它各种情况。虽然将VM进行“Lift and Shift”式的整体迁移通常来说是云迁移的最简单方式，但它的复杂性往往走出想象。此外，这种方式不会促使你重新考虑应用程序的架构，以及为了应对云环境而对应用进行重构的策略。

迁移数据。你的数据可能会迁移至某个数据即服务环境，或某种自托管的数据库实例中。请确保你了解提供商具备哪些可用的工具，以及这些工具在数据容量或结构方面存在着哪些限制。

迁移应用。如果你的应用程序部署工具能够原生支持指向云基础设施、容器或应用平台，那说明这个工具功能比较出色。但你也可能属于尚未具备这一能力的少数派！可能需要花上一些时间对你的本地工具进行一些重新配置，才能够将代码部署到云端，或者你也可以试用一些新的工具，以使整个流程更顺畅。

重建元数据。许多公司总是表示，他们希望获得云端的“可移植能力”，而试图避免“绑定”在某个特定提供商的云平台上。这个……祝你好运吧。虽说像虚拟机或应用程序的代码这些资源可以相对比较容易地搬到云环境中，但环境元数据往往是特定于提供商的。每个云平台的帐户结构、用户、权限、策略、负载均衡器等等都是不同的。请确保你了解如何在特定的目标云平台上建立这些支持性配置信息。

第四阶段：验证

当迁移过程结束后，必须对应用程序进行全方面验证，以确保它完全按预期的方式运行。

21.应用是否可访问？这种测试很简单，但重要的是要全方面地检查应用服务的方方面面，确保用户能够访问这些服务，而且内部的组件也能够互相通信，并且没有出现错误。

22.是否所有的数据都已经正确地传输到云端了？通过自动化的检查，或者在最糟糕的情况下可以采取手工检查，以检验是否事务型数据以及引用数据都已经成功地传输至云端。如果你的数据关系非常复杂，那么一旦迁移过程出错，有可能会造成一连串的问题。

23.管理工具能否访问云环境？正常情况下，在计划阶段就应该对这一点进行校验了，但现在是最后一次机会，以验证所有的管理工具都能够访问云环境中的应用程序，并且能够对其进行监控，而不出现任何问题。

总结

每一天都有新的组织在成功地实施云服务，通过将应用程序迁移至这个更敏捷的环境，为他们的IT环境引入了新的活力。而在迁移过程中，不实际的期望最有可能导致整个过程的挫折。要摆脱这种焦虑，较好的方式是对组织的目标与意愿进行详细的评估，对于计划中的迁移流程中的各种问题给出实践性的回答。