devops概念最早是谁提出的

DevOps 起源于亚马逊和 Google 这样的大型互联网公司

DevOps: Development和Operations的组合

可以把DevOps看作开发(软件工程)、技术运营和质量保障(QA)三者的交集。

传统的软件组织将开发、IT运营和质量保障设为各自分离的部门。在这种环境下如何采用新的开发方法(例如敏捷软件开发)，这是一个重要的课题：按照从前的工作方式，开发和部署不需要IT支持或者QA深入的、跨部门的支持，而却需要极其紧密的多部门协作。然而DevOps考虑的还不止是软件部署。它是一套针对这几个部门间沟通与协作问题的流程和方法。

需要频繁交付的企业可能更需要对DevOps有一个大致的了解。Flickr发展了自己的DevOps能力，使之能够支撑业务部门“每天部署10次”的要求──如果一个组织要生产面向多种用户、具备多样功能的应用程序，其部署周期必然会很短。这种能力也被称为持续部署，并且经常与精益创业方法联系起来。 从2009年起，相关的工作组、专业组织和博客快速涌现。

DevOps的引入能对产品交付、测试、功能开发和维护(包括──曾经罕见但如今已屡见不鲜的──“热补丁”)起到意义深远的影响。在缺乏DevOps能力的组织中，开发与运营之间存在着信息“鸿沟”──例如运营人员要求更好的可靠性和安全性，开发人员则希望基础设施响应更快，而业务用户的需求则是更快地将更多的特性发布给最终用户使用。这种信息鸿沟就是最常出问题的地方。

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

使用敏捷或其他软件开发过程与方法

业务负责人要求加快产品交付的速率

虚拟化和云计算基础设施(可能来自内部或外部供应商)日益普遍

数据中心自动化技术和配置管理工具的普及

有一种观点认为，占主导地位的“传统”美国式管理风格(“斯隆模型 vs 丰田模型”)会导致“烟囱式自动化”，从而造成开发与运营之间的鸿沟，因此需要DevOps能力来克服由此引发的问题。

DevOps经常被描述为“开发团队与运营团队之间更具协作性、更高效的关系”。由于团队间协作关系的改善，整个组织的效率因此得到提升，伴随频繁变化而来的生产环境的风险也能得到降低。

DevOps对应用程序发布的影响

在很多企业中，应用程序发布是一项涉及多个团队、压力很大、风险很高的活动。然而在具备DevOps能力的组织中，应用程序发布的风险很低，原因如下：

与传统开发方法那种大规模的、不频繁的发布(通常以“季度”或“年”为单位)相比，敏捷方法大大提升了发布频率(通常以“天”或“周”为单位)

减少变更范围与传统的瀑布式开发模型相比，采用敏捷或迭代式开发意味着更频繁的发布、每次发布包含的变化更少。由于部署经常进行，因此每次部署不会对生产系统造成巨大影响，应用程序会以平滑的速率逐渐生长。加强发布协调靠强有力的发布协调人来弥合开发与运营之间的技能鸿沟和沟通鸿沟；采用电子数据表、电话会议、即时消息、企业门户(wiki、sharepoint)等协作工具来确保所有相关人员理解变更的内容并全力合作。自动化强大的部署自动化手段确保部署任务的可重复性、减少部署出错的可能性。术语“DevOps”通常指的是新兴的专业化运动，这种运动提倡开发和IT运维之间的高度协同，从而在完成高频率部署的同时，提高生产环境的可靠性、稳定性、弹性和安全性。

DevOps运动的起源通常被放在2009年前后，伴随着许多运动的相辅相成和相互促进——效率研讨会运动，特别是由John Allspaw和Paul

Hammond展示的开创性的“一天10次部署”，基础设施即代码”运动(Mark Burgess 和Luke Kanies)，“敏捷基础设施运动” (Andrew

Shafer)，“敏捷系统管理”运动(Patrick DeBois)，“精益创业”运动(Eric Ries)，Jez

Humble的持续集成和发布运动，以及Amazon的“平台即服务运动”等这些运动的相辅相成和相互促进而发展起来的。DevOps起源于亚马逊和Google这样的大型互联网公司

再看看别人怎么说的。DevOps起源于亚马逊和Google这样的大型互联网公司，这些公司需要员工紧密协作，同时又不希望出现部门割据。

如果希望了解DevOps，就不可避免需要切分这个词中的两个角色：Dev和Ops(注：这里的Dev包括常说的开发和测试人员，Ops则指服务运维人员，更多时候特指生产环境的服务运维人员)。回顾历史，Dev和Ops这两个角色从计算机诞生之日就已经存在，而且在诞生之初它们本身就是一体的。在最早期，计算机的使用范围非常有限。其

硬件生产、软件开发和日常运维很多时候都是来自同样人员或者团队。所以，Dev和Ops这两个角色也就自然融合在一块。

随着计算机使用用途的扩展，越来越多行业开始采购计算机来提升效率，其中个人电脑(PC)的出现则让计算机从传统的计算领域向外延伸到各行各业。于是，PC时代其就诞生了许多独立的计算机软硬件供应商。而步入这个阶段后，计算机软硬件研发就会和最终使用者自然分离。当企业普遍开始使用计算机及相关软件来提升日常运营效率时，通常会需要专职的IT系统运维管理人员来保证其正常运行，于是最早期的专职运维人员(也称系统管理员)应运而生。在这个阶段，系统的研发人员(Dev)和运维人员(Ops)其实是处在不同的

机构中，他们之间的沟通和交互主要靠产品说明书、操作文档以及付费的Support完成。为保证企业内IT系统的稳定运行，以Ops为中心的运维管理体系(如ITIL)逐步形成。在这个时间段，企业运维管理体系以服务企业内部运营为主，并不直接面对企业最终用户。实际运维过程则以保证系统稳定为核心目标，对于系统自身的迭代速度要求并不高。一个最明显的例证就是这个时期软件及系统的交付周期一般都是以年为单位(甚至那个时候的Windows版本更新甚至以3年记)。同时，由于这个阶段的Dev和Ops完全分离在不同组织中，基本无法形成持续有效的沟通和交互，从而也无法相互了解。通常Ops团队对于软件的设计及实现思路缺乏最基本的了解，而Dev团队对于Ops在实际运维过程中的挑战和问题也知之甚少。

随着互联网和移动互联网的出现，人们终于找到了一种更好的软件及服务交付方式，即在线服务。在这种模式下，用户无需再承担软件及服务的运维工作，而是直接“开箱即用”。系统的开发和运维工作再次回到一个组织内部，即在线服务提供商。但是，由于遗留系统(很多在线服务提供商在早期并没有自研能力，而是采购外部技术来搭建自身服务系

统)及传统运维思路的影响，很多在线服务供应商仍然是按照传统模式组建自身的运维团队。于是，很多组织内部的运维团队和研发团队虽然是在一个公司，也服务于同一个产品，但是他们在组织架构上仍然是独立向上汇报。甚至，这种组织架构在很多公司内部还作为一种均衡各方势力的法宝。基于这些原因，那些因Dev和Ops相互分离而造成的问题并未由于他们重新回到一个组织内而得到根本改观。同样存在Dev和Ops相互不了解，互不信任，上线流程异常缓慢等众多老问题。于是，人们就会思考一个问题：既然都在一个组织内，而且是服务于同一个产品，为啥不能让两者走向融合，变成一个以给最终用户交付最大价值为目标的团队呢?于是，DevOps思潮开始涌现，并从理论研究逐步成为目前非常主流的软件生产方式。在这其中也诞生了很多非常优秀的DevOps践行者，如Facebook、Amazon、Netflix等。

回顾整个发展过程，我们可以看到随着系统交付及使用方式不断变化，Dev和Ops两者也经历了由合到分，又重新走向融合的过程。从中可以看出，系统的生产方式其实和系统交付及使用方式息息相关。有什么样的交付及使用方式，就会诞生与之匹配的系统生产方式。而现在，以互联网和SaaS为代表的交付及使用方式已经成为主流趋势，与之相对应的软件生产方式也必然会向全新的DevOps方向发展。DevOps(英文Development和Operations的组合)是一组过程、方法与系统的统称，用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。Dev和Ops这两个角色从计算机诞生之日就已经存在，而且在诞生之初它们本身就是一体的。

在最早期，计算机的使用范围非常有限。其硬件生产、软件开发和日常运维很多时候都是来自同样人员或者团队。所以，Dev和Ops这两个角色也就自然融合在一块。

随着计算机使用用途的扩展，越来越多行业开始采购计算机来提升效率，其中个人电脑(PC)的出现则让计算机从传统的计算领域向外延伸到各行各业。于是，PC时代其就诞生了许多独立的计算机软硬件供应商。而步入这个阶段后，计算机软硬件研发就会和最终使用者自然分离。当企业普遍开始使用计算机及相关软件来提升日常运营效率时，通常会需要专职的IT系统运维管理人员来保证其正常运行，于是最早期的专职运维人员(也称系统管理员)应运而生。在这个阶段，系统的研发人员(Dev)和运维人员(Ops)其实是处在不同的机构中，他们之间的沟通和交互主要靠产品说明书、操作文档以及付费的Support完成。为保证企业内IT系统的稳定运行，以Ops为中心的运维管理体系(如ITIL)逐步形成。Dev和Ops这两个角色从计算机诞生之日就已经存在，而且在诞生之初它们本身就是一体的。

在最早期，计算机的使用范围非常有限。其硬件生产、软件开发和日常运维很多时候都是来自同样人员或者团队。所以，Dev和Ops这两个角色也就自然融合在一块。

随着计算机使用用途的扩展，越来越多行业开始采购计算机来提升效率，其中个人电脑(PC)的出现则让计算机从传统的计算领域向外延伸到各行各业。于是，PC时代其就诞生了许多独立的计算机软硬件供应商。而步入这个阶段后，计算机软硬件研发就会和最终使用者自然分离。当企业普遍开始使用计算机及相关软件来提升日常运营效率时，通常会需要专职的IT系统运维管理人员来保证其正常运行，于是最早期的专职运维人员(也称系统管理员)应运而生。在这个阶段，系统的研发人员(Dev)和运维人员(Ops)其实是处在不同的机构中，他们之间的沟通和交互主要靠产品说明书、操作文档以及付费的Support完成。为保证企业内IT系统的稳定运行，以Ops为中心的运维管理体系(如ITIL)逐步形成。

随着系统交付及使用方式不断变化，Dev和Ops两者也经历了由合到分，又重新走向融合的过程。从中可以看出，系统的生产方式其实和系统交付及使用方式息息相关。有什么样的交付及使用方式，就会诞生与之匹配的系统生产方式。

devops开发运维一体化

DevOps 标准是什么？

DevOps 标准是指《研发运营一体化(DevOps)能力成熟度模型 》 ，是指包含总体架构、敏捷开发管理、持续交付、技术运营、应用设计、

安全及风险管理、评估方法、系统和工具的系列标准。你好！

DevOps这个词，不同的人不同理解。有些人说他是一种文化并且行业中的每个供应商声称，他们的工具有助于DevOps。取决于你如何定义DevOps，这些指标会对你和你的团队多多少少有些帮助。

仅代表个人观点，不喜勿喷，谢谢。