全业务90天机房迁移小结
序：
借当下流行的图
关于「上云」，从技术角度称呼「机房迁移」会更合适一点。对于运维或数据中心而言，机房迁移无疑是职业生涯中最庞大的工程了，没有之一。普通运维职业生涯有幸接触，对职业提升会有比较大的提升，但通常讲有且有一次就好。~0~
就当下公司业务特性来讲，其它公司的经验有我们可参考的地方，但基本属于零帮助，为什么这么讲呢，且听我的一些简单分「牢」析「骚」。
一点“牢骚”
刚听说有这个项目的第一刻,我的心里绝对是“万马奔腾”的。对的，第一刻起，我就已经断定这个项目是作死，！！这是不可能完成的任务！！，为什么这么肯定呢？
1. 业务概况：当下业务生产环境本身就已经隐患重重
DB没有从库备份
DB的变更都是不停进程的情况下强行更新，库表变更全在拼人品
所谓DB的备份都存放在家用NAS上，备份丢失只在一念间
某模块Server 负载高达280,是正常服务器的50倍
生产服务器满容量运行。
composer依赖文件不全、phpconfig不生效。。。等等
上面的任何一项出问题，整个业务都会停摆甚至永久损坏，而业务还一直看似正常的运行，大家可以想像这个团队同学是积了多少人品！！！
2. 业务团队：运维团队最长入职时间10个月。。。
短短一年，运维人员高达5轮迭代，连WIKI文档都严重断档
这个项目的负责人，刚入司3个月（对，负责人是我）。
JAVA几乎全部人力被抽离支持新项目，老项目仅留1人支持。最重要的是
a. 所有项目的排期以月为单位，即需求30天后排期
b. 手头一堆知道的和不知道的项目，自己手头有哪些项目自己也不清楚
c. “不知道” “不懂” “我得去看代码” ，已然是整个项目是出现频率最高的词汇。
3. 系统环境：异常复杂，无人能把握全局
生产环境配置异常杂乱，没有任何可靠文档
项目复杂 20+ JAVA项目，40+ PHP项目
一直在数个月后才发现，生产环境NGINX服务真假“美猴王”
没有环境部署文档且开发同学也不知道，开局一套旧环境，后面全靠摸。
生产环境的架构图还是2年前的
近30%的机器无人认领
4. 人员配备：运维仅配备了1个人？1个人！
本次迁移竟然只配备1个运维。
大家可能不知道：
15年在58同城实施过一次（“逐日”项目），几千台物理机，从IDC迁到了腾讯的天津机房，项目做了10个多月，跨所有的部门，与所有的业务都相关；
饿了么机房双活，业务运维、DBA、基础运维、框架研发、工具研发等等水平团队，运维人力投入约100人，历经约6个月
淘宝双11，这么多年每年双11，必须提前6个月全员准备，提前3个月全员实操演练
5. 制度流程：无成熟稳健规章
多部门协作，但无规章制度，流程规范，全靠口口相传
流程冗杂，效率低下，OA单据是老大，再简单的OA单据连催带赶走1周是常事
各部门自动化程度低，交付率低下，更不用提交付质量和自定义
综上，我的断定是这个项目是不可能成功的，这个项目不仅仅是个锅，还是天锅「天大的锅」，随之而来的负面情绪更是翻江倒海。当时手头也有些其它机会，是甩袖闪人还是拼一把试下，几经纠结后最终还是决定拉拼一把试试。开始之前很好的说服自己，时刻保持好心态对于做好一件事有多重要相信大家深有感触。
心态归心态后，怎么解决上面这些问题仍然头大。
一点过程
简单分享一些过程，很重要但也可能稍些空洞，涉及业务层面，一些细节不方便过多透露，主要执行层面的一些分享。
1. 抛弃经验，空杯心态
经验固然重要，但被经验坑相信也是常有的事。
由于经过太多迭代，每个人掌握的信息都是片面零碎的，但迁移又是一件要求面面具到，对业务深入了解，因此深入了解业务成为必须。既然大家都不知道，但总得有一个人尽可能知道的多一点，因此就有了：
1700+行的config配置文件逐条分析，最终有了“头重脚轻”的最新版架构拓扑图，因为内/外部的接口调用多到比业务自身的架构还复杂，同时我们也知道了，我们需要配置中心
100+条的crontab任务，非常重要的日志信息却打在/tmp目录，同时我们也知道，我们需要任务中心
所有运维工具底层代码的全新梳理，最终有了发布效率的30倍提升
所有部门的交付一律重置信任，做二次check，而最终也确实帮我们跳过了很多不必要的坑。
历经1个月的梳理，终于对生产环境大家都知道的信息做了汇总。到此，所有的信息最少有一个人较全面知道了。
//PS
其实这里只是梳理出来了大家都知道或者挖掘出来了绝大部分的信息，但仍有很多大家都不知道的信息没有被暴露出来。
设立共同的目标
上云是个大项目，不单业务部门需要参与，更需要各部门的全力冲刺，密切合作。周边部门的历次合作不可谓摩擦不断，没有兄弟部门的支持迁移只能是空中楼阁了。尝试过多种方式，但收效甚微。但这次不一样，任何一个部门的资源配合有问题，都会导致迁移的不确定性。既然不能好好合作，那就一起战斗吧。
多部门设置共同目标，以团队内部合作而非团队间合作方式支持机房迁移工作。结果证明，收效显著
拒掉了所有紧急度一般的干扰项目，除业务需求外，所有需求以迁移为重心。
借助团队的力量
团队初期磨合，任何没有数据支撑的需求都是伪需求，即使是合理的需求，也需要契合的时机！！！
运维1个人力的投入明显会有问题，但考虑到团队都是新成员，内部还处于磨合阶段，在进行至关键节点前，根据现有进度，同时细化任务复杂度及难度，在大家一致认可的前提下，全员参与保障关键时间节点。
和开发同学定期站会，同时单向汇集对应模块负责开发同学，在最小消耗开发同学精力的同时将单线条信息在自己这里汇集成网。
尽可能详细的规划
在诸多潜在未知因素中，一份尽可能详尽的计划安排就尤为重要!!!
根据当时的情况，我们安排了一个那里认为可行的详尽规划。
但现在反过来看，这份规划其实详尽还差很多，比如：
缺少突发事件的时间冗余规划
缺少具体工作项的实际操作，这也导致时间估算不准的罪魁祸首
缺少周边支持部门的不可控因素的时间冗余规划
最终的结果也果然出乎我们预期，原计划1个月的迁移足足准备了3个月才着手迁移。虽然经历了第一次上云的意外回退，但值得惊喜的是第二次上云异常顺利。在经历了极为忐忑的第一个工作日考验后，心里的石头终于落下了，早早守候在电脑旁边的同学们疲惫也早被喜悦冲淡。我们知道我们完成了一件不可能的事情。
一点成果
这次顺利迁移外，我们也取得了一些成果：
最新业务架构拓扑图的梳理绘制
完备的wiki文档
原来的纯人肉手工逐一部署环境，到现在全自动化的环境部署，30倍效率提升
全业务目录、应用、操作标准化
JAVA项目全新部署发布优化，让原来的TOMCAT升级从以天为单位到以分钟为单位的优化，百倍效率提升
全业务配置全自动生成，旧环境的配置不可维护的情况成为过去式
全业务无单点
最重要的是运维对现在的环境有了全面的掌控力，没能力维护成为过去式。
鸣谢
最重要的是要鸣谢团队成员和各兄弟部门的鼎力支持了。