在快速增长的创业公司中做基础设施决策是一场持续四年的拉锯战 —— 每个选择都伴随着权衡，而时间会验证一切。Jack Lindamood 在 cep.dev 上发表的基础设施四年复盘文章，提供了极为难得的视角：亲历从零扩展到一定规模的全过程，用「认可」「后悔」「无怨」三种态度评价了数十个技术决策。这些经验对于正在搭建基础设施的工程团队而言，具有极高的参考价值。本文从可维护性、规模化成本、团队效率三个维度，提取最关键的工程教训与可操作参数。
一、基础设施选型：为何成熟生态比新潮方案更重要
1.1 Kubernetes 与 EKS：灵活性的双刃剑
在容器编排层面，作者明确「认可」使用 EKS 的决策。理由很直接：除非团队极度节约成本且时间免费，否则没有理由自己运维控制平面。EKS 的主要优势在于与 AWS 生态的深度集成 ——external-dns、external-secrets、load balancer controller 等组件已经非常成熟。更重要的是，Kubernetes 社区在 AWS 集成方面已经迎头赶上，曾经选择 GCP 做 Kubernetes 的理由已经不再成立。
但作者同时对「EKS 托管插件」表达了「后悔」。他们最初使用 AWS 托管的插件（add-ons），但很快遇到需要自定义的场景 ——CPU 请求配置、镜像标签更新、ConfigMap 调整等。作者最终转向 Helm Chart 管理这些组件，部署流程更好地融入了 GitOps 流水线。这里给出的工程教训是：托管服务虽然降低了初始运维负担，但灵活性受限会在规模化阶段成为瓶颈。团队在评估托管方案时，应该提前思考「如果需要自定义，会怎么做」。
关于 Kubernetes 本身，作者给出了一个精辟的论断：「任何有多种使用方式的系统，都会有多种错误的使用方式。」这意味着 Kubernetes 的灵活性是一把双刃剑 —— 它能适应各种场景，但也意味着团队需要投入大量精力建立使用规范。对于初创公司，作者建议使用 Karpenter 进行节点管理，这是他们测试过最可靠且成本效益最高的方案。使用 EKS 且不使用 FaaS 的团队，应该毫不犹豫地采用 Karpenter。
1.2 数据库与缓存：数据层无小事
在数据层面，作者的立场极为坚定：「认可」RDS 和 Redis ElastiCache。核心理由只有一句话：「数据是基础设施中最关键的部分。网络丢失是停机，数据丢失是公司终结事件。」使用托管数据库的溢价成本是值得的 —— 初创公司没有专职 DBA，而托管服务提供了备份、补丁、故障转移等能力的开箱即用。
Redis 的选择同样被「认可」。作者指出，Redis 相比 Memcached 提供了更多功能特性，不仅仅是缓存，还可以作为通用的快速数据存储工具。这种「瑞士军刀」式的定位使其成为多场景下的首选。
但作者对「多个应用共享一个数据库」表达了明确的「后悔」。这是典型的技术债务积累 —— 最初只是「不加思考地创建新表」，随后表中出现大量外键关联，最终变成「每个人都使用，但没有人维护」的状态。具体问题包括：数据库中积累了不确定能否删除的 CRUD 数据；性能问题时基础设施团队缺乏产品上下文，难以定位问题根源；某个应用团队的代码导致数据库问题，却由负责基础设施的团队收到 PagerDuty 告警。作者的建议是：为每个主要应用分配独立的数据库 schema 或完全独立的数据库实例，确保应用团队成为第一响应者。
1.3 容器镜像仓库：从自建到托管的迁移
从 Quay.io 迁移到 Amazon ECR 被明确「认可」。作者用「一塌糊涂的稳定性问题」形容之前的 Quay.io 体验，而 ECR 带来了显著的稳定性提升，并且与 EKS 节点和开发服务器的权限集成更加顺畅。这个决策提醒我们：镜像仓库虽然看起来是基础设施中的「小」组件，但持续不稳定会影响整个部署流水线的可靠性。
二、成本控制：被低估的隐性成本与月度审视机制
2.1 AWS 高级支持：一个值得反思的溢价
作者将 AWS 高级支持列为「后悔」决策，理由非常直接：成本几乎相当于雇用另一名工程师的价值。只有当团队内部几乎没有 AWS 专业知识时，高级支持才能体现其价值。对于拥有成熟云原生团队的创业公司，这个溢价往往不值得。这给我们的启示是：在评估企业级支持服务时，需要将「问题解决效率」与「工程师时间成本」进行量化对比，而非仅关注服务等级承诺。
2.2 Datadog 的定价陷阱：Kubernetes 与 AI 场景的特殊考量
这是整篇文章中最具警示意义的「后悔」决策之一。Datadog 本身是优秀的产品，但其定价模型对于两类场景尤为不友好：第一类是快速扩缩容的 Kubernetes 集群 ——Datadog 按实例数量计费，即使某小时内最多只有 10 个实例在线，但如果在这小时内启用了 20 个不同的实例，就需要支付 20 个实例的费用，这对于使用 Spot 实例和快速扩缩容的团队极为不利；第二类是 AI 公司使用的 GPU 节点 ——CPU 节点可以运行数十个服务，分摊每个节点的成本，而 GPU 节点通常只运行一个服务，使得每个服务的 Datadog 成本显著上升。
作者因此建议，在选择监控方案时，需要特别关注定价模型是否与实际资源使用模式匹配。对于使用 Karpenter 或类似快速扩缩容方案的团队，传统的按实例计费模式可能带来意外的高成本。
2.3 月度成本追踪会议：一个被低估的最佳实践
在所有「认可」决策中，月度成本追踪会议是最具可操作性的实践之一。作者在早期设立了每月一次的会议，由财务和工程团队共同参与，审查所有 SaaS 成本（AWS、Datadog 等）。会议的核心不是财务审核，而是「直觉检验」—— 这个数字合理吗？
具体操作方式包括：按标签和账户对 AWS 成本进行分组，结合服务类型（EC2、RDS 等）识别主要成本驱动因素；深入分析 Spot 实例使用情况和高网络成本账户。这个实践的价值在于：它建立了工程团队对基础设施成本的感知，避免了「月底收到账单才发现超支」的被动局面。
2.4 FaaS 的成本误区：被误解的 Lambda 经济性
作者对「没有更多地使用函数即服务（FaaS）」表达了后悔。常见的反驳观点是「24/7 运行的 EC2 实例比 Lambda 便宜」，但作者指出这是一个虚假的比较。实际场景中，服务不会以 100% CPU 利用率持续运行，而是依赖某种自动扩缩容策略 —— 通常设置为「永远不要达到 100%，达到 70% 就扩容」，而何时缩容回来则是一个不确定的启发式判断。Lambda 的真正优势不仅在于按调用计费，还在于成本的可追溯性 —— 在 Kubernetes 环境中，成本可能隐藏在节点级别的其他对象中，难以精确归因。
三、可维护性与供应商锁定：早该做好的基础工作
3.1 身份平台：早该采用的 Okta
「没有尽早采用身份平台」被明确列为后悔决策。最初使用 Google Workspace 组来管理员工权限，但这种方式的灵活性远远不够。作者的建议是：尽早采用 Okta 或类似的身份解决方案，它几乎与所有 SaaS 服务都有集成，能解决大量合规和安全问题。这个决策的核心教训是：身份与访问管理是基础设施的「横向能力」，在早期搭建好基础，后续接入新工具时会省去大量麻烦。
3.2 可观测性：OpenTelemetry 的 vendor-neutral 价值
「没有尽早使用 OpenTelemetry」同样被列为后悔。最初直接使用 Datadog API 发送指标，导致后续很难切换到其他供应商。OpenTelemetry 在四年前还不够成熟，但现在已经足够完善 —— 指标（metrics）部分尚在发展中，但追踪（tracing）已经非常好。作者的建议是：从一开始就使用 OpenTelemetry，这样可以在不修改应用代码的情况下切换监控后端。
这个决策给我们的启示是：在选择与供应商深度集成的工具时，需要考虑「如果将来要迁移，成本有多高」。可观测性是基础设施中更换成本最高的领域之一，因为应用代码中会散布大量监控 API 调用。vendor-neutral 的方案虽然短期功能可能不如原生集成，但长期灵活性价值更高。
3.3 GitOps 与 Terraform：版本控制即基础设施
GitOps 被明确「认可」，尽管需要额外投资工具来回答「我提交了代码，为什么还没部署」这类问题。核心优势在于灵活性 —— 可以统一管理服务、Terraform 配置和各类配置。但作者也承认，传统的流水线式工作流在可视化方面更直观。
在 Terraform 与 Pulumi/CDK 的选择上，作者选择了前者并「无怨」。理由是 Terraform 的 HCL 虽然限制性强，但恰恰是这种限制性帮助控制了复杂度 —— 复杂代码在 HCL 中比在通用编程语言中更显而易见。作者的做法是使用「中间层」方案：生成基本 Terraform 代码骨架，抽象掉重复部分。
3.4 密钥管理：从 SealedSecrets 到 ExternalSecrets 的演进
这是另一个值得关注的「后悔」转「认可」决策。最初使用 SealedSecrets 管理 Kubernetes 密钥有两个主要问题：对不熟悉基础设施的开发者来说创建和更新密钥太复杂；丢失了 AWS 原生提供的密钥轮换自动化（如 RDS 凭证自动轮换）。迁移到 ExternalSecrets 后，同步 AWS 到 Kubernetes 密钥的流程对开发者更加友好，同时保留了 Terraform 管理密钥的能力和 AWS Secrets Manager 的 UI。
这个决策的教训是：在 Kubernetes 生态中，选择密钥管理方案时需要同时考虑开发者体验和与云服务商原生服务的集成度。
四、团队效率：自动化与文档的长期回报
4.1 优先级：团队效率优先于外部需求
作者「认可」的一个核心原则是：始终优先考虑团队效率而非外部需求。在产品压力下，很容易牺牲自动化和文档工作来「更快交付功能」。但作者的经验是：「除了极少数例外，我从未后悔花时间写一些自动化脚本或文档。」这与飞机安全提示「先给自己戴好氧气面罩」同理 —— 只有团队高效了，才能更好地支持业务需求。
4.2 告警疲劳的演进路径
关于告警的演进路径，作者给出了一个几乎所有运维团队都会经历的四阶段模型：第一阶段完全没有告警；第二阶段告警太多导致被忽略；第三阶段优先级排序后只有关键告警会唤醒值班人员；第四阶段非关键告警被完全忽略。作者的解决方案是每两周举行一次 PagerDuty 评审会议，逐个审视告警 —— 关键告警讨论是否保持为关键，非关键告警则通过调整阈值或创建自动化来解决。
4.3 故障复盘：用 Notion 而非专门的 incident management 工具
作者「后悔」使用 Datadog 或 PagerDuty 内置的故障复盘功能，因为它们难以定制化。改用 Notion 后，可以完全控制复盘模板的格式和流程。类似的，使用 Slack 机器人自动化故障复盘流程 —— 在事件发生特定时间后提醒相关人员发布更新，或在规定时间内提醒安排复盘会议。自动化让机器人扮演「提醒者」的角色，比人工催促更不容易引发抵触。
五、技术债务与权衡：没有完美的选择
5.1 服务网格：复杂度被低估
作者对没有使用服务网格（Istio/Linkerd 等）表示「无怨」。他们的观点很明确：服务网格功能强大，但大多数公司低估了引入的复杂度。基础设施的一般原则是「少即是多」—— 在真正需要服务网格的复杂场景之前，避免过早引入。
5.2 Nginx 与 Ingress：稳定压倒一切
Nginx 作为 EKS 的 Ingress 解决方案被标记为「无怨」。作者的选择理由非常朴素：Nginx 历史悠久、经过充分测试、稳定可靠。这反映了作者的核心基础设施哲学 —— 在基础设施层面，稳定性通常比功能丰富度更重要。
5.3 Bottlerocket 的教训：从尝试到回归
使用 Bottlerocket 运行 EKS 节点被列为「后悔」—— 主要问题在于频繁遇到网络 CSI 相关问题，且 Bottlerocket 镜像的调试比标准 EKS AMI 困难得多。最终回归到 EKS 优化版 AMI，后者提供了更好的稳定性，并且保留了调试节点的「后门」。
六、决策清单：创业公司基础设施关键原则
综合上述复盘，以下是可以直接指导决策的关键原则：
技术选型层面，优先选择有成熟生态和深度云服务商集成的方案；避免过早使用托管服务的自定义功能，评估托管方案时要思考自定义需求；Kubernetes 是运行长期服务的首选，但需要建立严格的使用规范。
成本控制层面，对溢价型企业支持服务进行严格的 ROI 计算；关注监控工具的定价模型是否与实际资源使用模式匹配；建立月度成本审视机制，让工程团队对成本有持续感知；重新评估 FaaS 的成本优势，考虑实际利用率而非理论峰值。
可维护性层面，尽早采用身份管理平台，不要依赖 Google Workspace 组这类权宜之计；从一开始就使用 OpenTelemetry 等 vendor-neutral 方案；为每个主要应用分配独立的数据库所有权；密钥管理方案需要同时考虑开发者体验和云服务商集成。
团队效率层面，永远优先保障团队效率，自动化和文档的短期投入会在长期获得回报；建立定期告警评审机制，每两周审视一次；用 Slack 机器人自动化流程提醒，用 Notion 等灵活工具管理故障复盘。
整体哲学层面，「简单优于复杂」—— 成熟、稳定、经过充分测试的方案通常是更好的选择；接受技术债务的存在，但要有意识地管理它 —— 共享数据库等决策在当时合理，但要清醒认识其长期代价。
资料来源：本文核心内容来自 Jack Lindamood 在 cep.dev 发表的文章《(Almost) Every infrastructure decision I endorse or regret after 4 years running infrastructure at a startup》。