云迁移已成为现代企业数字化转型的关键方面。数据传输过程往往是复杂且耗时的，给迁移项目带来挑战。自动化数据传输过程是简化云迁移并提高效率的最佳方式之一。
云迁移中的数据传输
数据传输是云迁移过程中的关键步骤，涉及将本地数据移动到云环境中。此过程可能涉及大量数据，因此需要仔细计划和执行以确保数据的完整性、安全性和可用性。
手动数据传输既耗时又容易出错，尤其是在处理大量数据时。自动化数据传输过程可以解决这些问题，使迁移项目更有效率、更可靠。
自动化数据传输过程的优点
- 减少时间和成本：自动化数据传输工具可以大大减少数据传输所需的时间和成本。
- 提高精度：自动化流程消除了人为错误的可能性，从而提高了数据传输的准确性。
- 提高效率：自动化数据传输工具可以同时处理多个任务，从而提高整体效率。
- 加强安全性：自动化工具可以采用安全协议和加密技术，确保数据的安全传输。
- 简化的项目管理：自动化数据传输过程使项目管理变得更加容易，因为可以轻松跟踪和监控迁移进度。
自动化数据传输过程的步骤
自动化数据传输过程通常涉及以下步骤：
- 规划：确定要迁移的数据、目标云环境和所需的工具。
- 选择工具：选择符合迁移需求的自动化数据传输工具。
- 配置工具：配置工具以连接到源数据和目标云环境。
- 执行传输：启动数据传输过程并监控进度。
CODING X C-Life：DevOps 加速企业数智化
数字化开始从抽象化、标准化走向智能化
2020 给全民普及了什么是线上化、数字化、智能化，也加速了企业的数字化转型。
“全数字化”时代，已经不仅仅是简单粗放的数据采集、映射、抽象。
数字化开始迈入高级阶段——数据驱动的智能化 ：基于云管端 + AIoT 等为代表的新技术群落开始大量涌现，数智化企业思考的核心问题转向了如何以客户运营为核心，通过智能化手段提高客户全生命周期的体验。
作为物联网大数据行业的排头兵， 深圳数联天下智能 科技 有限公司 （以下简称数联天下）倾力打造的 C-Life 大数据综合计算服务平台，致力于为个人、行业、政府提供全周期、全链条、全维度、全方位的专业级运营顾问式服务。
依托着公司强大的研发投入与技术实力，数联天下在智慧养老、智慧 健康 校园、智慧美业、智慧家庭、智慧酒店、智慧农业、智慧水生态等多个智慧领域，打造了一批又一批的标杆示范项目。
企业的敏捷性、适应性、反脆弱性，决定其在这场数字化颠覆中的胜与负
在交付各个领域的智慧项目过程当中，数联天下的研发部门逐渐发现问题：研发团队面对的是一个更加不确定、个性化、碎片化的市场需求。
行业项目虽然存在着一定的通用性，但也因地制宜的存在大量定制化需求。
如何让个性化与规模化齐头并进？多变的客户需求带动了研发组织开展与业务相适应的调整。
通过研发流程数字化提升研发流程的敏捷性、适应性、反脆弱性，数联天下开启了研发提效之路 。
数联天下研发团队和我们分享道：“客户项目周期紧张，需求变化比较频繁，开发团队需要在短时间内完成软件开发并发布上线。
而在之前的研发流程当中：发布流程长，审批环节多，发布节奏缓慢，开发运维之间没有良好协作来提升发布效率。
所以亟需打破跨部门之间的壁垒，减少开发、测试、运维之间的沟通环节、沟通成本。
DevOps 是我们在较短开发周期内开发高质量软件的首选方法，希望通过使用 DevOps 平台 —— CODING 来提升客户满意度。
”
区别于之前通过多个工具自建研发流程，数联天下团队首先基于 CODING 的持续集成、制品库、持续部署逐步提升交付带宽，再将项目管理、研发数据管理等流程统一至 CODING ，渐进式实现研发流程从需求提出到应用部署的价值交付，从而让研发团队各个角色基于统一平台通力协作，按期保质交付项目。
持续交付驱动业务加速
在使用 CODING 的过程中，数联天下研发团队遵循着循序渐进的路线。
首先基于 CODING 持续集成、制品库、持续部署建立持续交付流水线。
区别于自建 Jenkins 与 Nexus， CODING 的持续集成与制品库开箱即用 ，研发团队通过持续集成构建好的 Docker 镜像可以直接推送到 CODING 制品库中，再通过持续部署拉取指定版本镜像进行部署。
CODING 持续集成在构建脚本语法上全面兼容 Jenkins，支持数联天下无缝地迁移 Jenkins 的构建到 CODING 中。
并且支持 Docker 镜像的构建，在基础功能上满足了研发团队对构建制品的迁移需求。
在使用上，CODING 比自建 Jenkins 要方便许多，打开浏览器就可以使用，不需要繁琐的机器配置、构建环境搭建、软件插件安装。
而且 CODING 提供了多地域境内外构建节点，并优化国内访问海外主流镜像链路，支持构建任务中开启缓存，大大提升了构建速度。
在构建资源的灵活性上，既支持数联天下使用 CODING 云主机进行构建，也支持数联天下将使用中的腾讯云机器设置为构建资源。
在使用 CODING 制品库之前，数联天下团队基于开源项目自建制品库，在使用自建私服制品库常常遇到性能问题或易用性问题，比如一上传大容量的 Docker 镜像时，自建的制品库就常常服务不可用，导致后续一系列的版本发布受阻，使用 CODING 后这类问题就迎刃而解了。
CODING 制品库是专为生产环境打造的企业级制品库 ，无论是制品库的容量、分发效率都经过产品团队精心优化。
数联天下团队将所有制品推送至 CODING 制品库，利用 CODING 制品库提供的版本策略、权限控制、安全扫描等能力对制品进行了规范管理。
不仅仅是 Docker，CODING 制品库提供了十多种主流制品类型，包括 Helm、通用文件、npm、Maven、PyPI 等等，可以支持研发团队多样化制品托管需求。
同时制品库提供的精细化的权限设置，支持每个制品库设置项目内、团队内、公开的开放范围，针对多团队并行开发的场景，数联天下可以轻松地将通用组件设置为团队内开放，将项目独有的制品设置为项目内可见，既能加速公共制品在企业研发内部的共享与流动，也能确保项目独有制品的权限安全。
对于频繁进行商业交付的研发团队，安全也是商业客户关心问题之一。
CODING 制品库除了解决数联天下团队的制品托管问题，还对制品的安全质量进行了规范。
通过制品扫描设置质量红线标准，杜绝问题组件发布至生产环境，扫描方案还提供了详细扫描记录和缺陷统计，方便研发团队快速修复。
这在一定程度上提高了制品的安全性，减少了应用在生产环境出现的安全漏洞问题。
接下来就是打通持续交付的最后一环——持续部署。
通过持续部署，研发团队可以自动、频繁地将软件部署到各种生产环境，使软件产品能够快速地交付使用。
1. 清晰灵活的流程编排
数联天下运维团队首先根据测试流程、上线流程以及部署环境规划好每个应用的 部署流程 。
针对开发环境、测试环境、类生产环境、生产环境分别创建不同的流程分支。
基于 CODING 持续部署，可以快速地编排出串行或者并行的部署流程：例如针对类生产与生产环境，必须要在类生产的集成测试（自动化+人工）通过之后，才可以进入生产环境发布；而多地域的生产环境发布，就可以并行部署，提高效率。
基于 CODING 持续部署 清晰灵活的流程编排，应用所有的部署分支流程一目了然。
2. 人工审批加上自动通知机制
针对过去运维发布过程中的多环节、多审批、多等待的情况，数联天下团队根据发布流程的级别差异将测试、产品经理等角色加入审批环节，配合自动化部署过程和通知机制，解决了从前需要人工反复确认部署环节的问题；也解决了从前开发人员只能等待运维人员定时部署版本的难题，开发和运维人员都可以随时随地按需部署应用。
每个环节的通知除了支持常见的站内通知、企业微信、钉钉、Bearychat 等方式，还支持团队通过 Webhook 的方式接入企业使用的其它协作工具，满足团队的个性化通知需求。
3. 规范的制品版本规则
在项目紧张的开发周期当中，数联天下的制品构建地十分频繁，制品数量也在急剧增长，其中包含了开发自测的 snapshot 版本和正式转测的版本。
如何确保测试环境、生产环境等能够始终选择主干发布的稳定版本，避免因为手误选到开发自测版本？通过在持续部署中的制品分支策略制定所选制品的规则，杜绝以往人工选择临时分支版本导致的错误情况。
4. 统一的部署控制台
在数联天下团队的日常应用部署管理过程当中，CODING 持续部署提供了以应用为视角的控制台。
运维人员可以对所有应用的配置信息、基础设施、资源分配、部署流程进行全面管理，无需在各个项目视图之中来回切换。
这对于需要面对繁多项目的数联天下研发团队来说， 统一的部署控制台面板，大大提升了应用部署管理效率。
在应用部署完成后，就可以在 Kubernetes 集群面板中方便地检查部署好的资源，包括集群内资源的工作负载情况。
一气呵成的部署操作帮助运维或者开发人员一站式完成部署资源准备、部署流程编排、应用部署、部署后的检查工作。
紧接着研发团队将代码管理、项目管理迁移至 CODING 的代码托管、项目协同中。
告别了过去的 SVN 代码管理，基于 CODING 代码托管进行 Git 式开发，基于代码扫描与 Code Review 建立研发质量的基线。
切换到项目协同进行项目管理后， 真正打通了从需求->代码->制品->应用的全部链路 ，数联天下研发团队基于统一云平台真正实现端到端的价值交付。
和以前基于多个工具自建研发平台的方式对比，统一研发管理平台带来的好处有：
基于 CODING 的 DevOps 实践，数联天下的交付带宽达到了较大提升。
DevOps 实践给数联天下的研发团队带来的不仅仅是流程上、工具上的改变，也进一步加深了团队的业务共识。
所有角色都坐在了一起：测试、运维、开发、产品、项目管理等，研究如何基于统一平台通力协作，按期保质地交付项目，服务好客户。
数据已经成为生产的要素之一
研发数字化不仅仅是自动化流程的搭建，更重要的是在数字化落地过程当中，如何将有机串联的研发环节发挥出 1 + 1 > 2 的效果？如何让研发数据服务于研发？
目前数联天下的研发团队已经将研发全流程切换到 CODING，慢慢积累的研发数据也给研发管理带来了新的指引。
通过效能度量，可以清晰分析成员工作负载；通过仪表盘可以清晰看到代码提交数、事项完成数、构建次数、发布次数等等多个维度的数据展示。
这些数据也将支撑着研发团队快速地调整和检视以适应更加多变的未来。
数联天下研发团队负责人告诉我们：“最开始选择 CODING，因为 CODING 持续集成全面兼容 Jenkins 的持续集成服务，支持 Java、Python、 等所有主流语言，并且支持 Docker 镜像的构建。
这与公司现有的发布方式，架构体系相吻合。
在使用了一段时间后，不仅仅是持续集成，包括 CODING 制品库、持续部署在内的 DevOps 工具给我们的研发流程带来不少提升，也期待 CODING 能够在研发工具链上给我们带来更多惊喜。
”
在全面了解数联天下的 DevOps 实施路径之后，我们也发现企业的研发变革不是一蹴而就的，需要从流程上环环打通， 选择一个迁移成本低、使用门槛低、功能灵活的一站式研发管理工具，能够让变革事半功倍。
我们欣喜地看到，数联天下一直走在提升内部效率的道路上，这家志在提升各行业数智化水平的企业全然拥抱了研发数字化，我们期待 C-Life 凭借着变革初心与极速交付能力，逐步成为智慧生活的强有力支撑平台。
在这场数字化颠覆中，CODING 也会坚定地与研发团队站在一起，依托 DevOps、云原生、敏捷等研发利器，帮助各行各业改进、提升并创新。
云迁移实践：VMware虚拟机迁移到华为云
在云迁移领域，VMware虚拟机迁移到华为云，通常采用HyperMotion作为迁移工具。
HyperMotion具备无缝对接VMware虚拟化层的能力，支持无代理模式迁移，显著减少大规模虚拟机迁移时的安装Agent和系统重启带来的工作量和安全顾虑。
通过调用VMware原生API接口，获取虚拟机数据，利用CBT技术和快照技术实现在线迁移，确保源端VMware虚拟机在迁移过程中持续对外提供服务。
目标端华为云则通过云迁移产品HyperMotion的自动化操作，实现资源调度，简化操作流程。
该迁移架构设计强调点对点数据传输与加密，确保数据安全与高效。
迁移操作流程包括添加源端VMware无代理配置、添加目标华为云配置、批量选择迁移机器和开始同步数据等步骤。
在源端，用户可选择Agentless模式，获取虚拟机数据，通过中间网络传输至目标云存储网关进行存储。
目标端，云存储网关接收迁移数据并存储至云盘，支持自动创建接收数据的代理，进行高效数据同步。
在迁移过程中，提供进度条显示数据拷贝状态和剩余时间，确保迁移操作可见性和可控性。
迁移完成后续步骤包括在华为云启动主机，验证迁移结果，最终实现虚拟机在华为云平台的成功运行。
总结而言，HyperMotion云迁移解决方案提供了一套从源端到目标端的全面迁移流程，包括数据获取、传输、存储和操作自动化，确保了VMware虚拟机迁移至华为云的高效、安全和便捷。
对于有需求的企业或组织，可进一步了解HyperMotion和其他云迁移技术的详细信息，以满足自身上云或容灾需求。
云服务器与云服务器该怎么迁移数据?
在支持京东集团内部及京东云外部客户的业务迁移到京东公有云及京东私有云、京东政务云的过程中，京东科技-京东云事业群-技术服务组积累了相关业务系统数据迁移的一些管理和技术经验，以案例的形式分享给大家，希望对大家的业务迁移工作有所帮助。
业务迁移上云涉及到的业务数据种类繁多，主要类型包括： 数据库： 关系型数据库 MySQL 、PG、Oracle等 对象存储： 标准S3接口对象存储迁移中间件数据：ES、mongoDB、redis等 文件存储：文档、图片等非结构化数据 大数据：HBASE、HDFS files等。
在上云过程中，大部分业务均涉及到以上多种数据类型，基于相关迁移的案例所积累的经验，数据迁移需要在迁移启动前至少做好如下准备工作。
数据迁移技术方案制定完成，包含明确的迁移操作步骤、执行人、确认人。
制定迁移应急预案及回切方案，明确责任矩阵，确认异常情况的决策条件及决策人。
确认数据安全等级，确认数据迁移的方案合规安全，通过相关业务安全部门审核。
迁移时长及割接数据同步窗口的评估，确认各个业务及数据迁移可选的第二方案。
确认网络带宽及质量满足迁移需求。
下面是几个案例，涉及到了不同数据迁移的场景。
关系型数据库迁移：MySQL 数据迁移工具DTS服务在传输及同步、数据校验等步骤实现了一定的抽象化，具有相对友好的交互界面，同时可以实现多个任务并行进行，对要求平滑迁移的场景，具有自动化优势，节省大量人力，但需要满足源端数据库与目标端数据库与DTS管理服务IP网络互通，并具备稳定的网络连接。
mysqldump工具适合于网络连接不佳或需要一定业务中断时间的场景，本地操作速度快，但需要考虑数据文件的传输时间。
DTS与mysqldump工具都有各自的限制条件，需要仔细阅读产品说明，并通过POC验证功能。
案例一：从友商公有云迁移到京东云公有云，由于源端binlog问题导致DTS任务失败，最终通过mysqldump模式导出文件，本地导出速度很快，压缩后的数据库导出文件体积缩小，减少了网络传输耗时。
通过网络传输到京东云侧的云主机，然后source方式导入RDS，整个过程耗时小于2小时。
导入MySQL数据后，使用checksum_table工具对源端和目的端数据库做对比，发现部分表不一致，与业务方确认为源端在迁移开始后，停止服务不彻底导致，仍然有数据写入操作，后经业务及研发检查新增数据，对部分数据做清理后，完成数据库的迁移工作。
厂商改良（非原生）的数据库的迁移：在某些云厂商的特定数据库版本中，会对标准的数据库产品如mariaDB、PG等数据库做一些定制化的开发，以满足客户的业务的某些特殊需求，这种数据库属于厂家深度绑定的类型，在做业务迁移或灾备数据同步的时候，根据时间场景做定制化的迁移及同步方案，大部分需要从研发层面做一些定制化的配置和操作。
案例二：某金融用户，原系统运行于T的金融云，使用了定制化的RDS服务，因金融行业的业务及数据灾备规范，需要做异地容灾，将灾备系统运行于京东金融云平台。
为实现从T云定制化的TDSQL到京东云的迁移，对源端的数据库做了详细调研，因为源端是定制化的、具有自动水平拆分、Shared Nothing 架构的分布式数据库，因此使用京东云的DTS工具不适用于这个场景，同时，在两个环境，要求数据基本为实时同步才能满足业务容灾的需求。
制定方案时，考虑了传统灾备厂商的方案，但因传统厂商灾备方案多以主机级别数据及IO分析或日志分析为基础，无法适应云上RDS的场景，最终方案采取了基于gtid的主从复制的方案来实现数据库的异构云同步。
案例三：客户业务从友商云迁移到京东云，源端ES为K8S集群自建服务，服务访问方式为nodeport方式，选择迁移技术方案时，考虑了源端自建的ES未安装S3插件，因此采取reindex方式来做业务数据的迁移。
为实现从京东云侧对ES的数据拉取，在源端配置了一个nginx反向代理，实现了通过公网对内部ES接口的访问，同时配置白名单，限制访问IP为京东侧NAT网关出口的公网IP，确保数据的访问安全。
在京东云侧，临时调整路由表，配置明细路由，将源端公网IP配置到对应子网的路由表中，指向NAT网关，通过NAT网关可以拉取到源侧的ES数据，并在ES服务中对源端的公网IP做加白操作。
对象存储的迁移：对兼容S3协议的对象存储数据迁移，各个公有云厂商均有迁移工具或脚本，迁移技术难度不高。
但是，因为不同厂家的对象存储在不同region可能存在底层版本及配置差异，因此需要对迁移的数据做完整性和可用性校验。
在实际迁移中，需要根据项目实际的数据存储量、业务访问特性、业务停机窗口等信息，综合考虑迁移流程和选择技术方案。
Redis迁移：业务中Redis使用有两种场景，一种是仅作为缓存，不做数据持久化，这种业务场景，迁移后在新环境部署业务后直接调整业务指向新的redis实例即可。
一种是有数据持久化，这种业务在迁移到云上时，需要根据业务需求，做redis数据的迁移操作。
Redis有rdb（point-in-time snapshot）和aof两种持久化方案，其中rdb模式是二进制格式，类似于快照，恢复直接覆盖，aof保存的是命令（文本格式），类似于追加模式。
如果需要保留目标端的redis的数据，可以使用aof方式，但需要注意老版本Redis服务不兼容新版RDB格式。
数据备份的重要性：数据备份是在业务迁移的全生命周期怎么强调都不过分的环节，因数据备份不充分导致数据丢失、业务受损的教训很多。
在迁移实施过程中，因忽视数据备份而导致出现问题的事件仍然很常见。
问题可能来自客户，可能来自我们实施团队，也可能来自ISV或者其他可能操作数据的团队或个人。
在重要业务场景中，迁移前，需要对数据备份所需的存储空间做好评估并考虑备份空间的成本。
业务数据迁移总结：提前做好备份，有了备份数据，迁移过程的压力会减小，相对宽松的迁移氛围对迁移实施很有利。
迁移技术及工具的选择，需要根据业务性质选择并验证。
准备回退预案，做好POC验证，POC能发现部分问题，提前准备解决方案。
做好流程手册，明确操作责任人，联系相关部门做好迁移的切换阶段的护航准备。
产品和服务类的问题一定要能找到人支持。
明确责任矩阵、进行全面沟通，沟通能够发现技术层面很难发现的问题，越早建立迁移组织并形成有限的沟通机制，对迁移的顺利实施越有利。
致谢：本文写作过程中，京东科技-京东云RDS研发同事、京东科技-京东云对象存储研发同事、京东零售-企业业务事业群的研发同事提供了宝贵资料和建议。
向他们表示衷心地感谢。
