DevOps 的起源可以追溯到 2008 年，在一次敏捷大会的敏捷基础设施话题组被提及，从起源我们可以了解到 DevOps 的发展跟敏捷软件开发是密不可分的。
DevOps 定义
DevOps 经过这些年的发展，其定义也在不断变化，先来看三段 DevOps 的 wiki 定义。
DevOps 2017 - 2020 年英文 wiki 定义（直译）
DevOps是一种 软件工程文化和实践（Practices），旨在整合软件开发和软件运维。DevOps运动的主要特点是强烈倡导对构建软件的所有环节（从集成、测试、发布到部署和基础架构管理）进行全面的自动化和监控 DevOps 的目标是缩短开发周期，提高部署频率和更可靠地发布，与业务目标保持一致。
DevOps 2021 年英文 wiki 定义（直译）
DevOps 是一系列整合软件开发和软件运维活动的 实践（Practices）。目标是缩短软件开发生命周期并使用持续交付提供高质量的软件。
另：
DevOps 与敏捷软件开发是互补关系，DevOps 的许多方面来自于敏捷方法论。
DevOps 中文 wiki 定义
DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间 沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
提取这三段的共同点，可以看到不论定义如何变化，DevOps 所要实现的目标都是一致的——缩短软件开发生命周期并使用 持续交付 提供高质量的软件。由于持续交付活动中包含了构建、测试和发布等活动，我更倾向于用这个定义，可以更好地缩减定义长度。
另外可以看到英文直接翻译过来的定义中都包含「实践」 一词，而中文 wiki 经过一定的翻译或本地化后变成了「文化、运动或惯例」，其还更强调开发运维之间 沟通合作 这一点，因此将最新的英文 wiki 定义与中文 wiki 定义相结合，可以帮助我们更好地理解 DevOps，那么它的最终定义是什么就交由读者朋友自己去领会吧。
DevOps 发展背景
为什么 DevOps 会如此热门，时常被人所提及，这与其发展背景是分不开的，主要原因可以概括为以下几点：
敏态需求的增加，即探索性工作的增加；
- 软件开发从传统的瀑布流方式到敏捷开发，再到现在对敏捷开发提出了更高的要求，近些年创新型的应用不断涌现，在这些应用的研发过程中多采用小步快跑、快速试错的方式，这些探索性工作要求运维能够具备一天发布多次的能力，需要企业完成由稳态到敏态的转变。
软件开发活动在企业经营活动中占比的不断增加；
- 业务发展对软件的依赖由轻度依赖、中度依赖发展到目前的重度依赖。
企业存在对消除浪费的需求。
- 软件开发活动在企业中的位置越来越重要，而像企业经营活动一样，软件开发活动中也存在着许多的浪费，企业管理上必然存在着 识别并消除浪费 的需求。
- 软件开发中的浪费包括不必要和必要的浪费，不必要的浪费有：无人使用的功能、软件bug、等待测试、等待审批等；必要的浪费包括：工作项移交、测试、项目管理等。
以上主要从企业的角度说明了 DevOps 的发展，这是较为深层次的原因，表层的推动因素包括：容器化技术的发展、微服务架构的发展等等，这些技术上的创新为 DevOps 提供了良好的发展条件，以解决企业面临的这些问题。
DevOps 原则与实践
了解了什么是 DevOps 及其发展原因后，又该如何具体的进行 DevOps 实践，我们采用黄金圈法则来思考这一问题。
DevOps 原则是总体指导思想，实践是具体的执行方法，DevOps 是一个动态的过程，在进行相关实践的时候可以看看其应用了哪些原则，当违背原则的时候需要思考实践的合理性。
DevOps 原则
DevOps 包含以下三大原则：
- 流动原则：加速 从开发、运维到交付给客户的流程；
- 反馈原则：建设 安全可靠 的工作体系；
- 持续学习与实验原则：采用科学的工作方式，将对组织的 改进和创新 作为工作的一部分。
流动原则
坚持少做
- 产品开始开发时采用 MVP 原则。
- 产品迭代时要适时做减法。
持续分解问题
- 大的变更或需求拆解为一系列小的变更，快速解决。
工作可视化
- 采用 Sprint 看板将工作可视化。
控制任务数量
- 减少前置时间，降低测试人员的等待时间。
- 任务越多，预估越不准确。
减少交接次数
- 减少不必要的沟通和等待。
持续识别和改善约束点
- 识别出影响流动的主要前置因素，比如搭建环境、需求文档。
- QA、开发、运维、产品持续提升生产力。
- 为非功能性需求预留20%的开发时间，减少技术债务。
消除价值流中的困境和浪费（导致交付延迟的主要因素）
- 半成品——未完全完成的工作。
- 额外工序——从不使用的文档、重复编写接口文档等。
- 额外功能——用户实际不需要的功能。
- 任务切换——将人员分配到多个项目或截然不同的工作任务中。
- 等待、移动、缺陷、非标准化的手动操作。
反馈原则
在复杂系统中安全地工作
- 管理复杂的工作，识别出设计和操作的问题；
- 群策群力解决问题，从而快速构建新知识；
- 在整个组织中，将区域性的知识应用到全局范围；
- 领导者要持续培养有以上才能的人。
及时发现问题
- 快速、频繁和高质量的信息流——每个工序的操作都会被度量和监控。
- 技术价值流的每个阶段（产品管理、开发、QA、安全、运维），建立快速的反馈和前馈回路（包括自动化构建、集成和测试过程）。
- 全方位的遥测系统。
在源头保障质量
- 过多的检查和审批流程，使得做决策的地方远离执行工作的地方，这导致流程有效性降低，减弱了因果关系之间反馈的强度。
- 让开发人员也对系统质量负责，快速反馈，加速开发人员的学习。
为内部客户优化工作
- 运维的非功能性需求（如架构、性能、稳定性、可测试性、可配置性和安全性）与用户功能同样重要。
持续学习与实验原则
- 建立学习型组织和安全文化
- 将日常工作的改进制度化
- 把局部发现转化为全局优化
在日常工作中注入弹性模式
- 缩短部署的前置时间、提高测试覆盖率、缩短测试执行时间，甚至在必要时解耦架构，都属于在系统中引入类似张力的做法。
领导层强化学习文化
- 领导者帮助一线工作者在日常工作中发现并解决问题。
DevOps的一个巨大好处就是可以高效交付，这也正好是它的初衷。Puppet和DevOps Research and Assessment (DORA) 主办了2016年DevOps调查报告，根据全球4600位各IT公司的技术工作者的提交数据统计，得出高效公司平均每年可以完成1460次部署。
与低效组织相比，高效组织的部署频繁200倍，产品投入使用速度快2555倍，服务恢复速度快24倍。在工作内容的时间分配上，低效者要多花22%的时间用在为规划好或者重复工作上，而高效者却可以多花29%的时间用在新的工作上。所以这里的高效不仅仅指公司产出的效率提高，还指员工的工作质量得到提升。
DevOps另外一个好处就是会改善公司组织文化、提高员工的参与感。员工们变得更高效，也更有满足和成就感；调查显示高效员工的雇员净推荐值（eNPS:employee Net Promoter Score）更高，即对公司更加认同。
快速部署同时提高IT稳定性。这难道不矛盾吗？
快速的部署其实可以帮助更快地发现问题，产品被更快地交付到用户手中，团队可以更快地得到用户的反馈，从而进行更快地响应。而且，DevOps小步快跑的形式带来的变化是比较小的，出现问题的偏差每次都不会太大，修复起来也会相对容易一些。
因此，认为速度就意味着危险是一种偏见。此外，滞后软件服务的发布也并不一定会完全地避免问题，在竞争日益激烈的IT行业，这反而可能错失了软件的发布时机
为什么DevOps会兴起？
为什么会继续火下去？
条件成熟：技术配套发展
技术的发展使得DevOps有了更多的配合。早期时，大家虽然意识到了这个问题的，但是苦于当时没有完善丰富的技术工具，是一种“理想很丰满，但是现实很骨感”的情况。DevOps的实现可以基于新兴的容器技术；也可以在自动化运维工具Puppet、SaltStack、Ansible之后的延伸；还可以构建在传统的Cloud Foundry、OpenShift等PaaS厂商之上。
来自市场的外部需求：这世界变化太快
IT行业已经越来越与市场的经济发展紧密挂钩，专家们认为IT将会有支持中心变成利润驱动中心。事实上，这个变化已经开始了，这不仅体现在Google、苹果这些大企业中，而且也发生在传统行业中，比如出租车业务中的Uber、酒店连锁行业中的Airbnb、图书经销商Amazon等等。能否让公司的IT配套方案及时跟上市场需求的步伐，在今天显得至关重要。
DevOps 2016年度报告给出了一个运维成本的计算公式：
停机费用成本 = 部署频率 版本迭代失败概率 平均修复时间 * 断电的金钱损失
来自团队的内在动力：工程师也需要
对于工程师而言，他们也是DevOps的受益者。微软资深工程师Scott Hanselman说过“对于开发者而言，最有力的工具就是自动化工具”（The most powerful tool we have as developers is automation）。
工具链的打通使得开发者们在交付软件时可以完成生产环境的构建、测试和运行；正如Amazon的VP兼CTO Werner Vogels那句让人印象深刻的话：“谁开发谁运行”。（You build it, you run it）
