提问

#楼主# 2020-3-23

跳转到指定楼层
本帖最后由 sinnet-cloud 于 2020-3-27 18:28 编辑

2月19日,光环云社群举办了在线直播《业务迁移上云要点解读:从准备到实施》,本次直播是“云与数字化转型系列直播”的第二期,依然由光环云的陈昕老师为大家分享。

12.png

在这次直播中,陈昕老师从企业上云的各个阶段、AWS入云框架、业务迁移上云的实施路径、迁移准备和实施等几个方面做了详细的阐释。直播视频可点击以下链接观看。(时间较长,建议在WiFi下观看)



不方便观看视频的朋友,可以快速阅览我们整理的本期直播的图文精华:

https://www.bilibili.com/video/BV1y7411A76U/


01
准备上云战略

当企业决定上云后,其上云历程一般会分为以下几个阶段:

1.png
(图片来源:medium)

项目
在项目阶段,您会运行各种项目来熟悉云并体验云的优势。

基础
体验过云的优势之后,就要开始构建基础,以便扩大云采用的规模。这项工作包括创建着陆区(一个预置的、安全的多账户 AWS 环境)、卓越云中心 (CCoE) 和运营模型,还要做好安全性和合规性工作。

迁移
在这一阶段,随着采用范围在 IT 产品组合中不断扩大,您会将包括任务关键型应用程序在内的现有应用程序或整个数据中心迁移到云。

重构
迁移到云之后,您可以利用 AWS 的灵活性和各项功能重点进行重构工作,通过缩短产品进入市场的时间和提高创新意识来实现业务转型。


AWS入云框架

针对企业上云的准备和实施,AWS发布了经典的入云框架:

2.png

该框架是AWS根据众多企业的上云经历总结出的指导性框架。从业务、人员、治理、平台、安全、运营六个视角,分析了企业上云过程中应该关注的重点内容。AWS入云框架不仅仅适用于亚马逊云,在上任何公有云的时候都可以用这个框架。

组织结构和思维转变
用云不仅仅是IT部门的事情,其他部门也会因为上云的战略受到影响。要让组织架构和企业思维适应上云的整体战略。

关注目标
在完成上云的思维转变后,六个视角在上云过程中关注的目标也不一样。比如,业务视角关注业务和IT需求之间的对齐;治理角度关注合规性、云计算投资、业务成果等;运营角度关注系统健康及可靠性、积累最佳实践等等。

行动计划
框架完成之后就需要制定上云的行动计划了。根据组织架构、业务种类的不同,每个公司的上云行动计划都不一样。

02
上云迁移

企业上云常见的业务驱动力包括几个方面:

运营成本:云计算具有的一些特性能够帮企业降低运营成本。包括明确的基础设施单位计价、灵活计费模式适应不同业务、支持弹性成本,以及成本透明推动了精益思维。

员工生产力:上云能够提升员工生产力,自动化驱动的高效运维、减少了计划/非计划停机的成本,也提升了开发效率。

成本规避:使用云服务后,企业在IT方面能够消除硬件更新成本,消除设备维护成本。

运维弹性:云计算的弹性运维特点能够减少风险发生点/减低风险控制所需投入成本;通过减少系统停机故障从而提高收入与利润。

业务敏捷性:使用云计算能够缩短创新及上市时间;增加运营敏捷性(快速拓展市场,新增合并或终止业务)。


云迁移实施路径

企业上云的迁移实施路径包含几种情况:

1. 整体全部迁移:
整体迁移首先要确保你的业务系统能够完全在云上运行。采用的迁移策略可以选择热迁移或冷迁移。其中,数据迁移比较有挑战(数据库、文件等),计算迁移相对容易(镜像导入/导出)。

2. 业务混合架构
采用混合云架构的企业可能会使用以下迁移路径:
实现内网与云平台打通(如AWS VPC、DX服务);
实现数据共享和交互(如AWS Storage Gateway等);
优先迁移计算资源上云。

3. 灾备系统上云
有些公司会首先选择灾备系统上云,这比自建机房进行灾备成本要小很多。根据灾备业务的不同,灾备系统上云的复杂度也不同。常见路径为:
实现内网与云平台打通(如AWS VPC、DX服务);
按用户灾备业务要求确定合适灾备模式并实施;
发挥云上灾备的成本和灵活性优势(如停机不收费)。

4. 开发测试上云
在开发阶段就把项目部署在云上环境。在云上部署业务开发测试环境,实现和企业内部研发流程对接(代码管理,构建管理等),发挥云上开发测试的灵活性(如全栈自动化)。

常见的企业级应用场景包含:从应用系统本身出发设计上云路径;和从企业整体环境出发设计上云路径两种。

3.png

企业应用迁移上云通常会遇到的阻力,包含三个维度:技术层面、安全层面、人员和流程层面。


云迁移策略汇总

我们把迁移上云的策略汇总归类为六种情况:

1. 应用保留(Retain)
客户将在原有环境保留主机/应用程序
不需要牵涉复杂分析/验证
依赖于集成服务管理

2. 应用淘汰(Retire)
源上的应用程序和主机停用
无需迁移到其它环境包括云平台
需要得到应用所有者的批准


3. 重新托管(Rehost)
从本地数据中心平行迁移到云环境
无需牵涉架构变更
仍然需要对数据迁移作考量

4. 平台重构(Replatform)
针对云上操作系统和数据库作版本升级
应用程序需要在云上重新安装
数据转换;数据库转换到MySQL,Amazon Aurora或其他

5. 应用重构(Refactor/Re-architect)
操作系统和数据库移植
更改中间件和应用程序为云服务产品
牵涉对现有应用程序的代码作更改

6. 重新购买(Repurchase)
应用重新购置
采用SaaS模式

03
测试和验证


上云迁移流程分为:需求分析、规划设计、迁移实施、迁移验收几个阶段。

4.png

迁移准备和计划

在做上云迁移的准备和计划的时候,最好是以项目的方式进行。业务相关和技术相关的人员坐下来好好讨论一下,要投入多少资源,有多少收益,具体怎么做。针对云迁移,每个部门关注的KPI的点不一样。

5.png

迁移成本方面,包括购买云平台服务的成本、第三方成本(如迁移工具、供应商服务成本、软件许可等)、人力成本、企业变革成本等,都需要考虑进去。

在迁移的准备阶段,我们需要首先确定迁移目标和各个项目的优先级,对现有业务和数据进行梳理,做安全和风险评估、Poc测试。因为上云迁移可能不是一朝一夕的事情,需要很严谨规范的项目管理以把控迁移进度。

需要准备的材料包括:迁移项目说明书,迁移操作手册,资产清单,现有架构拓扑图,参与人员清单等等。

PoC测试(可行性测试)

为了了解上云是否可行,需要进行PoC测试。一般包含这几个步骤:设定目标、设计架构、实施测试。

6.png

04
迁移实施

进入迁移实施阶段,首先要准备好迁移环境。迁移实施分三个部分:应用环境迁移、数据迁移、云上环境集成。完成之后进行系统启动。此外,如果在迁移过程中遇到问题,要有回退检测的机制。

AWS提供了很多的迁移工具,如下图所示。不同的迁移工具都提供了相应的解决方案。

7.png

(图片来源:AWS官网)

对于很多大型的项目来说,整个迁移周期可能会比较长,这就需要做好迁移的过程管理。

包括要形成项目日报&周报、各子项目进度同步、目标变更、持续数据同步,等等。

迁移完成之后,要先做一些测试。进行功能验证、数据完整性验证、各业务连通性验证,在最后的业务割接阶段,还要做数据增量同步、蓝绿测试、DNS切换等工作。


云迁移的风险和挑战

云迁移也面临一些风险和挑战,需要提前做出应对预案。常见的风险和解决办法见下图:

8.png

对于云迁移失败的情况,分为迁移中失败和迁移完成后发现故障两种情况。

迁移过程中失败
影响:
迁移过程失败不影响原有业务服务,原有业务可以继续正常运行。
处理预案:
对各点预备1-2台备机,并提前部署好环境,如出现单点故障后可以快速切换;
检查迁移失败原因,重新执行迁移过程;
若无法迁移,检查原生产环境并重新对外;
总结迁移问题,梳理迁移流程,准备第二次迁移。

迁移完成后故障
影响:
迁移完成后故障,需根据实际情况判断。
处理预案:
原有业务在迁移完成后的7天,锁定原有业务环境,并做好随时重启准备;
检查问题原因,判断问题原因,预估恢复时间;
用户告知;
若严重问题,短期无法修复的且严重影响用户使用的,酌情考虑是否回退;
回退到原有生产环境到原程序和原数据库上服务。


最终验收交付

迁移完成后,经过测试确认各个系统和功能在生产环境下运行正常,就可以进行验收交付了。需要交付的内容通常包括:验收测试报告、测试用例、基础检查表等,交付双方需要对检查表签字留档,有时还需要交付长期维护手册和对运维人员进行培训。

下图是AWS认证的一些培训路径,供大家参考。企业上云之后,做一些持续的培训和人力储备也是很重要的。

9.png
(路径图片来源:AWS官网)

完成上云迁移之后,企业就可以花更多的时间关注在业务发展方面,根据业务需求持续的优化系统和应用。

总结

上云是一个持久的过程,不是一朝一夕就可完成;
除了IT架构的变换,运维和研发的思维模式也要跟着转变;
迁移很难,但值得。

参考资料:
AWS Landing Zone (着陆区)介绍:https://aws.amazon.com/cn/solutions/aws-landing-zone/?nc1=h_ls

二维码进群.png

转播转播
回复

使用道具

联系楼主
*
*
客户公司所在区域:
*
产品:
*
简述客户的业务场景和需求
*
*
*

成为第一个回答人

B Color Link Quote Code Smilies
光环云社区 |京ICP备18044167号-13|

京公网安备 11010102003758号