如何避免为每个新项目重建基础设施

如何避免为每个新项目重建基础设施

来源 URL: https://www.freecodecamp.org/news/how-to-avoid-rebuilding-infrastructure-for-every-new-project/

发布时间: 2026-05-21T21:27:06.173Z

每支生产工程团队都熟悉这种模式。一个新项目开始时充满活力。产品目标很明确。截止日期很有挑战性。团队希望快速行动，交付客户可以使用的东西。

然后真正的开始了。必须配置基础设施。需要设置 CI/CD 流水线。需要管理密钥。需要连接监控。需要部署数据库。需要配置日志记录。需要实施安全策略。需要审查网络规则。

在用户看到任何有用的东西之前，几周时间就消失了。许多组织认为这是正常的。他们称之为工程严谨性。他们假设这个操作设置阶段就是软件开发的一部分。

事实并非如此。

对于已经在运行生产系统的团队来说，为每个新项目重建基础设施基础是组织浪费。这是伪装成工程学科的重复操作劳动。

令人不安的问题不是"我们如何能更快地完成这个设置？"真正的问题是：为什么我们还要自己来做这件事？

这就是 Platform as a Service 改变对话的地方。一个好的 PaaS 将起点从"重建基础"转变为"开始交付"。因为新项目应该更接近客户价值，而不是更接近基础设施组装。

在本文中，我们将探讨为什么许多生产团队在每个新项目上浪费时间重建相同的基础设施，PaaS 如何帮助消除这些工作，以及工程团队是否应该质疑管理复杂基础设施对大多数项目是否有意义。

我们将涵盖的内容：

**大多数团队不是为了构建基础设施而被雇佣的**

软件团队存在的目的是解决业务问题。客户不在乎 Kubernetes 清单是否结构优雅。他们不会欣赏精心设计的 Terraform 模块。他们不会庆祝手工制作的网络策略。

客户关心结果。他们关心更快的入职体验。更好的推荐。更顺畅的支付。更少的 bug。更简单的流程。

然而，许多工程组织花费大量时间做客户永远看不到的工作。

团队反复创建部署流水线。配置环境。管理证书。设置可观测性堆栈。调整基础设施规则。组装云原语。

基础设施很重要。可靠性很重要。安全性很重要。

问题是重复。如果每个项目独立地重新创建相同的操作系统，组织就会一遍又一遍地重建内部平台而不承认这一点。

这种行为已经变得如此正常化，以至于团队几乎不再注意到它。但是反复重建相同的基础并不是操作成熟度。它是组织范围内的低效率。

**AWS 原语不是竞争优势**

许多团队混淆了云所有权和战略优势。拥有 Kubernetes 集群并不能创造差异化。管理 IAM 规则不能创造客户价值。编写基础设施胶水代码不会加强市场地位。

这些都是实现细节。然而，许多组织花费巨大精力管理它们，好像它们是核心业务资产一样。

一些团队实际上在不知不觉中变成了兼职基础设施公司。他们的工程师慢慢积累操作职责，直到维护系统消耗的努力超过了交付产品的努力。

结果变得可预测。基础设施扩展。操作复杂性增长。交付速度下降。没有人注意到，因为痛苦是逐渐到来的。

团队从一个 Kubernetes 集群开始。然后出现另一个环境。更多部署流水线涌现。额外的工具被叠加在顶部。日志系统变得碎片化。监控在不同产品间发展得不同。

最终，团队花费越来越多的时间维护他们从未打算拥有的系统。

基础设施所有权通常不是一种策略。它是惯性。

**大多数团队不应该管理 Kubernetes**

Kubernetes 已经成为一种工程文化。它出现在架构图、会议演讲、招聘要求和内部路线图中。它的采用往往感觉不可避免。

但标准化和必要性不是一回事。许多组织采用 Kubernetes 是因为行业势头让它看起来像是默认路径。而不是因为他们有需要其复杂性的工作负载。但结果是可以预测的。

中小型团队最终管理为大规模运营环境设计的编排系统。

他们在交付有意义的产品价值之前，维护 YAML 配置、网络层、入口系统、部署策略和操作工具堆栈。这已经变得奇怪地被接受。

一个十人工程团队维护为互联网规模组织设计的基础设施模式应该引起严重质疑。一个小团队假装成为一个平台团队是一种操作功能障碍。

许多公司采用为完全不同规模的组织构建的基础设施复杂性。他们继承了负担却没有继承好处。

**PaaS 改变起点**

传统基础设施 方法迫使团队从下往上思考。首先是服务器。然后是操作系统。然后是网络。然后是部署系统。然后是监控。最终，应用程序到达。

PaaS 颠倒了这个顺序。开发人员从应用程序和业务目标开始。平台吸收了操作的复杂性。

团队不再问"我们如何配置资源？"他们开始问"我们要解决什么问题？"这听起来像是一个小的变化。实际上，它改变了一切。

一个成熟的 PaaS 环境通常在团队编写有意义的应用程序逻辑之前就提供了部署管道、集成可观测性、数据库、扩展行为、安全控制和操作标准。

项目从产品开发开始，而不是基础设施建设。这极大地改变了价值实现的时间。

组织通常低估了操作浪费，因为重复的工作让人感觉很熟悉。设置部署管道可能只消耗几天时间。配置日志记录可能感觉很常规。创建安全规则可能看起来可以管理。

没有单个任务看起来很昂贵。成本出现在重复规模扩大时。

如果十个项目独立花费两周时间重建几乎相同的操作系统，数月的工程能力就会消失。那些工程师本可以交付客户功能。他们本可以减少摩擦。他们本可以测试新想法。相反，他们重新构建了基础设施。

工程团队在几乎所有其他领域都理解杠杆作用。没有人会为每个应用程序重写排序算法。没有人会从头开始重新创建数据库引擎。没有人会反复构建网络堆栈。

重用被视为基本的工程智慧。基础设施不应受到特殊对待。一次构建。多次重用。

PaaS 只是将软件工程原则应用于操作系统。

**标准化通常比灵活性更快**

工程团队经常抵制标准化，因为他们害怕失去控制。每个项目都感觉独特。每个系统看起来都不同。对灵活性的渴望听起来很合理。

但完全的灵活性往往会创造操作混乱。不同的团队以不同的方式部署应用程序。日志记录行为不一致。监控在系统间变化。安全实施偏离轨道。

文档碎片化。入职变慢。事件响应变得更加困难。复杂性悄悄积累。

PaaS 引入约束，许多工程师本能地抵制约束。他们不应该这样做。有用的约束通常会提高速度。

可预测的部署模式减少混淆。共享监控标准简化故障排除。一致的环境减少认知负担。

开发人员花更少的精力理解基础设施差异，花更多时间交付产品功能。

一致性会累积。

**平台团队成为倍增器**

许多组织将 PaaS 解释为购买供应商产品。这错过了更大的概念。

PaaS 基本上是关于创建可重用的能力。一些组织购买平台。其他组织构建内部平台。

原则保持不变。

平台团队创建系统一次，让所有其他人受益。不是数十个产品团队独立解决操作问题，而是专门小组集中专业知识并构建可重用的解决方案。

效果变得显著。一项部署改进加速每个未来版本。一项可观测性改进加强每个应用程序。一项安全增强保护每个团队。

平台团队创造组织杠杆。没有这种模式，专业知识保持碎片化。有了它，专业知识会累积。

**更容易的开始创造更多创新**

操作摩擦改变行为。当启动项目变得昂贵时，组织变得谨慎。团队避免实验。小想法感觉有风险。原型变得难以证明合理性。

随着时间推移，创新放缓。不是因为组织缺乏想法，而是因为开始变得太昂贵。

运行成熟平台的团队了解这种关系。减少启动摩擦增加实验。较小的项目变得实用。学习周期变得更短。

新想法出现得更频繁，因为测试它们的成本大幅下降。启动某事物越容易，组织创造的机会就越多。

PaaS 减少启动摩擦。这种减少改变文化。

**何时专业化控制真正重要**

有例外情况。大规模数据平台、高度专业化的机器学习系统和极度定制的环境可能需要更低级别的基础设施所有权。

一些工作负载确实需要更深的操作控制。但这些场景是例外，不是默认情况。太多团队继承了为边缘情况设计的基础设施复杂性，并将其视为标准实践。

大多数生产应用程序不需要自定义编排层。大多数团队不需要拥有 Kubernetes。大多数工程组不需要花费数周时间组装基础设施才能发布软件。

默认假设应该是相反的。

**从零开始是一个过程失败**

许多组织使不必要的操作拖累正常化。长设置周期被接受。基础设施重复成为例行公事。云复杂性成为预期。

最终，团队停止质疑它。他们假设这只是工程工作的方式。事实并非如此。

如果启动新应用程序需要数周的基础设置才能出现客户价值，这不是工程纪律。

目标从来不是成为一家基础设施公司。而是发布软件。

免费学习编程。freeCodeCamp 的开源课程已经帮助超过 40,000 人获得开发者工作。开始学习