说起DevOps就不得不从DevOps之父——Patrick Debois说起。2007 年，Patrick参与了比利时一个政府下属部门的大型数据中心迁移项目。在这个项目中，他分别负责测试和验证的工作。这就意味着他不光有机会和开发团队（Dev）工作，也时常要和运维团队（Ops）工作。在开发团队中，他需要适应敏捷交付的节奏，但在运维团队他又得按照传统模式，像管理消防队员那样维护系统。两种工作氛围的来回切换，令他十分沮丧。




不同的工作方式、思维方式势必存在着巨大差异，所以在这两者之间工作，到处都是冲突。作为一个敏捷的簇拥者，他果断调整自己，试图通过打通开发和运维的这堵部门墙。而他所开展的敏捷管理实践就是DevOps发展的第一个雏形。




DevOps的发展在业界有几个公认的、比较重要的阶段。2008年，敏捷博客的诞生，到后来在多伦多大会上，持续集成的流行为DevOps埋下种子。2009年，Velocity大会提出，一个中心两个基本点的概念，更强调了发展DevOps的两个重要概念——文化和工具的重要性。随之在同年10月， DevOps便正式诞生。次年，敏捷博客发表什么是DevOps文章，重点阐述了依据敏捷体系构造出的DevOps体系。它包括一系列价值观、原则、方法、实践以及对应的工具支撑。




回顾软件发展的管理模式，在传统瀑布模式下，开发、测试和运维分属于不同的部门，相互之间都有着厚厚的部门墙，下一个环节的动作，必须要等到上一个环节全部完成外才能进行。再到后来的敏捷时代，也主要是打通了开发和测试的部门墙，采用迭代的方式，测试驱动开发。




比较两种模式的不同，我们会发现，传统瀑布管理模式注重在交付范围不变的情况下，通过计划驱动修改交付的时间和协调调动资源来完成交付。而敏捷则讲求的是在资源、时间不变的情况下，通过价值驱动更改交付范围。




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




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




总之，DevOps准确的定义就是Development和Operations的组合，是一组过程、方法与系统的统称，用于促进开发、技术运营和质量保障（QA）部门之间的沟通、协作与整合。简单来说，其核心理念是提倡开发、测试、运维，三者之间的高度协同，在高频率部署的同时，保证生产环境的可靠性、稳定性和安全性。




DevOps好处就是能不断地以端到端的传播形式，向用户端直接传递价值，通过缩短业务上线时间，保障业务的市场竞争力。任何直接面向用户，并为他们提供产品和服务的企业，都可以实践DevOps。




很多人说，2008年就提出了DevOps的概念，但到2010年，DevOps才逐步开始被大众所谈论。也就最近几年的实践，才开始逐步在企业中推行落地，发光发热。这是为什么呢？因为DevOps的发展离不开技术手段的进步支撑。




随着微服务、容器以及云技术的成熟，DevOps强调的持续集成、持续部署、持续交付的概念，才能更好地发挥价值。尤其是万物互联的时代，一个连接着人与人、人与物、以及物与物的信息时代，需求关系的转变，让业务变得越来越复杂，系统功能越来越多。如果继续让整个系统耦合在一起，则必定会牵一发而动全身，系统维护肯定直线上升。因此，IT技术架构必定会随着系统的复杂化而要求不断地变化革新。

由上图所示，DevOps、微服务、容器、云计算都经历了一个进阶发展的过程。像从瀑布到敏捷再到DevOps一样，微服务也经历了一体化到n层架构再演变为微服务架构。部署方式也是，从物理服务器到虚拟服务器再到容器技术。最后，云计算也可以看出，早期的数据中心概念如今也演变成了大家都比较熟悉的云计算技术。


那微服务、容器、云计算的具体概念是什么呢？我们一起看下。

• 微服务：是一个新兴的软件架构，就是把一个大型的单个应用程序和服务，拆分为数十个微服务。微服务的策略就是可以让工作变得更为简便，它通过扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议，类似于我们在敏捷概念里所讲的MVP。
• 容器：是一种轻量级、操作系统层面的虚拟机，它为应用软件及其依赖组件，提供了一个资源独立的运行环境。应用软件所依赖的组件，会被打包成一个可重用的镜像，镜像运行环境并不会与主操作系统共享内存、CPU和硬盘空间，由此，也保证了容器内部的进程与容器外部进程的独立关系。
• 云技术：是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。现行比较流行的概念有公有云、私有云、混合云、社区云几种形式，按服务场景分又可以分为IaaS、PaaS、SaaS三种。
  

再说回DevOps概念，比如说微服务架构要求松耦合，每一个服务都要具有它自己的代码库和状态，由更小规模的敏捷开发团队，进行独立的管理，这就满足了DevOps更快、更敏捷开发、部署和更新要求。容器技术相当于很好地解决了微服务的复杂性，每个微服务的依赖组件、运行环境都不一样，被打包到一个容器当中，即使服务有不同的版本，不同的运行环境和不同的依赖组件，容器技术依然都可以让它们运行在相同的主机之上。微服务运行依托的所有东西都被打包在一起，成为一个不可变的环境，这也正是一个典型的持续集成实践。云原生技术的出现，它利用的正是容器的效率，微服务的架构，比组合或单体环境更加实用和具有自适应性。

很多人说DevOps是当今时代的产物，2016年诺基亚总裁，斯蒂芬·埃洛普，同意微软收购时说: 我们并没有做错什么,但不知道为什么，我们输了！




这是一个瞬息万变的时代，我们所处的时代充满了易变性、不确定性、复杂性和模糊性，业务需要，频繁地从真实用户那里得到对商业假设的有效验证，成功者必须具有拥有快速交付价值、灵活应对变化的能力。这也就必然造就了DevOps快速发展的环境。




近几年，几乎每个行业机构和组织，都想制定一套自己的DevOps实践。很多人以为只要进行自动化、配置管理和敏捷开发，就算是真正意义上了解并实践了DevOps。然而并没有那么简单。DevOps与软件系统的发布机制是密切有关的。DevOps要求建立协作互通的开发团队，可以朝着一个可预见的目标一起工作。还涉及到实践过程中的集体性和服务心态。DevOps要求团队组织中建立一种敏捷而灵活的传输机制。




有一种说法是DevOps其实和工具、技术以及自动化无关。自动化实际扮演的是实现敏捷开发，减少团队内部合作并辅助更快交付的角色。DevOps并不提供框架和方法，当它应用到团队和项目管理中，它其实是DevOps和企业共同实现既定目标的一系列原理和实践经验。其次，这些原理和实践经验并不执行任何特殊程序、工具和技术，甚至环境。最后，即便DevOps有的技术和流程本身确实可能对实现DevOps的目标和愿景比较适用 ，但事实上，DevOps只是在应用实践这些工具、技术和流程的过程中提供了指导思想。（[url=]伪文艺的小青年[/url]）

说起DevOps就不得不从DevOps之父——Patrick Debois说起。2007 年，Patrick参与了比利时一个政府下属部门的大型数据中心迁移项目。在这个项目中，他分别负责测试和验证的工作。这就意味着他不光有机会和开发团队（Dev）工作，也时常要和运维团队（Ops）工作。在开发团队中，他需要适应敏捷交付的节奏，但在运维团队他又得按照传统模式，像管理消防队员那样维护系统。两种工作氛围的来回切换，令他十分沮丧。




不同的工作方式、思维方式势必存在着巨大差异，所以在这两者之间工作，到处都是冲突。作为一个敏捷的簇拥者，他果断调整自己，试图通过打通开发和运维的这堵部门墙。而他所开展的敏捷管理实践就是DevOps发展的第一个雏形。




DevOps的发展在业界有几个公认的、比较重要的阶段。2008年，敏捷博客的诞生，到后来在多伦多大会上，持续集成的流行为DevOps埋下种子。2009年，Velocity大会提出，一个中心两个基本点的概念，更强调了发展DevOps的两个重要概念——文化和工具的重要性。随之在同年10月， DevOps便正式诞生。次年，敏捷博客发表什么是DevOps文章，重点阐述了依据敏捷体系构造出的DevOps体系。它包括一系列价值观、原则、方法、实践以及对应的工具支撑。




回顾软件发展的管理模式，在传统瀑布模式下，开发、测试和运维分属于不同的部门，相互之间都有着厚厚的部门墙，下一个环节的动作，必须要等到上一个环节全部完成外才能进行。再到后来的敏捷时代，也主要是打通了开发和测试的部门墙，采用迭代的方式，测试驱动开发。




比较两种模式的不同，我们会发现，传统瀑布管理模式注重在交付范围不变的情况下，通过计划驱动修改交付的时间和协调调动资源来完成交付。而敏捷则讲求的是在资源、时间不变的情况下，通过价值驱动更改交付范围。




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




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




总之，DevOps准确的定义就是Development和Operations的组合，是一组过程、方法与系统的统称，用于促进开发、技术运营和质量保障（QA）部门之间的沟通、协作与整合。简单来说，其核心理念是提倡开发、测试、运维，三者之间的高度协同，在高频率部署的同时，保证生产环境的可靠性、稳定性和安全性。




DevOps好处就是能不断地以端到端的传播形式，向用户端直接传递价值，通过缩短业务上线时间，保障业务的市场竞争力。任何直接面向用户，并为他们提供产品和服务的企业，都可以实践DevOps。




很多人说，2008年就提出了DevOps的概念，但到2010年，DevOps才逐步开始被大众所谈论。也就最近几年的实践，才开始逐步在企业中推行落地，发光发热。这是为什么呢？因为DevOps的发展离不开技术手段的进步支撑。




随着微服务、容器以及云技术的成熟，DevOps强调的持续集成、持续部署、持续交付的概念，才能更好地发挥价值。尤其是万物互联的时代，一个连接着人与人、人与物、以及物与物的信息时代，需求关系的转变，让业务变得越来越复杂，系统功能越来越多。如果继续让整个系统耦合在一起，则必定会牵一发而动全身，系统维护肯定直线上升。因此，IT技术架构必定会随着系统的复杂化而要求不断地变化革新。

由上图所示，DevOps、微服务、容器、云计算都经历了一个进阶发展的过程。像从瀑布到敏捷再到DevOps一样，微服务也经历了一体化到n层架构再演变为微服务架构。部署方式也是，从物理服务器到虚拟服务器再到容器技术。最后，云计算也可以看出，早期的数据中心概念如今也演变成了大家都比较熟悉的云计算技术。


那微服务、容器、云计算的具体概念是什么呢？我们一起看下。

• 微服务：是一个新兴的软件架构，就是把一个大型的单个应用程序和服务，拆分为数十个微服务。微服务的策略就是可以让工作变得更为简便，它通过扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议，类似于我们在敏捷概念里所讲的MVP。
• 容器：是一种轻量级、操作系统层面的虚拟机，它为应用软件及其依赖组件，提供了一个资源独立的运行环境。应用软件所依赖的组件，会被打包成一个可重用的镜像，镜像运行环境并不会与主操作系统共享内存、CPU和硬盘空间，由此，也保证了容器内部的进程与容器外部进程的独立关系。
• 云技术：是指在广域网或局域网内将硬件、软件、网络等系列资源统一起来，实现数据的计算、储存、处理和共享的一种托管技术。现行比较流行的概念有公有云、私有云、混合云、社区云几种形式，按服务场景分又可以分为IaaS、PaaS、SaaS三种。
  

再说回DevOps概念，比如说微服务架构要求松耦合，每一个服务都要具有它自己的代码库和状态，由更小规模的敏捷开发团队，进行独立的管理，这就满足了DevOps更快、更敏捷开发、部署和更新要求。容器技术相当于很好地解决了微服务的复杂性，每个微服务的依赖组件、运行环境都不一样，被打包到一个容器当中，即使服务有不同的版本，不同的运行环境和不同的依赖组件，容器技术依然都可以让它们运行在相同的主机之上。微服务运行依托的所有东西都被打包在一起，成为一个不可变的环境，这也正是一个典型的持续集成实践。云原生技术的出现，它利用的正是容器的效率，微服务的架构，比组合或单体环境更加实用和具有自适应性。

很多人说DevOps是当今时代的产物，2016年诺基亚总裁，斯蒂芬·埃洛普，同意微软收购时说: 我们并没有做错什么,但不知道为什么，我们输了！




这是一个瞬息万变的时代，我们所处的时代充满了易变性、不确定性、复杂性和模糊性，业务需要，频繁地从真实用户那里得到对商业假设的有效验证，成功者必须具有拥有快速交付价值、灵活应对变化的能力。这也就必然造就了DevOps快速发展的环境。




近几年，几乎每个行业机构和组织，都想制定一套自己的DevOps实践。很多人以为只要进行自动化、配置管理和敏捷开发，就算是真正意义上了解并实践了DevOps。然而并没有那么简单。DevOps与软件系统的发布机制是密切有关的。DevOps要求建立协作互通的开发团队，可以朝着一个可预见的目标一起工作。还涉及到实践过程中的集体性和服务心态。DevOps要求团队组织中建立一种敏捷而灵活的传输机制。




有一种说法是DevOps其实和工具、技术以及自动化无关。自动化实际扮演的是实现敏捷开发，减少团队内部合作并辅助更快交付的角色。DevOps并不提供框架和方法，当它应用到团队和项目管理中，它其实是DevOps和企业共同实现既定目标的一系列原理和实践经验。其次，这些原理和实践经验并不执行任何特殊程序、工具和技术，甚至环境。最后，即便DevOps有的技术和流程本身确实可能对实现DevOps的目标和愿景比较适用 ，但事实上，DevOps只是在应用实践这些工具、技术和流程的过程中提供了指导思想。（[url=]伪文艺的小青年[/url]）