Karpenter 开源地址： github.com/kubernetes-…
本文由 Anthropic 工程师 Jack Lindamood 撰写，分享了他之前在一家初创公司中负责IT基础设施的经验，包括从中吸取的教训和一些最佳实践。
过去四年里，我负责了一家初创公司的基础设施建设工作。这家公司当时正寻求快速扩大规模。从一开始，我们就做出了一些核心决策，这些决策在过去四年中一直影响着公司，不管结果是好是坏。在这篇文章中，我将列出一些主要的决策，并分享我是否推荐这些决策适合你的初创公司，或者如果我后悔了，我会建议你选择其他方案。
文章分为上下两篇，本文为上篇，关注「CloudPilotAI」及时获取下篇更新。
AWS
选择 AWS 而不是谷歌云
🟩 推荐
早期，我们同时使用了 GCP 和 AWS。那时候，我根本不知道 Google Cloud 的“客户经理”是谁，而与此同时，我却能定期与 AWS 的客户经理开会沟通。这让我感觉 Google 更倾向于依赖自动化和系统化流程，而 Amazon 则专注于客户体验。
这种支持在我们评估和尝试新 AWS 服务时非常有帮助。除了出色的支持之外，AWS 在稳定性方面表现突出，并且尽可能避免向后不兼容的 API 变更，这一点值得称赞。
曾经，Google Cloud 是 Kubernetes 集群的首选，尤其是在 AWS 是否会倾注资源到 EKS 而非 ECS 还存在不确定性的时候。然而现在，AWS 针对 Kubernetes 的深度集成（如 external-dns、external-secrets 等）让开发者的工作更加高效和便捷。这些改进让 AWS 成为 Kubernetes 生态中一个可靠的选择，这方面的担忧已经完全消除了。
EKS
🟩 推荐
除非你预算极其紧张（并且你的时间毫无成本可言），否则没有理由自己运行控制平面，而不选择使用 EKS。使用 AWS 内其他替代方案（如 ECS）的主要优势在于它与 AWS 服务的深度集成。幸运的是，Kubernetes 在许多方面已经迎头赶上，比如通过 external-dns 与 Route53 集成。
EKS 托管插件
🟧 不推荐
一开始，我们选择了 EKS 的托管插件，因为我认为这是使用 EKS 的“正确方式”。但遗憾的是，我们总会遇到需要自定义安装的情况，比如调整 CPU 请求、镜像标签，或者修改某些 configmap。后来，我们改用 Helm chart 来管理这些原本是插件的功能，现在一切运行得更加顺畅，同时还能与我们现有的 GitOps 流水线无缝衔接。
RDS
🟩 推荐
数据是你基础设施中最重要的部分。网络中断可能会导致停机，但如果数据丢失，那可能直接导致公司灭亡。使用 RDS（或任何托管数据库）的额外成本是完全值得的。
Redis ElastiCache
🟩 推荐
Redis 在缓存和通用用途方面表现优异。它速度极快，API 简单且文档清晰，且经过长期实战检验。与 Memcached 等其他缓存方案不同，Redis 提供了许多额外功能，使它不仅仅是一个缓存工具。它几乎是一个全能工具，适用于各种“快速数据处理”场景。
虽然有时我对 Redis 在各大云服务商中的情况心存疑虑，但由于它在 AWS 用户中的广泛应用，我相信 AWS 会持续提供优质的支持。
ECR
🟩 推荐
我们最初将镜像托管在 quay.io 上，但那时稳定性问题不断。自从迁移到 ECR 后，情况变得稳定了许多。ECR 与 EKS 节点和开发服务器的深度权限集成也是一个很大的优势。
AWS VPN
🟩 推荐
市场上有像 CloudFlare 这样的公司提供零信任 VPN 替代方案。我相信这些产品运行得很好，但 VPN 的设置和使用简直太简单明了（“简单为佳”是我的座右铭）。我们使用 Okta 来管理 VPN 访问，体验非常好。
AWS Premium Support
🟧 不推荐
它非常昂贵：几乎与聘请一位工程师的费用相当（甚至更多）。我认为如果我们对 AWS 的内部知识非常匮乏，那么这项服务可能是值得的。
Control Tower Account Factory for Terraform
🟩 推荐
在集成 AFT（Account Factory for Terraform）之前，使用 Control Tower 非常繁琐，主要是因为自动化实现非常困难。自从将 AFT 集成到我们的技术栈后，账户创建流程变得更加顺畅。AFT 还简化了账户标签的标准化过程。
例如，我们为生产环境账户添加了一个标签，这使得我们可以基于标签做出相应的决策。对我们而言，标签比组织结构更有效，因为“哪些属性能描述此账户”并不总是遵循树形结构。
协作流程优化
使用 Slack 机器人自动化复盘提醒
🟩 推荐
每个人都很忙。提醒大家填写复盘分析报告时，可能会让你感觉像是“坏人”。让机器人来担任“坏人”角色效果很好。它通过提醒团队成员遵循公司内部的复盘流程，简化了整个过程。
开始时不需要太复杂。仅仅是一些基本的提醒，比如“已经一个小时没有更新了，谁来发布一下进展？”或“已经一天没有日程安排了，谁来安排一下复盘分析会议？”这些简单的提醒就能起到很大的作用。
使用 PagerDuty 的事件模板
🟩 推荐
为什么要重复造轮子呢？PagerDuty 提供了一个应急响应模板，详细列出了处理事件的步骤。我们根据自己的需要做了一些定制，得益于 Notion 的灵活性，调整起来非常方便，但这个模板一直是我们很好的开始。
response.pagerduty.com/after/post_…
定期审查告警工单
🟩 推荐
公司在设置告警时经历了这样的过程：
-
一开始没有告警。我们意识到需要告警。
-
有了告警，但数量过多，导致我们忽视了它们。
-
我们对告警进行了优先级划分，现在只有关键告警会把我叫醒。
-
我们忽略了非关键告警。
我们有一个两级告警系统：关键告警会直接叫醒工程师，非关键告警则通过异步方式（邮件）提醒值班人员。问题是，非关键告警常常被忽视。为了解决这个问题，我们每两周（通常是）召开一次告警审查会议，讨论所有的告警。对于关键告警，我们会评估是否仍然需要将其等级设置为关键。然后，我们逐一查看非关键告警（通常每次挑选几个进行讨论），并分析如何处理这些告警（例如调整阈值或创建自动化流程）。
每月成本跟踪会议
🟩 推荐
一开始，我设立了每月一次的会议，专门审查我们所有的 SaaS 成本（如 AWS、DataDog 等）。之前，这只是从财务角度进行的审查，但财务团队很难回答一些关于“这个成本数字是否合理”的问题。在这些会议中，通常财务和工程部门的成员都会参加，我们会逐一检查每一份与软件相关的账单，并对“这个账单是否合理”进行初步评估。我们会深入分析一些高额账单，尝试拆解其组成部分。
例如，在 AWS 上，我们根据标签对项目进行分组，并按账户进行分类。这两个维度，再加上通用的服务名称（如 EC2、RDS 等），能帮助我们更清楚地了解主要的成本驱动因素。我们会进一步分析这些数据，比如深入研究 spot 实例的使用情况，或哪个账户产生了最多费用。但不要仅限于 AWS，还可以检查公司所有主要的支出项。
在 DataDog 或 PagerDuty 中管理复盘分析
🟥 非常不推荐
每个人都应该进行复盘。DataDog 和 PagerDuty 都有集成功能来管理复盘分析的撰写，我们也尝试过这两者。不幸的是，它们都使得定制化的分析流程变得困难。考虑到像 Notion 这样强大的类 Wiki 的工具，我认为使用这类工具来管理复盘结果会更好。
未充分使用函数即服务（FaaS）
🟥 不推荐
目前没有适合运行 GPU 工作负载的 FaaS 选项，这也是我们无法完全转向 FaaS 的原因。然而，许多 CPU 工作负载是可以使用 FaaS 的（如 Lambda 等）。反对的人通常认为成本太高。他们可能会说：“这个 EC2 实例类型全天候运行、满负荷工作，成本比 Lambda 运行要便宜得多。”这确实是事实，但这种比较并不完全公平。因为没有人会让服务长时间保持 100% CPU 使用率并持续运行。
通常，服务会通过自动扩缩容机制来控制负载，例如“始终避免达到 100% CPU 使用率，达到 70% 时自动扩容”。而且，何时缩容往往不明确，通常使用一种条件性规则：“如果 CPU 使用率在 10% 以上持续 10 分钟，则开始缩容。”
此外，许多人在使用 EC2 实例时会选择 Spot 实例，但它们存在中断的风险。（spot.cloudpilot.ai 可以帮助你查看 spot 实例的实时价格、中断情况以及历史价格趋势）
Lambda 另一个不容忽视的优点是，它能让我们更准确地跟踪成本。在 Kubernetes 中部署服务时，成本往往会被其他节点级别的资源或同一节点上运行的多个服务所掩盖。
GitOps
🟩 推荐
到目前为止，GitOps 运行得相当顺利，我们在基础设施的许多部分都使用了 GitOps，包括服务、Terraform 和配置等。
GitOps 的一个主要缺点是，与传统的流水线工作流相比，GitOps 需要更多的工具支持来帮助团队理解和追踪流程。在传统的工作流中，流水线的各个阶段通常有清晰的可视化界面，能直观地看到“你做了提交，然后按顺序依次进行下一步操作”。而在 GitOps 中，团队可能会遇到像“我已经提交了代码，为什么还没有部署？”这样的困惑，且难以通过传统流水线的可视化界面来解决。
尽管如此，GitOps 的灵活性为我们带来了巨大的好处，我强烈推荐你们在公司中使用 GitOps。
优先考虑团队效率，而非外部需求
🟩 推荐
大概率情况下，你的公司并不是在销售基础设施，而是销售其他产品。这会给基础设施团队带来压力，迫使他们专注于交付新功能，而忽视了扩展和优化自身工作量的需求。但就像飞机上的安全提示建议你先为自己戴上氧气面罩再帮助别人一样，你需要先确保团队的高效运作。除非是极少数特殊情况，否则我从未后悔过优先抽时间编写自动化工具或整理文档。
多个应用共享数据库
🟥 非常不推荐
像大多数技术债务一样，这并不是我们主动做出的决定，而是我们没有避免做出的决定。最终，某个团队希望产品能实现新功能，并且创建了一个新表。表之间有了外键关系，表面上看似很有条理，但由于每个表的“所有者”通常是某一行数据，这就意味着整个系统中的所有对象都会相互关联。
由于数据库是由所有团队使用的，最终却没有人真正负责它。初创公司通常没有数据库管理员（DBA）的角色，最终“没有人负责”的数据库就会由基础设施团队来管理。
共享数据库的最大问题有：
-
数据库中的垃圾数据不断积累，但很难判断是否可以删除。
-
当出现性能问题时，基础设施团队（通常缺乏深刻的产品知识）不得不调试数据库，找出需要联系的责任团队。
数据库用户可能会推送不良代码，造成数据库出现问题。这些问题可能会触发告警，通知基础设施团队（因为他们负责数据库）。当其他团队的问题被转交给基础设施团队时，尤其是深夜接到告警，感觉十分糟糕。如果数据库是应用团队所拥有的，应用团队应该是第一响应者。
尽管如此，我并不完全反对某些架构下共享一个数据库。只要充分意识到上述的利弊，并有一个明确的管理方案来应对这些问题，就可以考虑这种做法。
SaaS
早期未采用身份管理平台
🟥 不推荐
刚开始时，我坚持使用 Google Workspace，通过创建员工组来分配权限，但它的灵活性实在不够。事后看来，我真希望我们能早点使用 Okta。它非常有效，几乎支持所有集成，并解决了许多合规性和安全性问题。在早期就选择一个身份管理解决方案，并只选择与之集成的 SaaS 供应商，这样会更有利。
Notion
🟩 推荐
每个公司都需要一个存放文档的地方。Notion 是一个很好的选择，比我过去使用过的工具（如 Wiki、Google Docs、Confluence 等）都要更加便捷。它的数据库概念让页面的组织方式变得更加灵活，也使我能够创建更复杂的页面结构。
Slack
🟩 推荐
Slack 作为默认的沟通工具非常出色，但为了减少压力和噪音，我建议：
-
使用 thread 来集中沟通内容
-
设定预期，告知大家可能不会很快回复消息
-
避免私信，鼓励使用公共频道
从 Jira 转向 Linear
🟩 推荐
这两者差距非常大。Jira 太臃肿了，我甚至担心在一家 AI 公司使用它，可能会让它变得完全具有自我意识。当我使用 Linear 时，我常常会想：“我能做到 xx 吗？”然后我一试，结果发现完全可以！
未使用 Terraform Cloud
🟩 不后悔
刚开始时，我尝试将我们的 Terraform 迁移到 Terraform Cloud，最大的缺点是无法证明其成本的合理性。后来我将其迁移到了 Atlantis，使用起来相当顺利。在 Atlantis 存在不足之处时，我们在 CI/CD 流水线中编写了一些自动化来弥补。
使用 GitHub Actions 进行 CI/CD
🟧 推荐...吧
我们和大多数公司一样，将代码托管在 GitHub 上。最初我们使用的是 CircleCI，但后来切换到了 GitHub Actions 进行 CI/CD。GitHub Actions 提供了一个庞大的 action 市场，供你在工作流中使用，且语法易于阅读。
GitHub Actions 的主要缺点是对自托管工作流的支持非常有限。我们在 EKS 上使用 actions-runner-controller 来托管自托管的 runners，但集成常常存在一些 bug（不过我们能够解决）。希望 GitHub 在未来能更加重视 Kubernetes 自托管的支持。
Datadog
🟥 非常不推荐
Datadog 是一个很棒的产品，但它非常昂贵。不仅如此，我还担心它的定价模型对于 Kubernetes 集群和 AI 公司来说尤其不友好。Kubernetes 集群在快速启动和停止多个节点以及使用 Spot 实例时最具成本效益。
而 Datadog 的定价模型是基于实例数量的，这意味着即使我们同时运行的实例不超过 10 个，如果在一个小时内启动和停止了 20 个实例，我们仍然需要为这 20 个实例付费。
类似地，AI 公司通常会大量使用 GPU。虽然 CPU 节点可能会同时运行多个服务，从而将每个节点的 Datadog 成本分摊到多个用例上，但 GPU 节点可能只有一个服务在使用，这使得每个服务的 Datadog 成本要高得多。
PagerDuty
🟩 推荐
PagerDuty 是一个很棒的产品，且价格合理。我们从未后悔选择它。
本文为上半部分，介绍了 IT 基础设施团队在云、协作流程以及 SaaS 产品做出的决策以及从中吸取的经验教训。在下篇中，将介绍基础设施技术栈的选择。
