慢速软件：为高延迟系统开发辩护

# 慢软件：高延迟系统开发的理由 来源：https://www.sigops.org/2026/slow-software-the-case-for-high-latency-systems-development/ 系统研究追求效率与性能。过去十年，我从事超低延迟系统的工作：Demikernel 及其相关的纳秒级系统（如 Cornflakes、Capybara）的目标是用更少的周期做更多的事。AI 编程将同样的效率带到了系统构建中，让更少的程序员编写更多的代码。然而，这也使得开发速度与软件重要性脱钩，导致故障频发且“影响范围广”（https://www.businessinsider.com/amazon-tightens-code-controls-after-outages-including-one-ai-2026-3）。这些问题只会变得更糟，除非我们找到一种方式，让*慢软件*在最关键的系统中强制实施深思熟虑的设计与开发。 ## 背景：天然缓慢的系统 直到现在，系统构建一直是耗时的。首先，底层系统开发通常与硬件绑定，硬件需要物理构建和部署。其次，系统软件的部署可能很慢；它通常需要软件被物理交付和安装，或者需要整个系统重启或替换。最后，使用基本工具（通常是汇编或 C）构建大型系统意味着实现的复杂性限制了开发速度。 这些障碍在开发速度与系统重要性之间强加了一种粗略的关联。软件越依赖某个系统，实现和更新它所需的努力就越多。同样，系统故障的影响范围越大，自然就会花更多时间来构建系统并确保其不会失败。 在过去 20 年里，这些障碍已被系统地消除。超大规模数据中心建设速度前所未有，并持续部署新硬件。大多数软件运行在集中式云上，可以实现每周甚至更频繁的更新。AI 虽不完美，但已极大地加快了使用基本工具编写系统代码的速度。随着时间的推移，软件的重要性已经与开发时间完全脱钩。 这种脱钩让人们把系统软件当作其他任何软件一样对待。同样的推动使用 AI 的趋势被平等地应用到各个领域，包括我们的测试基础设施、网络路由、数据中心管理和操作系统。最近的工作（https://www.sigops.org/2026/let-the-barbarians-in-how-ai-can-accelerate-systems-performance-research/）强调了如何利用 AI 在不理解整个系统甚至没有实现优化的情况下提升系统性能。程序员正在快速做出更改，而不理解系统或我们用来推理底层基础设施的保证。 虽然这种方法对许多软件来说效果很好，但它对系统构建有影响。举一个具体的例子，分布式系统依赖于底层存储层提供的一致性保证。然而，今天的存储系统通常具有复杂的弱一致性模型，这些模型文档不全，且如果不将存储系统的整个代码库添加到训练上下文中（这可能不可用或本身在不断变化），AI 模型可能无法正确理解。结果，AI 模型可能会更改某些违反一致性假设的代码，而这很容易被程序员忽略。 这种态度导致了可预见的副作用。不可避免地，某些东西会出故障（因为人类和 AI 都不完美）。只有到那时差异才会显现，因为广泛的影响范围会拖垮许多依赖单个故障系统的其他服务。打个比方，我们都使用快速廉价制造的现实世界产品（例如加工食品、宜家家居），但也想要一些并非如此的产品（例如水果蔬菜、道路桥梁）。我们不一定有好的方法来区分两者，直到出了问题（例如健康问题出现、桥梁倒塌），因此学习区分重要的基础设施服务与其他不那么关键的软件非常重要。 ## 慢软件运动 这促使我们重新建立软件系统重要性与开发时间之间的关联。人们需要时间考虑他们的设计决策，而迫使他们放慢速度就强加了这种时间。因此，我提出*慢软件运动*，类似于慢食运动，它敦促我们更认真、更体贴地对待我们的饮食。同样，目标不是放慢所有软件的开发，而是识别出重要的基础设施软件，在这些软件中，较慢的开发速度是一个特性，而不是缺陷。 更具体地说，软件上的依赖越多，就应该投入更多的努力来开发它。故障的影响越大，就应该投入更多的努力来避免故障。有经验的程序员可以做出这种区分：Mark Russ 最近谈到（https://dl.acm.org/doi/10.1145/3779312）他是如何知道哪些代码需要读、哪些不需要，并主张通过指导计划将同样的经验传授给其他人。然而，我相信这种直觉不必完全从经验中学习，我们可以将某些东西构建到开发环境中来提供帮助。 不仅新程序员需要花时间思考这些并学习，经验丰富的程序员也应该如此。应该清楚哪些软件需要更多思考，哪些不需要。在没有自然阻力的情况下，我们或许可以引入人为障碍，促使程序员在实现重要内容时更有“投入感”。他们最终需要投入时间来维护软件，而一开始写得快只意味着以后出问题时更痛苦，尤其是对年轻程序员而言。 注意，我并不是说我们不应该使用 AI 来编写代码。它对于快速原型化想法或编写繁琐重复的代码显然很有用。如果我正在构建一个新系统，我不需要整个工程师团队来编写编译脚本、测试基础设施或评估框架。如果我想尝试不同的缓存算法，我不必手动实现所有算法。然而，这些代码在故障时影响范围很小，因此应该开发得更快。另一方面，更快的系统构建是有代价的，这些代价在编写代码时就应该显现出来，而不仅仅是在以后修复时。 ## 系统研究的机会 这对系统研究意味着什么？思考我们构建的任何系统背后的动机始终很重要。过去，原型化一个想法成本高昂，因此几乎所有值得构建的想法都值得发表（例如，参见第一个 SOSP 议程）。现在这个障碍已经被移除，因为实现原型变得极其廉价，结果我们的会议被大量考虑不周的投稿淹没。学生和研究人员不再在实现之前仔细思考一个想法是否好，而是直接实现并提交，把思考这个想法是否能成为有用贡献的艰苦工作留给了审稿人。 不幸的是，这就像试图猜测一个建筑的模型在不太理想的天气条件下是否能够屹立或持续数十年。有经验的审稿人，他们几十年来一直在构建和维护系统，通常能做出判断，但这将研究中最难的部分从学生转移到了审稿人身上，并且会迅速耗尽经验丰富的审稿人。我们需要某种节流机制——以前是由原型化的难度强加的——来强化系统研究需要以更慢、更深思熟虑的节奏进行的必要性。 我们不应该责备或忽略过去十年加速系统研究步伐的因素，但我们也不应该过分依赖它们。相反，我们需要专注于研究，重新确立系统开发的最佳实践。我们应该积极尝试找出如何判断系统的实用性和可维护性，以及性能和通用性，并迫使论文作者在这些维度上证明他们的决策。虽然我没有所有的答案，但系统社区过去已经适应过变化，我相信他们会再次做到。