一、DevOps的由来和概念
1、由来
2009年6月：美国圣荷西，第二届Velocity大会上最大的亮点是一个名为“10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”的演讲，可以作为DevOps萌发的标志。这个演讲提出了DevOps的“一个中心，两个基本点”——以业务敏捷为中心，构造适应快速发布软件的工具（Tools）和文化（Culture）。
2009 年 10月，Patrick想通过 Twitter 召集开发工程师和运维工程师在比利时根特举办一个类似于Velocity的大会，会议名称叫做DevOpsDays，取得了出乎意料的成功，然而， DevOpsDays的讨论仍在Twitter上继续着。由于Twitter140个字符的限制，大家在Twitter 上去掉了DevOps中的Days，保留了DevOps。于是，DevOps这个称谓正式诞生。
2010 年：在DevOpsDays之后，DevOps被越来越多的人所熟知并迅速得到了大多数人的认可。人们认为这正是IT部门的正确运作方式，DevOps成为了一种促成开发运维合作的运动。为了统一化DevOps的见解的需要，The Agile Admin博客发表“What is DevOps”， 给出了详细 DevOps 的定义，并且依据敏捷的体系构造出了DevOps的体系: 它包括一系列价值观、原则、方法、实践以及对应的工具。并且梳理了DevOps的历史和对DevOps 的一些误解。
2010 年：《持续交付》的作者Jez Humble参加了第二届的DevOpsDays并做了 “持续交付”的演讲。“持续交付”是“持续集成”的延伸，而这点恰恰和2008年敏捷大会中的观念一致。但由于发生时间的先后关系，“持续交付”被看作是敏捷以及DevOps文化的产物。而今，持续交付仍然被作为DevOps的核心实践之一被广泛谈及。
2、DevOps概念解析
来自不同渠道和来源的定义：
（1）百度百科：DevOps是一组过程、方法与系统的统称，用于促进开发（应用软件和软件工程等）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它的出现时由于软件行业日益清晰地认识到，为了按时交付软件产品和服务，开发团队和运营团队必须紧密合作。
（2）维基百科：DevOps是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。其通过对“软件交付”和“架构变更”的流程进行自动化，使得构建、测试、发布软件更加快捷、频繁和可靠。
（3）Wikipedia：DevOps是软件开发、运维和质量保证三个部门之间的沟通、协作和集成所采用的流程、方法和体系的一个集合。它是人们为了及时生产软件产品或服务，以满足某个业务目标，对开发与运维之间相互依存关系的一种新的理解。 ......DevOps并不仅仅关注软件部署，它是部门间沟通协作的一组流程和方法。
（4）IBM：DevOps是一种软件交付方法，它基于精益和敏捷的软件开发，在需求人员、开发人员、测试人员、运维人员的协同下，保证软件的交付能够基于真实的用户反馈。
（5）CA：DevOps是通过文化、流程、工具的转换和改进以加速软件交付的。
（6）Gartner认为：DevOps代表一种文化的转变，它通过敏捷和精益实践来进行IT服务的快速交付。DevOps寻求开发团队和运维团队进行合作，同时强调利用技术对软件进行改善，尤其是使用工具对软件的整个生命周期的自动化进行改善。
（7）DevOps是一种文化转变，或者说是一个鼓励更好地交流和协作（即团队合作）以便于更快地构建可靠性更高、质量更好的软件的运动。（CloudTechnology Partners公司的副总裁兼首席架构师Mike Kavis）
3、其他摘录
（1）DevOps是软件开发、运维和质量保证三个部门之间的沟通、协作和集成所采用的流程、方法和体系的一个结合，体现了精益管理中的客户价值原则，即以客户的观点来确定企业从设计到生产交付的过程，实现客户需要的最大满足。实现的关键有两点：一是全局观，二是自动化。
（2）DevOps=Culture+Tools，DevOps是一个循环递进的过程，通过文化的指引，打造符合当前组织和文化的相关工具链，固化协作的规范、流程；然后随着工具落地、实践推广，促使组织更快地发展和改进产品，从而进一步加强协作文化和方式。所有未通过工具/平台固化下来的流程规范，如果仅仅依靠文档和意识，当团队迅速扩大时，其腐化速度是超过想象的。
（3）DevOps是对敏捷软件开发和精益生产思想的演进，应用于IT端到端的价值链中，使得业务基于现代信息技术，并通过文化、组织与技术变革来获得更大的成功。实施DevOps可以：缩短市场响应事件、减少技术债务、消除脆弱性。
（4）SRE由Google提出，即Site Reliability Engineering网站可用性工程，SRE团队通过雇佣软件工程师，创造软件系统来维护系统运行以替代传统模型中的人工操作。SRE团队中基本有两类工程师：50%~60%是标准的软件工程师，其他40%~50%是一些基本满足Google软件工程师标准（具备85%~99%所要求的技能），但是同时具有一定程度的其他技术能力的工程师，目前Google最看重的两类额外技术能力是UNIX系统内部细节和1~3层网络知识。
二、DevOps内容相关
正如在由来和概念中提到的，DevOps中非常重要的几个词：敏捷/持续交付、工具、文化。
DevOps核心原则：（1）基础架构即代码（IaC）是企业级DevOps实践的前提提交，即计算基础架构（容器、虚拟机、物理机、代码管理、软件安装等）的管理和供应，需要实现自动化，均可编码并存储至版本控制仓库；（2）持续交付，确保团队可以在任何时间发布可靠的软件，并以更快速度、更高频率进行软件的构建、测试和发布，它包括3个关键实践（度量一切、持续改进；实现自动化；频繁部署）；（3）协同工作，解除开发与运维人员的隔阂，鼓励开发与运维人员的协作，可以通过两个C来实现，即协作（Collaboration）和沟通（Communication）。
支持DevOps运作的三个原理：（1）系统思考，对于开发驱动的组织，其主要责任不是制作软件，而是持续地交付客户价值，而整个价值流速并不依赖单个部门的杰出工作，而是受到整个价值链最薄弱环节的限制；（2）强化反馈环，过程改进常常通过加强和缩短反馈环来完成，没有测量就没有提升，反馈要以测量和数据作为基础，通过反馈数据来优化和改进系统；（3）持续试验和学习的文化，在企业文化层面强调勇于试错和持续试验的文化，让企业内部自发涌现出更多创新和系统提升的反馈环。
DevOps的三步工作法：第一工作法是关于从开发人员到IT运维人员再到客户的整个自左向右的工作流，为了使流量最大化，我们需要较小的批量规模和工作间隔，防止缺陷流向下游工作中心，并且为了整体目标不断进行优化；第二工作法是关于价值流各阶段自右向左的快速持续反馈流，放大其收益以防止问题再次发生，或者更快地发现和修复问题，这样就能在所需之处获取或嵌入只是，从源头上保证质量；第三工作法是关于创造公司文化，该文化可以带动两种风气的形成，不断尝试，这需要承担风险并从成功和失败中吸取经验教训，熟练掌握、理解、重复和练习是熟练掌握的前提。
持续交付1.0：持续交付是一种能力，能够以可持续方式，安全快速地把代码变更（包括特性、配置、缺陷和试验）部署到生产环境上，让用户使用。持续交付2.0，将精益创业与持续交付1.0相结合，强调业务与IT间的快速闭环，以“精益思想”为指导，全面贯彻“识别和消除一切浪费”的理念，通过一系列工作原则和实践，帮助企业以一种可持续方式，高质量、低成本、无风险地快速交付客户价值。持续交付2.0的4个核心工作原则是：坚持少做、持续分解问题、坚持快速反馈和持续改进并衡量。
敏捷运维（DevOps）需要团队之间高度的信任，建立信任的三个技巧：1、不要试图使用技术解决方案来解决文化的问题，文化高于过程；2、当你处于防御的姿态时，是不可能敏捷的；3、很强的领导力是非常重要的，领导力不需要管理授权，你可以成为公司中任何级别的领导。
DevOps主要由三大支柱和一个基础组成：规范敏捷，一支训练有素的敏捷开发团队是成功实施DevOps的关键，规范敏捷意味着三个方面（速度稳定、适应变化、总是能发布优质的无错误代码）；持续交付，是应用程序的构建、部署、测试和发布流程的自动化实施；IT服务管理，当技术成为大多数业务流程的核心环节时，IT服务的连续性和高可用性是业务存亡的关键因素；以TPS（精益管理Lean）理念为基础，包括JIT和自动化，JIT意味着以单件流的方式建立一个流水线式的供应链，而自动化意味着尽可能实现自动化，并且当出现缺陷时能停止整个过程。
DevOps成熟度模型，分为5个阶段：初始阶段，初始状态，手工作业较多，交付流程不稳定；基础阶段，流程标准化开始阶段，部分自动化，结合手工能完成可重复的交付；可靠阶段，整体标准有清晰定义，大部分作业可自动化进行，能够较稳定地提供可预期的交付；成熟阶段，整体过程可度量，结果可视，状态可追踪，数据可分析；优化阶段，全生命周期统一平台管理，基本无手工操作，不断优化完善。
DevOps是一种将同理心带回到我们工作中的方法，而工具可以帮助你做到这一点。同理心指的是和所有的同事建立同理心，而不是仅仅局限于DevOps里的开发和运维两种角色。在工程师和销售人员之间，高管和员工之间同样需要建立同理心，而且组织里的所有部门都应该关注全局优化，而不是只顾自身的局部优化。你需要意识到其他同事可能面临的问题，而不仅仅是那些影响你自己或你所在部门的问题。工具正是带回同理心的一种途径，这对工程师很有吸引力，因为工程师都喜爱工具。
SRE团队要承担以下几类职责：可用性改进、延迟优化、性能优化、效率优化、变更管理、监控、紧急事务处理以及容量规划和管理。SRE几个核心方法论包括：确保长期关注研发工作、在保障服务SLO的前提下最大化迭代速度、监控系统、应急事件处理、变更管理、需求预测与容量规划、效率与性能。
典型的SRE活动包括：（1）软件工程，编写或修改代码，以及所有其他相关的设计和文档工作；（2）系统工程，配置生产系统，修改现存配置，或者用一种通过一次性工作产生持久的改进的方法来书写系统文档；（3）琐事，与运维服务相关的重复性的、手工的劳动；（4）流程负担，与运维服务部直接相关的行政工作，如招聘、团队/公司会议、工作总结、同行评价、培训等。
三、DevOps与其他理论的关系
1、DevOps与微服务
微服务架构是一种基于DevOps的演进式架构，架构师的运维意识是演进式架构的关键；对于服务间的异步通信，复杂场景用消息队列，简单场景使用后台任务系统处理；每个服务都应该有一个内嵌在服务代码库中的自解释文档，包括服务开发与 运维过程的核心信息；新人需要多长时间才能开始贡献代码，这个时间是检验服务粒度粗细与自解释文档完备与否的最好指标。
2、DevOps与ITIL/ITSM
ITSM相关：一个只包含最少必要信息（MRI）、严格聚焦于业务持续性管理（BCM）、可落地的轻量级ITSM，要远远好于贪大求全却无法落地的重量级ITSM；IT要通过可视化、自动化、高可用、准时制（JIT）的单件流流水线持续向业务和客户交付价值；一切自动化是运维的目标，自动化之后的目标是智能运维（AIOps），最终都服务于业务运维；软件定义世界，今后没有运维工程师，只有运维开发工程师，再往后没有运维开发工程师，只有全栈工程师。
在DevOps与ITIL之间存在着根本对立的矛盾。ITIL的两个关键原则之一，是由IT以服务的方式来交付业务价值，服务模式中必不可少的一环是客户与供应商之间的关系，这些关系要求记录在服务级别协议SLA中，包含各方职责。DevOps的主张在很大程度上基于单一团队的概念，包括IT与业务在内，各种角色一起工作，关注长期的成功，而不是短期的胜利，当然更不会关注书面上的协议。团队对失败早已达成一致，一旦失败，他们不会相互问责，而是从自身错误去学习。在极致情况下，IT与业务之间的边界完全消失。
DevOps和ITSM在小的方面也存在分歧：
（1）DevOps的资金以完全不同的方式设置：资金是分配给产品，而不是项目；
（2）长期以来，IT部门的原则是以成本优化为基本原则，DevOps则建议切换到以提高速度为原则；
（3）ITIL定义的变更管理关注于降低风险，通过相当缓慢并且严格的正式流程实现，包含诸多的控制、通知、协议以及审批；DevOps所倡导的变更，则是在伴随自动化测试以及日志自己录的情况下，越快越好；
（4）由于大量通过繁重的手工操作来收集和更新配置信息，ITIL中所描述的配置管理以及配置管理数据库时间中很难实现，而DevOps的配置管理在很大程度上是自动化的并且是强制的；
（5）与ITIL相比，DevOps的发布概念发生了变化，从“发布是一个复杂的、有准备的、测试过的、实时执行的变更”到“新功能对客户可用”
（6）事件管理实践，包括支持业务线的分离以及问题的升级，被DevOps中的另一个原则所取代“谁构建，谁来运行”
（7）问题管理（处理事故根因）在DevOps实践中显得毫无意义：在ITSM中问题管理极具挑战性，在DevOps实践中却并非必要；
（8）ITIL中的容量管理是基于容量计划的极大延伸，应该涵盖对IT资源的所有需求，并且通常与公司每年的预算周期绑定；在DevOps实践中，容量必须在需要的那一刻就绪，不能因为找供应商、签合同、等待交付等事宜而被延误。
四、DevOps相关的工具
全链路全开源的自动化运维工具链：自动化安装，物理服务器上架后使用Cobbler实现操作系统的自动化安装；配置管理，使用Saltstack进行操作系统层面的初始化部署、配置管理；自动化监控，服务上线后使用Zabbix企业级监控平台进行自动化的监控；持续交付，使用Jenkins进行端到端的部署；日志收集，使用ELK进行自动化日志收集、汇总和展示；CMDB，存储所有配置数据；私有云，基于OpenStack构建企业私有云，也可使用salt-cloud进行虚拟机自动化管理；容器云，使用Kubernetes实现企业内部容器云。
实现自动化部署的部署服务工具链，分为三个层面：（1）引导BootStrapping，服务器OS的配置及基于虚拟器的服务器安装自动化的相关工具，如Vagrant、Kickstart、WMWare等；（2）配置Configuration，服务器及中间件的配置自动化工具，如Ansible、Puppet、Chef；（3）业务流程Orchestration，代码部署及发布相关的服务器操作等自动化工具，如Capistrano、Fabric。
持续集成的反模式建议：（1）频繁提交代码，可以防止集成变得复杂；（2）在提交源代码之前运行私有构建，可以避免许多失败的构建；（3）使用各种反馈机制避免开发人员忽视构建状态信息；（4）有针对性地向相关人员发送反馈，这是将构建问题通知团队成员的好方法；（5）购买更强大的构建机器，优化构建过程，从而加快向团队成员提供反馈的速度；（6）避免构建膨胀。
企业应该在工具平台建设方面改变一下思路，通过运用先进的生产技术，使得环境部署、数据统计这一类事务性操作不再依赖专家型人才，而是在每个人在其需要时都能够自助服务，那么每个人都可以流畅地工作，而且专家型人才被打断的次数也会减少。而这也可以利用开发环节暂时过剩的人力来建设工具平台，提升下游的基础能力，使得在不增加测试人力的情况下，永久提升团队整体产能。
参考书籍：
《Devops开发运维训练营》
《DevOps三十六计》
《大规模组织DevOps实践》
《智能运维》
《凤凰项目》
《敏捷无敌之DevOps时代》
《DEVOPS精要：业务视角》
《企业级DevOps技术与工具实战》
《持续交付2.0：业务引领的DevOps精要》
《SRE Google运维揭秘》
《DevOps悖论》