频频出现的DevOps到底是什么呢？浅浅了解下什么是DevOps吧

文章目录

📑前言

🧩DevOps的概念和起源

📰DevOps的概念

📰DevOps的起源与发展

📰总结

🧩DevOps的发展

📰发展过程速览

📰发展现状

📰未来发展

📄以下几方面因素可能促使一个组织引入DevOps：

📄DevOps对应用程序发布的影响

💻参考文章

📑前言

近几年来，即便是在疫情影响下，互联网的发展脚步也未曾停止过，技术更新迭代的速度飞快，因此不断学习是我们应对现状的最好办法。回归主题，那么近几年爆火的DevOps是什么呢，一种方法？一种工具？一种思想？一种开发流程？对此有着层出不穷的说法，那么它到底是什么呢？接下来我们一起来简单了解一下吧。

从以下三个角度入手了解

起源
原理
发展

🧩DevOps的概念和起源

📰DevOps的概念

首先我们先了解一下DevOps这个词是什么意思

DevOps这个词来源于2009年在比利时根特市举办的首届DevOpsDays大会，为了在Twitter上更方便的传播，由DevOpsDays缩写为DevOps。
DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。
它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运维工作必须紧密合作。

📰DevOps的起源与发展

说起DevOps就不得不从DevOps之父——Patrick Debois说起。2007年，Patrick参与了比利时一个政府下属部门的大型数据中心迁移项目。在这个项目中，他分别负责测试和验证的工作。这就意味着他不光有机会和开发团队(Dev)工作，也时常要和运维团队（Ops)工作。在开发团队中，他需要适应敏捷交付的节奏，但在运维团队他又得按照传统模式，像管理消防队员那样维护系统。两种工作氛围的来回切换，令他十分沮丧。不同的工作方式、思维方式势必存在着巨大差异，所以在这两者之间工作，到处都是冲突。作为一个敏捷的簇拥者，他果断调整自己，试图通过打通开发和运维的这堵部门墙。而他所开展的敏捷管理实践就是DevOps发展的第一个雏形。
DevOps的发展在业界有几个公认的、比较重要的阶段。2008年，敏捷博客的诞生，到后来在多伦多大会上，持续集成的流行为DevOps埋下种子。2009年，Velocty大会提出，一个中心两个基本点的概念，更强调了发展DevOps的两个重要概念——文化和工具的重要性。随之在同年10月，DevOps便正式诞生。次年，敏捷博客发表什么是DevOps文章，重点阐述了依据敏捷体系构造出的DevOps体系。它包括一系列价值观、原则、方法、实践以及对应的工具支撑。
回顾软件发展的管理模式

不同岗位的程序员各司其职完成开发任务

在传统瀑布模式下，开发、测试和运维分属于不同的部门，相互之间都有着厚厚的部门墙，下一个环节的动作，必须要等到上一个环节全部完成外才能进行。再到后来的敏捷时代，也主要是打通了开发和测试的部门墙，采用迭代的方式，测试驱动开发。比较两种模式的不同，我们会发现，传统瀑布管理模式注重在交付范围不变的情况下，通过计划驱动修改交付的时间和协调调动资源来完成交付。而敏捷则讲求的是在资源、时间不变的情况下，通过价值驱动更改交付范围。

到DevOps时代，其实就是敏捷思想从软件开发端(Dev)到系统维护端(Ops)的延伸。"Dev"是开发人员的简称，但真正在实践中，意味着更广泛的“参与开发产品”的所有人，包括产品、质量和其他种类的工种。"Ops"也是一个总括术语，泛指系统工程师、系统管理员、操作人员，发布工程师、数据管理员(DBA)、网络工程师、安全专家等维护支撑类工种。

DevOps聚焦软件快速交付、系统稳定运营。通过让团队共享面向客户的价值和集成目标，同时也共担质量责任。但是，DevOps并不会取代敏捷，而是对敏捷的补充。它通过消除浪费和简化部署等思想，来实现持续交付的目标。DevOps是集大成者，它并不制造概念，而是将很多理念和实践做了整合，是真正打通端到端交付的方法体系。

📰总结

总之，DevOps准确的定义就是Development和Operations的组合，是一组过程、方法与系统的统称，用于促进开发、技术运营和质量保障（QA)部门之间的沟通、协作与整合。简单来说，其核心理念是提倡开发、测试、运维，三者之间的高度协同，在高频率部署的同时，保证生产环境的可靠性、稳定性和安全性。 DevOps好处就是能不断地以端到端的传播形式，向用户端直接传递价值，通过缩短业务上线时间，保障业务的市场竞争力。任何直接面向用户，并为他们提供产品和服务的企业，都可以实践DevOps。
随着微服务、容器以及云技术的成熟，DevOps强调的持续集成、持续部署、持续交付的概念，才能更好地发挥价值。尤其是万物互联的时代，一个连接着人与人、人与物、以及物与物的信息时代，需求关系的转变，让业务变得越来越复杂，系统功能越来越多。如果继续让整个系统耦合在一起，则必定会牵一发而动全身，系统维护肯定直线上升。因此，IT技术架构必定会随着系统的复杂化而要求不断地变化革新。
一图流

🧩DevOps的发展

目前，DevOps处于高速增长的阶段。尤其是在大企业中，DevOps受到了广泛的欢迎。根据2018年的调查发现，74%的受访者已经接受了DevOps，而前一年这一比例为66%。越大的企业，越喜欢DevOps。包括Adobe、Amazon、Apple、Airbnb、Ebay、Etsy、Facebook、LinkedIn、Netflix、NASA、Starbucks、Walmart、Sony等公司，都在采用DevOps。

📰发展过程速览

DevOps包含development和operations，是开发和运营维护的总称。软件设计过程中，应对开发部门、运维部门进行协调，确保各项工作流程与方法高效使用，为项目管理工作提供可靠参考。基于devops软件开发源于2009年欧洲传统IT模式，对解决运维管理问题起到关键作用。为巩固软件设计与开发结果，将开发、运维与测试结合一起，形成了DevOps软件开发管理模式。
基于DevOps软件开发可对测试环境进行应用，同时可将数据包融入到软件环境中。DevOps立足全局角度，对开发效果进行分析，加强人员之间的合作与交流也是软件开发设计工作重点，应对其进行合理安排。在devops框架下，对软件进行开发可实现自动化操作，使得人机交互方案应用具有可行性。
传统的软件组织将开发、IT运营和质量保障设为各自分离的部门。在这种环境下如何采用新的开发方法（例如敏捷软件开发），这是一个重要的课题：按照从前的工作方式，开发和部署不需要IT支持或者QA深入的、跨部门的支持，而却需要极其紧密的多部门协作。然而DevOps考虑的还不止是软件部署。它是一套针对这几个部门间沟通与协作问题的流程和方法。
需要频繁交付的企业可能更需要对DevOps有一个大致的了解。Flickr发展了自己的DevOps能力，使之能够支撑业务部门“每天部署10次”的要求──如果一个组织要生产面向多种用户、具备多样功能的应用程序，其部署周期必然会很短。这种能力也被称为持续部署，并且经常与精益创业方法联系起来。从2009年起，相关的工作组、专业组织和博客快速涌现。
DevOps的引入能对产品交付、测试、功能开发和维护（包括──曾经罕见但如今已屡见不鲜的──“热补丁”）起到意义深远的影响。在缺乏DevOps能力的组织中，开发与运营之间存在着信息“鸿沟”──例如运营人员要求更好的可靠性和安全性，开发人员则希望基础设施响应更快，而业务用户的需求则是更快地将更多的特性发布给最终用户使用。这种信息鸿沟就是最常出问题的地方。
DevOps经常被描述为“开发团队与运营团队之间更具协作性、更高效的关系”。由于团队间协作关系的改善，整个组织的效率因此得到提升，伴随频繁变化而来的生产环境的风险也能得到降低。

📰发展现状

在云计算、大数据等技术颠覆性趋势继续在应用经济下发挥作用的同时，DevOps也已经稳健地在业务思维方式中占有一席之地，并将在2015年扮演主要角色。在应用驱动、云连接、移动化的大环境下，DevOps战略将助力业务增值。2015年对于很多公司来说是DevOps之路的第一步。
紧跟行业趋势、进行新的技术变革往往会带来发展的阵痛，DevOps也同样要经历这一过程。中国及全球各地的企业正在认识到DevOps可以助力软件开发速度加快，软件应用质量提升，更重要的是与业务目标更完美地结合。如果说，2014年DevOps还在谋求广泛的认可，那么2018年DevOps将走到舞台中心，被整合成为企业战略的重要组成部分。
与DevOps相伴的一个变化是向持续集成的演进。软件开发和部署的速度是其中一个驱动因素，使得开发和运维的合并不是空谈而成为必需。

📰未来发展

DevOps、微服务、容器、云计算都经历了一个进阶发展的过程。像从瀑布到敏捷再到DevOps一样，微服务也经历了一体化到n层架构再演变为微服务架构。部署方式也是，从物理服务器到虚拟服务器再到容器技术。最后，云计算也可以看出，早期的数据中心概念如今也演变成了大家都比较熟悉的云计算技术。
再说回DevOps概念，比如说微服务架构要求松耦合，每一个服务都要具有它自己的代码库和状态，由更小规模的敏捷开发团队，进行独立的管理，这就满足了DevOps更快、更敏捷开发、部署和更新要求。容器技术相当于很好地解决了微服务的复杂性，每个微服务的依赖组件、运行环境都不一样，被打包到一个容器当中，即使服务有不同的版本，不同的运行环境和不同的依赖组件，容器技术依然都可以让它们运行在相同的主机之上。微服务运行依托的所有东西都被打包在一起，成为一个不可变的环境，这也正是一个典型的持续集成实践。云原生技术的出现，它利用的正是容器的效率，微服务的架构，比组合或单体环境更加实用和具有自适应性。
这是一个瞬息万变的时代，我们所处的时代充满了易变性、不确定性、复杂性和模糊性，业务需要，频繁地从真实用户那里得到对商业假设的有效验证，成功者必须具有拥有快速交付价值、灵活应对变化的能力。这也就必然造就了DevOps快速发展的环境。
近几年，几乎每个行业机构和组织，都想制定一套自己的DevOps实践。很多人以为只要进行自动化、配置管理和敏捷开发，就算是真正意义上了解并实践了DevOps。然而并没有那么简单。DevOps与软件系统的发布机制是密切有关的。DevOps要求建立协作互通的开发团队，可以朝着一个可预见的目标一起工作。还涉及到实践过程中的集体性和服务心态。DevOps要求团队组织中建立—种敏捷而灵活的传输机制。
有一种说法是DevOps其实和工具、技术以及自动化无关。自动化实际扮演的是实现敏捷开发，减少团队内部合作并辅助更快交付的角色。DevOps并不提供框架和方法，当它应用到团队和项目管理中，它其实是DevOps和企业共同实现既定目标的一系列原理和实践经验。其次，这些原理和实践经验并不执行任何特殊程序、工具和技术，甚至环境。最后，即便DevOps有的技术和流程本身确实可能对实现DevOps的目标和愿景比较适用，但事实上，DevOps只是在应用实践这些工具、技术和流程的过程中提供了指导思想。

📄以下几方面因素可能促使一个组织引入DevOps：

使用敏捷或其他软件开发过程与方法
业务负责人要求加快产品交付的速率
虚拟化和云计算基础设施（可能来自内部或外部供应商）日益普遍
数据中心自动化技术和配置管理工具的普及
有一种观点认为，占主导地位的“传统”美国式管理风格（“斯隆模型 vs 丰田模型”）会导致“烟囱式自动化”，从而造成开发与运营之间的鸿沟，因此需要DevOps能力来克服由此引发的问题。

📄DevOps对应用程序发布的影响

减少变更范围
与传统的瀑布式开发模型相比，采用敏捷或迭代式开发意味着更频繁的发布、每次发布包含的变化更少。由于部署经常进行，因此每次部署不会对生产系统造成巨大影响，应用程序会以平滑的速率逐渐生长。
加强发布协调
靠强有力的发布协调人来弥合开发与运营之间的技能鸿沟和沟通鸿沟；采用电子数据表、电话会议、即时消息、企业门户（wiki、sharepoint）等协作工具来确保所有相关人员理解变更的内容并全力合作。
自动化
强大的部署自动化手段确保部署任务的可重复性、减少部署出错的可能性。与传统开发方法那种大规模的、不频繁的发布（通常以“季度”或“年”为单位）相比，敏捷方法大大提升了发布频率（通常以“天”或“周”为单位）。