机房搬迁整体方案是为了平稳迁移所有业务，在有限的资源和有限的切换时间（甚至秒钟级别时间内）完成搬迁（银行、ATM之类的公司不能比，在不提供新资源或者提供基础几台资源的情况下搬迁）， 保证机房业务和数据能够安全、可靠、快速的搬迁。

二、 背景

现今IDC跟10多年前IDC不同，第一是数量开始增多，第二是价格下降，第三是很多公司使用公有云替换了IDC，当然也有使用公有云+IDC的公司。总之现在因为需求的不同，各种方案都有。(使用公有云替换自己租IDC的公司，主要考虑自己维护管理机房、采购服务器、后期维保服务器等不是专业的，专业的事交给专业的公司干，将公司的精力集中到公司业务，当然关键的还能提升运维效率，如，一个项目立马上线，如果普通中小企业无备用服务器的情况下，就需要立即购买，可能会有选型、招标过程，这样整个采购周期就很长，项目上线可能延迟。如果使用云几分钟就完成任务）。

三、 迁移前的考虑

（其实这里搬迁到云上已经包含其中，当然有一些没法搬迁的后面补充）

1、 机房标准：环境了解，机柜位置了解，机房动环系统，pdu插口是否满足需求。

2、 一般租用的机房公司，他们是否给巡检，是否有基本的上架，梳理线缆服务（实际工作中，上架、拉线、绑线很浪费时间，最后还不是很美观。）

3、 机房专线进入是否方便，进园区是否收费，机房所在公司是否在收端口费用，端口费用有多贵？

4、 网络如何规划，需要多少个接入交换机，路由器、防火墙，是否满足高可用，是使用大二层还是3层网络？是使用基于单个主机冗余（交换机浪费，但是适用于中小企业），还是基于整个机柜甚至整排机柜的冗余？我们曾经的机房是基于主机冗余（单台主机双网卡绑定），现在新机房是使用基于机柜冗余（允许宕机一个机柜）

如果是公有云：考虑网络规划、网段、安全组等基础环境配置，然后考虑专线跟IDC打通。

四、 搬迁团队（运维人员+开发+业务）

1、 是否雇佣专业搬迁公司，还是自己搬迁+雇佣车。原则上是重要设备、高端存储之类的设备雇佣专业公司进行搬迁，普通x86服务器，多节点的业务，自己搬迁即可。（可以节省很大的成本）

2、 一般情况下搬迁团队是由公司运维部门担任，当然一般搬迁都是公司大事，必须知会各个开发部门领导和产品，甚至开专门的动员会，这样开发才会配合支持。

五、 原机房注意事项

1、 统计搬迁的数据：机器数量、分别每个机器的u数，分类搬迁。

2、 准备打包箱子、标签纸、扎带等

3、 小型机链接线务必轻拔轻放，包装好。

4、 根据业务类型划分搬迁次序，分配到责任人，责任人务必包含运维、开发、产品。比如：支付系统、营销等

5、 识别特殊系统，比如：有停机先后顺序的，带存储的，挂载有nfs的系统，带狗的系统，有物理机授权等。

六、 针对每套系统具体方案编写

1、 按照具体业务列出具体系统中的每个模块，如营销系统中的优惠券、活动，采销系统中的订单、主数据等，越细越好。

2、 按照每套系统的每个模块编写文档，内容包含原主机ip、部署内容、部署路径或者目录、缓存ip、数据库连接ip，zk地址等等，所有详细信息均要列出。

3、 与开发沟通编写api部分模块，具体到调用接口和http接口，所有接口都要列出（后期用于验证）

4、 网络层面权限查看，是否有特殊限制，比如分支机构或者分公司是否有权限访问。

5、 域名查看，是否有公网。

6、 注意点：如tomcat是否有用户限制，最好方式是将tomcat直接打包原路径解压。即使是平台管理也可以这样操作。

7、 数据库连接查看，是否有共用库的情况，是否有大数据抽数，是否有其他特殊权限。

七、 具体切换方案

1、 网关或者负载均衡按照原配置配置即可，后面切换dns即可。

2、 Web层大部分系统为基于互联网的多web或者多模块系统，1：1部署即可，按照第六步统计结果进行部署即可。

3、 Redis、mysql、mongodb采用数据同步

4、 Es采用加入集群同步数据方式，完成后把老机器踢出集群。

5、 如果有Oracle，采用OGG或者DG同步到新机房，提前配置应用JDBC链接，当数据追平时，重启应用即可生效。这步说来简单，实际办起来可能因为数据大小，或者每天产生的数据过多，会导致性能问题。当然还有一些其他的问题，细节上要注意，多想问题。

6、 最难的就是一些老系统，比如一些win系统，开发走了无人维护，甚至一些系统是购买的商业软件，但是这个商业软件公司已经倒闭。这种系统最麻烦，一般采用硬搬，当然要备份相应的数据。

7、 小型机和存储搬迁也是麻烦事，注意上面拆除小型机，一些连接线要保存好，存储这个该买保险买保险。

八、 具体切换

1、 按照上面7个步骤该准备的准备，越细越好。

2、 提前将新环境部署好，只等待dba同步数据，等到数据同步完毕，每套系统按照具体的修改代码提交，发布，链接到新机房的库。

3、 数据库检查链接正常，即可验证业务。

4、 产品通知业务一起验证业务。

5、 回顾切换过程中的问题，形成总结文档。

九、 总结

以上几点均是我在搬迁工作中形成的一些经验，越细越不容易出问题，一般迁移切换选择闲时进行，比如晚上或者半夜迁移切换，往往第二天早上因为一个配置疏忽造成业务受影响，所以重要系统，重要配置最好双人检核，避免出现事故。

迁移这个活对公司内部成员来说不是功劳苦劳，是应该干好的，不出现问题是应该的，出现问题就要追责。一入运维深似海，万年填坑填不平。