云基础架构采用者避坑指南：传统 IT 向云迁移实践企业IT系统拥抱云往往始于云迁移

【云基础架构采用者避坑指南：传统 IT 向云迁移实践】企业 IT 系统拥抱云往往始于云迁移，或基于云原生的构建。如今对于企业用户，仍有很多应用部属在本地数据中心，且属于业务关键型系统，比如 SAP HANA 。因此，确保安全平滑稳定迁移到公有云，对于这类客户至关重要。今天我们邀请微软资深云解决方案架构师，为您带来传统 IT 向云迁移的实践指南。
文章插图
云迁移项目实施流程通常为：
【1】需求调研；
【2】迁移方案详细设计；
【3】技术验证；
【4】实施及切割；
【5】迁移结果验证及验收。
每个公有云厂商会沉淀出自己的迁移方法论，微软的方法论云采用框架（CAF）看着的是理论联系实际，同时结合优化结构框架（WAF），侧重上云细节设计以及实际操作。详情可以参考参考我们之前发布的内容：云基础架构采用者避坑指南：拥抱“云” ，更懂“云” 。本篇我们会重点介绍项目实施过程的前三步。
需求调研：明确迁移目标迁移项目始于客户的迁移动机，根据客户的迁移动机来指定迁移目标，这个目标是衡量迁移项目是否成功的基准。所以风险分析第一步就是明确客户迁移目标，结合客户的现有 IT 环境来综合评估客户的目标是否可以完成。
也许在客户 IT 环境调研时发现各种复杂的技术问题，企业级客户系统繁多，并且复杂，来自不同时期上线的，使用了异构的技术架构。这些需要进行评估能否靠一些技术方案解决。如果是绕不过去的硬伤，要及时跟客户提出来与客户讨论解决方法。
客户调研阶段，我们需要对客户的IT信息尽量做细致的了解，以提早发现可能导致迁移失败的风险点。针对客户每个系统，提出相关问题及拓扑图逻辑图信息。
迁移方案设计：风险最小化了解了客户 IT 信息后，开始考虑迁移方案。通常迁移方法有很多种，比如下图中看到的Rehost,Refactor,Rearchitect,Rebuild,Replace（重新托管，重构，重新架构，重建，替换）等。这些方法从左到右，迁移后对系统的革新程度（现代化或数字化转型）越来越显著，也越来越多利用到云的特性，但需要实施周期通常也会更长，且可能带来更大的实施风险。所以对于大型云迁移项目中，考虑最小的风险，最适合的方式是 Rehost（即Lift & Shift）：通过镜像迁移的方式将系统迁移上云，从云上的基础架构上看基本与客户本地数据中心保持一致。这种迁移最简单，花费的时间通常也是最短。如某些系统无法通过 Rehost 方式迁移的话，可以考虑 Refactor 等方式。
文章插图
所以，总体来说，建议优先考虑 Rehost 。迁移实施结束后，客户可以基于云的使用阶段继续按照下图所示架构，在云上进行优化。
文章插图
确定了迁移方法，开始考虑使用的迁移工具，从下图列出了一些相关工具种类，目前针对不同的迁移方法会有多种迁移工具来选择，公有云第一方或第三方工具，功能上各有特色。选择的原则是：使用适合自己的工具，无论第一方或第三方。
文章插图
技术验证：修正迁移方案确定了迁移方案后，需要对迁移系统做一个迁移的技术验证（PoC），建议使用客户 IDC 的真实环境（或客户测试环境），基于有代表性同时对业务影响小的系统环境做迁移测试，通常 Rehost 方式也可以基于技术类验证，并非整个系统。在验证中可以暴露出方案中没有考虑到或着隐性的一些坑，通过验证结果能及时修改迁移方案。