戏说云上日式搬家

2019-09-05

声明

这不是一个搬家公司的广告，只是一个漂泊云上的挨踢狗的戏说。

前言

做为一个北漂，搬家就如同家常便饭，但是每次搬家仍然感觉是一次灾难：打包时发现纸壳箱各种不足，搬家过程的各种混乱，家具被磕磕碰碰，很多小物件从此消失不见，在搬家后，有那么几天，感觉生活停摆。做为一个云上挨踢狗，帮助更多的企业将系统搬迁上云也已经是日常工作的一部分。某日，在总结工作时，忽然发现两者居然是如此的类似，于是决定把二者合二为一来戏说下，给生活增添下乐趣。

第一次用公有云，很多人会发现，原来你在本地机房中繁琐的安装和配置工作，在云端只需要分发一个小程序，数秒内你部署在世界各地的系统就可以同步更新，系统迭代的速度大幅度提升。相信这是很多人喜欢上公有云的重要原因。但是，真正把系统搬迁到公有云，就会发现，一切并非那么简单。数据问题、存储问题、网络问题、接口系统、安全问题等等，各种问题就像那挡在你搬家道路上的障碍物，严重的时候让你的业务停摆。不合理的迁移是一场灾难，让你的上云信心大打折扣。

不知道大家是否看过日本人搬家公司的搬家过程，可以说全过程追求细节的保护与服务，策划、打包、搬运、归位、清洁，一站式服务，搬家变得更加有条不紊，更加安全。做为一个资深运维专家，神州泰岳在结合了AWS的相关最佳实践，以及本身的迁移经验基础上，提出了五步迁移法，使得上云迁移服务就如同日式搬家服务一样，提升了用户的云端感受。

五步迁移法

下图为AWS给出的最佳经验。神州泰岳在上云迁移方面遵循了五步法，同时通过自身经验，对五步法进行了完善，形成了泰岳上云五步法，就是我们后面想要戏说的云上的日式搬家法。

AWS五步迁移方法论

下面开始我们的戏说吧，看看日式的云上搬家会是什么样子的呢？

第一步：定目标

其实准确来说，真实生活中的搬家目标是比较清晰的，而云上的搬家目标则非常复杂。即使是在一个公司，由于职位不同，大家对云上迁移的目标也不尽相同。例如，就CFO而言，云上搬迁可能解决的是本地数据中心的投资问题，其自然希望搬迁后成本能够更加优化；而业务人员可能更多的是希望搬迁的速度更快，业务能够更少受到影响；运维人员可能更多的是希望搬迁更加简单便捷而不是带来更多的工作量和风险；做为安全人员则更多的是希望迁移不要带来更多的安全风险。因此，由于迁移目标的不同，所选择的迁移方法的差异很大，迁移的成本也将会有很大差距，所以，迁移目标的确定在迁移之初是非常重要的。这一点已经远远超出了生活中的搬家。

正是由于制定目标是决定整体迁移活动的关键，AWS在总结经验的基础上，给出了从6个视角来重新审视业务和技术的框架，名为AWS云采用框架(简称AWS CAF)。该框架可以帮助客户更加全面的进行评估，确定合适的目标，从而更快、更低风险地实现采用云带来的可度量的业务收益。框架所涉及的访谈客户上到CTO、CFO，下至系统维护人员，可以说是相当的全面。

实践证明此方法论下，最终确定的目标是科学的，也是得到了用户的一致认可的。目标的确定往往最终与搬迁的结果和搬迁后的效益直接相关。

第二步：策划

一般的搬家公司来了就搬，没有这一步骤，所以往往你也记不清楚到底搬了多少件东西，即使你数清了大件，往往还有很多小件被遗忘。而日式搬家的第一步就是将物品分门别类，然后列出一份一张详细清单，之后按照你家具物品的数量和种类，为你规划出一套最划算、最周全的搬家方案。如果其中有非常贵重的钢琴或者大穿衣镜，将受到额外隆重的待遇。

云上的迁移也是从基础设施和应用的调研开始的。收集客户当前基础设施的性能、使用情况、部署情况，进行记录（包括业务的闲忙时及该期间的使用情况）；了解业务应用的优先级，系统间的相互依赖度；列出应用程序基础设施清单。在这方面有很多类似的工具进行现有系统和设备的配置收集。

当处理一个重大的项目时，最具挑战性的部分是决定从哪里开始。如果客户有明确的选择，这一步会相对简单；但是，如果客户的基础设施分布在多个数据中心或多个团队中，没有一组用于评估应用程序的统一度量标准，则很难确定哪个APP最适合第一波迁移。

第一波迁移的项目，我们会希望是那些对业务影响较小，且迁移后效果明显的项目。行业研究表明，多达30%的本地服务器都是僵尸(在6个月或更长时间内没有显示出有用的计算活动的迹象)，超过35%的服务器显示活动的时间少于5%。此类应用对业务的影响一般情况下会比较小，首先进行迁移，且在云上正确调整部署的大小，就能够使用户明显感受到迁移到云端的高性价比。毫无疑问，这是云端迁移最佳的撬动点。

事实证明，寻找的与其他应用依赖性少，服务器冗余多，且当前容量有浪费的应用做为首次迁移的应用，会很快让你的客户尝到迁移的甜头，后续的迁移会更加顺利。如果碰巧需要迁移那种大型的，已经无法招待开发人员的应用，则让你的迁移困难重重。

不同的业务，如何迁移上云呢？错误的规划，往往会直接影响到迁移的成败。在云上迁移过程中，我们也会根据用户的业务特性，遵循AWS的6R法则，帮助客户确定，哪些应用是可以直接迁移的（Rehost），哪些是需要修改后迁移的（Replatform），哪些需要重构后再迁移的（Refactor），哪些是不能迁移的（Retain），哪些是停用的（Retire），哪些是需要重新购买服务的（Repurchase）。

当然，最终迁移规划的制定往往也是与财务、公司规划等方面直接相关的，经过各方面的协商，最终才会得出一个被大家认可的迁移计划。

第三步：打包（设计）

从这一步就能够看出来，云上的迁移远远比现实中的搬家复杂的多。当业务真正搬到云端，需要考虑的问题较之前要更加全面，比如安全传输问题，数据的安全存储问题。原来你没有意识到的问题，纷至沓来。公有云与生俱来的弹性扩展、简单易用的高可用性和容灾方案等，只有在真正使用起来才能够发挥其强大的功效，如果只是将物理机上的配置简单搬迁到云端，没有合理的使用这些特点，仍然无法真正实现公有云的优势。因此，优秀的云上良好框架的设计，是云端迁移的基础，也是为什么很多企业请求专业公司协助进行迁移的主要原因。

良好框架的建立除了要求熟悉云端计算，也要求对用户的业务应用情况和应用的相关软件技术非常熟悉。因此，在设计阶段，客户的业务和技术人员也是需要全程参与的。

在架构设计方面，我们遵循AWS的良好框架要求。对设计的合理性，一般在迁移中，挑选部分简易的应用进行验证，然后再根据验证结果进行设计修改。因此，第三步与第四步是循环往复的。

第四步：搬家（迁移和验证）

日式搬家当天，为了不损害大楼墙壁、设备等，工作人员会在搬动前铺设保护垫。算你家是公寓楼，他们也会一路从大楼门口、电梯、楼梯、走廊一路贴到你家地板，以免搬运过程中碰到你的物品。

此外，让人印象最深的是，为了不使衣服在搬运时弄皱，搬家公司会准备像类似简易的移动衣柜的衣架箱，短袖、短裙会塞进小纸箱中，大衣、外套则会放进大纸箱中；鞋子在搬运中不会被挤变形，因为搬家公司会准备专门的简易鞋柜；至于易碎物品，搬家公司也会准备专用的"缓冲气垫包装箱"逐个隔开放。

云上迁移中，我们也是小心翼翼的。有的项目中，在用户预算允许的情况下，为了不影响业务的持续运行，采用了CI/CD的迁移方式。在迁移中，使用AWS CloudFormation模板构建框架，派生出未来的环境；使用AMI和Puppet或Chef等自动化配置管理工具等自动化的迁移手段更是迁移的首选。在迁移过程中，我们也将根据用户的业务和系统的需求，进行迁移工具的选择，如服务器和数据库迁移工具，数据迁移工具等。就如同那些大小的纸箱，完全根据用户的业务要求进行选择。

为了帮助一些初创企业更加顺利的完成迁移，我们更是帮助他们向AWS进行优惠政策的申请，以更低的成本完成迁移。

第五步：清扫归位（优化）

日式搬家的后续清扫和归位，也是让人印象深刻的一个地方。大件物品工人会按照主人要求摆放。小型物件会依照原样，摆放在之前的位置。连鞋子和衣架箱里的衣服，工作人员都会帮你挂回相应的地方。待物品都按照主人的指令归位后，他们还不会离开，还会再重新打扫一次。

而云上业务的迁移完成后，我们的架构师也会对系统进行一段时间的观察，保证业务正常进行的同时，检查哪些系统运行较为低效并提出优化建议。通过不断调整和优化，将系统和运营调整到最佳状态，才最终完成整个迁移过程。这就如同日式搬家最终的清扫和归位，云上的优化不仅仅是归位，更多的是为了达到系统状态的最优，达到对业务的促进。

以上关于搬家的内容，参考了一些搬家公司的宣传手册，由于是戏说，云上部分较为笼统，如有兴趣，请留言进行咨询。

 

返回技术博客