运维演变之路
概述
运维体系经历了脚本时代、工具时代以及目前的DevOPS时代。另外在未来走向自动化运维和智能化运维时代。
脚本时代是所有公司都会经历的过程，运维工作需要通过脚本来操作，但随着业务扩大和复杂度增加，通过脚本越来越难以完成，所以就引入工具理念，在运维工具时代，通常都会经历从纯粹的工具团队/运维团队并行的阶段，为了更好保障工具质量的在进入到工具团队阶段，再到逐渐由DevOPS思想和只能的偏软件思想的工具团队时代，到后来的应用运维团队全部打散合并到各个BU的软件开发团队中，全面实践DevOPS思想。
运维演变
运维是一种能力而不是一种岗位。研发人员将具备运维自身产品的能力，同时运维人员具备研发能力，技术将不在成为限制业务发展的瓶颈，DevOps带来的效能提升反而能助力业务的构建。
脚本化
应用运维团队，首先要做所有日常运维的工作比如发布、扩容、重启、修改脚本等，另外就是环境维护，比如操作系统升级也是运维来负责。除了这些日常工作还会负责容量管理，比如某个流量大的时期要确定扩容多少。
在这个阶段通过脚本来进行运维工作，写一些单机脚本，数量多而且还有一些批量操作的措施。
这个阶段最容易出问题，复杂的逻辑会非常难实现。比如你的服务器数量多分布在不同城市，通常发布时间窗口并不长，如果发布的应用比较多，你就需要打开很多窗口，最后你自己可能都不知道哪个窗口是更新的那个城市机房的服务器，哪些更新了哪些没更新。因为更新的时候肯定不能全部更新一定是分批进行的，要保证业务可以正常使用。
工具化
工具化非常简单，思想就是通过软件的系统实现复杂操作，复杂操作的本后其实可能是单机上的脚本操作，因为这对运维人员来说便于维护，如果全部程序化就非常难了。
在这个阶段通常会有一个工具团队，专门做运维系统专门做软件层面的开发，同时保留运维团队，运维团队主要负责之前提到的哪些内容。这就意味着工具团队不负责这些具体操作只负责写系统。开始这2个团队是分开的，然而在实际工作中也发现不少问题，工具团队觉得自己做了很多工具，运维应该可以很轻松；运维告诉你其实并不是这样，基本上跟以前差不多。
这里的问题就是运维只是操作方式变化了，变成了点点点只是UI上的区别并没有实质变化，而工具团队也很容易有成就感认为做了很多可是别人不认可。出现这种问题的原因是工具不够完善，工具使用过程中如果工具出现问题运维很难介入，只能让工具团队来解决，在这种情况下还不如手工操作脚本执行这样出现问题自己可以查。
另外如果把运维分成很多团队比如网络、服务器等每个团队都是独立的，他们去开发工具都是按照自己熟悉的语言和架构来编写，这就变成百花齐放什么都有，一出问题各种语言的各种架构的人都要来，生产系统是一个整体框架而运维系统则是一个各自为政的状态。
所以需要对工具团队进行合并。向对待一个研发项目一样去看待运维系统。另外需要要工具团队自己做运维工作，这样就成为一个团队的工作，不存在协调沟通问题。
另外工具化的前提是标准化，目录结构、账号等等，前期一个坑后期需要很多时间和经历去解决。
DevOPS
Google的SRE团队要求50%时间开发50%时间运维，但实际我们做不到因为运维压力太大了还是别做开发了。但谷歌认为如果运维时间超过50%则会把这个压力转到研发团队。那么如何做好这个思想的落地？
决定把整个运维团队拆掉，直接交给研发团队，目标就是日常的运维操作逐步让研发自己去做。但这个前提是，比如说你要把日常的运维操作全部交给这个系统的研发人员去做，意味着需要有一套很高质量标准的运维系统，如果你没有这个系统那研发就要崩溃了，所以这里的挑战是工具化的程度。
因为把这些工作交给了研发团队，所以在这个阶段可以把之前在工具化阶段遇到的问题解决掉。
如何将这种思想落地是一个需要思考的事情，在这里Docker是非常有效的让DevOPS强制落地的方法，因为它有一个DockerFile，生产环境的一台机器的整体环境，可能不是研发独自搭建出来的，有可能是运维做一部分开发做一部分，所以没有一个人请出这儿环境到底是什么。而DockerFile强制描述了这些环境信息，所以这个强制方案可以让DevOPS很好的推进。
自动化
自动化意味着，怎么样让工具中人参与的多个环节直接到没人参与，这实现起来其实非常难。
比如发布，发布时运维中最常发生的变更，一个发布动作怎么做到没有人？为什么很难？比如发布完一台机器之后重启了，你怎么知道重启完应用到底是否正常，这个标准很难去确定。
另外做到无人值守还会需要做到架构层面的支撑比如机房流量一键切换如果各个系统不具备这个能力，整个架构也不会具备。
智能化
智能运维、智能化的前提是需要有大量的数据收集，如果没有足够的数据和经验是难道做到自动化的，因为智能化的前提是就是自动化。
目前的自动化只能做到针对非常强的特征匹配因为毕竟目前很多时候还需要人去判断。只有当你有大量实践经验和准确的数据之后才有可能做到，而且所谓的经验如果不是格式化的就很难学习，还有特征，人工提取的特征意味着是偏向固化的，所以需要机器学习去提取特征。
DevOPS转型不是简单的把工作量从运维转向开发，目的是用研发的手段去改造传统的人工、低水平的运维，真正用工具化、数据化来提升运维。
总结
在运维上，要避免的是开发系统的人不知道这个系统是如何部署和运维的，这样知识不完整。很多系统开发简单，但规模大，部署导致了复杂性，研发部知道这些，对系统认识不够，也就不知道程序设计十分合理。
把日常工作交给研发、让运维同学能有时间去做运维系统的研发。这样研发同学对自己的系统的运行环境更加清楚，增强控制权，自己写的系统自己负责，同时运维也可以建设更好的系统。其实运维工作方式的变化也在倒逼运维人员的转型，如果还停留在人肉上线的阶段那么被时代所淘汰是必然的，目前一二线互联网公司已经没有了人肉上线工作全是开发自己上线运维人员的角色得到了转变同时在这种转变过程汇总能力也得到了提升。不过小型互联网公司还处在脚本和工具化阶段，这个没办法大公司也是这样一步一步走过来的在阿里早期也是这样一台电脑打开N多个shell脚本进行停服务更新服务启动服务的阶段。所以我觉得目前运维转型是一个自我驱动的过程而不是公司推动，因为真的到了公司去推动的时候你已经没有价值了。
