DevOps 的成本:27 个消声器

一则或许对你有用的小广告

欢迎加入小哈的星球 ,你将获得:专属的项目实战 / Java 学习路线 / 一对一提问 / 学习打卡/ 赠书活动

目前,正在 星球 内带小伙伴们做第一个项目:全栈前后端分离博客项目,采用技术栈 Spring Boot + Mybatis Plus + Vue 3.x + Vite 4手把手,前端 + 后端全栈开发,从 0 到 1 讲解每个功能点开发步骤,1v1 答疑,陪伴式直到项目上线,目前已更新了 204 小节,累计 32w+ 字,讲解图:1416 张,还在持续爆肝中,后续还会上新更多项目,目标是将 Java 领域典型的项目都整上,如秒杀系统、在线商城、IM 即时通讯、权限管理等等,已有 870+ 小伙伴加入,欢迎点击围观

想象一下,您正在设计 2016 款路虎揽胜系列运动型多用途车。与所有汽油动力车辆一样,每辆都需要一个排气消声器。路虎揽胜可能已经缩小了首选消声器供应商的范围。但是想象一下,如果设计师和工厂生产线工人可以从他们首选的供应商提供的 27 种过去版本的消声器中选择任何一种用于新车型年,会发生什么情况。是的,选择任何一个——即使它已经过时、性能较低、不符合当前排放标准或存在已知缺陷。订购它,将其放在车辆上,然后发货。

我们都意识到这种情况永远不会发生。没有人会为他们正在制造的产品选择已知有缺陷的部件。如果没有支持空气质量的最新进展,谁会故意选择 10 年前的消声器版本?没有任何组织会允许他们的每一位设计师和生产线工人在单一车型年采购 27 种不同消声器中的任何一种。想象一下测试不同消声器的运营成本。想象一下运输同一部件的不同版本的维护成本。更糟糕的是,想象一下运输具有已知缺陷的零件的责任。

Land Rover 没有采用这种方法,但软件开发团队采用了这种方法。

27个版本

我的最新研究报告 《2015 年软件供应链状况》 显示,大型软件开发组织去年平均采购了 27 种不同版本的开源组件用于开发。更具体地说,在 2014 年这些公司从互联网下载的前 100 个开源组件中,他们平均每个组件有 27 个版本。













虽然像 Land Rover 这样的汽车制造商更喜欢经过审查的零件供应商,但开源组件的采购往往更像是免费的。如果一个组织有 300 名开发人员,他们实际上有一个 300 人的采购部门来采购外部开发的软件组件。如果您有 4,000 名开发人员,则有 4,000 名执行采购人员。众所周知,只有最新版本的组件才是功能最丰富、质量和完整性最高的。

并非所有组织都允许对组件进行免费采购。 百分之五十七 (57%) 的受访者制定了开源政策, 以此作为引导开发人员开发已知缺陷或安全漏洞最少的更高质量部件的方法。像谷歌这样的组织要求在其开发团队中使用不超过两个版本的给定开源组件。

好的成本,坏的成本

这对一个软件开发组织意味着什么——尤其是一个专注于改进其 DevOps 实践的组织?首先是好消息:开发人员正在使用开源组件来加快发布时间和改进创新。都是好东西。

坏消息:组织正在通过采购同一组件的平均 27 个版本,通过糟糕的软件供应链实践积累大量技术债务,影响质量、复杂性、可维护性、可支持性等。他们在前 100 个组件中这样做在一年内下载,相当于管理 2700 多个不同版本(当优化实践只需要 100 个最佳版本时)。

组织正在采购组件“部件”以用于其应用程序,这些应用程序具有多达 26 个已知的更好版本(更多功能、更少错误、改进的性能等)。

组织正在下载和使用有时已有 9 年甚至更早历史的部件(简单的数学计算:开源项目每年发布 3-4 个新版本的组件)。他们有选择地使用过时的零件。

组织还下载了一些具有已知安全漏洞的版本。他们有选择地使用已知的易受攻击的部分。

通过改善采购进行网络创新

虽然我们经常听到人们吹捧“更快”的 DevOps 口头禅,但不惜一切代价追求速度的后果是:技术和安全债务。











开源组件是速度的推动者。但是,对所有人免费采购和使用的做法会增加技术和安全债务,从而减少“净创新”并增加运营成本。随着技术债务的增长,净创新和商业价值下降。


图片来源:http://joapen.com/blog/2014/06/17/how-to-monetize-application-technical-debt/


如果减少 100 个组件的 2,700 个版本的使用还不够激励,请考虑一下: 研究 还显示,大型开发团队正在使用来自 7,600 多个外部开源项目(供应商)的软件组件。包括这些组件的所有版本,他们平均在 2014 年组织消耗了近 19,000 个独特的组件。

改进采购实践只是改进网络创新和增加商业价值的整体故事的一部分。改进采购实践还可以实现更高效的运营,减少平均补救时间,并消除许多 DevOps 实践的计划外工作。许多行业都采用了改进的采购实践,从而获得了持续的竞争优势。改进的采购实践是更广泛的 软件供应链管理战略 的一部分。

持续学习

我们可以从其他已实现供应链自动化和优化的行业(例如 Land Rover 和其他汽车制造商)中学到很多经验教训。今年夏天,我将在这里分享更多来自 2015 年软件供应链状况的 经验教训和观点,并扩大围绕“网络创新”的讨论。敬请关注。