作者：Jason
一、DevOps的起源和发展历程
在过去的几十年里，为了按时交付软件产品和服务，大家越来越意识到，对于传统把开发和运营割裂开的做法，不适合现代产品和服务开发的需求。于是，把开发和运营作为整体来看待的DevOps工程思想逐步深入人心，随之也逐步有了对DevOps系统的需求，希望能有个平台或工具来统一支持开发和运营的交付工作及之后的环境管理工作，即需要一系列的持续集成，持续交付，自动化部署，自动化测试监控，自动化伸缩，自动化恢复系统，以提升开发测试运营过程中的部署效率，简化开发测试运维过程的管理，降低交付风险，降低沟通成本及运营成本。
从广义来讲，不管是云管理平台工具(比如RightScale)，还是各种PaaS平台(CloudFoundry，Heroku etc.)，还是自动化部署工具比如Chef、Puppet和Ansible等，其本质上都是DevOps系统的一部分，都是为了解决在开发过程的交付环节问题和交付后的运营管理问题，即
- 在开发和测试过程中，帮助开发测试人员搭建和管理环境，以便在变更后部署变更以测试;
- 在运营和支持过程中，帮助运营支持人员升级系统，扩展重建恢复系统，在升级后能够持续地掌握系统整体和各个栈的状态，从各个层面监控系统，伸缩系统，恢复系统。
这些年，随着云计算和容器技术的进步，以及产品业务对IT能力的需求推动，DevOps系统发展越来越快，其角色和概念也越来越清晰和独立。回顾其发展的路径和变迁的过程，我们认为基本可以分为三代：基于物理机或独立虚拟机的部署时代，基于IaaS可编程资源的部署时代和基于容器的部署时代。随着这三代的改进，DevOps系统的整体能力越来越强。下面我们首先看一下各代DevOps系统的特点和能力，之后再对DevOps系统进行更进一步的分类，以帮助我们选择合适的DevOps系统。
二、DevOps的变迁及其关键使能技术
1. 基于物理机/独立虚机的部署时代
这是第一代DevOps系统，特点是静态配置 + 人工协调 + 仅应用部分自动部署。
在搭建整个应用系统的过程中，首先需要在DevOps系统外创建运行应用所需的资源环境(如主机，网络，存储等)，DevOps系统对这部分没有控制，只负责在资源环境搭建好后自动化部署应用，资源环境的搭建与之后的应用部署过程是割裂开来的，需要人为的手工协调控制，即等资源环境搭建好后，由人控制时机，等待资源环境准备好后再手工修改配置（如各种主机IP地址，登陆密码Key信息），然后手工运行自动化脚本工具，如Shell，Python，Ruby脚本，进行应用的安装部署升级，而且之后当增加或减少节点后，也由人来手工运行自动化脚本来配置系统，不能实现包括资源环境创建或节点变更到应用部署的整个过程的一键部署，即集群感知 + 自动协调控制 + 动态配置 + 全栈自动化。
目前，可以说大多数的DevOps系统仍然停留在这个阶段，由于DevOps系统没有实现资源环境创建的自动化与基于集群感知的协调自动化，那么这个阶段的DevOps系统的能力会造成以下几个影响和后果:
- 创建系统资源环境效率低、耗时、风险高，特别是创建复杂的系统组件多结构复杂时;
- 创建系统资源环境过程需要专门的网络工程师、系统工程师，不能够实现开发测试运维人员自助服务，系统越复杂，沟通成本越大，开发运维过程管理也越复杂;
- 创建整个系统需要网络工程师，系统工程师，开发人员的共同参与和合作，系统组件越多结构越复杂，沟通成本越大，开发运维过程管理也越复杂，费时费力，协调麻烦，风险高且易出错;
- 当系统资源环境变更时，如在增加减少主机后，由人来手工协调控制，人为手工静态配置部署升级所需IP，登陆密码或Key等信息，造成变更过程风险高且效率低，特别是系统庞大和复杂时;
- 交付过程风险高，开发测试产品各个环境不统一，经常出现在一个环境里运行正常，另外一个环境不正常的现象
这里需要提的一点就是，尽管很多组织已经在使用IaaS（如阿里云）创建虚拟机搭建应用系统所需资源环境，但是并没有实现集群感知，系统整套环境创建的自动化，仍然停留在半自动化的阶段（例如，先启动一组包年包月虚拟机后，然后手工配置部署脚本所需IP地址，登陆密码，登陆密钥等信息，然后手工运行自动化脚本部署），所以这种方式仍然属于第一代的DevOps系统。同时，这也是国内大多数组织DevOps的现状，其自动化和效率的改进空间巨大。
2. 基于IaaS的部署时代
这是第二代DevOps系统，特点是集群感知 + 自动协调控制 + 动态配置 + 全栈自动化。
借助于云计算IaaS资源的可编程特性，这一代的DevOps系统实现了集群感知，自动协调控制，动态配置，全栈自动化，即实现了从创建环境到部署安装应用组件整个过程的一键创建和部署，并且在创建后的阶段，能够实现集群感知(Cluster-Aware)，即自动根据环境的变更，自动部署和配置系统。举个例子，某网站业务量增长需要扩容时，当人为添加Web计算节点后，能够自动在新添加Web虚拟机启动后安装Web组件，并将各个虚拟机Web服务注册配置到负载均衡服务中，当收缩时，自动移除，这个过程不需要人为的协调控制，DevOps系统能够根据集群的变化自动地配置集群。
目前，做到这个层面DevOps系统还是比较少的，由于这个阶段的DevOps系统自动化管理覆盖了环境的创建变更，应用组件部署自动化，以及环境创建，集群感知和应用组件部署的各个过程自动化协调控制，那么这个阶段的DevOps系统相比第一代会给开发和运维工作带来以下非常巨大的改进:
- 开发测试运维人员能够自助创建环境和部署系统，系统越复杂，沟通成本减少越多，开发运维过程管理复杂性风险减少越多，比如只能由有专门知识的工程师做，如果工程师在需要的时候不可用，就很麻烦;
- 创建环境和部署效率高，自动化，快速，所需时间少，风险低;
- 当系统资源环境变更时，如伸缩时，在增加减少主机后，能够实现集群感知，动态配置集群，提高变更过程效率且降低风险，特别是系统组件多庞大和复杂时;
- 能够按需快速创建环境满足各种测试，演示，上线扩容需要
- 能够按需创建启动关闭开发测试环境，节约成本
- 能够提高开发测试和交付的效率
3. 基于容器的部署时代
这是第三代DevOps系统，特点是在第二代基础上，又增加了应用跨云可迁移性。(基于容器技术)。
借助于云计算IaaS资源的可编程特性以及Linux容器技术，不仅实现了集群感知，自动化协调，动态配置和全栈自动化，而且实现了应用跨云可迁移性和弹性伸缩，消除了开发，测试，生产环境的不一致，使应用不会被锁定在某个IaaS上，让所有的基础设施服务IaaS及物理机都变成通用的资源池，还可以提高资源利用率，这给IT的开发建设和运营带来了更多更大的想象空间，这也是Docker，Kubernetes现在很火的原因。
举个例子: 如果我们想把一套服务从AWS迁移到Azure上，那么，我们将不得不从头开始创建一组虚拟机镜像及虚拟机，并配置安装系统或应用的组件，如果系统复杂庞大的话，这个过程仍然会耗费很多的时间和人工，并且依赖于某些具备这个知识的工程师，但是如果有容器技术及相关容器工具的支持，那么这个过程会变成一个非常快速简单的过程，变成在目标云如Azure上自动启动需要的标准虚拟机，然后下载容器镜像，配置启动容器，配置相关DNS等，真正实现方便的跨云迁移，和弹性动态的伸缩服务。
再举个例子，目前Google开源的容器管理系统Kubernetes可以说得到了工业界的广泛认同和支持，当我们已经做好应用系统的Docker images后，那么只要在各个不同的IaaS上有支持Docker的环境，如Kubernetes集群，那么我们就能在不同的IaaS上快速方便的迁移应用系统，或者扩容，下图展示了基于FIT2CLOUD的跨云部署和管理解决方案，我们希望未来用户可以使用FIT2CLOUD在多个不同的IaaS上创建Kubernetes集群，通过Kubernetes管理和部署应用系统。之后，我们会有新文章来分享FIT2CLOUD是如何创建和运维Kunerbetes集群的。
上面这一节中我们介绍了不同时代的DevOps系统的特点和能力，那么是不是我们直接选择能力最强的第三代DevOps系统就可以了吗? 是不是选一种DevOps系统就通杀了呢? 答案是否定的，每种DevOps系统都不是银弹，都需要我们根据要管理的系统的需求来选择合适的DevOps系统或工具，在接下来的一节，我们来回答这个问题。
三、如何选择适合自己的DevOps系统？
目前DevOps系统可以说五花八门非常多，功能上差别大，适用场景也不同，那么我们究竟该如何选择合适的DevOps系统呢? 这里我们建议一种基于目标系统分类的选择方法。我们根据要管理的目标应用或系统类型来分类，对于目标系统，我们可以将其首先分为三大类，即IaaS服务系统，PaaS服务系统，应用系统，应用系统又可以分为简单的Web应用系统，复杂的分布式系统，那么有了这个分类，我们选择DevOps系统和工具就会相对容易和明确一些。
1. IaaS服务系统
由于IaaS系统的创建，本身就是基于物理机创建的，所以对于这类的系统，其适用的DevOps系统或工具就是Shell，Chef， Puppet及IaaS服务提供商自身开发的自动化运维管理系统，只能选用第一代的基于物理机的DevOps系统。
2. PaaS服务系统
如果一个PaaS不是部署在IaaS之上，从本质上说这不是一个PaaS，因为其不具备弹性和自动伸缩。真正的PaaS系统是部署在IaaS上，为开发测试运维人员来提供服务，那么其适用的DevOps工具就可以选用RightScale，Scalr，Cloudformation，Opsworks和FIT2CLOUD这类第二代基于IaaS可编程资源的DevOps系统，当然也可以选择第三代基于容器的DevOps系统，只是第三代的目前还在发展中，还不如第二代成熟。
3. 简单的Web应用系统
对于简单的Web应用系统，突出的特点就是应用的结构简单，比如只包含一个Web组件及数据库，缓存，或一些常见的中间件服务等，没有包含非常多的分布式组件，那么对于这类的系统可以选择容器类的传统PaaS，即CloudFoundry，Heroku，OpenShift等。
4. 复杂的分布式应用系统
对于复杂的分布式应用系统，无法使用容器类PaaS来管理，只能通过自定义的DevOps工具或系统，或者使用云管理RightScale，Scalr，Cloudformation，Opsworks，FIT2CLOUD这类工具的某种或某种组合，即第二代基于IaaS可编程资源的DevOps系统，也可以选择第三代基于容器的DevOps系统。因为这类工具给用户提供了对IaaS主机更大的控制权，且提供了各个部署过程中的回调接口，实现了集群感知及各个部署过程的自动协调控制，即全栈自动化。
以上是我们对DevOps系统变迁的一些思考，大家通过微博和我们进行讨论，我们的微博是：@fit2cloud。