全业务90天上云小结
「上云」，从技术角度称呼「机房迁移」会更合适一点。因为涉及的变更非常之大，因此对于运维或数据中心而言，机房迁移无疑是职业生涯中最为庞大的工程，对于公司而言，也不亚于高速行驶的车辆不停车换轮胎。本次微诺亚迁移也不例外，同时又因为人员流动、资源安排、项目排期、新人接手业务等原因，更让迁移难度陡增。好在经过团队成员3个月夜以继日的全力以赴、领导大力的支持，最终在没有重大人为事故的背景下完成该项难度非常高的项目。现就迁移概况及部分成果展示如下。
一、迁移计划
原计划：2018.3.5 - 2018.4.13
实际周期：2018.3.5 - 2018.6.9
总耗时：约3个月(延期2个月)
Delay原因：
主要有如下四个方面（后文会就原因逐一反思）低估迁移项目复杂度
资源紧张
流程繁杂
大型项目经验欠缺
******行业数据参考*******
2015年58同城机房迁移：历时约10个月
2017年饿了么机房双活：历时约6个月
二、人力投入
共约16人，参与部门：测试、开发、运维、集团IT
测试部：5人
开发部：5个
运维部：3人
集团IT部: 3人
******行业数据参考*******
2015年58同城迁移：横跨公司所有部门，全员参与（产品、运营、开发、运维、测试、QC、QA）
2017年饿了么机房双活：运维人力投入约100人 （业务运维、DBA、基础运维、框架研发、工具研发等等水平团队）
三、取得成果
本次要迁移的项目是已经运行了3年的项目，项目庞大，又历经数次人员变更，让原本难度很高的迁移工作平添不少困扰。虽然迁移之路漫漫，但经过团队的通力支持，克服重重困难，最终没有重大人为失误的完成项目迁移，并由此取得如下成果。
无重大人为失误完成机房迁移
本次迁移工作量、项目复杂度远超预期想像，结合运维团队刚成立不久，项目主导人更是入职刚满3个月，这不仅让项目主导人还是运维团队都背负极大的心理压力！但迁移工作迫在眉捷，每延迟1个月公司都要为些平白多支出近数万元/月。运维的责任第一项就是为公司节约成本，而这件事也正是运维价值的最佳体现，而如何在
刚接手业务
在不影响业务正常使用的前提下尽可能快
的完成迁移工作是一项极大的挑战，而最终让的结果也证实了努力的人最幸运，经过团队的全力以赴，大家终于完成了一项前期认为是不可能的事情。
全业务无单点
零单点故障（单点发生故障即会影响整体使用）。业务发展的太快，以至于无力同时兼故速度和质量，同时又因为人员多次迭代，因为风险远高于收益，因此全业务高可用几乎成为不可能。而本次迁移运维同学原本有“捷径”可选，但最终选择了一条最难走的路，将业务疱丁解牛，刨根问底，深挖模糊地带，最终不仅仅完成迁移工作，与此同时对业务架构做了全新设计和优化，剔除原有单点及不合理模块，使整体项目不再有任何单点故障的重大隐患，更好更专业更高效为业务保驾护航。
完备的wiki文档
单项目积累文档20+篇（共100+），从零构建运维权威、有效、高质的文档库结束了运维对业务无法掌控的窘境。
全自动化环境搭建
原本环境部署是一项非常复杂且考虑细节的工作，除此外还有大量的重复工作耗费大家不必要人力成本。本次迁移性质上已经被运维优化为为业务治病，从零重构自动化部署工作，结束纯人肉手工环境部署，实现环境部署、系统初始化一键搞定，30倍效率提升。剔除重复工作，节省海量人力投入，
全业务目录、应用、部署、操作标准化
旧业务历经时间考验，结合现有问题将经验落实到最新上云业务，让上云后的全业务目录、应用、部署、操作标准化，极大保障业务长期维护可维护性，为未来web自动化、流程自动化夯实基础。最大限度做好自身工作的时候，多为后人着想。
JAVA项目环境构建自动化及部署优化
java项目全新部署发布优化，让原来的TOMCAT升级从以天为单位到以分钟为单位，百倍效率提升。一键打通环境搭建到项目部署全流程。
全业务配置全自动生成
全业务配置文件一键生成，原来的手工逐条修改成为过去，所有配置采用template一键刷新。百倍效率提升，从根本上避免长尾业务维护成本指数上涨的隐患，旧环境的配置不可维护的情况成为过去时。
DB结构优化
针对DB库上百 G容量，虽然历时弥久，但运维同学并没有停留于“常态”，而是针对历史数据深入挖掘，全库扫表追踪数据增长点，技术库表拆分优化，最终为业务实现80%容量优化，每次为业务更新节省70%的发布时长。
四、一些反思
本次迁移虽然事先对迁移的难度有心理预期，但具体实施过程暴露出来的诸多问题还是很出意外，主要有如下四个维度。
（1）低估迁移项目复杂度
生产环境配置紊乱，可参考文档少；
项目复杂： 20+ JAVA项目，40+ PHP项目；
环境混乱，无人知晓环境部署方式；
近30%的机器无人认领，为数众多的项目无对应负责人；
（2）资源不足
运维人员迭代较快，WIKI文档断档严重；
项目负责人刚入司3个月，对业务的了解度严重欠缺。
JAVA几乎全部人力被抽离支持新项目，老项目仅留1人支持。更严重的是
a. 所有项目的排期以月为单位，即需求30天后排期
b. 手头一堆知道的和不知道的项目，自己手头有哪些项目自己也不清楚
c. “不知道” “不懂” “我得去看代码” ，已然是整个项目是出现频率最高的词汇。
（3）流程繁杂
机房迁移涉及多部门协作，但各部门初次合作无成熟规章制度，流程规范
流程冗杂
自动化程度及交付率低，不支持提交付质量和自定义
（4）大型项目经验欠缺
迁移规划欠缺细节和全面规划，主要如下三个方面：
缺少突发事件的时间冗余规划
缺少具体工作项的实际操作，这也导致时间估算不准的罪魁祸首
缺少周边支持部门的不可控因素的时间冗余规划
迁移初期的迁移方案规划如下
五、特别鸣谢
机房迁移不仅对运维来讲是职业生涯一项极为庞大的项目，相对大家更是如此，没有大家的鼎力支持更是不可能成功。正是因为大家的共同付出，才让我们完成了一项原本不可能完成的任务。这里也请允许我代表运维同学向测试团队、开发团队、集团IT、信息安全表示万分感谢，同时也要感谢团队内小伙伴对我的鼎力支持、感谢XX的无偿支持。
感谢测试同学！没有测试同学详实有效的测试结果，一轮不行再来一轮，平时工作忙时间不够，周末加班测试，测试同学的辛苦大家看在眼里。
感谢开发同学！没有开发同学的手把手调试排查问题，数万行代码的逐条梳理，就不会完整有效的文档列表让运维同学省去海量精力排查确认，开发同学的辛苦大家看在眼里。
感谢集团IT同学！没有集团IT同学的一对一服务，就不会有数十台服务器的快速交付，更不会有回炉重构的快速响应，SLA在你们身上体现的淋漓尽致，集团IT同学的辛苦大家看在眼里
感谢信息安全同学！没有信息安全同学的安全护航同时大力支持，业务侧多达50条OA单据的流程走完可能都需要3个月，信息安全同学的辛苦大家看在眼里。
感谢团队的小伙伴们！在我独自一人战斗到无力时，义不容辞的放下手头工作全力支持机房迁移工作，尽最大努力保障迁移进度的不逾期！
感谢领导的大力支持，XX总、XX总在业务测试关键逻辑阶段，不仅全力支持帮助调动公司资源进行资金支持，更是自筹资金全力支持！！
感谢各位，没有各位的全力支持，没有一起全力以赴的团队伙伴们，机房迁移不可能成功，我们更不可能完成一件预期不可能的事情。感谢各位，成功属于大家！谢谢