clinging to 过时软件的成本：风险与现实

遗留软件在科技界几乎有着神话般的地位——它古老、可靠（直到它变得不可靠为止），而且常常难以替代。可能它是一个默默支撑你系统的废弃的库，或者是一个迟迟未进行的核心包更新。遗留软件的一个挑战在于，它常常隐藏在明面上，常常让人忽视。《免费和开源软件普查 III 报告的详细说明》指出，遗留软件是一个带来实际后果的持续挑战。

遗留软件，根据我们今天的定义，是指尽管有更新且更稳定的替代品，仍然被使用的过时或未维护的技术。这些工具在当时是开创性的，但现在往往成为了负担。《普查 III 报告》中提到，例如 minimist，一个 JavaScript 包，已被 yargs 超越，但仍被广泛采用。为什么？因为切换到更新的包可能比想象中更复杂。

1. 迁移成本：从一个套餐切换到另一个套餐并不总是无缝的。兼容性问题、API差异和功能错配会使升级变得复杂且耗时，即使对于经验丰富的团队也是如此。
2. “修旧如旧”的心态：许多组织认为，如果某个系统在运作，就没有必要改变它。但正如报告所强调的，遗留软件并不是静态的；它会随着时间的推移变得越来越有风险。
3. 资源限制：小型团队或组织可能缺乏时间、预算或专业知识来替换旧系统，即使他们意识到这些风险。

1. 安全漏洞：不再更新的软件是攻击者的主要目标。例如，著名的 Log4j 中的 Log4Shell 漏洞就说明了如何利用关键却已经过时的软件。（更多细节请见这里。）
2. 稳定性问题：旧工具通常缺乏更新，因此在与现代系统集成时可能会出现问题。
3. 依赖链：许多旧的库逐渐嵌入到项目中，形成了一个难以理清的依赖关系网。

想象你正在运行一个依赖于旧日志库的 web 应用程序。该库工作得很好，你的团队也没有看到立即升级的必要。然而有一天，有人发现该库存在一个关键漏洞。但是修复它并不像打个补丁那么简单——你的整个代码库依赖于一个已经弃用的 API，切换到新库需要重写应用程序的很大一部分代码。突然间，这个曾经“运行良好”的旧工具成了一个紧急危机的来源。
对于许多组织来说，维护旧软件的成本往往只有在出现问题时才变得明显。

根据《Census III》报告不仅指出问题，还提供了这些问题为什么存在以及如何解决的见解：

• 意识是关键：许多组织往往直到情况变得严重时才发现其系统中嵌入了多少遗留软件。工具如软件物料清单（SBOMs）可以帮助在这些依赖关系成为隐患之前识别它们。（了解更多关于 SBOMs 的内容 此处。）
• 支持过渡：开发人员和组织需要更好的支持来从遗留工具转向现代工具。这包括清晰的文档、社区指导以及对主动升级的激励。
• 协作并分担责任：开源社区的成功在于协作。通过共享资源和共享专业知识，大家可以通过合作降低与遗留技术相关的风险。

改变确实是艰难的，这一点毋庸置疑。但继续使用旧技术并不是一个长久之计。风险远大于便利，而拖延的成本可能非常高昂。

所以，重点是什么呢？企业和开发者们需要认识到投资于转型过程的价值。这不仅仅意味着升级库文件，还意味着创建一个优先重视进步的文化，并让社区团结起来支持那些迈出这一步的人。让社区支持那些勇于转型的人。

在科技界，“没问题”很快就会变成这样：不安全、不稳定、不可持续。正如报告所问，“为什么要修那些还没坏的东西？”因为在科技界，“没问题”很快就会变成“不安全、不稳定、不可持续”。

遗留软件讲述了一个关于创新与惯性的故事。曾经引领潮流的工具可能已经被遗忘在角落里，锈迹斑斑。挑战在于找到一个既能尊重过去又能拥抱未来的平衡点。更多详情请访问Census III。如果您想在这个季度提升技能，请查看在[工程、DevOps、系统管理、云原生等技能和认证]方面享受高达60%的折扣。