服务迁移总结
2016-11-26 23:14
197 查看
近日公司将机房从阿里云服务器迁移至腾讯云,现将迁移过程进行总结,方便以后进行参考。
一迁移前准备:
决策部门:提前规划将服务器由阿里云迁移至腾讯云服务器,因此各个技术部门在正式迁移前三个月及已经着手进行准备。规划好不同业务的迁移时间表和指挥负责人。
运维部门:首先验证服务器是否满足需求,各个资源进行同步的方案(可进行模拟迁移),随后进行各业务服务器环境配置搭建,主要是JRE+Tomcat + Zookeeper + Nginx。由这些进行服务化远程调用以及负载均衡。同时运维使用运维提供服务器的内部域名进行各个项目的调用(防止出现ip地址变更,导致的坑)。
DBA部门:和业务部门规划好数据库迁移方案,做好迁移期间的服务器和数据库的监控。
各项目部门:提前规划好迁移步骤、流程以及注意事项。做好应急方案以及补救措施。确定好程序发布的版本,防止出现发布了错误的代码程序。当接受到服务器后具体的负责人将自己的项目进行部署,部署结束后,自己手动修改本机的host文件,验证服务部署的是否正确。若不正确进行修复后重新进行验证,如此反复。
测试部门:提前规划不同业务需要进行验证点,写出测试用例,方便迁移开发人员能够准确的验证每一点。
二迁移过程中:
在正式业务进行迁移前,运营部门向客户发出通知,提示在xx-xx时间段内进行服务器的迁移,期间各服务均将停用。防止出现意外的损失。
等到正式迁移的时间到时候,
运维将原先的服务关闭,用户访问主页面时候,均出现后台进行维护页面。然后进行服务器域名的重定向指向新的IP地址,同时运维需要监控各服务器的运行情况,防止出现I/O过高、CPU过载等情况。
DBA数据库管理员进行数据库的迁移,期间注意数据的增量和丢失的日志,防止出现数据丢失。同时监控数据库服务器的运行情况。防止出现I/O过高、CPU过载等情况。
基础服务部门:快速进行服务的发布、验证,确保后续的业务部门进行服务的验证。
业务技术部门:各项目负责人根据测试部门体现规划的测试点,进行验证,配合测试人员进行项目验证,如若发现问题,快速定位问题,解决问题。稍后进行再次的发布,测试,直到项目验证成功。同时监控服务器的运行情况,查看有无错误日志,防止出现各种隐藏的问题。
其他部门:协调好各种资源利用情况,准备好零食、咖啡、提神醒脑的饮料等。
三迁移后:
随着迁移结束两天内,各主要的人员进行休息,留下部分人员进行监控、防止项目出现异常情况,一般等到钱以后两天项目才算稳定运行。迁移才算告一段落。
四迁移正式结束后:
每个人进行迁移期间的问题进行统计、总结分析。都应该给自己一份总结报告。
注:本文是一个小公司中的一个小程序猿的总结,站的角度和看到的只有这么多,大神勿喷。
一迁移前准备:
决策部门:提前规划将服务器由阿里云迁移至腾讯云服务器,因此各个技术部门在正式迁移前三个月及已经着手进行准备。规划好不同业务的迁移时间表和指挥负责人。
运维部门:首先验证服务器是否满足需求,各个资源进行同步的方案(可进行模拟迁移),随后进行各业务服务器环境配置搭建,主要是JRE+Tomcat + Zookeeper + Nginx。由这些进行服务化远程调用以及负载均衡。同时运维使用运维提供服务器的内部域名进行各个项目的调用(防止出现ip地址变更,导致的坑)。
DBA部门:和业务部门规划好数据库迁移方案,做好迁移期间的服务器和数据库的监控。
各项目部门:提前规划好迁移步骤、流程以及注意事项。做好应急方案以及补救措施。确定好程序发布的版本,防止出现发布了错误的代码程序。当接受到服务器后具体的负责人将自己的项目进行部署,部署结束后,自己手动修改本机的host文件,验证服务部署的是否正确。若不正确进行修复后重新进行验证,如此反复。
测试部门:提前规划不同业务需要进行验证点,写出测试用例,方便迁移开发人员能够准确的验证每一点。
二迁移过程中:
在正式业务进行迁移前,运营部门向客户发出通知,提示在xx-xx时间段内进行服务器的迁移,期间各服务均将停用。防止出现意外的损失。
等到正式迁移的时间到时候,
运维将原先的服务关闭,用户访问主页面时候,均出现后台进行维护页面。然后进行服务器域名的重定向指向新的IP地址,同时运维需要监控各服务器的运行情况,防止出现I/O过高、CPU过载等情况。
DBA数据库管理员进行数据库的迁移,期间注意数据的增量和丢失的日志,防止出现数据丢失。同时监控数据库服务器的运行情况。防止出现I/O过高、CPU过载等情况。
基础服务部门:快速进行服务的发布、验证,确保后续的业务部门进行服务的验证。
业务技术部门:各项目负责人根据测试部门体现规划的测试点,进行验证,配合测试人员进行项目验证,如若发现问题,快速定位问题,解决问题。稍后进行再次的发布,测试,直到项目验证成功。同时监控服务器的运行情况,查看有无错误日志,防止出现各种隐藏的问题。
其他部门:协调好各种资源利用情况,准备好零食、咖啡、提神醒脑的饮料等。
三迁移后:
随着迁移结束两天内,各主要的人员进行休息,留下部分人员进行监控、防止项目出现异常情况,一般等到钱以后两天项目才算稳定运行。迁移才算告一段落。
四迁移正式结束后:
每个人进行迁移期间的问题进行统计、总结分析。都应该给自己一份总结报告。
注:本文是一个小公司中的一个小程序猿的总结,站的角度和看到的只有这么多,大神勿喷。
相关文章推荐
- 迁移微服务框架-SpringCloud-事后总结
- 新智云从服务迁移到docker的想法和总结
- 一次生产环境web服务迁移故障总结与反思
- 从服务迁移到docker的想法和总结
- 迁移打印服务--活动目录管理技术(转贴--收藏)
- 一次web项目从Weblogic服务到oracle AS10gR2的迁移过程
- [总结] 关于 JavaScript 跨站点/域服务的资料
- 把java程序作成windows EXE程序或windows服务---经典总结
- linux开启telnet服务(总结)
- 迁移到面向服务的体系结构
- 关于Remoting服务启动和停止的简单总结
- ArcCatalog连接远程机器的ArcSDE服务总结
- 申请了blogmove.com.cn域名,准备提供博客迁移服务
- Remoting服务集成到IIS的简单总结
- javamail邮件服务发送总结
- 关于Remoting服务启动和停止的简单总结 (转)
- ASP.NET的SMTP邮件服务编程总结
- 理论为实践服务:ASP开发10条经验总结
- ASP.NET 状态服务 及 session丢失问题解决方案总结
- 关于公司服务器及应用服务的迁移