CI/CD存储瓶颈破局：为什么资深工程师重返存储赛道

为什么资深工程师会重返存储领域

在云计算基础设施日益复杂的今天，存储技术看似是一个「成熟」甚至「无聊」的领域。然而，一位经验丰富的工程师却选择加入初创公司 Blacksmith，重新投身存储系统的开发工作。这个决定背后，折射出当前 CI/CD 基础设施领域一个被长期忽视的关键瓶颈——存储与缓存的性能问题。

Blacksmith 定位为 GitHub Actions 的高性能运行器（runner）替代方案，其核心差异化在于底层基础设施的重新设计。传统 GitHub Actions 使用标准云虚拟机，存储依赖通用的云磁盘和 GitHub 自带的缓存服务（有 10GB 大小限制）。Blacksmith 通过定制化的存储栈——可能包括本地 NVMe 缓存、智能预取算法、以及针对 CI 工作负载特征优化的文件系统——实现了显著的性能提升。这类公司属于 Developer Infrastructure 赛道，与 Depot（优化 Docker 构建）、Namespace（云开发环境）等公司共同构成了新一波开发者基础设施创业浪潮。

本文将围绕这一职业选择背后的技术逻辑展开，探讨为什么在 GitHub Actions 等主流 CI 平台大行其道的当下，底层存储优化反而成为了一个值得投入的高价值方向。

CI/CD 流水线中被忽视的存储瓶颈

现代软件开发高度依赖持续集成（CI）流水线。每一次代码提交、每一个 Pull Request，都会触发大量的构建、测试和部署任务。然而，开发者常常抱怨 CI 运行速度慢，等待构建结果的时间令人沮丧。

这里有必要理解 CI/CD 的基本概念：CI/CD（持续集成/持续部署）是现代软件工程中的核心实践。持续集成要求开发者频繁地将代码合并到主分支，每次合并都会自动触发构建和测试流程。持续部署则将通过测试的代码自动发布到生产环境。GitHub Actions 是 GitHub 于 2019 年推出的内置 CI/CD 平台，它允许开发者通过 YAML 文件定义工作流，直接在 GitHub 仓库中完成从代码提交到部署的全流程自动化。由于其与 GitHub 生态的深度集成和免费额度，GitHub Actions 迅速成为开源项目和中小团队的首选 CI 方案，但其共享基础设施模式也带来了性能上限的限制。

缓存才是CI性能的核心变量

很多人将 CI 性能问题归因于计算资源不足，但实际上，存储和缓存往往才是真正的瓶颈所在。在典型的 CI 流程中：

• 依赖包的下载与恢复（如 npm、Maven、Cargo 缓存）
• Docker 镜像层的拉取与缓存
• 构建产物（artifacts）的存储与传输
• 增量编译的中间产物复用

这些环节都严重依赖高效的存储 I/O 和智能的缓存策略。存储 I/O 性能通常由 IOPS（每秒输入输出操作数）、吞吐量（带宽）和延迟三个维度衡量。在 CI 场景中，缓存策略的核心挑战在于：缓存键（cache key）的设计需要在精确匹配和模糊匹配之间取得平衡——太精确会导致缓存命中率低，太模糊则可能引入过时的依赖。此外，像 npm 的 node_modules 目录可能包含数万个小文件，这对文件系统的元数据操作性能提出了极高要求。传统的对象存储（如 S3）虽然成本低廉，但其高延迟特性使其在频繁的小文件读写场景中表现不佳。

当缓存命中率低、存储带宽受限时，即使拥有再强大的 CPU，构建速度也会被拖累。

值得特别说明的是 Docker 镜像层缓存的机制：Docker 镜像采用分层（layer）存储架构，每一条 Dockerfile 指令都会创建一个新的只读层。构建时，Docker 会检查每一层的缓存是否可复用——如果某一层的输入（指令内容和上下文文件）未发生变化，就可以直接使用缓存层而无需重新构建。在 CI 环境中，由于每次构建通常在全新的虚拟机或容器中执行，本地没有任何缓存层，导致每次都需要从头拉取基础镜像并重新构建所有层。远程缓存（如 Docker BuildKit 的 cache-to/cache-from 机制）可以缓解这一问题，但其效果高度依赖底层存储系统的读写速度。

Blacksmith 正是瞄准了这一痛点——通过重新设计底层存储架构，为 CI 工作负载提供更快的缓存读写能力，从而显著缩短构建时间。

存储技术在云原生时代的「重生」价值

对于这位选择「再次做存储」的工程师而言，吸引力恰恰在于存储是一个既古老又常新的领域。

老问题遇上新场景

存储系统的基础理论——文件系统、块存储、对象存储、缓存一致性——已经存在了数十年。但当这些经典技术遇上云原生、容器化、以及 CI/CD 的高并发短生命周期工作负载时，就产生了全新的挑战：

1. 短暂性工作负载：CI 任务通常运行几分钟后即销毁，传统持久化存储的设计假设不再适用。
2. 高并发突发流量：大量并行任务同时读写缓存，对存储系统的吞吐能力提出极高要求。
3. 成本敏感性：CI 平台需要在性能与成本之间精细权衡，无法简单堆砌高端硬件。

从技术架构的角度看，云原生存储经历了从块存储（EBS）、文件存储（EFS/NFS）到对象存储（S3）的演进，每种方案都有其适用场景。块存储提供最低延迟但与单个计算实例绑定；文件存储支持多节点共享但性能受限于网络；对象存储提供近乎无限的扩展性但延迟较高。近年来，新一代存储方案如本地 NVMe SSD 与分布式缓存层的组合架构开始流行——利用本地高速存储作为热数据缓存，远程存储作为持久化后端，这种分层架构特别适合 CI 这类「热数据集中、生命周期短」的工作负载。

这些约束条件迫使工程师重新思考存储架构的设计，而不是照搬通用云存储方案。这种「戴着镣铐跳舞」的挑战，正是资深工程师愿意回归的原因。

从职业选择看基础设施创业趋势

这个案例也反映了当前技术创业的一个重要趋势：深耕垂直基础设施。

通用云服务留下的缝隙机会

虽然 AWS、Google Cloud、Azure 等巨头提供了全面的基础设施服务，但它们的通用性也意味着无法针对特定场景做极致优化。GitHub Actions 作为默认的 CI 方案，在灵活性和性能上都留下了改进空间。

Blacksmith 这类公司的策略，是在巨头覆盖不到的「缝隙」中，为特定工作负载（如 CI 构建）提供数倍性能提升。这种「专注单点、做到极致」的打法，往往能形成差异化竞争力。这也是近年来 Developer Infrastructure 赛道持续火热的原因——随着软件开发复杂度的持续攀升，开发者对工具链各环节的性能和体验要求水涨船高，每一个被忽视的痛点都可能成长为一个有价值的细分市场。

对于工程师个人而言，加入这样的团队意味着能够：

• 触及真实的、有明确价值的技术难题
• 在小团队中承担更大的技术影响力
• 将底层系统知识转化为可衡量的业务价值

结语：基础技术永不过时

在 AI 和大模型占据科技头条的今天，选择投身存储这样的「传统」基础设施领域，看似逆流而行，实则体现了对技术本质的深刻理解。再快的计算，也需要更快的数据供给；越是上层应用繁荣，底层基础设施的优化价值就越凸显。

这位工程师重返存储战场的选择，提醒我们：技术的价值不在于「新旧」，而在于能否解决真实的痛点。在 CI/CD 效率成为开发者体验核心指标的当下，存储与缓存的优化，正是一个既有技术深度、又有商业价值的黄金赛道。

核心要点