作者： 刘涛，FIT2CLOUD联合创始人 & 技术总监。
前言
最近Puppet和RightScale相继发布了DevOps 2016报告，其中Puppet的报告侧重于DevOps的价值ROI的调查结果，用调查结果佐证了DevOps给企业研发生产力和质量带来大幅的提升。RightScale的报告则侧重于DevOps的接受度和DevOps工具的采纳使用情况，特别是Docker的采纳接受度，结论是Chef和Puppet依然是最常用的DevOps工具，Docker接受度出现大跃进，对Docker的接受呈现出野火燎原般的发展趋势。但是对于RightScale给出的DevOps的工具的调查，主要局限于传统配置管理工具Chef、Puppet和Docker等工具调查上，仅仅以Chef、Puppet、Docker等来涵盖DevOps的工具采纳上，还是有些局限。
图1 DevOps平台
如今，企业上云使用云已是常态，云计算和容器从基础设施层面进一步解开了研发运维的枷锁，除了传统的配置管理类型诸如Puppet、Chef等DevOps工具，也出现了多种其他类型来源的DevOps工具和解决方案，大多都面向和基于云基础设施和容器以最大限度的提升Dev和Ops的效率，加速业务创新。接下来我就在这里抛砖引玉，谈谈我对DevOps解决方案的理解和看法，和大家共同探讨DevOps解决方案的过去、现在和未来，探讨当前的解决方案，我们需要的是怎样的解决方案，理想中的解决方案，希望能引起大家的思考。
DevOps也和敏捷一样，由文化、实践、方法和工具组成，从理念到落地并非易事，同样也需要工具的支撑，这里我们着重讨论工具层面的方案，先从DevOps的定义入手，从定义上看从最初提出到现在内涵和外延上的变化，然后一起讨论下DevOps解决方案的几种不同来源、类型和特点，从传统静态基础设施到云可编程弹性基础设施时代的变迁，之后谈谈理想和现实，谈谈那些年我们用过的产品、工具和玩具，得到的教训，谈谈当前常见的DevOps解决方案，以及理想和现实的差距。
一、DevOps定义及变化
以下是Wiki上DevOps的定义:
DevOps (a clipped compound of development and operations) is a culture，movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes.It aims at establishing a culture and environment where building，testing，and releasing software can happen rapidly，frequently，and more reliably.
翻译成中文:
DevOps(英文Development和Operations的组合)代表一种文化、运动或实践，强调在软件交付和基础设施变更过程的自动化，以及过程中软件开发人员(Dev)和IT运维技术人员(Ops)之间的合作和沟通。它的目的是构建一种文化和环境使构建、测试、发布软件更加快捷、频繁和可靠。
以上Wiki的定义清晰地阐述了DevOps的目的、要解决的问题以及包含的内容。这个定义的内涵和外延从最初提出到现在还是有变化的，变化的主要点在于基础设施变更(infrastructure changes)这个部分。在最初提出DevOps概念时，在传统静态基础设施时代，由于受限于基础设施的静态局限性，变更基础设施仅指静态的主机虚拟机准备好之后，对应用运行环境主机OS进行的变更配置管理，而在云计算时代，这个部分，不仅仅指应用运行环境OS的配置管理，还涵盖了基础设施云资源生命周期的管理，比如虚拟机等资源的创建释放等。那么接下来，我们一起看一下DevOps解决方案工具链和DevOps工具及解决方案的变迁。
二、DevOps解决方案工具链
以下是Puppet给出的DevOps工具链(5 Pillars of the DevOps Toolchain)
- Version control (GitHub、Mercurial、Perforce、Subversion、Team Foundation Server)
- Continuous integration (Atlassian Bamboo、Go、Jenkins、TeamCity、Travis CI)
- Configuration management (Puppet and others)
- Deployment (Capistrano、MCollective [part of Puppet Enterprise])
- Monitoring (New Relic、Nagios、Splunk、AppDynamics、Loggly、Elastic)
Puppet将DevOps工具链分为5个部分，版本控制、配置管理、持续集成、部署和监控，并给出了每个部分可选的工具。尽管Puppet在Puppet Enterprise里加入了对云服务如AWS的支持，但是从工具链上看，由于没有将Provisioning基础设施自动化和部署后的环境应用管理单列出来，仍处于传统的配置管理思路上。而在基于云的DevOps工具链中，除以上工具外，还引入了环境创建(Provision)以及部署之后的应用生命周期管理部分。以AWS的工具链为例:
图2 AWS DevOps解决方案
我们看到相比传统的DevOps工具链，AWS的DevOps解决方案增加了Provision这个部分，在AWS这个部分有CloudFormation产品，用于基于一个定义的环境模版从无到有完成环境的创建，包括虚拟机、网络、存储、RDS等。
以上我们从DevOps的定义内涵外延以及工具链整体上分析了DevOps解决方案的变化，接下来我们具体分析一下这些内在变化以及这些内在变化给外在DevOps解决方案输出的能力上，给Dev和Ops以及组织在各个场景中效率带来的影响。
三、云时代DevOps解决方案的变迁
DevOps解决方案的核心能力在于规范和自动化，基于规范和自动化就能够为Dev和Ops提供面向各种场景的工具和服务，自内而外极大提升Dev和Ops各自的效率以及之间的协作效率。对于DevOps解决方案的变迁，我们从上面工具链的变化能够看到，在版本控制、持续集成这两个部分没有差别，最关键的变迁在于之后的环境与应用自动化部分:从Configuration Management扩展为Infrastructure Automation，从Application Deployment扩展为Application Lifecycle Management。具体来说就是，从局部仅涵盖静态基础设施手工准备好之后的静态配置管理、应用部署交付，转变为实现了全方位的资源环境动态编排自动化及应用自动化，自动化范围纵向上既涵盖下层资源环境也覆盖上层应用，横向上涵盖面向物理机、虚拟化、公有云、私有云各个基础设施环境资源及应用发布和管理，管理过程范围涵盖资源和应用的整个生命周期。
图3 DevOps解决方案自动化涵盖范围变化
图4 局部自动到全方位自动化
1、从局部自动化到全栈自动化
从局部仅涵盖静态基础设施手工准备好之后的静态配置管理、应用交付，不涵盖资源自动化创建管理，转变为实现了涵盖下层资源环境及上层应用的整体动态编排自动化。
2、从应用局部生命周期到资源应用全生命周期
传统DevOps解决方案仅管理局部，即静态基础设施手工准备好之后的静态配置管理和应用部署交付，没有涉及应用部署后的生命周期管理，如故障恢复，弹性伸缩以及资源管理等，到了基于云的DevOps解决方案，则扩展到包括资源环境在内的资源和应用的全生命周期管理。能够一键创建环境及应用，完成从无资源无环境到包括资源环境应用在内的全栈自动化以及之后的监控、自动化故障恢复及弹性伸缩管理等。这里有必要说明下环境所包含的内容，这里我们所说的环境，不仅仅包含通常的虚拟机、虚拟机承载的OS、OS中安装的运行时环境，还包括中间件、防火墙设置、负载均衡设置、DNS配置等。
3、提供上下文事件驱动编程接口
基于云的DevOps解决方案，往往提供多种事件驱动的接口以可以实现基于手工触发的、时间的、资源变化的、监控变化的事件的自动化处理，从而实现开发运维多种场景的自动化。比如云管理平台Scalr，Scalr能够基于云的API实时了解资源的情况，Scalr提供了虚拟机生命周期事件接口，可以设定当虚拟机创建、重启或释放触发在指定范围的虚拟机执行脚本，借助这个事件驱动编程接口，我们就能实现从无到有创建整个环境并部署应用，也能实现一键扩容时完成虚拟机创建及应用部署，实现自动获取虚拟机IP信息进行动态的应用连接配置，实现自动故障处理等。这个功能能力是衡量诸多DevOps方案的一个非常关键的能力。
4、支持IT资源获取环节的Dev和Ops协作
由于传统物理机虚拟化时代基础设施为静态基础设施、使用审批以及手工创建方式，所以传统的DevOps解决方案并没有覆盖Dev和Ops在资源获取环节的协作。经常出现的问题就是，Dev经常需要等待IT Ops提供资源，并且经常出现沟通的不一致问题，导致在Dev创建环境这一环节往往需要数天甚至数周的时间。到了基于云的DevOps解决方案，由于有了自动化可编程的基础设施，因而能在此基础上提供自服务IT的功能，能够让Dev人员在允许的额度和限制范围内自助获取资源，减少了很多与IT Ops的沟通的时间和问题，也减少IT Ops的工作量。
可以说，以上DevOps解决方案几个方面的变迁对开发测试及运维业务场景的影响上非常大，下面我列了一个表格，比较了开发测试和运维中使用DevOps解决方案能力上的差别。
图5：传统DevOps解决方案和云DevOps解决方案能力比较
以上我们具体分析了DevOps解决方案的变迁和对DevOps能力的影响，当前DevOps解决方案有很多，但是各有各的特点、优缺点和适用的范围，接下来我们看看常见的DevOps解决方案的类型和特点。
四、常见DevOps解决方案的类型和特点
当前DevOps解决方案主要来自于五种类型的公司：云服务提供商、云管理平台公司、传统配置管理类型、Docker公司、大型互联网公司。
图6 DevOps解决方案分类
尽管云计算提供了弹性可编程的基础设施，但是当前的各种DevOps解决方案各有其特点和局限性，同时也均有非常大的改进空间:
- 传统的开源配置管理解决方案：仍然专注于静态基础设施思维下的配置管理，在环境自动化，应用自动化方面均不够好，与各个云的对接支持上，产品化上易用性上均需要提升；比如Puppet，尽管提供Puppet Enterprise解决与云基础设施服务的对接，但是对接上与云管理平台对各个云服务的对接上相比相距甚远；
- 云服务提供商的解决方案：云服务提供商自身提供的DevOps解决方案又多出于锁定用户角度目的设计，仅仅适用于其自身云服务，对其他云各种公有云、私有云以及国内本地云服务缺乏支持；比如AWS提供的DevOps工具，只能在AWS云服务范围内使用，无法在其他公有云私有云和传统虚拟化及物理机环境下使用。
- 传统PaaS：对应用架构有限制和侵入，落地困难，选择时需要明确要管理的应用的架构是否仅为Web类型进行慎重选择。一个事实是，尽管云计算和PaaS发展多年，但是迄今为止，当前大多数上云的应用和平台仍然直接运行在IaaS上，而不是在PaaS上。
- 云管理平台解决方案：在云的对接上往往比较广泛和易用，提供以应用为中心的管理视图，对应用的架构没有限制和侵入，易于落地，但是在应用管理方面支持相对缺乏和单薄，需要基于其提供的事件驱动编程接口设计方案，定制开发，比如Scalr。
- 基于Docker的容器云解决方案：容器云是是目前市场上解决方案最多最热，由于容器的轻量、标准化和可移植性，这一点给应用在异构资源池中的部署提供了统一的标准和接口，相比基于传统虚拟化基础上的DevOps方案，容器云更容易实现在同构异构IT资源池环境中快速部署，发布、迁移、扩展，以及防止供应商锁定，同时能极大地提升资源利用率。容器云是当前和今后的热点，但是对研发运维原有的使用习惯改变不小，需要较全面的支撑工具，当前产品化上仍然不够，使用起来还有有不小的门槛，需要较强的技术能力。还有一点就是，不适用于传统已存在应用和主机的纳管，只能管理通过容器云启动的容器之上的应用。
- 互联网公司解决方案：比较典型的是Netflix开源的Spinnaker。对于Spinnaker，可以借鉴Spinnaker的思路和设计，一个是对部署流水线的过程和可视化支持非常好，另一个是管理的维度分为集群管理和部署管理，对资源以应用为中心进行逻辑上的划分非常直观和清晰和符合管理习惯，但是由于Netflix是重度AWS用户，所以其内部开源出来的和AWS的绑定很深，不太适用于其他公有云、私有云，另外就是作部署前需要先做镜像，这个还是有些重，做镜像非常耗费时间，在集成阶段需要不断修改和获取反馈时不太合适。
五、理想中的DevOps解决方案
尽管时代在发展，各种DevOps工具也一直在发展，但是当我们每天在工作中在使用现有工具，在各种基础设施环境中创建环境和部署管理应用时，仍会遇到很多当前工具没有解决的问题，不适用的场景，导致我们不得不花费很多的时间精力在沟通、靠手工弥补、定制化的开发、解决方案的设计上，即费时又费力，关键是效率很低，浪费了很多可以通过工具来节约的时间。那么我们期待的DevOps解决方案、产品是什么样的？
1、支持各种公有云、私有云及各种基础云资源
看过用过许多DevOps的工具，特别是一些开源的工具，要么不支持与某些云的对接，要么支持多为需要二次开发编程配置，对于云资源和应用的管理，我们需要一个广泛支持各种公有云私有云且易用的工具，能够让我们快速简单的创建环境和部署应用，减少手工二次开发和配置上浪费的时间和不便。
2、支持已有主机应用的纳管
当我们要将DevOps落地时，不可避免的会碰到现有正在开发中项目，对于这些项目，一方面往往主机等资源已存在，应用已部署并在运行中，另一方面，架构基本已定，很难会为DevOps自动化部署进行架构上的调整，对于这种情况而言，对应用架构有要求的，比如需要以微服务架构而基础的，只能管理通过DevOps管理平台启动的主机或容器的方案就不适用了。我们需要一种对应用架构无侵入对已有代码无修改的DevOps管理平台，一种能够对已启动主机进行纳管的平台解决方案，才能够落地。
3、无侵入支持各种架构类型应用和平台
这一点非常重要，DevOps平台首要的就是能够部署和管理应用，且能够易于落地，支持现有的项目、近期的项目实现DevOps，如果对应用的架构上有限制和要求，则很难落地和实施。另外，其实平台本身也是应用，比如云平台本身、PaaS平台、容器云同样也需要管理，如果管理平台也支持物理机或虚拟机之上的这些平台本身的管理，这样的管理平台DevOps解决方案无疑是最强大的。
4、开发的平台
- 提供事件驱动可编程接口，能够手动按需、定时、基于监控、基于代码变化、API进行响应自动化处理;
- 提供云平台支持可扩展接口，能够以插件方式支持各种不同的云; - 提供HTTP API扩展接口，能够基于API进行扩展和集成。
5、产品化且易用
看过用过需要DevOps的工具，特别是一些开源的工具，灵活性和扩展性都不错，但是在易用性上，学习和使用的门槛上，还是有很大欠缺，如果能够更加易用些、更加产品化一些将能节省更多的时间，让更多的人更快地用起来。
6、一体化的平台
在研发和运维的过程中，不仅仅需要快速可靠部署的发布，还需要对业务系统整个生命周期的管理，包括资源环境信息、分组分类、环境管理、权限管理、部署发布管理、批量管理、告警监控、伸缩管理等，希望能有这样比较全面的管理平台，而不用再东拼西凑拼接解决方案，再花费精力二次开发打通各个管理工具。
7、支持全方位的自动化编排
企业在上云的过程中，我们的业务系统，应用分布在传统数据中心和私有云、公有云中，希望能够一个DevOps平台在纵向支持下层资源和上层应用的全栈自动化编排，横向上能够支持跨传统DC、私有云、公有云的任务编排，包括对资源任务、对脚本任务、对部署任务的编排，这将使得我们能够在很多场景如灾难备份恢复、扩容缩容、部署升级发布，极大地提升自动化的程度和效率。
8、支持通用易用易于落地部署规范
如果有一套通用易用易于学习落地的部署规范，则DevOps的落地，在组织范围层面的落地会变的更容易一些。
图7 理想中的DevOps解决方案
六、总结
云计算从基础设施层面实现了敏捷IT，进一步解开了研发运维的枷锁，使得DevOps解决方案也有了长足的发展，使得其所能提供的DevOps能力有了一个飞跃，实现了涵盖资源环境在内的应用全栈自动化，并基于强大的自动化能力，基于事件驱动的环境创建管理自动化、应用生命周期管理自动化，为开发测试和运维各个场景提供高效的管理工具，比如一键编排创建开发测试环境，批量管理、应用部署、自动故障恢复、备份恢复、自动伸缩、自服务IT等，极大地提升了Dev和Ops各自的效率以及在部署发布环节和获取IT资源环节协作的效率，实现了从敏捷IT到敏捷开发再到敏捷运维的端到端的敏捷。然而，尽管云计算和容器提供了非常好的基础设施，但是现有DevOps解决方案在产品功能上、产品化和易用性上仍然有巨大的改进空间，我们需要根据自己的DevOps需求和条件限制选择合适的方案并进行扩展和二次开发。