一名后端研发眼中的机房服务迁移

原来的平台硬件设施满足不了业务的增长，需要将现有的服务整体搬迁到新的机房，以提供足够高性能的硬件及网络支持。由于是线上平台，迁移前后的网络架构应保持一致，以保证后续服务运营的延续性。迁移过程对线上服务的影响应尽可能少，如果能做到不间断服务就最好。

迁移前，应成立项目小组，把所有相关的人员组织起来沟通各人的工作安排。就这次迁移而言，涉及的人员包括以下几类：

运维人员作为机房维护的最前线人员，也应是本次项目的发起人。

开发人员对应用的部署以及业务逻辑的实现是最清楚的，很多配置和技术细节，以及服务之间的依赖关系，只有开发人员才清楚。

架构师比运维和开发更清楚服务架构及需要的设备性能，大的方向还是需要架构师来把控。

迁移前后的性能对比，迁移后的服务可用性，都需要测试人员测试。

运营人员负责在迁移前提供迁移通告，提前通知用户迁移事宜，对迁移过程中可能出现的问题提前告知用户，并提供相应的临时解决方案以安抚用户。

作为直接与客户打交道的人员，销售和客服需要知道服务迁移的整个过程，提前与客户沟通，特别是重大客户，必须通知到位，维护好客户的利益。

人员聚集齐后，就需要讨论迁移方案了，各方根据自己的角色提出关心的问题。这里我试代入以上人员的角色，列出他们关心的问题。

迁移时间定于国庆长假第一天晚上12点，需要开发、测试到时配合处理。正式迁移切换前，会把旧平台的数据、应用通过同步的方式安装配置到新平台。

机房迁移，涉及到ip的变换，运维应给出新旧平台的ip对应列表，提前检查应用里使用了ip的配置项是否配置好。新平台应给开发人员分配同样的机器访问权限，以便开发人员直接查看配置、应用版本、数据的完整性等等。

新平台的架构图，与旧平台的架构对应关系如何，设备性能有哪方面的提升？

什么时候能做旧平台的压力测试？什么时候可以做切换前新平台压力测试？什么时候做切换后新平台的业务回归测试和压力测试？需要提供测试的环境。

影响的用户范围、持续时间多久？客户系统是否需要配合修改的？什么时候出公告通知用户？是直接系统内发公告，还是由销售、客服发邮件通知客户？

同运营人员，越早通知客户越好。

根据各相关人员关心的问题，制订对应的措施，最终得出的结论就是宏观上的迁移方案了。至于迁移的技术细节，主要是由运维人员实施，由运维团队内部考虑即可。

为保持数据一致性，运维人员选择了暂停服务的方式，等数据手工同步完成后，再通过dns切换的方式，把原域名指向新机房的ip，即可恢复服务。期间，服务不可用，具体不可用时间要视数据同步导入新平台所消耗的时间。

开发和测试也要随时待命，以便在迁移过程中出现问题时及早处理，等迁移完成后也需要验证迁移是否成功。

所有服务迁移到新平台后，运维和开发仍需密切留意新平台的服务质量，通过监控平台观察新平台的性能和负载。还需要观察服务的日志是否有异常。

运营需要观察用户数据，如果用户活跃数出现较大的落差，需要及早反馈给技术人员。同时，观察用户的反馈留言及客服接到的客户反馈问题。