DevOps是基于持续交付的软件工程

一、软件工程一撇

科学管理之父泰勒的理念是：

少数精英负责制定标准的工作流程、工具操作、工艺质量，再由管理层完成监督和管理工作，大量的蓝领工人可以不用动脑子、不思考地就可以完成符合质量标准的工作，从而产生合格的产品。一句话：“我需要的是一双手，而不是一个人”。

洛克希德软件技术中心的 Winston W. Royce，在其1970年的论文“Managing the Development of Large Software System”中提出了一个长得很像瀑布（waterfall）的流程。

《人月神话》一书以“没有银弹”的论断直言没有任何一项技术或方法可使软件工程的生产力在十年内提高10倍。

Scrum 框架中，迭代被称为Sprint。而 Scrum 的项目过程有一系列的 Sprint 组成。Sprint 的长度一般控制在2-4周，通过固定的周期保持良好的节奏。产品的设计、开发、测试都在 Sprint 期间完成。在 Sprint 结束时交付可以工作的软件。整个 Sprint 的过程中（计划会议确定下工作项内容后）不允许发生变更。

“DevOps之父”是来自比利时的帕特里克·德布瓦(Patrick Debois)。2007年，对IT组织结构颇有兴趣的帕特里克在从事大型数据中心迁移工作中意识到，开发团队和运维团队之间的信息鸿沟和组织冲突往往造成 IT项目的结果令人沮丧，作为一名敏捷开发的拥护者，他此后为改变这种状况而努力。

2009年6月举办的圣荷西第二届Velocity大会是一个重要转折点，会上的一个名为《10+Deploys Per Day: Dev and Ops Cooperation at Flickr》的演讲引起了帕特里克的共鸣。

2010年，The Agile Admin博客发表“What is DevOps”一文详细定义了DevOps的概念与体系，越来越多的IT从业者认识到DevOps的理念和意义。同年在德国汉堡第二届DevOpsDays大会上，《持续交付》一书的作者杰兹·汉布尔发表了关于“持续交付”的重要演讲。由于持续交付（CD）是持续集成（CI）的延伸，这与2008年敏捷大会的观点一致，因而CI/CD成为了DevOps的核心理念之一，而非另成一系。

DevOps是这个时代的方法论产物，有了这个理念，开发者世界在之后的十年里诞生了一批质量优秀且普遍适用的生产力工具和成熟的解决方案，Docker、Kubernetes就是其中的典型案例。

工具链的集成构建是 DevOps 落地过程中非常重要的一项工作。整个工具链的串联会涉及到很多工具。我们可以从两个维度列举一些常见的工具：

研发工程维度（软件交付过程）：

项目协同：Jira、BeyondDevOps Synergy；

代码托管：GitLab、Bitbucket；

制品管理：Artifactory、Nexus、Harbor；

构建管理：Maven、Docker、NPM；

代码质量：Sonar、Junit；

自动化测试：JMeter、Selenium；

流水线工具：Jenkins、JFrog。

基础设施维度（周边配套系统）：

IaaS平台：VMware、Openstack、BeyondCube；

容器管理：Kubernetes、BeyondContainer；

部署平台：Ansible、Python、Shell、BeyondStage；

ITSM：CMDB、CMP、BeyondCMP、BeyondCMDB；

日志平台：ELK、EFK；

自动化监控：Zabbix、Prometheus。

二、KOL只言片语

极力反对把devops、sre和平台工程混为一谈，更不可把一个概念去覆盖其他二者。既然是工程，一定是为了解决特定域问题，特定域问题是有预设条件的，泛泛而谈就是软件工程大类了。

从SDLC到ALM，DevOps …… 最后都要轮到IDP上！工具看似是最底层，最不重要的部分，确实最终形成能力的关键。枝繁叶茂最终也要落叶归根，大树参天的沃土都是落地的叶子腐烂的结果。

敏捷，精益，DevOps，研发效能和平台工程，再多的热词都离不开软件工程。

软件工程的基本工作思路 -  粒度和解耦，这与DevOps五大理念之一的局部性和简单性说的是同一件事，只有如此才有机会在复杂的企业研发环境中创造出顺畅的价值流动。

平台工程也许会是DevOps一体化研发平台的新名字，这也没有什么不好的 …… 进行软件交付确实不仅仅需要需求，代码，流水线，测试和制品这么简单 …… 安全合规，API治理，数据治理，效能指标，这些都应该为开发人员提供自助化服务。平台工程的外延更大，更容易让企业自由的组织和构建系统……其背后的逻辑没有变，仍然是IaC。基础设施即代码（Infrastructure as Code, IaC）是云原生、容器、微服务以及DevOps背后的底层逻辑 ～

如果没有整合的“开发者平台(IDP)”，那得有一些极为牛逼的开发高手，啥都懂，他不但（主动、被动）的承担了Ops 的职责，还得响应大量的初级开发者求助，他的精力没有用在撸码创造新的价值，而是被纠缠于运维和“被求助”的琐事中——而这些也未必是他的上级（通过是一个产品研发的Leader) 的关注点。

企业发展中，会衍生四种团队 : 1) 搞业务开发的 2) 为业务开发赋能提供子弹的； 3）高精尖技术研究的 4) 开发平台管理团队。

三、DevOps四书溯源

《持续交付》奠定了基础：三个基础能力（配置、集成、自动化），部署流水线，交付生态圈。

《DevOps实践指南》拔高到三步法：流动、反馈、学习。

《加速》进一步拔高到五大能力：

持续交付能力

架构能力

产品与流程能力

精益管理与监控能力

文化能力

​

​

​

​

（部分信息来自网络和朋友圈，如有侵权，请联系删除。）