第五章 | 运维的未来
DevOps的出现相对于瀑布开发模式，敏捷开发过程的一个基本原则就是以更快的频率交付最小化可用的软件。高频率的部署，每天数百个版本的发布，经常会由于运维部署自动化程度的不足，导致部署任务堆积在运维人员的面前。
对于研发人员而言，线上服务运行环境对其属于黑盒，研发、测试和上线时的行为不一致，研发和运维之间的沟通错位，会造成各种部署问题。
为了解决传统意义上的研发行为和运维行为存在的脱节现象，提高持续交付的效率，DevOps的理念应运而生。为了适用与DevOps相关的快速部署节奏，ITIL流程的很多方面，特别是围绕着变更、配置和发布流程方面，需要将所有过程尽量自动化起来。
伴随着DevOps的理念，涌现出一批优秀的开源软件，比如Jekins、Puppet、Chef、SaltSatck、Docker等。Jekins属于持续集成的自动化构建工具；Puppet、Chef、SaltStack属于配置管理和任务执行类工具，方便我们快速同步变更到所需要的环境中。
Docker是近两年来最火的开源项目，它在Cgroup、LXC基础之上封装，基于Linux内核支持的NameSpace进行资源隔离，实现了进程级虚拟化。
早期我们考虑服务整体部署的时候，抽象认为每台服务器类似一个终端设备，每个需要被部署的服务是其上安装运行的App应用。为了达到服务整体部署，不破坏系统纯净的环境，我们制定了一系列部署要求。比如，要求服务所依赖的相关组件自包含、自解决；制定线上目录规范，进行环境隔离；要求所有服务必须有统一的启停接口，方便运维人员或系统进行控制管理等。
在Docker出现后，这些部署需要考虑的前置条件都迎刃而解，Docker逐渐成为我们整个运维体系中一个不可或缺的关键组件，也是部署自动化、动态调度部署的前提。
研发人员通过Docker进行服务封装，能够很方便地在开发、测试和线上环境中部署运行服务，达到部署行为的幂等。在此过程中，运维人员不需要过多的参与，只需要把Docker容器放置在合适的地方启动即可；在有IaaS、PaaS或者自有调度系统支持的情况下，甚至部署Docker容器、启动容器和监控服务的工作都可以由系统自动完成，整个部署工作不需要运维人员参与。
云服务的普及近些年来，随着云服务概念的普及、云服务厂商的持续投入、技术的不断发展，云服务的单位成本在持续下降，云服务已经成为一种不可阻挡的趋势。这给传统的IT建设理念，造成了一定的冲击。
传统的应用部署，需要兼顾应用程序、数据、运行时环境、中间层、操作系统、虚拟化、服务器、存储、网络等很多方面，单位建设成本和维护成本很高，同时对专业人才的需求更多、要求更高，无形中增加了业务运行的成本支出。图5-1描述了传统IT建设和IaaS、PaaS所关注的不同层次。
640?wx_fmt=png&wxfrom=5&wx_lazy=1图5-1 传统IT和IaaS、PaaS方面的对比
IaaS（基础设施即服务），在传统应用部署的基础上，将OS以下的层次都负责起来，即操作系统、资源虚拟化、服务器、存储、网络，减少运维工作量；OpenStack作为领先的开源解决方案，也是我们运维体系建设的重要方向之一。提供商业服务的AWS，也是属于IaaS平台典型的代表。
安全问题是影响我们使用云服务的关键因素，和传统运维不一样，网络设备、宿主机等资源的权限都在云服务厂商手里，网络流量的出入也需要经过他们的设备，云服务厂商自身的安全规范和审计还比较薄弱。
随着HTTPS的大量使用、VPC的成熟、云服务厂商自身安全加固等，这些安全因素也在逐渐减小。当然，由于所有用户使用虚拟机共享宿主机，虚拟机被攻陷获取宿主机的安全问题还依然存在，比如2015年5月份披露的毒液漏洞（VENOM，CVE编号CVE-2015-3456），攻击者可以在有问题的虚拟机中进行逃逸，获取宿主机代码执行的权限。
现在也有一些云服务厂商，比如金山云也提供了混合云的服务，我们可以把非关键服务部署在云服务上，把关键服务部署在物理环境中，由我们控制物理设备的权限，通过公网或者私有专线进行通信，缓解云服务暂时还不能满足的安全需求。
云服务的出现，我们不需要再关注OS层面以下的问题。随着云服务的逐渐成熟，能够提供足够的资源储备和交付效率，我们不需要投入大量的人力在机房建设、服务器采购和网络管理方面，也不需要储备更多的资源应对突发业务、网络攻击等。对于公司而言，资源得到进一步优化，不需要那么多的基础运维人员，而且效率比以往更高了。
PaaS（平台即服务），在传统应用部署的基础上，将应用的运行时环境、中间层通过规范化的方式给管理起来，并实现容量的自动伸缩。本质上，PaaS是作为一种应用部署的规范，并通过相应的机制来保障该规范的实施，以及进一步地实现资源的动态调度，达到容量自动伸缩的目的。
CloudFoundry属于开源PaaS平台的典型代表，只要研发程序遵从一定的约束条件，服务的运行发布、扩容和故障容灾都由PaaS平台统一负责。PaaS由于具有强约束性，主要适用于简单业务，但不能满足比较复杂的业务架构。
我们可以根据PaaS的特性，通过Docker容器将业务进行封装，使业务达到可随意部署和资源隔离的程度，并参考Borg的设计思路定制动态调度系统，通过系统调度服务的部署和监控，减少对应用运维人员的依赖。
云服务厂商还会提供其他各种类SaaS（软件即服务）的服务，比如CloudWatch、EMR（Elastic MapReduce）、RDS（Relational Database Service）、CloudFront等，进一步降低对运维人员的依赖，运维人员不需要搭建和运维相关的基础设施或服务。
比如RDS提供丰富的数据库主从搭建、数据迁移、慢查询监控等功能，不需要数据库运维人员投入过多精力在数据库日常运维方面，可以把更过的精力投入在数据库设计和优化方面。StatHat属于SaaS类的云监控服务，我们自研的监控系统是参考它设计的。
网络虚拟化在传统网络架构中心，根据业务需求部署后，如果发生任何变更，都需要重新修改网络设备（如交换机、防火墙）的配置。这是一个非常痛苦的过程，并且不同品牌网络设备的OS都各不相同，统一配置的难度可想而知。
在移动互联网瞬息万变的今天，高稳定和高性能的网络已经不足以支持业务的需求，灵活性和敏捷性更为关键。传统网络模式的问题在于它的封闭性和自治性很难与应用直接产生关系。
随着SDN（Software Defined Network）技术的成熟，可以让其变得更轻而易举。SDN提出将控制层面和数据层面分离，通过集中或分布式控制器统一管控，通过OpenFlow协议提供网络的可编程能力，让用户可以在网络上定义各种应用程序，通过软件来定义逻辑上的网络拓扑，以满足对网络资源的不同需求，而无须关心底层网络的物理拓扑结构。在未来，也许网络设备也类似一台台服务器，由软件控制和管理，不需要过多依赖网络运维人员。
总结运维的未来是充满危机和挑战的，从当前虚拟化和云计算的发展趋势来看，未来的互联网服务一定是依托在云端。通过云服务厂商提供的各类服务组件，结合DevOps的理念，将运维所涉及的工作串联起来、自动化起来。
运维人员的工作逐渐由体力密集型向脑力密集型转变，不再需要大量的运维人员从事那些基础建设、服务变更、故障处理等烦琐的体力工作。
运维工作更大的方向是提供平台化的运维产品，提供运维数据的可视化、运维工作的自动化，由操作、响应类转变为优化、规划类的工作内容。甚至连传统的硬件设备管理，也逐渐地通过软件层面去实现，更加的高效和自动化。
本文转自 tianya1993 51CTO博客，原文链接：http://blog.51cto.com/dreamlinux/1859997，如需转载请自行联系原作者
作为运维人员，已经不能和以前一样，只关注某个产品、某个领域的专业技能运维，我们需要关注技术的变化趋势，拥抱变化，做好运维转型，成为云服务建设或使用的专家，成为业务规划或性能优化的专家，或许……
