3.6　DevOps

3.6.1　DevOps的诞生

我们从背景说起。

近年来，软件发布的形式发生了巨大的变化：过去常常是刻一张光盘，用户自己来安装软件。而现在越来越多的是提供在线服务，用户通过网页浏览器、移动端应用等来连接和使用在线服务。这样的在线服务，背后常常是一个运行在多台甚至海量服务器上的复杂的分布式系统。这就意味着如果想要发布软件，就需要做与运维相关的一堆事情。

于是就会成立相应的Ops（运维/技术运营）团队，与Dev（开发）团队相互配合。要上线了，Dev团队把一包东西从“墙”的这边扔到“墙”的那边，Ops团队接着把它部署上线。由于Dev团队的根本目标是开发出新特性并把它们发布上线，而Ops则特别关注线上运行的稳定性，不希望有任何风吹草动，所以这两个目标不同的团队配合起来就特别拧巴。

那怎么办呢？打破隔阂，加强协作，协作好了就是DevOps。回望从瀑布模式到敏捷模式的转变，其实质是在很大程度上打破了Dev和QA（Quality Assurance，质量保证，这里指测试）之间的“墙”，让协作更顺畅。而DevOps进一步打破了开发、测试与运维之间的“墙”，让Dev、QA、Ops甚至Sec（Security，安全）等更多角色、更多工作协作得更顺畅。这需要从组织结构方面想办法，从文化方面想办法，从工具和流程角度想办法，等等。这么一整套解决办法，就是DevOps。

3.6.2　DevOps三步工作法

DevOps三步工作法[10]是DevOps的重要方法论。

“第1步，实现开发到运维的工作快速地从左向右流动。为了最大限度地优化工作流，需要将工作可视化，减小每批次大小和等待间隔，通过内建质量杜绝向下游传递缺陷，并持续地优化全局目标。

第2步，在从右向左的每个阶段中，应用持续、快速的工作反馈机制。该方法通过放大反馈环来防止问题复发，并能缩短问题检测周期，实现快速修复。通过这种方式，我们能从源头控制质量，并在流程中嵌入相关知识。这样不仅能创造出更安全的工作系统，还可以在灾难性事故发生前就检测到并且加以解决。

第3步，建立具有创意和高可信度的企业文化，支持动态的、严格的、科学的实验。通过主动承担风险，不但能从成功中学习，还能从失败中学习。通过持续地缩短和放大反馈环，不仅能创造出更安全的工作系统，还能承担更多的风险，并通过进行实验帮助自己比竞争对手改进得更快，从而在市场竞争中战胜他们。”

3.6.3　DevOps落地实践

2009年，一场名为“10 + Deploys Per Day: Dev and Ops Cooperation at Flickr”的演讲[11]被认为是DevOps萌发的标志。这场演讲在DevOps的落地实践方面，主要涉及自动化基础设施、共享的版本控制、一键完成构建和部署、特性开关、共享度量统计、即时通信机器人这六种技术手段，以及尊重、信任、对失败的正确态度、避免指责这四个文化方面的要素。再后来，不断有新的方法和实践被添加到这个工具箱中。而工具箱的名字，就叫DevOps。

想当年敏捷兴起时，敏捷的概念和范围不断扩大。2010年，Ivar Jacobson在一篇博文中说，“过去你问我支不支持敏捷，我会说哪些支持，哪些不支持，并给出我的理由。但现在你再问，我就只能回答支持。因为，如今敏捷的意思已经演变成‘软件开发中一切好的东西’。”

DevOps也一样，它在吸纳越来越多的东西。比如把安全涵盖进来，甚至为此有了一个新名词——DevSecOps。如今，在DevOps协作框架下，安全防护是整个IT团队的共同责任，需要贯穿于整个软件生命周期的每一个环节。

现在DevOps越来越变成软件设计、开发、集成、测试、发布、运维、安全中一切好的东西的集合。那好的东西从哪里来呢？好的东西很多都是从软件工程来的，从敏捷和精益来的，从持续集成、持续交付来的，从容器化、微服务、云原生来的。DevOps逐渐变成了一个标签和代称，实质上是在讲，如今软件设计、开发、交付、运维该怎么组织。