四年的创业基础设施经历教会我最核心的一课是：技术选型本质上是组织能力的映射。很多时候我们讨论的是 “这个工具好不好”，但真正决定成败的是 “这个工具是否能被我们的团队驾驭”。本文将从云服务选型、容器编排、数据层设计、团队流程四个维度，凝练具体决策的取舍原则与工程权衡，为早期团队提供可复用的架构决策框架。
一、云服务选型：供应商成熟度与支持体系优先
在云服务选型上，我的第一条原则是供应商的支持体系与稳定性比功能先进性更重要。我们早期同时使用 GCP 和 AWS，但很快就发现两者的支持体验天差地别：Google Cloud 的账户经理响应迟缓，而 AWS 有定期的 cadence 会议帮助评估新服务。这种差异在遇到问题时会被放大 —— 当你凌晨三点排查生产故障时，一个响应及时的技术支持账户经理可能就是决定能否快速恢复的关键因素。
具体到 AWS 内部服务选型，有几个值得参考的参数阈值。EKS（Elastic Kubernetes Service）除非你在乎每一分钱的成本且工程师时间免费，否则没有理由自建 Kubernetes 控制平面。EKS 相比 ECS 的最大优势在于生态集成 ——external-dns、external-secrets 等工具让 Kubernetes 与 AWS 服务的连接变得顺滑。值得注意的是，EKS 的 managed add-ons 看似是官方推荐方式，但实际使用中总需要定制 CPU requests、image tag 或 ConfigMap，最终我们切换到 Helm chart 方式，部署流程反而更符合现有的 GitOps 流水线。
对于数据库，数据是企业最重要的资产，失去网络是停机，失去数据是公司终结事件。RDS 的溢价成本完全值得 —— 你需要的是快速恢复能力，而不是省下这笔钱去赌命。我们使用 Redis ElastiCache 作为缓存和通用数据加速层，API 简单、文档完善、社区成熟。对于容器镜像仓库，从自托管的 Quay.io 迁移到 ECR 后稳定性显著提升，且与 EKS 节点的权限集成更加顺畅。
在 VPN 方案上，我们最终选择了 AWS VPN 配合 Okta 管理访问权限。这不是最先进的选择 ——Cloudflare 等厂商的 Zero Trust VPN 产品功能更丰富，但 VPN 的设置和理解门槛最低，「简单优先」是我的基础设施信条。唯一的遗憾是 AWS Premium Support—— 它几乎等同于再雇佣一名工程师的成本，对于内部已有一定 AWS 知识的团队来说性价比不高。
二、容器编排与 GitOps：抽象与灵活的平衡
Kubernetes 已经成为运行长期服务的标准选择，但它的灵活也是双刃剑。任何灵活性高的系统都意味着大量错误使用的方式—— 这是我在 Kubernetes 实践中体会最深的教训。我们使用 Karpenter 进行节点管理，它比默认的 Kubernetes autoscaler 和 SpotInst 都更可靠、成本效益更高。如果你在使用 EKS（而不是完全托管的 Fargate），强烈建议采用 Karpenter。
在 GitOps 实践中，我们使用 Flux v2 作为部署工具。GitOps 的优势在于灵活性 —— 它不受限于传统的流水线视角（提交 → 构建 → 部署的线性流程），但代价是需要投入额外工具帮助开发者回答「我提交了代码，为什么还没部署」这类问题。对于早期团队，这个成本需要权衡考虑。
关于 Helm，v2 的糟糕口碑有目共睹，但 v3 已经足够稳定。我们将 Helm charts 存储在 ECR OCI 注册表中，相比之前放在 S3 并使用插件下载的方式，生命周期管理更加简洁。需要注意的是 Helm 的 Go templating 语言调试困难，但在封装和版本化 Kubernetes 对象方面依然足够好用。
在 Ingress 控制器选择上，Nginx 是经典选择 —— 它古老、稳定、久经考验。我们对没有采用服务网格（Istio 或 Linkerd）没有任何遗憾。网络网格确实酷炫，但大多数公司低估了引入的复杂度。我的通用建议是：基础设施层面，少即是多。
关于 FaaS（函数即服务），我们最后悔的是没有更早、更广泛地采用 Lambda。很多成本对比的论调基于「这台 EC2 24 小时满负载运行比 Lambda 便宜」—— 这是虚假比较。现实中没有人会让服务一直跑在 100% CPU 利用率，总是会有某种 autoscaler 告诉它「永远别到 70%，到 70% 就扩容」。Lambda 还有一个隐藏优势：成本追踪极其精确，而在 Kubernetes 中，成本可能隐藏在节点层面的其他 Pod 或合租服务中。
三、数据层设计：所有权与边界清晰是核心
多应用共享数据库是我们最后悔的技术决策之一。这不是我们有意识做出的决定，而是「没有决定」的结果 —— 有人想做新功能就建新表，表之间有外键关联，看起来很自然。但由于所有东西都依赖于「某个用户是某张表的一行」这个前提，最终整个栈的所有对象之间都有了外键关系。
共享数据库的最大问题在于：数据库被所有人使用，但最终无人负责。初创公司没有 DBA，而「无人负责」的东西最终会落到基础设施团队头上。具体表现为：数据库中积累了大量 CRUD 操作产生的垃圾数据，没人敢删；出现性能问题时，不熟悉产品逻辑的基础设施团队必须 debug 并定位到具体负责人；某个团队写了有问题的代码可能触发数据库层面的 PagerDuty 报警，基础设施团队被半夜叫醒却是在为其他团队的错误擦屁股。
如果必须共享数据库，必须提前设计好数据所有权边界和清理机制。否则，越早为每个主要服务分配独立的数据库越好—— 应用团队作为第一响应者，能更快定位和解决问题。
在 Schema 迁移策略上，我们采用「Schema -diff」方式：将整个 Schema 提交到 Git，用工具生成 SQL 来同步数据库。这种方式并非完美 ——Schema 管理本身就很难，因为数据很重要，一次糟糕的迁移可能丢失数据 —— 但在所有可怕的选择中，这是我们最满意的方案。
四、可观测性与安全：锁定供应商需趁早
在监控和可观测性方面，我们最后悔的决定是直接使用 DataDog API 发送指标，没有采用 OpenTelemetry。DataDog 是优秀的产品，但它的定价模式对 Kubernetes 集群和 AI 公司尤其不友好。Kubernetes 的成本效益来自于快速扩缩容和使用 Spot 实例，而 DataDog 按实例数量计费 —— 即使同一小时内最多只有 10 个实例运行，如果实际扩缩容了 20 个实例，就要付 20 个实例的费用。AI 公司使用大量 GPU，一个 CPU 节点可能运行数十个服务分摊成本，而一个 GPU 节点通常只运行一个服务，Dataadog 按服务计费的方式让单服务成本大幅上升。
OpenTelemetry 在四年前还不够成熟，但现在.tracing 已经非常优秀。建议从一开始就用它，避免被单一供应商锁定。唯一需要注意的是 metrics telemetry 目前仍有些许不成熟。
在 Kubernetes Secrets 管理上，我们从 SealedSecrets 切换到 ExternalSecrets。前者的主要问题是让不熟悉基础设施的开发者创建和更新 Secrets 变得复杂，且失去了 AWS Secrets Manager 自动轮换等现有自动化能力。ExternalSecrets 能很好地同步 AWS Secrets 到 Kubernetes，流程简单，开发者容易理解，还能利用 Terraform 集中管理 Secrets。
证书管理使用 cert-manager 配合 Let's Encrypt，极易配置且运行良好。唯一需要准备的是应对一些不信任 Let's Encrypt 的古老客户 —— 为这些客户准备付费证书。
身份平台是另一个教训。早期我们只用 Google Workspace 创建用户组来分配权限，这远远不够灵活。应该尽早采用 Okta 这样的专业身份解决方案，并要求所有 SaaS 供应商必须与其集成。
五、团队流程：自动化与人效优先
在流程层面，我的核心原则是：优先考虑团队效率，而非外部压力。大多数公司不是基础设施本身在售卖产品，这意味着团队总面临交付功能的压力。但正如飞机安全指示要求先给自己戴氧气面罩，你必须先确保团队效率足够高才能持续交付。例外极少，我从未后悔花时间写自动化或文档。
具体实践上，用 Slack 机器人自动化 post-mortem 流程非常有效 —— 让机器人扮演「坏人」提醒大家填写事故报告，比人际关系更自然。设置两周一次的 PagerDuty 告警审视会议也很关键，告警演进的典型路径是：从无告警 → 告警太多被忽视 → 优先处理告警 → 忽略非关键告警。通过定期审视，保持告警的有效性。
月度成本追踪会议值得坚持。我们将 AWS 费用按标签和账户分组，结合服务名称（EC2、RDS 等）能清晰定位成本驱动因素。这个会议需要财务和工程共同参与，财务难以回答「这个数字是否合理」这样的工程问题。
在开发工具链上，从 JIRA 迁移到 Linear 是正确选择 —— 两者差距不是量级而是质级。Notion 作为文档工具也很好用，Database 功能让页面组织变得非常灵活。依赖更新使用 Renovatebot（而非 Dependabot），它更灵活但配置也确实复杂 —— 这是所有「不完美选项中最好的那个」的典型代表。
六、决策框架：为早期团队的可复用原则
综合四年经验，我提炼出早期团队基础设施决策的核心框架：
第一，优先选择团队能驾驭的工具。复杂工具即使功能强大，如果团队无法掌握，反而是负债。简单优先 ——VPN 就选简单直接的 AWS VPN，Ingress 就选稳定可靠的 Nginx。
第二，用成本视角而非功能视角评估选型。比较 Lambda 和 EC2 成本时不要假设 100% 利用率，比较托管数据库和自建时要考虑 DBA 成本和恢复时间。
第三，尽早锁定身份和可观测性供应商。身份用 Okta，可观测性用 OpenTelemetry，被锁定后迁移成本极高。
第四，数据层边界要清晰。每个主要服务独立数据库，共享数据库必须有明确的数据所有权和清理机制。
第五，GitOps + Helm 是 Kubernetes 部署的稳态组合。Flux 加 Karpenter 加 Helm 加 ExternalSecrets，这个组合足够覆盖大多数场景。
第六，告警和成本审视要定期化。两周一次的告警审视会议、月度成本追踪，这两件事的投入产出比极高。
最后，不要在基础设施层面追求完美。你的产品是卖给客户的，不是卖给基础设施的。在基础设施上投入足够让它不成为瓶颈即可，剩余精力应该投入到产品本身。四年间最后悔的决定几乎都是「做得太多」而非「做得太少」——SealedSecrets 过度设计、没用更多 Lambda、Bottlerocket 过度定制。少即是多，简单优先，当你有足够证据证明需要更复杂的方案时再升级。