扒一扒你所不知道的DevOps发展史
- 2023-02-08 08:00:00
- 翰德恩咨询 原创
- 1079
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 在博客上发表了一篇题为“持续部署”的文章。
另外，DevOps 还基于并拓展了“基础设施即代码”的实践，该实践由 Mark Burgess 博士、 Luke Kanies 和 Adam Jacob 共同提出。在“基础设施即代码”这种实践中，运维工作被最大程度地自动化，并确保任何对基础设施的操作都通过代码来实现，从而将现代软件的开发实践应用到了整个产品交付中，其特性包括持续集成（由 Grady Booch 提出，是极限编程的 12 个实践
之一）、持续交付（由 Jez Humble 和 David Farley 提出）和持续部署（由 Etsy、Wealthfront
和 Eric Ries 在 IMVU 的工作中提出）。
丰田套路
Mike Rother 在 2009 年编写了《丰田套路：转变我们对领导力与管理的认知》一书，书中融入了他在丰田产品系统（TPS）中所积累的 20 年45实践经验。他也曾参与了精益工具箱的制作。Mike 在读研究生期间，曾和通用汽车公司的高层一起去日本参观丰田工厂，有一件事让他感到困惑：所有应用精益原则的公司中，没有一家能达到丰田的水平。之后，Mike 得出了结论：精益社区中大多数企业都没有抓住精益的核心——改善套路（Kata）。他解释说，所有企业都有日常的工作流程，而这些日常工作决定了最终的产出。通过设定目标，制订每周的详细计划，并持续改善日常工作，如此循序渐进，才能达到优化和改进的目
的。
来源：《DevOps实践指南》
翰德恩咨询洞见
：
任何概念或方法论都不是凭空出世。从DevOps的诞生过程可以看出，在DevOps诞生之前，已经有精益、敏捷、持续交付、丰田套路的成熟发展作为基础。了解了DevOps的前生今世， 让我们更加理解DevOps的本质。DevOps不是要代替敏捷，也不能够代替敏捷。
DevOps本质是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
以下几方面因素可能促使一个组织引入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 在博客上发表了一篇题为“持续部署”的文章。 另外，DevOps 还基于并拓展了“基础设施即代码”的实践，该实践由 Mark Burgess 博士、 Luke Kanies 和 Adam Jacob 共同提出。在“基础设施即代码”这种实践中，运维工作被最大程度地自动化，并确保任何对基础设施的操作都通过代码来实现，从而将现代软件的开发实践应用到了整个产品交付中，其特性包括持续集成（由 Grady Booch 提出，是极限编程的 12 个实践
之一）、持续交付（由 Jez Humble 和 David Farley 提出）和持续部署（由 Etsy、Wealthfront
和 Eric Ries 在 IMVU 的工作中提出）。
丰田套路
Mike Rother 在 2009 年编写了《丰田套路：转变我们对领导力与管理的认知》一书，书中融入了他在丰田产品系统（TPS）中所积累的 20 年45实践经验。他也曾参与了精益工具箱的制作。Mike 在读研究生期间，曾和通用汽车公司的高层一起去日本参观丰田工厂，有一件事让他感到困惑：所有应用精益原则的公司中，没有一家能达到丰田的水平。之后，Mike 得出了结论：精益社区中大多数企业都没有抓住精益的核心——改善套路（Kata）。他解释说，所有企业都有日常的工作流程，而这些日常工作决定了最终的产出。通过设定目标，制订每周的详细计划，并持续改善日常工作，如此循序渐进，才能达到优化和改进的目
的。
来源：《DevOps实践指南》
翰德恩咨询洞见 ：
任何概念或方法论都不是凭空出世。从DevOps的诞生过程可以看出，在DevOps诞生之前，已经有精益、敏捷、持续交付、丰田套路的成熟发展作为基础。了解了DevOps的前生今世， 让我们更加理解DevOps的本质。DevOps不是要代替敏捷，也不能够代替敏捷。
DevOps本质是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。通过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
以下几方面因素可能促使一个组织引入DevOps：
| 联系人： | 田老师 |
|---|---|
| 电话： | +86 135 5227 9573 |
| Email： | clientservice@hardenx.cn |
| 地址： | 北京市朝阳区福码大厦B座17层1705 |
加微领1G资料
