1. 概览
DevOps（Development和Operations的组合词）是一种重视「软件开发人员（Dev）」和「IT运维技术人员（Ops）」之间沟通合作的文化、运动。透过自动化「软件交付」和「架构变更」的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
DevOps综合了社会体系和技术体系。
2. 背景
传统的软件组织将开发、IT运营和质量保障设为各自分离的部门，在这种环境下如何采用新的开发方法（例如敏捷软件开发），是一个重要的课题。按照从前的工作方式，开发和部署，不需要IT支持或者QA深入的跨部门的支持；而现在却需要极其紧密的多部门协作。
而DevOps考虑的还不止是软件部署，它是一套针对这几个部门间沟通与协作问题的流程和方法。
需要频繁交付的企业可能更需要对DevOps有一个大致的了解。Flickr发展了自己的DevOps能力，使之能够支撑业务部门“每天部署10次”的要求──如果一个组织要生产面向多种用户、具备多样功能的应用程序，其部署周期必然会很短。这种能力也被称为持续部署，并且经常与精益创业方法联系起来。从2009年起，相关的工作组、专业组织和博客快速涌现。
3. DevOps与敏捷区别
相对于瀑布开发模式，敏捷开发过程的一个基本原则就是以更快的频率交付最小化可用的软件。在敏捷的目标里，最明显的是在每个Sprint的迭代周期末尾，都具备可以交付的功能。
敏捷对于开发重新获得商业的信任是大有益处的，但是它无意于将IT运维拒之门外，DevOps使得IT组织作为一个整体重新获得商业的信任。DevOps和敏捷软件开发是相辅相成的，因为它拓展和完善了持续集成和发布流程，因此可以确保代码是生产上可用，并且确实能给客户带来价值。
DevOps不仅仅创建了一个面向IT运维的工作流，当代码已经开发完成但是却无法被部署到生产上时，这些部署就会堆积在IT运维的面前，客户也将因而无法享受到任何价值，更糟糕的是，部署经常导致IT环境的中断和服务不可用。DevOps具有与生俱来的文化变革的基因组成，因为它革新了开发和IT运维之间的工作流和传统的衡量标准。
4. DevOps为何爆发
2009年，DevOps就被提出。但是，近两年才开始受到重视和实践。这是因为，DevOps需要很多基础技术作为支撑。2013年容器技术的爆发、2014年提出的微服务架构、云计算的普及，都有力地助推了DevOps的实践。
5. 机遇和挑战
5.1 应用领域
- 将开发延伸至生产中——包括拓展持续集成和发布功能至生产，集成QA和信息安全至整个工作流，确保代码和环境可在生产中直接部署。
- 向开发中加入生产反馈——包括建立开发和IT运营事件的完整时间表用于帮助事件的解决，使得开发融入无指责的生产反思，尽可能使得开发可以自助服务，同时创建信息指示器用来表明本地的决策如何影响全局的目标。
- 开发嵌入到IT运维中——包括开发投入到整个生产问题处理链，分配开发资源用于生产问题管理，并协助退回技术债务，而且开发为IT运维提供交叉培训，增加IT运维处理问题的能力，从而降低升级问题的数量。
- 将IT运维嵌入至开发——包括嵌入和联络IT运维资源至开发，帮助开发创建为IT运维(部署，生产代码的管理等)使用的可重用的用户故事，定义一些可以被所有项目共用的非功能性需求。
5.2 开发人员：什么都做过一点，什么都不精通
人类能运用的知识有限。在任务之间切换，无疑是代价昂贵的。强迫开发者去承担其他专业人员的角色，意味着他们将：
- 没有把时间花在开发上
- 需要跟上一个极其庞大的知识领域
- 会不堪重负
5.3 企业获得的优势
- 产品快速推向市场，缩短开发周期时间和更高的部署频率
- 提高质量，提高可用性，提高变更成功率，减少故障
- 提高组织的有效性，将时间花在价值增加活动中，减少浪费，同时交付更多的价值至客户手中
但是，DevOps的提出旨在消除开发人员和系统运维工程师之间的障碍，但能否成功却取决于企业的文化和灵活性。
