项目迁移总结

Posted 2020-07-05

入职接近一年时间，虽然说公司有几个项目，作为运维人员，各个项目还是多多少少有一些接触。但这么久的时间以来，一直感觉都是在帮人打打下手，跟着别人做事情，给安排什么就做什么，或是项目上某个部分弄个调整什么的，这里修修，那里补补。完全没有体系的概念。
    机会是留给有准备的人的，虽然二月底才开始有自己的计划，还没坚持几天，锻炼我的机会就出现了。3月2号至今也有一月有余，整个项目也算是迁移完成。因为除了乙方交接人员，这边都是我一手完成，从整体上来说，对于运维这个岗位又有了更全面的认识。由于步入职场不久，整个过程中还是有比较新鲜的事情让我印象比较深刻，现在记录下来，算是自我总结一下：

    架构图：是整个项目的依据，先看懂架构图，有多少个组成部分，各部分负责实现的功能是什么，各部分之间又是如何联系起来的（一般都用套接字）。还要注意架构图中标明的通信端口，走什么协议（udp/tcp），所在服务器（内网地址和外网地址标明的区别），如果是外网地址，很明显就想说明是对外开放的。如果有多个架构图，可能负责的是不同部分，前期不必过于纠结架构之间的联系，避免混淆思路。既然分开肯定是负责不同的功能，但在最后，对整个项目有一定了解后，一定要站在更高的层次把所有部分联系起来。
    在有自己的理解后，最好能用自己的方式把架构整理出来。
    服务器：拿到服务器权限，确认所有服务正常后，登录服务器尽量做到只查看，不做其他操作，避免自己的操作影响了原来的正常服务。通过netstat查看开启的端口，确认有套接字的服务，注意tcp/udp都不要遗漏；通过ps命令查看执行的进程信息（PID、cpu、内存开销）；通过lsof命令查看进程依赖的库文件和执行时调用的其他文件（配置文件，日志文件等）；通过pmap查看具体进程的开销；使用df命令查看磁盘使用率和使用du命令查找到磁盘占用的主要位置，如果很明显，无论是数据还是日志，都很有帮助；使用top命令对整个服务器上的服务开销做个整体的了解；使用free命令对系统内存做个评估。尤其充分利用/proc/PID/进程文件，查看进程信息最有效的方式（启动参数，执行路径等）。除了服务相关，还要注意系统方面(架构是32为的还是64的，选择依据是什么？系统有特殊设定么？内核有优化么？)
    可以通过表格形式，整理出线上的主要服务器，数据，业务，细化到位置，启动方式，开启的端口。
    源码：首先是源码的完整性（除了单个服务的源码完成，还有整个项目各个小服务的源码完整），不丢失一句源码，不遗漏一个脚本。线上拿到的源码可能已经被编译过，比较凌乱，要学会从中去除生成文件，旧版本文件，备份文件，整理出一套完整又清晰的代码。查看其中的makefile文件，通过的gcc命令查看编译的对象，注意生成的文件(和clean函数最直接的显示)。尽量将筛选出来的源码做个备份。筛选有价值的文件还有一个目的：除了源码和必要文件，尽可能少的上传原环境中的文件到新环境中，安全是一方面，减少垃圾也是一方面。
    数据：其重要性在整个行业中的地位大家都清楚。了解其存储结构，取有效数据提前做好备份。将整理出来的数据和对方做个确认，数据是可用的，没有遗漏。再考虑如何做数据同步，后期如何做好备份都是很关键的问题。
    目录结构：一般要注意的目录有/data/目录，和项目的具体服务相关；/usr/local/目录，除了项目本身服务，是否还安装了其他的服务，所用又是什么。
    站点：是一个直接的方面，通过记录能直接定位到服务器上，DNS、web-server、srv-server、及站点源码都不要遗漏。尤其是DNS的指向可能很直接的展示出了项目对外提供的接口和服务器之间的关系（有些服务是不是一定要放在一起，如何搭配的）
    配置文件：服务特定执行的配置，无论是项目服务还是其他安装服务，都能通过配置文件了解服务的特点，参数设置。服务能跑起来是一码事，能提供有效的服务是另一码事。对于没有把握的服务，配置尽量和线上的保持一致，对线上的各种服务配置文件做一个备份也是很好的选择。尤其web服务方面，如果web源码没有问题，原来线上的配置文件是你重新部署站点时最好的依据。
    其他：
        云控制台：费用方面（每月账单查看开销，当前价格，到期时间，余额，计费方式，是否自动续费，充值相关）
        云主机列表（数量，主机名一般对应主要负责的服务，服务器配置信息，安全组设定，服务器管理）
        监控：主机性能状态基础监控（新服务器购买依据），业务数据监控(业务重点)
        数据统计：日活相关

以上应该都还算是对整个项目的熟悉了解吧，越清楚越好，当时不明白没关系，有空的时候都想想，等你焕然大悟的时候，再到服务器上查看下，验证一番，顿时会有一种豁然开朗的感觉。

    新规划：可以参照线上的规划，但一定要比他更合理，这是降低成本的直接表现。除了保证所有服务能跑起来，还要充分利用服务器资源。且这个新规划自己肯定是最清楚的，完全就是对项目熟悉的一种表现。新规划中不要遗漏服务，注意资源合理分配，涉及数据的服务尽量保证其对数据的操作最便捷。各服务之间的关系，流量走向，用箭头表示出来。除了加深理解，同时注意还要给别人展示，让不知道项目的也能轻松地通过你的新架构规划了解项目。
    新规划中包含服务器合计信息：数量，操作系统（32/64），配置要求（cpu、内存、带宽），初期费用估算
    部署规范编写：后期的所有部署参照这个规范，整齐化一
        项目:源码位置、服务程序位置、日志文件位置
        数据：数据服务，数据存放，数据备份
        其他安装：基础命令可以直接yum安装
            编译安装服务：源码位置、安装位置、日志文件
        Web站点位置：
        脚本：脚本位置，基本描述，计划任务
    服务器购买：购买服务器时也不要极端，资源空间不足时可以扩容，尽量有合适的剩余空间为后期的规划，调整留下空间。先买一台，不要一次性全买，了解云控制台的计费方式，做到按需购买。选择基础的配置（前期规划的cpu、内存、系统），带宽可以保守一些，磁盘可以后期挂载。
    以上服务器购买尤其注意的有以下几点：
            1.服务器运行的操作系统：项目支持的版本，架构是32为还是64位
            2.内存，阿里云平台的32位系统有4G内存限制，所以新规划中是否考虑到，如果4G内存能否跑起分配在这台的程序。Ucloud上面没有4G内存限制还是很不错的。
            3.阿里云主机购买时如果出了40G的系统盘，又挂载其他硬盘，是不可卸载的。在后期如果遇到磁盘上面的数据迁移，很不方便。尤其在主机故障时，这个数据盘不能挂载到其他主机上，无法实现短时间内数据恢复，甚至造成数据的丢失。
            4.其他注意事项，依照不用云控制台略有不同：带宽计费（一般是出口流量）、区域间通信

系统初始化：密码，安全组设置，用户管理，系统更新，主机名设定，文件数限制ulimit及其他系统设置，项目需要的内核优化，磁盘挂载，添加主机基础监控。完成以上配置后，做一个镜像，系统初始状态的备份。
        部署:按照新规划上传相应的源码，编译，参照部署规范创建服务的工作目录，参照原来线上所需的文件（进程调用的文件）获取，配置相应的文件，调试运行程序。在程序运行没有问题后，同步线上的数据，此时再做一个镜像，不要怕麻烦，有备份总是会在出现异常时体现其价值。
        其他服务的部署类似：开服务器，初始化，部署，新部署的服务可用性测试，备份，准备割接。要注意端口的分配，不占用，同时有些服务涉及到内核需要管理员权限才能启动。
        在服务部署差不多的时候，加上进程监控，现在使用的supervisor还是不错的。
        当程序执行起来后，还要注意其产生的文件，做好操作：数据文件（备份），日志文件（日志处理）。
        以上镜像制作，作用还是有的，但制作镜像也要在合适的时期，备份有价值的状态，在镜像命名上也要区分出来（主机-磁盘-状态描述），避免一团糟。
        整个迁移过程，在服务器购买时（资金申请）一定要把具体的新规划详细向领导汇报，在成本上拿出一定的说服力。如果遇到这边没法处理的问题（域名备案或是其他非技术问题）及时向上级反映：我负责的部分能处理的已经处理，不要让那些非技术的问题影响整体的进度。

3月2号至今，迁移基本完成，所涉及的有技术方面的，也有非技术方面的，完完整整的弄完一个项目，对我来说还是比较有意义，有一定的收获。还有其他注意事项或是遇到的问题后面再补充。

本文出自 “11414123” 博客，转载请与作者联系！