2021年8月27日，天津“国资云"的一纸政令一下子成为整个云计算市场的热搜。同时，相同措辞的的政令，在各地国资委都已经出现。
上云迁移已经成为全社会各行业普遍的共识，“上不上云”已经无须讨论，“怎么上云”成为企业用户关注的重点。纵观整个云迁移市场，”上云方法论“几乎无异，但是在云平台建设初期，往往疏于云迁移成本的预算，等云平台建设完成后，才意识到问题的严重性。此时，只能从现有的资金中挤占出非常有限的预算进行云迁移，却又面临着用于上云资金投入与用户预期不符的情况。最终导致的结果就是，云平台资源的巨大浪费，平台长时间处于闲置状态。对于云平台厂商，在初期项目中往往“亏本赚吆喝”，一切指望后期项目中磨刀霍霍，由于始终无法用于生产，云平台规模也无法扩大，导致一期的投入血本无归。
云迁移是一个复杂的系统工程，并不是一个工具就解决的。要秉承一套科学的方法论，在用户、云平台和迁移方的三方协作下，才能顺利完成。目前在云迁移过程中，最大痛点来自于前期调研阶段，这是后续过程的基础，但是在实践中又面临诸多阻力，例如：用户不配合、系统陈旧、业务系统无人运维方等诸多问题，导致无法开展后续流程。本文主要介绍基于容灾演练的理念，利用渐进式云迁移的思路和方法，将一部分调研工作后置，解决在上云前调研中的难点，通过构建”仿真“环境，在实践中完成调研中最困难的部分，加速云迁移的过程。
云迁移之调研痛点分析
调研是云迁移实施前非常重要的一个环节，调研也决定了后续整个项目落地的进度和最终的效果。调研基本分为两个部分：
技术调研
技术调研核心目的是通过对源端主机和综合环境信息进行采集，找出适当的迁移方法，也就是AWS倡导的"6R"迁移策略。技术调研部分最重要的一个环节就是以单台主机为单位，通过收集计算、存储、网络等基础资源，合理对上云后的架构进行规划，以便来判断使用何种工具进行迁移。技术调研非常重要，因为这是决定是否可以迁移以及成本非常重要的一环。
业务调研
业务调研是以用户为主导，以技术调研的基础，对业务系统归属、关联性等进行分析，明确业务系统运维负责人和使用方，对于上云后发生的变更，还要明确变更的内容及执行人等信息。业务系统调研本身并不涉及过多技术内容，更多的是以现有的业务系统统计信息为基础，就可以很快得出结论，但是在实际的项目执行过程中，这部分往往是阻力最大的部分。
痛点分析
首先，责任归属问题。负责云平台建设和迁移的部门往往是底层基础支撑部门，例如：在传统的政企中的信息部、系统部等，而受影响的部门却是业务部门。而由于迁移过程中触发的上层业务系统变更，无疑给这些业务部门增加了额外工作。所以在实际走访调研过程中，不配合基本是常态，问题超过三个，就会出现了不耐烦、推三阻四或顾左右而言他的情况。稍微配合一点的，就是登陆系统后告诉你，双手一摊，”你自己看吧“。上云是一个自顶向下的过程，用户领导层的决心和执行力是项目成败的关键。
第二，数据安全。由于不清楚云迁移的风险，用户过分担心迁移过程后的数据安全性和业务连续性，要求迁移前进行大量前期的方案整理和调研工作。前期”空想“的内容太多，最终导致项目迟迟无法启动。
第三，业务无运维。用户的业务系统并不是一天建成的，这其中的跨度可能历经数十年的时间。从实际项目情况看，能够将自己业务系统梳理清晰的客户并不是很多，更别说是上云后要变更哪些内容，甚至一些陈旧的业务系统，连原厂商都找不到，而且这样的情况还不在少数（背后的原因大家可以自行脑补）。这也间接导致了第一点问题，没有人敢为此承担责任。在实际项目中，经常有些业务系统没有人敢重启，因为谁也不知道系统重启后业务还能不能用，因此没人愿意承担由此产生的后果。
第四，调研对人员专业性要求高。通常认为调研的难度往往与咨询划等号，天然认为调研人员往往需要具备较高的技术宽度，见多识广，接触过不同类型的业务系统架构，这样的门槛往往让许多传统集成商在转型云MSP时望而却步，根本不知道该从哪里开始。在实际项目中，调研工作往往依靠Excel统计，事实证明，填表人的想象力和创造力超乎你的想象，填回来的信息五花八门。如果靠人力去完成，用户的资金投入根本无法覆盖调研过程的成本，而且耗时耗力、周期长，很难避免错误的产生。
用容灾思路解决上云迁移痛点
与传统物理环境下的迁移不同，云的“软件定义一切”的特性，决定了云资源的可编排性和最终一致性。在之前《云原生趋势下的迁移与容灾思考》我曾经提到过，云计算平台解决了云上资源的可编排性，而云迁移与云容灾则是将云的编排性和数据结合在一起，形成了云上数据的管理平台。正因为如此，云间数据流转成为常态化需求，业务系统在不同云间运行成为可能，同时也进一步模糊了云上迁移与容灾的边界。
针对上述出现的痛点，我们在项目实践中通过容灾渐进式云迁移方式构建”仿真“环境，将一部分前期调研工作后置，通过容灾演练来解决前期调研中需要业务人员“空想”和“烦躁”的局面。使用技术调研标准化和工具化来保证调研结果的准确性，让迁移项目能够快速和顺利的推进。
容灾渐进式迁移
前面提到，业务调研中最大的阻力其实来自于”人“，技术手段解决不了”人“的问题，但是可以将工作难度降低，间接清除阻力。所以在最佳实践中，我们决定将部分调研工作后置，具体的做法如下：
业务调研阶段，需要明确业务系统组成范围，即哪些主机构成了一个完整的业务系统，因为这决定了迁移的顺序和方案的规划，这个环节还是必不可少的，而且基本上对于用户没有太大的难度。接下来，需要明确业务运维负责人（业务变更）和业务负责人（业务验证），对于没有业务运维负责人的老旧系统，可以考虑不迁移或者淘汰，如果用户执意迁移，则要明确运维边界（通常涉及商务问题）。而对于业务关联性、系统变更等复杂的业务问题，则后置在迁移验证阶段完成，在仿真环境完成。
目前，国内大部分政企客户的迁移中，主机级别迁移占绝大多数，基本上都会采用块级别整机迁移的方案来保持迁移的一致性。上面提到，云的可编排性让我们可以利用容灾演练的方式在云端重复仿真一个真实的”生产“环境，解决业务调研中，”受制于人“的部分。让业务运维人员和使用方都有充足的时间对系统的变更及稳定性做出验证，一方面杜绝了在调研前期的空想，另外一方面也能够将责任划分清晰。要实现这样的目标，在选择迁移工具时，要具备以下特征：
首先，迁移工具自身与云平台要进行过充分的对接，不能只是简单的对接一两个启动主机的接口，要充分利用云平台的卷快照、主机启动时的存储类型、网络等接口特性，例如：租户级别的卷转移、密码、密钥管理、指定IP、卷启动等特性，即实现利用数据副本还原生产环境的效果。这样原有增量同步仍然能够继续，保证后续割接顺利进行。当业务系统达到一定数量时，没有高度自动化的云上数据编排能力，是无法完成仿真环境的创建的，手动创建的工作量超出你的想象，而且极其容易造成错误，只有高度自动化的能力才能保证仿真环境构建的准确性和一致性。
第二，充分利用云上虚拟网络隔离的特性，构建近似真实的仿真环境，而不影响正常的业务系统运行。最好的方式，就是通过构建与真实环境相同的网络地址段（与原有网络隔离，避免造成数据污染），将业务系统按照原有IP地址恢复至该网段内，这样仿真环境就真正的建立好了。迁移工具在演练阶段要保证每台主机数据的完整性、系统的正常运行，而此后就可以让业务系统的运维方在仿真环境中进行业务变更验证，并将步骤记录，而业务系统负责人在仿真环境从业务维度进一步验证。解决之前空想状态下的调研工作，也让业务方能够安心进行验证后迁移。
最后，实现最终的迁移实施报告，在规定的时间窗口内，完成最终的业务割接上云。
技术调研标准化与工具化
技术调研是调研工作中技术要求最强的部分，也是最重要的部分，这部分并不是依靠经验，而是通过标准化的技术方案，形成流程的标准化。
在最早从事一家银行云迁移项目中，我们主要采用人工统计方式进行调研。使用Excel模板形式，发送给业务方进行填写，但是随着调研的推进，无论我们的模板做了多少种样例，填写回来的数据总是千奇百怪，有一半的数据是不可用的。后来我们成立专门的调研专家组，由我方（一人）和用户业务专家（两人）共同组建，由我方技术人员负责技术部分调研，由业务专家组负责调研关联性、停机窗口、迁移后变更信息等与用户业务相关的部分。在这种情况下，调研20套业务系统（主机数量在50台以上），大约在三天左右时间。虽然这样能有效提高调研结果的准确性，但是仍然有技术调研结果不准确，导致在迁移过程中临时变更方案的情况出现。
通过项目磨炼，我们经过对调研过程的总结，形成了标准化的技术调研方案，进而将该方案形成研发需求，开发出调研及分析工具。调研工具的原理非常简单，主要分为三个主要功能：
功能一，通过网络扫描所有存活的主机，通过对nmap的封装，能够对用户局域网内存活的所有主机进行针对性扫描，同时扫描出开放的端口等信息。该步骤作为详细采集前的准备数据。
功能二，基于第一步扫描的结果，由用户业务方提供主机和密码等信息，如果是VMWare，则只需要提供vCenter或ESXi的用户名和密码，程序执行后将自动获取必要的主机详细信息，为进一步分析提供依据。
功能三，基于功能二的详细输出，根据迁移工具的特点进行详细分析，最终得出准确的技术调研报告，其中包含迁移方法及预估的数据同步时间。
通过以上方式，在技术调研部分我们逐步形成了标准化和工具化，而上述调研工具我们也将逐步开源(github.com/hostminer)。
总结
相较于传统环境，云上环境更能模拟出”仿真“环境，而云的可编排性又为数据统一的管理提供了保障，充分利用云原生接口及资源的特性，能够让我们通过技术手段间接的解决业务上的问题，从而加速项目的推进和实施工作。以上就是我们在实践中总结出对迁移中业务调研难点的解决方案，这种方式特别适合于加速传统的政企客户上云，解决用户的后顾之忧。
