什么是DevOps？

DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。

它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。

它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运维工作必须紧密合作。

发展

DevOps: Development和Operations的组合

DevOps包含development和operations，是开发和运营维护的总称。软件设计过程中，应对开发部门、运维部门进行协调，确保各项工作流程与方法高效使用，为项目管理工作提供可靠参考。基于devops软件开发源于2009年欧洲传统IT模式，对解决运维管理问题起到关键作用。为巩固软件设计与开发结果，将开发、运维与测试结合一起，形成了DevOps软件开发管理模式。

基于DevOps软件开发可对测试环境进行应用，同时可将数据包融入到软件环境中。DevOps立足全局角度，对开发效果进行分析，加强人员之间的合作与交流也是软件开发设计工作重点，应对其进行合理安排。在devops框架下，对软件进行开发可实现自动化操作，使得人机交互方案应用具有可行性。

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

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

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

现状

很多组织将开发和系统管理划分成不同的部门。开发部门的驱动力通常是“频繁交付新特性”，而运营部门则更关注IT服务的可靠性和IT成本投入的效率。两者目标的不匹配，就在开发与运营部门之间造成了鸿沟，从而减慢了IT交付业务价值的速度 。

开发人员经常不考虑自己写的代码会对运营造成什么影响。他们在交付代码之前，并不邀请运营人员参与架构决策或代码评审。

开发人员对配置或环境进行修改之后，经常没有及时与运营人员沟通，导致新的代码不能运行。

开发人员在自己的机器上手工修改配置，而没有记录所有需要的步骤。想找到必要的配置参数，通常需要尝试很多不同的参数；在得到一个可工作的状态后，往往很难识别出通过哪些最小步骤就能到达该状态。

开发人员倾向于使用有利于快速开发的工具：对代码修改更快的反馈，更低的内存消耗，等等。这样的工具集与运营人员面对的目标运行时环境非常不同：后者对稳定性和性能的要求远胜于灵活性。

由于开发人员平时使用桌面电脑，他们倾向于使用为桌面用户优化的操作系统。生产环境的运行时系统通常都运行服务器操作系统上。

在开发过程中，系统在开发者的本地机器上运行。在运营过程中，系统经常分布在多台服务器上，例如web服务器、应用服务器、数据库服务器等等。

开发是由功能性需求（通常与业务需求直接相关）驱动的。

运营是由非功能性需求（例如可获得性、可靠性、性能等）驱动的。

运营人员希望尽量避免修改功能，从而降低满足非功能性需求的风险

如果拒绝了小的修改，但给定时间段内需要修改的总量不变，那么每次变更的规模就会变大

变更规模越大，风险也越大，因为其中涉及的区域越多

由于运营人员尝试避免变更，新功能流入生产环境的速度因此被延缓，从而延缓了开发人员将特性交付给用户使用的速度。

运营人员可能对应用程序内部缺乏了解，从而难以正确地选择运行时环境和发布流程。

开发人员可能对运行时环境缺乏了解，从而难以正确地对代码进行调整