第一部分 DevOps介绍

第一部分 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 在博客上发表了一篇题为“持续部署”的文章。1

1另外,DevOps 还基于并拓展了“基础设施即代码”的实践,该实践由 Mark Burgess 博士、Luke Kanies 和 Adam Jacob 共同提出。在“基础设施即代码”这种实践中,运维工作被最大程度地自动化,并确保任何对基础设施的操作都通过代码来实现,从而将现代软件的开发实践应用到了整个产品交付中,其特性包括持续集成(由 Grady Booch 提出,是极限编程的 12 个实践之一)、持续交付(由 Jez Humble 和 David Farley 提出)和持续部署(由 Etsy、Wealthfront 和 Eric Ries 在 IMVU 的工作中提出)。

丰田套路

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

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

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

目录

  • 版权声明
  • 推荐语
  • 译者序
  • 序言
  • 前言
  • 导言:展望DevOps新世界
  • 第一部分 DevOps介绍
  • 第 1 章 敏捷、持续交付和三步法
  • 第 2 章 第一步:流动原则
  • 第 3 章 第二步:反馈原则
  • 第 4 章 第三步:持续学习与实验原则
  • 第二部分 从何处开始
  • 第 5 章 选择合适的价值流作为切入点
  • 第 6 章 理解、可视化和运用价值流
  • 第 7 章 参考康威定律设计组织结构
  • 第 8 章 将运维融入日常开发工作
  • 第三部分 第一步:流动的技术实践
  • 第 9 章 为部署流水线奠定基础
  • 第 10 章 实现快速可靠的自动化测试
  • 第 11 章 应用和实践持续集成
  • 第 12 章 自动化和低风险发布
  • 第 13 章 降低发布风险的架构
  • 第四部分 第二步:反馈的技术实践
  • 第 14 章 建立能发现并解决问题的遥测系统
  • 第 15 章 分析遥测数据以更好地预测故障和实现目标
  • 第 16 章 应用反馈实现安全部署
  • 第 17 章 将假设驱动的开发和A/B测试融入日常工作
  • 第 18 章 建立评审和协作流程以提升当前工作的质量
  • 第五部分 第三步:持续学习与实验的技术实践
  • 第 19 章 将学习融入日常工作
  • 第 20 章 将局部经验转化为全局改进
  • 第 21 章 预留组织学习和改进的时间
  • 第六部分 集成信息安全、变更管理和合规性的技术实践
  • 第 22 章 将信息安全融入每个人的日常工作
  • 第 23 章 保护部署流水线
  • 行动起来——本书总结
  • 附加材料
  • 附录
  • 参考资源
  • 致谢
  • EXIN DevOps Professional认证备考指南 & 模拟题