第一部分 DevOps介绍

在本书的第一部分中，我们将回顾在管理和技术领域里所发生的几个重大事件，了解它们是怎样为DevOps的诞生奠定了基础的。同时，我们还将介绍“价值流”这个概念，解释为什么DevOps是把精益原则应用到技术价值流中的结果，并探讨DevOps的三步工作法：流动、反馈以及持续学习与实验。

第一部分包括以下内容。

❏流动原则：它加速了从开发、运维到交付给客户的流程。

❏反馈原则：它使我们能建设出更安全可靠的工作体系。

❏持续学习与实验原则：它打造出一种高度信任的文化和一种科学的工作方式，并将对组织的改进和创新作为日常工作的一部分。

简史

DevOps和它所产生的技术、架构及文化实践，体现了哲学和管理学原则的融合。虽说这些原则是由不同组织独立发现的，但DevOps博采众长，形成了John Willis（本书作者之一）所说的“DevOps的大融合”，展现了人们思想上的惊人进步和不可思议的相互关联。基于制造业实践了数十年的管理经验，它是将可靠性组织、信任度管理与DevOps实践相结合的产物。

DevOps基于精益、约束理论、丰田生产系统、柔性工程、学习型组织、安全文化、人员优化因素等知识体系，并参考了高信任管理文化、服务型领导、组织变动管理等方法论。把所有这些最可信的原则综合地应用到IT价值流中，就产生出DevOps这样的成果。将它贯彻于整个技术价值流中，涉及产品管理、开发、QA、IT运维和信息安全专员等不同角色，在更低的成本和努力下，保障产品的高质量、可靠性、稳定性和安全性。

虽然DevOps是精益原则、约束理论和丰田套路运动的衍生物，但也被许多人视为始于2001年的敏捷运动的延续。

精益运动

价值流映射、看板和全面生产维护这些实践起源于20世纪80年代的丰田生产系统。1997年，精益企业协会开始研究如何将精益理念应用于服务业和医疗行业等其他价值流中。

精益的两个主要原则包括：坚信前置时间（把原材料转换为成品所需的时间）是提升质量、客户满意度和员工幸福感的最佳度量指标之一；小批量任务的交付是缩短前置时间的一个关键因素。

精益原则聚焦在如何通过系统性思考为客户创造价值，系统性思考的范围涉及建立持久目标，拥抱科学思维，创造流和拉动（而非推送）的协作模式，提倡从源头保证质量，以谦逊为导向，尊重流程中的所有个体。

敏捷宣言

敏捷宣言是在2001年由软件领域的17位顶尖大师共同提出的。他们希望用一套轻量级的价值观和原则体系，来优化那些沉重的软件开发流程（如传统的瀑布式开发模型）和方法论（如统一软件开发过程）。

在敏捷宣言中，一个重要的原则是“频繁地交付可工作的软件，交付周期可以是数星期也可以是数月，推荐更短的周期”，并强调使用小批量任务进行增量发布，而非大规模的作业和瀑布流程的发布。同时，强调建立自组织的小团队，让成员在高度信任的环境中愉悦地工作。

在很多实施了敏捷的企业里，生产效率显著提升，敏捷也因此获得了越来越广泛的支持和认可。有趣的是，在DevOps的发展历程中，如下所述的几个关键活动都发源于敏捷社区或者敏捷大会。

敏捷基础设施和Velocity大会

在2008年加拿大多伦多的敏捷大会上，Patrick Debois和Andrew Clay Schafer主持了一场研讨，提倡将敏捷原则应用到基础设施而不是应用程序的代码上。尽管研讨的参与者数量并没有达到预期，但是他们还是很幸运地找到了几个志同道合者，其中包括本书作者之一John Willis。

在2009年的Velocity大会上，John Allspaw和Paul Hammond分享了题为“每日10次部署：Dev和Ops在Flickr的协作”的演讲，讲述了他们如何建立Dev和Ops共享的目标，并通过运用持续集成等实践，将部署变成了日常工作的一部分。据当时在场的听众回忆道，所有的参与者都认为他们见证了这个具有深远意义的历史性时刻。

虽然Patrick Debois并不在现场，但他对Allspaw和Hammond的想法产生了浓厚的兴趣，并在2009年比利时的根特市（他的居住地）发起了第一次DevOpsDays活动。“DevOps”这个术语也应运而生。

持续交付

基于持续构建、测试和集成的开发原则，Jez Humble和David Farley进行了延伸，提出了持续交付，并首次在2006年的敏捷大会上做了分享。在持续交付中，“部署流水线”确保代码和基础设施始终处于可部署状态，所有提交到主干的代码都可以安全地部署到生产环境。2009年，Tim Fitz在博客上发表了一篇题为“持续部署”的文章。

丰田套路

Mike Rother在2009年编写了《丰田套路：转变我们对领导力与管理的认知》一书，书中融入了他在丰田产品系统（TPS）中所积累的20年实践经验。他也曾参与了精益工具箱的制作。Mike在读研究生期间，曾和通用汽车公司的高层一起去日本参观丰田工厂，有一件事让他感到困惑：所有应用精益原则的公司中，没有一家能达到丰田的水平。

之后，Mike得出了结论：精益社区中大多数企业都没有抓住精益的核心——改善套路（Kata）。他解释说，所有企业都有日常的工作流程，而这些日常工作决定了最终的产出。通过设定目标，制订每周的详细计划，并持续改善日常工作，如此循序渐进，才能达到优化和改进的目的。

以上描述了DevOps的发展历史和大事记。在接下来的内容里，我们将主要介绍价值流，以及如何将精益原则应用到技术价值流中；同时介绍三步工作法：流动、反馈和持续学习与实验。