系统迁云规范流程

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,高可用系列 2核4GB
简介: 系统迁云规范流程

系统迁云规范流程
下面从流程角度简要阐述迁移上云的过程,整个过程分为系统调研、上云风险评估、方案设计与评审、系统改造、功能/性能测试、系统割接和回滚、系统交付与护航等几个方面组成,下面先看流程图的几个关键节点:
image.png

项目立项:由项目经理召集相关方,发起迁移上云项目;
系统调研:项目根据整个迁移计划,调研应用的系统架构图,数据库信息,系统整体压力情况,系统底层部署情况,商业软件依赖等等方面内容。特别调研系统有否使用特殊的传统行业专有的设备或者软件或者开发模式等内容,通过调研我们可以初步评估出系统是否可以上云,上云的改造难度大小,云平台是否可以完全匹配需求。
方案设计&系统改造:根据前期的调研及结合云平台特性,应用系统产出新的系统架构图和迁移的改造计划,比如是直接上云还是改造后上云,是否去O,是否使用分布式DRDS等。
功能&&性能测试:云平台和传统环境是有差异的,在系统上线前,务必在云平台上进行充分的功能验证和性能测试。
系统割接上线:通常说的系统割接就是把系统流量切换到云平台。但在迁移实施流程中,系统割接不仅是将系统流量切换到云平台,还包括流量切换前的准备工作如云产品资源准备、数据库迁移、应用程序迁移等工作。
系统交付:流量成功切换到云平台后,系统正式进入运行和后期运维阶段,交付后有任何技术问题,请随时提交工单,阿里云有专业的售后团队支持。

前期准备
收集应用系统信息汇总
收集一份系统信息汇总表,清楚知道多少个系统要迁移、系统平台情况、负责人、迁移完成时间、心里预期等,形成应用系统迁移清单,参见下表:
image.png

系统调研
调研可以让团队充分理解当前系统业务现状、系统未来规划,现有架构和云平台是否匹配等等,为后续的系统迁移方案制定和实施提供第一手资料。
迁移上云的系统调研阶段,此阶段主要是通过调研表、访谈、系统数据收集、应用系统观摩等标准化的流程及方法调研应用系统,使迁移上云团队充分的理解系统业务及应用现状,为后续的应用系统迁移方案制定、实施以及验证交付提供数据支撑。
系统调研阶段主要工作内容包含:业务调研、系统架构调研、数据库调研、应用程序调研。
业务调研:基于待迁移应用系统的业务层面开展基础性调研分析工作,主要包含对业务类型、使用人员、业务使用特征、业务性能指标等方面进行调研分析。
包括主要以下内容:
a) 系统名称
b) 所属单位
c) 系统业务说明及服务对象
d) 系统开发/运行情况(已上线,开发中,设计中,规划中)
e) 系统类型(网站,OA系统,ERP,CRM等)
系统架构调研:通过对整个应用系统部署、系统运行体系、系统运行现状、系统可扩展性、系统数据流、系统关联性等方面进行全面地调研分析。
主要内容包括:
1) 外设和商业软件需求调研
2) 网络需求调研
3) 改造规划调研
4) 系统各模块依赖调研,是独立系统还是有依赖其他系统。
5) 安全要求调研
6) 资源的使用情况(服务器,存储设备,网络带宽)
7) 系统是OLAP还是OLTP类型
数据库调研:需要通过收集数据库版本、部署结构、数据安全策略等基础信息,现有数据库容量、流量、SQL、高级特性等方面使用情况,进行数据库层面的技术调研和分析。
主要内容包括:
1) 数据库厂商/版本
2) 数据库架构(是否RAC,主备)
3) 备份策略(冷备、热备、备份周期)
4) 数据容量、流量统计(高峰TPS/QPS,数据库大写,超过 1000w记录的表数量及名称,峰值连接数)
5) SQL收集(一天内数据库访问top 50 SQL以及慢SQL)
6) 数据库高级特性收集(Oracle/SQL SERVER):存储过程,函数,触发器,包,物化视图,虚拟列,分区,DBLINK,SEQUENCE,全文索引,DTS等。
7) 数据库字符集

应用程序调研:搜集应用程序架构、中间件使用情况、应用负载等方面,进行应用程序层面的技术调研和分析.
主要内容包括:
a) 操作系统架构
b) 是否有高可用性设计
c) 是否有高性能设计
d) 数据存储方式
e) 系统类型
f) 应用程序使用哪种语言开发
g) 若采用php开发,采用的框架是
h) 若采用Java开发,采用的框架有哪些
i) 系统采用的架构是BS 还是CS
j) 系统部署是否使用了
k) 哪些第三方组件
l) 是否调用外部接口或服务
m) 若调用外部服务,采用的接口协议类型是什么
n) 若提供服务供外部调用,接口协议类型是
o) 若有文档存储,文件存储方案是什么
p) 文档存储中包含哪些文件类型
q) 日志文件存储方式
r) 系统是否同时使用多个数据源
s) 与数据库调用方式
t) 中间件类
u) 使用哪种中间件产品
v) 中间件是单节点部署还是采用集群方式部署
w) 系统部署使用的第三方组件类型是什么
x) 是否使用定制插件
y) 若使用定制插件,请提供开发语言和运行环境
z) 系统性能指标是什么

风险评估
基于系统调研阶段输出的调研报告,并结合云平台的架构特点,迁移上云团队对系统上云的风险进行评估,包括系统迁移上云的可行性(和云平台的兼容性),能否迁移到云端,是否需要做系统改造或是代码重构,改造难度的大小预估,迁移到云端需要云上什么的架构来支撑,通过一系列的调研,我们基本可以推算出项目迁移的改造工期和技术难点,比如平迁的系统,MySQL迁移到RDS,SQLSERVER迁移到RDS,文件系统迁移到OSS,通常风险很小,而需要去O改造的系统通常迁移风险比较大。
迁移上云团队对系统迁移过程中出现的风险点进行评估,对云平台暂时还不支持的功能进行分析,以便在方案设计阶段针对性出解决办法。风险评估主要包含如下图所示几个方面。
image.png

云平台兼容性评估:应用系统实际情况摸底,对云平台还不支持的软硬件进行摸底,以便制定相应的解决方案。
a)云数据库不支持oracle
b)云上对特定的硬件(加密狗,专线,高性能显卡,特定ip地址依赖等)不支持。
c)云上网络架构是否满足
d)云上安全是否满足系统安全等级
性能风险评估:结合甲方应用系统性能调研结果,对现有系统性能瓶颈点进行评估,以便制定应用系统系统优化方案,比如是否需要使用分库分表,是否需要海量数据处理技术等。
a)数据库资源是否满足并发访问以及空间存储限制
b)应用服务器是否满足系统性能需求
c)云上分布式存储接口是否满足并发要求
系统改造风险评估:根据现有应用系统业务特点、技术特征,以及云平台特性,评估系统在改造过程风险.
a)应用程序改造是否满足原系统设计指标
b)数据迁移方案是否满足系统割接要求
c)去O改造难度
d)改造后的模块是否能兼容其他系统的调用依赖。
资源风险评估:对迁移上云实施计划、云平台资源准备、迁移上云迁移实施团队人力资源等风险点进行评估。
云上架构设计
基于系统调研和风险评估结果,并结合云平台特点,确定应用系统云上的新架构和迁移方案,是直接平迁移到云平台上,是否需要一系列的改造(比如去O),文件系统是否需要迁移到OSS上,数据分析系统是否兼容云平台等等,改造周期预估等等,最终形成上云的架构设计和改造方案。
相比传统的APP+DB部署模式,云上更适合使用SLB+ECS+RDS来做到高可用(见下图)。
image.png

系统部署方案设计:基于应用系统特征,如可用性、稳定性、性能的要求,输出基于云平台的应用程序和数据库部署方案。
系统改造方案:基于系统调研、风险评估结果和云平台特性,设计数据库改造方案、应用程序改造方案、应用系统验证方案。
系统改造
本阶段基于系统改造方案,对现有应用系统进行改造,及测试验证。如下图所示主要包含:系统架构改造、数据库改造、应用程序改造和系统测试验证。
image.png

数据迁移验证
 本地数据库迁移到云上。
 文件系统、视频等迁移到OSS上。
 利用数据比对工具验证源数据库与目标数据库的数据一致性。
DTS已经支持Oracle、MySQL、SQL Server、DRDS(阿里云分布式数据库)、PPAS(PostgreSQL Advance Server)间的数据迁移功能。除了提供数据迁移功能,AMP也能够帮助用户进行结构对象的迁移,同时,DTS也提供了迁移数据一致性校验功能,可以校验迁移数据的正确性。用户只要在DTS的管理控制台上,配置待迁移数据库的连接信息及需要迁移的对象并启动任务后,即可轻松将源数据库数据迁移到目标数据库。任务启动后,用户可以在DTS控制台随时查看任务迁移状态及进度,并可以根据需要停止或删除迁移任务。
image.png

DTS提供了丰富灵活的迁移个性化配置,可以支持用户的多种数据迁移需求。具体功能如下:
(1) 支持多种迁移粒度,用户可以选择迁移实例、库、表或列
(2) 支持迁移对象重命名,即可以支持源库、目标库的库、表、列名不一致。但是用户一次只能重命名库名、表名、列名中的一个,例如只修改库名。
(3) 全量迁移支持只迁移一个表中的部分数据到目标库,可以通过配置一个表中某个列的where条件,只迁移满足where条件的部分数据到目标库。

功能/性能测试
由业务方根据系统设计中的测试用例来完成功能、性能及数据完整性校验等工作。匹配审核包含人工审核及工具审核两个部分;
迁移完成后,在开启功能测试前需要应用负责人进行系统架构及部署方面的人工审核,如审核无误可进入工具审核阶段;
人工审核后,由迁移脚本通过包含路径,文件列表,代码的对比进行对比审核,审核通过后开启功能测试;

系统割接
本阶段主要是完成新老应用系统的割接,并确保迁移上云后的应用系统可以稳定、高效的在运行在云平台上,具体的包括云上资源申请和开通、数据库迁移、应用程序迁移和业务割接。
image.png

系统环境准备:根据系统需求,完成应用系统所需云产品的资源申请和环境准备,及数据迁移工具准备。
应用程序部署:按照应用程序部署方案,通过功能和性能测试之后,部署到云平台上。
文件/数据库同步:将改造后的数据库设计,以及现有应用系统的存量数据、增量数据迁移到云平台,并且校验新老平台数据,确保云平台上数据的正确性。
业务割接:明确业务割接时间点后,按照业务割接方案完成应用系统到云平台的割接验证工作,完成流量切换。
回滚机制:每个系统都要回滚方案,包括应用程序的回滚,数据库的回滚。
系统交付
本阶段是指在应用系统完成系统割接,流量成功切换到云平台后,系统正式进入运行和后期运维阶段。
交付后有任何技术问题,请随时提交工单,阿里云有专业的售后团队支持。

相关实践学习
如何在云端创建MySQL数据库
开始实验后,系统会自动创建一台自建MySQL的 源数据库 ECS 实例和一台 目标数据库 RDS。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
对象存储 容器 云计算
标准流程描述语言 WDL 阿里云最佳实践
WDL 作为全球基因组与健康联盟 (Global Alliance for Genomics and Health)支持的工作流描述语言,已经被越来越多的客户所采用。通过阿里云的 Cromwell 方案,用户可以本地开发测试WDL流程,再使用云计算强大的计算能力,来完成基因组学数据分析工作。
10558 3
|
26天前
|
敏捷开发 数据可视化 数据挖掘
从需求到交付:五种管理方法让研发流程更高效
产品研发团队面临需求多变、任务紧迫等挑战,需要高效的管理方法来提升协作和执行力。本文推荐五种方法:看板管理、MVP最小可行产品、用户故事地图、双钻模型及Scrum框架,帮助团队实现“巧干”。
49 1
从需求到交付:五种管理方法让研发流程更高效
|
4月前
|
测试技术 持续交付 UED
|
7月前
|
运维 监控 Cloud Native
设计与构建 FinOps 流程、团队、体系与目标
企业 FinOps 实施不是一蹴而就的项目,如果您正在推进企业云原生 FinOps 落地,除了选择合适的技术手段,企业内部的流程和体系建设也尤为重要。
163732 21
CMMI流程规范—服务与维护
CMMI流程规范—服务与维护
402 0
|
敏捷开发 人工智能 数据可视化
敏捷需求管理流程规范-免费敏捷工具
Leangoo领歌是一款专业的敏捷开发管理工具,它覆盖了敏捷项目研发全流程,包括小型团队敏捷开发,规模化敏捷SAFe,Scrum of Scrums大规模敏捷。提供端到端敏捷研发管理解决方案,涵盖敏捷需求管理、任务协同、进展跟踪、统计度量等。
|
运维 监控 安全
《云上业务稳定性保障实践白皮书》——四. 变更管控体系——4.1 变更标准流程规范
《云上业务稳定性保障实践白皮书》——四. 变更管控体系——4.1 变更标准流程规范
559 0
|
容灾 数据中心
《云上容灾交付服务白皮书》——3交付标准化参考框架——3.1 需求分析
《云上容灾交付服务白皮书》——3交付标准化参考框架——3.1 需求分析
133 0
|
运维 JavaScript 安全
产品相关 细说软件产品和业务 & 业务过程(流程) & 业务逻辑
产品相关 细说软件产品和业务 & 业务过程(流程) & 业务逻辑
152 0
|
存储 SQL 供应链
软件需求人员-如何提升需求分析和业务方案的能力
  今天我准备再写一篇软件需求人员能力提升方面的文章,也就是把这个问题进一步谈透。对于IT行业来说,前面谈到更多的是招聘软件开发或架构设计人员不容易,特别是架构人员也难以培养。而对于软件需求人员也是同样的道理。   软件需求不同于用户需求或原始需求,对于业务需求往往你无需任何的IT技术背景就能够提出你的需求和问题,而对于软件需求则涉及到业务需求分析,分解,形成完整的业务解决方案,复杂的还是涉及到业务建模,最终才形成软件需求。   因此软件需求人员实际是衔接业务用户和内部技术团队的关键桥梁,软件需求和业务建模做得好,技术实现本身也更加高效。同样,一个软件系统最终实现出来灵活,可复用,那么首先
635 0