DevOps（英文Development和Operations的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。[1]
以下几方面因素可能促使一个组织引入DevOps：
- 使用敏捷或其他软件开发过程与方法
- 业务负责人要求加快产品交付的速率
- 虚拟化和云计算基础设施（可能来自内部或外部供应商）日益普遍
- 数据中心自动化技术和配置管理工具的普及
- 有一种观点认为，目前占主导地位的“传统”美国式管理风格（“斯隆模型 vs 丰田模型”）会导致“烟囱式自动化”，从而造成开发与运营之间的鸿沟，因此需要DevOps能力来克服由此引发的问题。
DevOps，是一种提倡将开发机构的文化、流程和工具整合到一起的集成软件交付方式，跨越从业务规划、创建、交付到反馈的整个软件开发生命周期。DevOps既不仅是一个工具、平台或技术，也不是简单的定义开发和运营，而是对软件开发及交付的一门哲学。DevOps里面包括四个维度：(1)计划和监控；(2)开发和测试；(3)发布和部署；(4)版本管理、反馈和分析。
在软件行业进入云计算时代后，在整个市场用户对软件产品以及服务的要求也跟着提高，这不仅需要开发和运维人员快速实现，而且要快速部署发布上线，并且必须保证业务可靠、高效运行。正如虚拟化改变了数据中心的运营一样，云计算的兴起也预示着IT应用运维将发生重大变革。目前，IT运维团队还一直处于以服务器为中心来驱动的运维模式，而具体的应用则扮演着次要作用。另一方面，云计算则是以应用为中心的运维模式。
运行在云环境下的应用程序也需要具有高可用性、高可靠性和高灵活性，以应对更多更复杂的工作负载和监测。过去由IT运维基础架构提供的这些功能现在将成为应用程序本身的一部分，这些运维能力需要融入到开发环境中。而在这些以应用为中心的新环境，运维团队将需要与开发者协同创建这些应用程序，也就是刚才我们所介绍的“DevOps”。DevOps团队是“一群采用新的方式实现更快、更好、更具效益和乐趣来推进开发和系统管理的人群。”
传统模型带来的是开发及测试的部门壁垒。随着我们通过像敏捷，像Scrum这样的敏捷方法，在加强开发团队和测试团队之间的沟通协作之后，其实我们不可避免地会面临到开发部门和我们的运维，以及发布运营这样的一个瓶颈。它会取代我们之前开发团队里面所遇到的障碍和瓶颈，我们新的要解决这样的问题。DevOps从它的思想和实践上来看，也是随着敏捷的实践项目继续集成、自动化部署这样的一些实践成熟。
传统的意义上讲，我们开发团队，开发完了之后往往是打包扔给发布团队，或者说是运维团队，随着我们对于发布的要求越来越高。我们其实是要求，就是说生产环境的运维部门和发布团队，跟开发部门坐到一起，双方角色互补，开发人员去学习运维的知识和工具。运维去提供我生产环境部署的约束和要求，双方融合形成一个比较一体化的DevOps这样的团队。
在虚拟化和云计算出来之前，往往我们的部署和生产运维，而且都是在实体机上面，实体机上面的成本基数很高的。在虚拟化技术出来之后，我一个普通的运维人员，输入命令就可以得到几台这样的虚拟机。当这样的工具出来之后，我可以再输入命令就会拿到一个完全一样的环境出来。所以我们来讲，随着虚拟化和云计算技术，以及周边的管理，像自动化创建工具这样的成熟后，DevOps就传统的运维技能会变得越来越大众化，可以被我们开发人员所接受、所拥抱，再用到环境里面去。
开发和运维是分开的两个团队，项目之间通过一个发布包，做出一个FTP这样的去沟通。其他团队把包放在FTP上面，然后运维从FTP上取下包去部署。这个导致的问题就是，很多生产环境下面的环境配置，这样的一些软件要求，跟开发的时候不一样。DevOps成员是作为团队的一分子参与到开发团队的日常工作里面去，它的几个主要工作职责会包括，第一，它会帮助团队把他们团队对环境的配置、对环境的要求，用一些工具把它变成代码，变成自动化的。另外一个就是说，在生产环境下面会考虑到可用性、考虑到安全、考虑到运维的要求。它会把这样的约束条件灌输给团队，团队在设计系统的时候就考量这一块的约束情况，这样的时候实施就会更好一些。
开发和运维其实是两种不同的技能，开发的头脑里面就是我赶紧把代码写完，扔给运维就好了。运维的头脑就想着，我这块要是出了问题，那我就可能睡不着觉，每天晚上接到电话起来维护。其实来讲，两边对对方存在一些这样的误解，很大的原因就是，大家对于各自工作是不了解的，他不知道运维需要做什么事情，我只看到运维可能有这样的一些报表，有这样的投影，投在那里说系统实际是怎么样，有没有出现问题。运维看到开发团队在那边写代码，也不知道在做什么事情。要想在团队里面实施这样的运维，DevOps的话，其实我们觉得它从文化和技术，或者是技能两方面都要提供相应的辅导。从文化层面上面来讲，就要鼓励我们的运维和开发人员坐在一起，互相地分享。因为团队的目标还是一致的，我把系统更快的部署到环境上去，让它能够稳定安全地运行。从文化上面来讲，首先要让大家理解这样的一个，大家是共同的目标，不是说势如水火。
其次的话，要营造出双方相互协作的一个情况、一个场景。就是文化上面，然后从场景和技巧上面来讲，除了双方对于各自技能的掌握和培训之外，我们发现还是有一些前提条件是比较满足的，比如说我们来讲企业集成。我们需要自动化测试，只要我们能够在团队内部把企业集成和自动化测试先做到一定程度的话，比如说我们可以有信心地拍胸脯说，我们这个软件没有太大的问题。在这样的情况下面，我们再引入DevOps做这个，从软件交付的角度来讲，会是比较好的一种方式。否则的话团队整天在修复缺陷，这时候我们的运维和开发坐在一起可能没有太多的意义，这是第一。
第二就是说，如果我们不是这么全局来看，我们是从局部优化来看，我们可以看到运维团队在系统配置、系统创建这一块的技能。它也是非常必要的，因为我们发现开发团队，不管是开发还是测试，它其实有一个很严重的问题，他们要想做调试、做测试的时候，环境是不够的。可能这个环境做完一套测试之后，环境就被污染了、数据被污染、我的应用包被污染。在追求环境的准备和提供方面，其实我们的运维是可以进来，或者是我们的DevOps团队是可以形成的，然后去做一些相对来讲没有那么广的事情，还是跟在这一块上面。而这个前提条件就可能是我们这样的一个架构也好、技术也好，能够比较好的支持我们DevOps去做基础设施代码的工作。
DevOps类似于我们敏捷方法，它其实也是跟思想原则和具体的实现，DevOps它的本身的这样一个思想和价值观就是说，让我们的开发和我们的运维也好，或者说我们的实施也好，让他们能够更好地，双方能够消除各自领域的浪费。从原则上来讲，就会有一些像基础设施代码、配置自动化等等这样的一些原则。
相关图书