数据迁移

前言：基于公司的战略的考虑，最近负责公司的两个产品线的相似的数据的整合与迁移的工作，中间碰到很多的坑，不得不说对于这种属于底层数据的迁移的工作，要做到万分的小心与谨慎

1. 迁移的内容
   A产品是我们的顶梁柱的产品，B产品是为了打造公司的战略的闭环孵化的产品，最开始的定位两个产品是没有交汇的可能，随着公司战略的调整，目前我们要求把B产品上的一些资源，主要是视频和文库迁移到A产品上，原来A产品上也有视频和文库这两种资源。如果在宏观上看，两边的资源的其实是一个东西，其实简单的拿过来是OK的

2. 困难

   • B产品中的一些东西是不需要迁移过来的
   • 迁移过来的视频和文库和目前A中的不是完全匹配，会有一定程度的数据得缺失与不对应
   • 对于迁移过来的数据在A中默认是和之前的数据没有区别，至少从展示层来看是这样的
   • 随着数据的迁移需要其他一定的数据的同步与初始化

3. 分工：本次数据迁移由我和另外一个同事负责

   1. 项目的进度的把控
   2. 数据的迁移我全权负责
   3. 迁移数据后终端页的生成、ES数据、Redis数据等数据的同步和初始化我来处理
   4. 数据迁移后对现有逻辑的影响与以后数据的同步我负责相对复杂的文库、另外一个同事负责视频模块.

4. 步骤

   1. 线下尝试做数据的迁移，确认对迁移的数据能否兼容原有数据，发现问题及时处理
   2. 后续数据的同步，保证以后新产生的数据两端数据的同步
   3. 对于文库、视频数据的多种场景的测试，跟踪
   4. 线上数据的迁移、终端页的生成、数据的同步。。。

5. 坑

   1. 现实永远比想象的问题更多
      • 在做最开始的工期的排期的时候，我们的计划是两个周的时间，然后在我们还在讨论需求的时候，领导告诉我们已经开始，后来我还没有提出异议这样我就生生少了两天了的工期
      • 在工作的过程中发现B产品中的线下的环境，因为年久的原因，好多地方已经不通畅的，调试那一堆未知的问题，花费了我不少的时间
   2. 对于未知事物盲目的自信是失败的根源
      • 对于视频和文库，我能说自己还是比较了解的，但是绝对不是彻底的了解，在处理后续的数据的实时同步的过程中，发现了还有好多自己之前没有了解到的业务，致使自己的在做实时同步这个工作的时候，实际的工期基本上double了
   3. 屏蔽细枝末节的干扰，抓住主干
      • 作为一个相对资历深一点的员工，平时工作中不可避免的要处理一些不是自己工作安排的内容，基本上是平时工作的一个常态
      • 公司目前在做线上测试服务器环境的搭建，提测的时候，有个别人要求提到线上的测试环境，然后一堆调试，浪费了不少时间，发现线上环境差的比较多，最后放弃线上的环境，改为提测到线下

PS:经过黑暗的一个周，最后提测的时间比实际的晚了一天，不过还好按时上线了。