第5章 大规模迁移至云端的流程

首次发布于2016年11月1日：http://amzn.to/migration-process

“我们不能也不应该阻止人们迁移。我们必须为他们提供更好的日常生活。迁移是一种过程，而非问题。”

——William Swing

本章将概述五段式“迁移过程”，希望帮助高管们在考量大规模云端迁移时得到启示。本章为系列三章中的第二部分。第4章（本系列的第一部分）介绍了大规模迁移概念，在本书中我们将其简称为“迁移”。第6章（本系列的第三部分）则将介绍应用程序云迁移工作中的6种可行策略。虽然各章节独立存在，但由于其内容相互关联，因此推荐您将其视为一个系列化整体。

迁移过程结合了我们（AWS）对技术迁移的理解以及我们在帮助众多组织进行IT资产组合迁移时积累的实践经验。这一基于经验的过程将提供多项指导原则而非固定快速的执行细则，以帮助您逐步完成迁移工作。每个组织都拥有着自己的独特约束条件、预算额度以及政治、文化与市场压力等因素，这一切都有可能影响您的实际决策过程。

第一阶段：机会评估

哪些商业案例或者重要事件，促使您将工作负载迁移至云端？

在理想情况下，您应该结合一部分既有经验（详见第2章与第3章）并借此考虑商业案例迁移的收益。在云市场的形成阶段，迁移工作往往出于本能性反应——即某位高管认为这代表着正确的发展方向。随着市场的发展，越来越多的企业开始考虑迁移什么以及如何迁移，而能够推动组织整体采取迁移行动的商业案例和重要事件也变得越来越多。

虽然我不可能了解每一项商业案例或重要事件，但在实际经历中，我发现数据中心租约到期、提高开发者生产效率、业务全球化扩展、即将进行的并购活动和架构标准化已经成为其中最为常见的驱动性因素。

举例来说，我们的一家合作客户开发出一个用于增强开发者生产力的商业案例。客户（理所当然地）认为通过将数据中心迁移至AWS，并在过程当中培训开发人员，将能够使2000名开发人员平均获得50%的效率提升。由于消除了基础设施的配置等待时间，且能够直接访问超过80项现成商用服务（无须自行构建或单独采购），该公司有望每年获得相当于1000人年的开发者效率提升。客户打算利用这部分额外的生产力支持100个新项目（每个项目分配10位开发人员），从而找到新的净收入增长来源。（作为拥有CIO任职经历的从业者，这可能是我最推崇的商业案例。当然，如果大家想听到其他有吸引力的商业案例，请告知我，我们将在其他文章中进行分享。）

即使您的组织不需要正式迁移至云端的商业案例，我认为领导者们仍然有必要在这方面建立明确的目的以及积极并可行的、整个组织可以团结在其周围的目标（第13章）。事实上，很多遭遇迁移失败的组织正是缺少这样的目的和目标。

随着迁移工作的推进，您将可以得到磨练去创造更多的价值，思考如何将这种价值信息传递给组织，并以更具信心的方式引导组织采纳这种即用即付的IT服务采购模式。

第二阶段：组合发现与规划

您的环境中有些什么要素、其依赖性如何、您打算首先迁移什么，又将如何实施迁移？

在此阶段，组织通常会对自身配置管理数据库（Conf i guration Management DataBases，CMDB）、机构知识以及部署工具（例如AWS Discovery Service和RISC Networks）进行检查，从而深入理解他们的周边环境。利用这一知识，组织将能够整理出一份计划（随着迁移与学习的进展将相应变化），用于阐明通过怎样的顺序对组织内的各应用程序进行迁移。

对现有应用程序进行迁移的具体复杂程度，取决于您的实际业务架构以及当前的许可安排。如果要将应用程序迁移的复杂度范围视为一段频谱，那么我会把虚拟化且面向服务的架构作为低复杂性的一端，整体式大型机应用则作为高复杂性的一端。

在这里，我建议大家从低复杂度一端作为起始，因为其明显更易于实现——这将为您快速带来积极的反馈，或者可称为“快速胜利”。

此外，复杂性也会影响具体迁移方式。托管在虚拟化环境中的现代应用程序往往更容易直接迁移，而且刚刚开发3年的技术方案在技术债务方面也远少于拥有20年历史的技术方案。在这方面，我们强烈倾向于采取重新托管（亦称“直接迁移”）。另外，由于无法对大型机进行直接迁移，我们也强烈倾向于进行功能合理化与架构重构。我们（AWS与APN迁移合作伙伴）正在尽一切可能降低大型机（以及其他遗留系统）的迁移门槛（请联系我以了解更多细节信息）。但必须承认，截至目前还不存在百试百灵的解决办法。

第三阶段与第四阶段：应用程序的设计、迁移与验证

我通常将这两个阶段称为“迁移工厂”，其中迁移工作的关注重点由组合层面转移至单一应用程序层面。而每一款应用程序都将根据六项应用程序迁移策略（第6章）中的一项进行设计、迁移与验证。

这里建议大家采取持续改进的方法。首先从复杂度最低的应用程序开始学习如何执行迁移，了解关于目标平台的更多信息；而且随着组织内有关云和迁移知识的普及提升，将能够实现更复杂的应用程序的迁移。

为了快速扩展迁移工厂的规模，这里建议大家建立敏捷团队，专注于特定类型的迁移主题。可以指派多个团队致力于负责一种或者多种迁移策略、常见的应用程序类型（包括网站、Sharepoint、后台等）、不同的业务单位或者是这些因素间的某种组合。确定迁移主题提升各团队的专注水平，将进一步加快他们整理出常见模式以及执行迁移工作的速度。在理想情况下，此前建立的云卓越中心（第24～31章）将为各团队的迁移事务提供建议与指导，从而帮助其切实取得进步。

最后，请确保您拥有一套遗留系统的测试与清退策略。好消息是，大家在清退旧有硬件时不必再经历新硬件的采购与配置过程。大家可以在对流量、用户或内容进行迁移的同时，保留一段时间原有的环境。为了缩短这一时段，请确保每项业务的负责人皆参与其中并准备好实时验证迁移结果，同时在实施过程中不断衡量二者在成本与性能方面的差异。

第五阶段：现代运营模式

最后，随着应用程序的持续迁移，将对新的基础设施进行迭代改进、关闭旧有系统，同时不断更替直到建立起现代运营模式。

在就职于道琼斯时，我们曾以迁移来强制性采纳DevOps文化（第28～31章），而且如今已经有越来越多的高管希望以同样的方式为组织引入敏捷理念、精益文化或者其他听起来很精彩的能够推动应用程序开发效率的方法。

在这里，我鼓励大家把自己的运营模式理解成不断进步的人员、流程与技术组合，这些因素会在应用程序的迁移过程中持续改进。大家不需要以一蹴而就的心态指望快速解决一切可能出现的问题。在理想情况下，您会在建立商业案例的同时积累起新的开发基础。如果没有，请利用此前几次应用程序迁移积累得到的经验不断改进现有运营模式，并随着迁移工厂体系的加速推进提高其复杂成熟度。