很多人一提到DevOps就想到工具，但DevOps不仅仅是工具，而是一组最佳实践，旨在将制造领域的精益概念应用到软件领域。DevOps的核心是三种方式：
- Flow原则，可加速从开发到运营，再到客户的工作交付；
- 反馈原则，使我们能够创建更安全的工作系统；
- 持续学习和实验的原则，作为日常工作的一部分，培养高度信任的文化和组织改进的科学方法。
如果遵循这些方式，改变就会发生，但这并不容易，过程将面临各种困难：从技术到心理，团队每天都必须努力实现这一改变。
目 录
你需要做的是通过小改动一遍又一遍地提供快速反馈，永远不要停止这个过程，你的团队在日常工作的某些方面就会被不断改进。
1. 一个简短的历史
DevOps以及由它产生的技术、架构和文化实践代表了许多管理方法的总和。DevOps源于许多运动，数十年来，从制造业、高可靠性组织、高信任管理模型以及其他促成DevOps最先进技术的人那里吸取了经验教训。
DevOps是将物理制造世界中最值得信赖的原则中的最佳实践应用于IT价值流的结果。DevOps的基础是精益、约束理论、丰田生产系统等。
DevOps借鉴的其他有价值的背景包括管理文化和组织变革管理。结果是以更低的成本和工作量获得世界一流的可靠性、稳定性和安全性；以及整个技术价值流中的加速流动和可靠性，包括产品管理。
2. 精益运动
精益原则侧重于如何通过创建流程和拉动流程（相对于推动）、将质量更接近源头、谦虚地领导和尊重每个人，通过系统为客户创造价值。
3. 敏捷运动
敏捷开发描述了一套软件开发的价值和原则，在这些价值和原则下，需求和解决方案通过自组织跨职能团队的协作努力发展。
“敏捷”一词因敏捷软件开发宣言而闻名，该宣言由17位软件开发领域的领先思想家于2001年创建。他们希望针对瀑布开发等其他软件开发流程创建一套轻量级的规则和原则。主要原则之一是“频繁地交付工作软件，从几个月到几周不等”。
4. 持续交付运动
持续交付 (CD) 是一种软件工程方法，其中团队在短周期内生产软件，确保软件可以随时可靠地发布。持续交付的概念建立在持续构建、测试和集成的原则之上，定义了部署管道的作用，以确保代码和基础设施始终处于可部署状态，并且所有签入主控的代码都可以安全部署投入生产。
5. 制造价值流
精益的基本概念之一是价值流。为了更好地理解，接下来会使用制造业的一些例子，然后推断技术生态系统的概念。
价值流可以定义为企业根据客户要求进行的一系列活动，包括信息和材料的流动。
在制造运营中，价值流通常很容易看到和观察：它在收到客户订单并将原材料发布到工厂车间时开始。在任何价值流中，通常都会持续关注创建顺畅的工作流程（DevOps的第一种方式），使用诸如小批量、减少在制品和减少返工等技术。
6. 技术价值流
同样的原则也适用于科技世界。对于DevOps，我们通常将技术价值流定义为将功能或变更请求转换为技术支持的服务，从而为最终用户提供价值所需的过程。
团队流程的输入是制定业务概念或客户请求，并在接受开发工作时开始，将其写入团队的待办事项。
接下来，遵循典型的敏捷或迭代过程的开发团队会将这个想法转化为某种规范，然后在源代码中实现。再将代码签入版本控制，其中每个更改都与软件系统的其余部分集成和测试（在DevOps中此过程自动化）。
团队的服务是在生产中创造价值的，所以团队必须确保不仅能提供快速的流程，而且也能在不导致服务中断的情况下安全地执行部署。
DevOps从来都不是关于完美，而是关于一致性。这就是关键：真正重要且持续很长时间的一切都需要付出耐心和努力。
将DevOps引入组织并非易事。它可能会产生风险，并开始一个令人不喜的改变过程。但遵循DevOps原则，从小目标和渐进步骤开始，其实这也没什么好害怕的，不是吗？
