从DevOps发展历史来理解DevOps

DevOps是一个合成词，源于“Development（开发）”和“Operations（运维）”两个词，它涉及以特定的方式实践应用程序开发的任务，是软件开发、测试和运维结合的过程、方法及系统，可以简单理解为“开发运维一体化”。

搜索DevOps时，总会出现敏捷、Scrum等容易混淆的概念，本文从DevOps发展历史来看，理清这些相关概念。

1948 - 丰田生产方式

丰田副社长大野耐一为挽救丰田濒临崩溃的生产过程，决定创建一个“ 消除浪费、持续改善”的精益生产方式。

在福特生产模式的基础上，大野耐一提出了“准时生产（JIT）”， 决定控制库存，力求达到“零库存”。准时制的基本思想是“只在需要的时候，按需要的量，生产所需的产品”。准时生产通过看板管理进行“后拉式”带动生产，实现清晰、有序的生产管理，拉动价值流动，使在制品、库存减少，从而有效地提高了生产效率。

除此之外，大野耐一针对丰田生产过程中的其他问题，提出了相应的解决方案，在不断优化、改进后，最终找到了一套适合丰田自身的标准化流程，逐步形成了以人为本、全员参与、追求质量，并能够在过程持续改善的精益生产方法。

1960-Kanban

Kanban 源于丰田生产模式，Kanban 一词来源于日文。随后，在2006年，软件行业中也出现了 Kanban 的概念。

看板作为一种敏捷方法论，通过工作流程以及任务的可视化来识别并纠正出现的失误。起初，看板通常为 物理看板（白板），随着 项目管理流程移至线上，看板也逐渐转为虚拟看板（软件工具）。

1970-瀑布开发

瀑布模型是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到软件产品。多用于军工国防领域，以基础软件居多，且软件的发行主要途径以物理介质为主，因此软件售出后再进行升级、修复的成本较高，行业竞争节奏相对平缓。

瀑布模型是最早出现的软件开发模型，在软件工程中占有重要的地位，提供了软件开发的基本框架。

1995-Scrum

Scrum术语来自英式橄榄球运动，本质含义是“争球”。
Scrum 是用于开发、交付和持续支持复杂产品的一个框架。Scrum是迭代式增量软件开发过程，是敏捷方法论中的重要框架之一，通常用于敏捷软件开发。Scrum包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务，产品负责人代表利益所有者，开发团队包括了所有开发人员。

2001-敏捷开发

2001年春，17名软件专家在雪鸟会议上提出并发布《敏捷宣言》，正式宣布了对四种核心价值和十二条原则，可以指导迭代的以人为中心的软件开发方法。

敏捷宣言强调的敏捷软件开发的四个核心价值是：

• 个体和互动高于流程和工具
• 工作的软件高于详尽的文档
• 客户合作高于合同谈判
• 响应变化高于遵循计划
  

也就是说，尽管右项有其价值，我们更重视左项的价值。

2009-DevOps

DevOps这个词来源于2009年在比利时根特市举办的首届DevOpsDays大会，DevOps是一个简单的缩写词，源于“Development（开发）”和“Operation（运维）”两个词，它涉及以特定的方式实践应用程序开发的任务。更广泛地说，软件开发和IT运维的结合被称为DevOps。

DevOps在促进IT运维和软件开发之间的敏捷关系方面的有效性受到几个因素的支持。通过在软件开发和IT运维部门的多个业务部门内实现更好的通信，DevOps通过以下优势的结合改进了软件的总体生产：稳定的运行环境、超快速的交付、坚实的合作、时间优化（特别是在修复/维护阶段）、持续创新。这样的技术优势使得DevOps成为世界上软件应用程序开发中备受追捧的方法。

至今-多种Ops

DevSecOps

在DevOps协作框架下，安全防护是需要贯穿至整个生命周期的每一个环节。这个理念非常重要，因此催生出了“DevSecOps”一词，即在开发和运维紧密结合的基础上再强调了Security，强调必须为 DevOps 打下扎实的安全基础。

DevSecOps意味着从一开始就要考虑应用和基础架构的安全性；同时还要让某些安全网关实现自动化，以防止DevOps工作流程变慢。要选择合适的工具来持续集成安全防护，比如在集成开发环境（IDE） 中集成安全防护功能。高效的DevSecOps安防需要的又不仅是新工具，它更需要整个公司实现DevOps 文化变革，从而尽早集成安全团队的工作。

GitOps

GitOps是一种实现持续交付的模型，它的核心思想是将应用系统的声明性基础架构和应用程序存放在Git的版本控制库中。主要围绕IaC（基础设施即代码）、拉取请求、CI/CD展开。

将Git作为交付流水线的核心，每个开发人员都可以提交拉取请求并使用Git来加速和简化Kuberne- tes的应用程序部署和运维任务。通过使用像Git这样的简单工具，开发人员可以更高效地将注意力集中在创建新功能而非运维相关任务上。

ITOps

ITOps相对于DevOps更偏传统，它将软件开发和IT基础设施管理视为一个统一的管道，并试图改进该管道并推动更高的灵活性。

ITOps的最佳实践更倾向于使用可靠的、经过高度测试的商业软件和解决方案来构建基础设施——包括硬件，因为ITOps倾向于关注物理服务器和网络。ITOps更关注稳定性和长期可靠性，而非推崇敏捷性和速度。

CloudOps

当ITOps将基础设施转移到更传统的一边时，CloudOps却恰恰相反。同样，这种方法与DevOps非常相似，但是在基础设施管理方面的关注点有所转移。顾名思义，CloudOps更多地利用现代服务提供商
（如Amazon）提供的云原生功能，让开发人员更专注于其核心竞争力。

CloudOps主要有三个要素：分布、无状态和可伸缩性。分布式开发和部署意味着不存在单点故障。整个云环境变得更加可靠，并且可以保持正常运行时间。同时，至少在工作流的某些部分，无状态化的能力对于成本效率来说是一个巨大的优势。