前言：自从发布上一篇文章《互联网运维新时代》（http://dwz.cn/5KaCVv）已经快一个月了，其中文中也提到新一代运维必须迎合’DevOps’，而’DevOps’在企业内部的成功实施也会取决于三个要素：理念＋自动化工具＋人。前两者比较好理解，无非就是想法与工具实践，而整个环节中最重要的应该是人，在这个过程中，究竟需要怎样的人以及如何实施，才能最终将DevOps理念所倡导的文化实施到自动化工具中，所以人（Opser）才是运维开发一体化成功的决定性因素。而人其实是三个要素中最难搞明白的，不像理念和自动化工具，认真读几本相关的书就可以大概懂产品要如何做，最终做成怎样。在人这个环节，我们需要考虑更多，包括业务架构设计，IT基础架构设计，流程管控，风险管控，个人目标以及时间管理等等。这个过程中的确是很耗费脑细胞的，我不得不承认，去思考一个工程或者想办法优化工程体系远远比单纯码代码要复杂和难的多。
其实我个人挺懒的，虽然在JDJR这两年不论是在技术还是思路上我都学到很多东西，而且在别人说到相关的东西也立马能够心领神会（原谅前面有点夸张），but，我仍然不能够将自己熟悉的技术理论以及一些运维理念流程之类的东西很自然的结合到一个整体。我总结了下，原因是太懒，没有将平时的所学所感所悟进行系统性梳理和结合。然而，任何事物，如果我们只是单纯的去执行，不去思考深层次的东西或者站在工程学角度去系统思考的话，那么最终我们也将会遇到瓶颈，而作为一个运维人来说，我觉得这点尤其重要。So，即使比coding难很多，我还是打算好好梳理下。
来PE（应用运维）团队接触的第一个大项目可以算是大规模业务项目机房迁移了。背景大概是由于网络架构改造，当时所有金融的在线业务都需要平滑迁移到另外一个机房。（没办法，赶上了移动互联网的大浪潮，业务发展也是节节升高，考虑到未来的发展，网络架构调整实在是一个明智的规划）。业务机房迁移其实说起来很好理解，简单点说就是将业务迁移到另外一个机房的应用服务器上去，然而操作起来并不是那么简单的，至于多复杂，很多辛酸泪就不说了，反正整个迁移从项目开始到最终结束大概经历了一年半的时间，当然这些不是重点，重点是在这整个迁移过程中我学到了哪些，作为一个运维人（Opser）应该如何去支持并帮助应用业务项目实现价值。
基本上业务迁移项目快完结的时候就开始接手公司内部的分布式键/值存储系统（主要是当时待迁移的业务属于非标应用，研发部门迁移成本比较大，况且当时我们已经把迁移需要的准备工作都已完成，如果继续将大部分精力投入该项目，时间成本以及精力成本将会很大）。公司上一代分布式键/值存储系统是基于Redis 2.8使用一致性hash算法构建的K/V存储系统，在维护期间深入学习了Redis相关的知识，包括各种使用场景的使用方式，troubleshooting，甚至底层系统的相关内核调优等工作（很遗憾的是Redis的源码没有看太多）。好的架构总是不断演进而来的，Redis 3.0以前的版本是不支持集群模式的，但是业界总是能搞出一些工具系统去支撑业务的高吞吐、高并发请求，实现分布式存储，比如由Twtter开源的Twemproxy,豌豆荚开源Codis，搜狐视频开源的CacheCloud。当然啦，使用外部代理的方式总会有些许问题，比如通过代理后的性能问题，数据一致性的问题等等（感觉自己说了一句废话，因为没有完美的解决方案，总会有些许问题的），So，Redis 3+之后的版本增加了集群模式（相当于在存储层面多了一层slot用来进行数据管理，使用Raft协议来保持一致性），而公司内部正好有大神在做基于Redis 3+ 的分布式弹性K/V存储。由于老系统在金融业务使用过程中的种种弊端，最终通过综合对比决定将目前业务在使用的Redis集群迁移到内部大神们构建的基于Redis 3+的分布式弹性K/V存储系统R2M上。（其实当时个人考虑最多的是运维成本，毕竟之前那种代理方式运维工具太不友好了，而Redis Cluster中内部集成了运维管理工具，再加上当时对比Redis代理集群模式和Cluster集群模式的性能测试并没有发现什么差异，就向领导申请将业务使用的Redis迁移新集群平台上，主要是想在精神上有满满的支持）。紧接着就是持续了大半年的Redis迁移，Redis迁移不像业务应用迁移那样，毕竟是用来存数据用的，秒级的失误也是可能导致业务可用率下降的，当时迁移也是经常在半夜里进行，不过后来随着工具的完善以及经验的丰富，迁移进度和迁移时间也都很随意了（迁移这件事肯定不能随意），只要研发确定好时间随时可以迁移，截至去年618（全职维护分布式K/V存储R2M的最后一个月），整个R2M平台已经将大部分老系统的业务迁移过来，并承载了金融大部分的业务系统。在维护整个分布式K/V存储系统期间其实也是我成长最快的阶段，因为从开始的业务应用项目的维护到基础平台项目的维护过程中需要转变和学习的东西还是蛮多的，个人总结大概以下几点：
去年618结束之后，分布式k/v存储系统R2M基本上已经可以平稳支撑各个业务系统，当然R2M平台未来还是需要不断改进的，包括业务支持，事实证明这大半年搞R2M那帮大神和当时我交接运维的那些同事都是相当牛逼的，我离开之后就去搞docker了，而他们在精细化运营的道路上一直探索着，并且稳定度过11.11和各个大促。
我开始搞Docker是一个很机缘巧合的过程，618过后正值有个业务系统想尝试使用Docker的特性进行构建业务系统，虽然当时Docker也炒的比较火，但是对于我们内部来说还是比较未知，比较新的一个东西。之后我便接下来这个项目去研究Docker相关的技术，不可不说的是Docker用于生产环境还是蛮复杂的，因为里面需要考虑到很多相关的东西，包括底层操作系统，网络，Docker的存储驱动选型，数据卷存储，容器的编排调度以及生命周期管理，监控以及日志等等。另外一个要说的是，Docker真的有多的优势，在使用Docker的同时一定要想清楚要解决什么问题，结合业务场景去选择Docker的某一种技术选型，以业务支撑的角度去做docker选型而不是以Docker技术本身去做技术选型。幸而那个业务比较简单规模也比较小，基本上两个月就上线了（虽然后期也不断出现一些问题，但总是会有办法去解决改造的），后期就是正常的业务升级以及维护了。由于该项目比较特殊，当时无法使用我们生产的部署系统进行快速的变更管理，初期靠人工进行维护变更。然而后期在不断的学习中引入的各种自动化工具进行变更管理。在负责整个业务项目中，相当于是从底层操作系统，到最上层的应用我都全部接手了一遍，说实话从底层完整的支撑一个业务系统让我学到并且思考了更多的东西。
现在，我依然负责部分的业务运维，上面那个Docker项目我也依然在维护支持，但是目前更多的是研究Docker相关的技术，也有其他团队在一起努力做这件事，最终实现基于Docker的CI/CD整个流程、基于Docker的标准化应用支持（包括编排调度）、企业内部的多功能镜像仓库（App Store）。关于目前Docker相关的一些感悟和思考，实在是太多了，也许等过一段时间再总结起来收获会更多，因为整个过程中需要考虑和关注的点更多，我还在继续前行，继续努力探索，期待未来分享的那天。
