云的时代：

云时代已经到来，在选择云之后，企业首要的问题是选择什么样的方式迁移上云？这会影响企业的迁移周期和迁移后的业务服务品质，所以迁移时一定要按照一定的方法论和流程，而不是盲目的迁移。最基本的也要遵守这五个过程：计划，设计，迁移，运营及优化，在这套方法论里面您可以按您们的实际业务情况进行微调。所有云厂商里面，AWS拥有最完善的迁移方法论。例如：CAF（采用云框架），LandingZone，Well-architected（良好的架构）和三天迁移培训课程，这些能使您意识到使用云会是一种什么样的模式，解决您在使用过程中的疑问。个人认为一个AWS初级用户学习CAF的方法论更为关键，这样可以让您对云有更深次的使用体验。

借鉴我们过往的经验，我们建议客户在AWS上有小量的应用后，再来研读Well-architected，Well-architected中的专业术语较多，建议可以进行初步的了解后，进行简单的应用实践，后期在实践过程中不断的巩固知识点，以掌握该部分的精髓。当然也有缩短学习时间的方法，那就是选择有经验的AWS Partner做一次详细的讲解以及陪您们一起上云实践，他们会根据您企业的业务运行状况告诉您们什么是最佳实践。

实践分享：

根据我们经历过大量迁移的实践总结，让我们一起分享在迁移过程中，最为关键的两个阶段，分别是计划和设计。它们是整个迁移中最为基础的部分，就像一栋大楼的地基，如何详细地做好这两个阶段的工作，我们一起来探讨，希望能对您及您的企业有帮助。

1) 计划：

建议在做计划前，先做一个迁移优先级列表，里面必须包含几个核心的字段，例如：操作系统版本/实际数据量/应用提供商/业务依赖服务/技术复杂度/RTO/RPO等，这些是决定您选择什么样的迁移模式（平滑/替换/重构），什么样的迁移工具，因为它们会影响您迁移周期长短和效果（当然也有一些企业也有一些特别的指标，例如：兼容性（迁到其他云的可能性））。请把这个表填完整后，再做整体的迁移计划，而不是在没有任何依据的情况下做计划。

按以上指标来看，也许你们会感觉操作系统版本并不重要，实际上非常重要，首先要清楚AWS支不支持这种AMI，如果AWS不提供，Marketplace和社区有没有？（如果您对安全很注重，建议不要使用社区的AMI）您也可以选择自己制作AMI（选择Vmware方法制作），而我们的建议是采用AWS提供的AMI，这样不管理是性能，稳定性，功能和故障排查都会较为可靠。举一个我们实践过的通讯行业的案例：客户在上AWS前，有对AMI进行简单的功能测试，并没有针对他们在On-premises修改内核的CentOS的AMI进行性能测试。在实际迁移后进行性能测试时就发现各种故障，此时AWS的售后技术也无法解决。根据我们的经验建议您尽量采用AWS提供的AMI，如果对AMI确实有非常严格的要求，那么请做好所有必要的测试。应用提供商，这是对应用能不能迁移起到决定性的作用，例如：License，版本以及软件提供商是否还存在？业务依赖服务，这个指标描述的是业务之间的数据交互，业务之间的紧耦合关系，它们之间有多少服务数据存在交互或者它们仅是其他业务的数据提供商，请注意“实际上有时其他业务只是依赖这个业务的数据库的数据，并不依赖于业务本身“，所以业务存不存在并无关系。RTO/RPO，这个指标会决定迁移成本，要保持业务不中断，迁移成本就越贵。根据我们实践过的经验，RTO/RPO更合适在容灾和备份场景，在迁移场景我们更认为业务可中断的时间更为关键，因为这是用来做数据同步和业务切换的时间，最重要的是：“请别认为自己的业务永远不可中断”（这样造成迁移成本浪费，甚至不可迁移）。决定迁移时间的长短还有三个相关的因素分别是：数据同步技术、网络带宽与数据量大小。

把以上指标，还有客户自己要求的指标，做相关评估与验证（下一个阶段的“设计”是此阶段“计划”最重要的验证测试）才能决定业务迁移的优先级、业务迁移的模式、业务迁移的工具、业务迁移的时间。

2) 设计：

拥有以上已完善的迁移优先级列表后，此阶段将进行架构设计与验证测试，以至确保迁移模式，迁移工具与迁移优先选择正确，这也说明设计与计划是承上启下的作用，并不是各自独立。通过计划阶段的业务分析与评估，您已经可以进行相应的架构设计，同时进行相关验证测试（在云的时代，这个非常重要），以便调整迁移的优先级与迁移模式。在这此阶段验证的业务越多，迁移阶段的风险就越小，时间就越短。例如我们的一个高新制造行业客户，他们在上AWS前跟我们一起对现有在某云厂商的业务架构进行详细地评估与分析后，在采用替换迁移的模式下得出他们最关键的验证测试是以EC2为基础的K8S和网络VPC，所以对这两样进行充分测试，例如： K8S的License有效期，K8S的Autoscaling，K8S分成不同业务组以及K8S的网络测试，还有做一些关键业务迁移测试。由于设计阶段充分测试使得正式迁移时节省两周时间。如果有可能的话，建议采用与生产环境1:1的验证测试环境，在验证完成后，可以把资源Stop，这时只收取部分资源的费用例如：EBS、EIP、S3等。对于那些必须删除的资源，可选择先做备份为正式迁移做准备，还有可以使用Cloudformation做好模板，这样可以减少正式迁移的准备工作。

实践总结：

很多企业都喜欢通过少量验证或不验证，就开始执行迁移，在执行过程中遇到各种各样的问题，有些问题以致他们无法继续，必须从头开始。从我们过往的经验来讲，建议最好先把简单的业务迁移上云，最好都是平滑迁移，最好在前两个阶段做好充分验证测试准备。对一些确实无法中断的业务（实际上DNS域名切换还是需要中断几分钟的）设计好数据同步的方式（主要还是数据库数据的同步，可以利用AWS DMS或专门针对数据库实时同步的第三方软件），这里的数据同步会存在一定延迟，要考虑业务可承受的时延范围。一定记住和理解每个阶段之间是存在严格的关联关系。

迁移，运营，优化这三个阶段也非常关键，而在迁移的前两个阶段做好了充分准备，到迁移阶段会相对轻松，只需注意风险评估和人员工作分配，运营和优化属于高级阶段，对迁移后的业务在稳定性，性能，安全，可用性和成本等方面进行逐步优化。（此文章若有错误，请指正，谢谢！）

参考学习地址：

【关于博思云为】

作为一家专业的云计算服务型企业，博思云为专为客户提供 AWS 上的运营服务：包括架构咨询服务、迁移服务、云安全集成服务、混合云管理服务、大数据服务以及 DevOps 服务。目前，博思云为在大数据、DevOps、架构、数据库以及操作系统等都已取得厂商认证，在上海、南京、杭州、武汉等地设有分公司。为创新服务模式、引领 IT 服务业的发展，博思云为将持续投入资源开展智能混合云管理平台、图数据库的研发等。