1.背景
xx机房使用已久，机器老旧，已支撑不了业务爆炸式的增长。而客服系统应该是这次机房迁移里最复杂的系统了，一是系统用了很久，遗留下了很多问题，而且全部署在物理上，不能使用容器云平台；再者，系统庞大，迁移时有将近20来个域名，各模块调用复杂，耦合性高，其中一个小系统出问题都会影响业务使用，而且是7x24的，迁移只能选在凌晨流量小的时候，比较蛋疼。。。
2.方案选择
最初讨论的是平滑迁移，但是系统使用了rabbitmq、zk、redis分页式锁等，由于历史原因还有个别系统使用了ip_hash，并且还要考虑基础组件跨机房无法消费和已经建立的长连接无法随时重启的情况，由于客服系统消息队列不仅使用了mq同时还使用了thift框架传输消息，有些生产者还得同时担任消费者的情况，综合考虑最后还是否定了平滑迁移的方案，可控性低，风险太高，一亘出问题就是大故障。
经过和开发讨论最终还是选用在新机房重新部署一套新的系统，基础组件全部使用新的节点，并且选择在凌晨业务量最小的时候进行停机迁移，事后证明这种方案确实是可靠性更高的方案，有问题回滚也很快，风险大大降低了。
3.迁移中的问题
第一次迁移域名解析后，客服反应没有用户签入，一直在排队，而我们这边查看各系统日志也没有看到报错信息，后来怕影响使用直接回滚了，由于疲劳操作，最后还把新机房机器上混部的服务误杀，还好不是重要服务，否则不堪设想。
事后分析：
由于经验不足准备不充分，应急方案也不完善，由于时间安排不合理，也忘了让业务参与到测试中来是这次迁移失败的主要原因。
迁移前没有完整的流程测试，迁移前测试时出现有业务白名单限制及网络访问限制的问题。
对迁移的工作量和系统业务之间的复杂度预估不足。
回滚流程混乱，一个人在没有同事效验的情况下疲劳操作很容易犯错。
事后看当天的日志旧机房代理上也还有少量访问流量，当时也没有考虑到dns缓存和业务是否绑了旧ip访问的问题
改进措施：
让业务也参与测试，整个流程多检测几遍，迁移后有些老服务可停掉，因为有消息队列的调用需防止干扰。
提前检察接口之间调用，排除白名单及网络限制等问题。
客服业务分散各地，需考虑好dns解析生效时间的问题，可以将新的域名配置覆盖到老的代理，后端都打到新机房。
制定好应急和回滚方案及迁移人员分工安排。
让使用者提供机器的相关配置如hosts，看是否有绑定ip访问，有没有其它特殊配置，如修改过dns，若使用绑定域名访问，事后需找业务沟通，统一去除，防止留坑。
(事后证明业务都是使用自己的dns,通过绑定hosts访问系统，所以这是个大坑！)
4.总结
通过这次迁移，收获了很多宝贵的经验，这是以往没有的，迁移实际占用的时间也就2天多，感谢开发及相关同事的配合帮助，虽然累但是成长很大，写几点感想吧!
每个公司、每个业务都有自身的痛点，历史原因和人为原因都有吧。
迁移前方案确定很重要，关乎成败，最好多集思广益，多与开发、业务沟通，多向有经验的人请教，不要闭门造车，刚愎自用。
在迁移前最好把相关配置及准备工作做好，一些能迁的服务都先迁走，迁移时集中精力，减少干扰。
了解要迁移业务系统的历史情况，更要多了解使用者那边的情况，迁移前与各方都协调沟通好，这一步往往是成功的关键。
迁移中要仔细，制定好回滚及相关方案，做到有备无患，有条件最好能请相关同事协助一起验证。
网络限制、业务白名单、相关接口调用是否存在风险、迁移后业务稳定性的关注、迁移后整个系统配置检察、报错通知等这些都要在事先和事后认真考虑，这样迁移才能顺顺利利。
就写到这儿吧，留与有缘人借鉴，愿世间采坑人越来越少哈！ ——2018年6月27日记
