共计 8392 个字符，预计需要花费 21 分钟才能阅读完成。
Hacker News 帖子
过年这段时间，Hacker News 上也涌现了不少好帖子，除了霸榜的 Sora 外，技术贴最靠前的就是这篇 (Almost) Every infrastructure decision I endorse or regret after 4 years running infrastructure at a startup。作者依据过来 4 年在一家守业公司里负责基础设施的经验，复盘了简直每一个基础设施选型的得失。作者所在的公司叫 Cresta，其实是硅谷一家规模不小的公司了，还是由国人创建的，做客户联系核心 (Contact Center) 的解决方案。
AWS
抉择 AWS 而不是谷歌云
✅ 点赞
晚期，咱们同时应用 GCP 和 AWS。在那段时间里，我不晓得我的谷歌云「客户经理」是谁，与此同时，我定期与咱们的 AWS 客户经理散会。有一种感觉是谷歌依赖机器人和自动化，而亚马逊则专一于客户。这种反对在评估新的 AWS 服务时对咱们很有帮忙。除了反对外，AWS 在稳定性方面做得十分好，并且尽量减少向后不兼容的 API 更改。
已经有一段时间，Google Cloud 是 Kubernetes 集群的抉择，特地是当 AWS 还没有决定是否要投入 EKS 时。然而当初，在 AWS 服务四周减少了许多额定的 Kubernetes 集成（如 external-dns、external-secrets 等），这个问题曾经不再重要了。
EKS (AWS 容器托管服务 Elastic Kubernetes Service)
✅ 点赞
除非你很勤俭（而且你认为本人的工夫是收费的），否则没有理由本人运行管制立体，而不是应用 EKS。在 AWS 中应用 ECS 等代替计划的次要劣势是与 AWS 服务的深度集成。侥幸的是，Kubernetes 在许多方面曾经赶上：例如，应用 external-dns 与 Route53 集成。
EKS managed addons (EKS 托管插件）
❌ 打脸
咱们最后抉择了 EKS 托管的插件，因为我认为这是应用 EKS 的「正确」形式。可怜的是，咱们总是遇到须要自定义装置自身的状况。兴许是 CPU 申请、镜像标签或某些配置映射。起初咱们转而应用 Helm Chart 来代替插件，当初所有都运行得更好了，并且与咱们现有的 GitOps 流水线相匹配。
RDS (AWS 关系数据库服务)
✅ 点赞
数据是您基础设施中最要害的局部。如果网络挂了，那就停机。如果失落了数据，那公司就挂了。应用 RDS（或任何托管数据库）的额定老本是值得的。
Redis ElastiCache
✅ 点赞
Redis 作为缓存和通用产品体现十分杰出。它速度快，API 简略且文档欠缺，实现通过了大量测试。与其余缓存选项（如 Memcached）不同，Redis 具备许多性能，使其不仅实用于缓存。它是一个「做疾速数据处理」的绝佳瑞士军刀。我对云服务提供商中 Redis 的前景感到不确定，但我感觉因为 AWS 客户宽泛应用它，AWS 将会持续很好地反对它。
ECR (AWS 容器镜像服务）
✅ 点赞
咱们最后托管在 quay.io 上。那里的稳定性问题一团糟。自从迁徙到 ECR 后，状况变得更加稳固。与 EKS 节点或开发服务器进行更深刻的权限集成也是一个重大劣势。
AWS VPN
✅ 点赞
CloudFlare 等公司也有 Zero Trust VPN 的代替计划。我置信这些产品运作良好，但 VPN 只是如此简略易懂（「简略就好」是我的座右铭）。咱们应用 Okta 来治理咱们的 VPN 拜访，这是一次很棒的体验。
AWS 高级反对
❌ 打脸
这太贵了：简直（如果不是更多的话）比另一位工程师的老本还要高。我认为，如果咱们对 AWS 知之甚少，那么这个费用就是值得的。
Control Tower Account Factory for Terraform
✅ 点赞
在集成 AFT 之前，应用控制塔很苦楚，次要是因为很难自动化。自从咱们将 AFT 整合到咱们的技术栈中后，启动账户工作就很顺利。AFT 让另一件事变得更容易，那就是为咱们的账户标准化标签。例如，咱们的生产账户有一个标签，而后咱们能够用它来做 peering 决策。对于咱们来说，标签比组织更无效，因为「哪些属性形容这个账户」并不总是一个树形构造。
流程
通过 Slack 机器人自动化复盘流程
✅ 点赞
每个人都很忙。揭示他人填写复盘报告可能让你感觉本人是「好人」。让机器表演好人的角色成果很好。它通过促使人们遵循 SEV 和复盘程序来简化流程。
开始时不用太简单。只需根本的「曾经一个小时没有音讯了，有人更新一下」或者「曾经一天没有日历邀请了，有人安顿一下预先总结会议」，就能够走得更远。
应用 PagerDuty 的故障模版
✅ 点赞
为什么要反复造轮子呢？PagerDuty 公布了一份对于事变期间该做什么的模板。咱们稍作定制，这就是 Notion 灵活性派上用场的中央，但它的确是一个很好的终点。
定期回顾 PagerDuty 上的工单
✅ 点赞
公司的警报状况如下：
- 基本没有任何警报。咱们须要警报。
- 咱们有警报。有太多的警报，所以咱们疏忽它们。
- 咱们曾经对这些警报进行了优先级排序。当初只有要害的那些才会叫醒我。
- 咱们疏忽非关键的警报。
咱们设置了两个档次的告警零碎：要害和非关键。要害告警会立即告诉到人。非关键告警将通过值班异步（电子邮件）告诉值班人员。问题是，非关键告警常常被忽视。为解决这个问题，咱们定期（通常每 2 周一次）举办 PagerDuty 审查会议，在会上审核所有的告警状况。对于重要告警，咱们探讨是否应该放弃其重要性不变。而后，针对非重要性告警（通常每次选取几个），探讨如何革除它们（通常调整阈值或创立一些自动化）。
开销追踪月会
✅ 点赞
早些时候，我设立了一个每月会议，审查咱们所有的 SaaS 老本（AWS、DataDog 等）。以前，这只是从财务角度进行审查的事件，但他们很难答复对于「这个老本数字是否正确」的一般性问题。在这些会议上，通常有财务和工程人员加入，咱们会查看咱们收到的每份与软件相干的账单，并对「这个老本是否正当」进行直觉测验。咱们深入研究高额账单中的各项数字，并尝试将其合成。
例如，在解决 AWS 时，咱们按标签对我的项目进行分组，并按帐户进行辨别。这两个维度联合个别服务名称（EC2、RDS 等）让咱们大抵理解次要老本驱动因素所在。利用此数据做出的一些操作包含更深刻地钻研 spot 实例应用状况或哪些帐户占了网络费用的大头。但不要仅限于 AWS：应该染指公司所有次要收入点所波及的全副重要开销畛域。
在 DataDog 或者 PagerDuty 里治理复盘报告
❌ 打脸
每个人都应该进行复盘报告。DataDog 和 PagerDuty 都有集成来治理编写复盘报告，咱们尝试过每一种。可怜的是，它们都很难定制化复盘报告流程。思考到像 Notion 这样功能强大的 wiki 工具，我认为最好应用相似的工具来治理复盘报告。
没有尽可能多地应用函数即服务 (FaaS)
❌ 打脸
没有很好的用于运行 GPU 工作负载的 FaaS 选项，这就是为什么咱们永远无奈齐全采纳 FaaS。然而，许多 CPU 工作负载能够应用 FaaS（lambda 等）。人们提出的最大拥护意见是老本问题。他们会说相似于「这种 EC2 实例类型在满负荷下运行 24/7 比 Lambda 便宜得多」。这是事实，但也是一个谬误的比拟。没有人会以 100% 的 CPU 利用率来运行服务。通常都有一些规模器在那里说「永远不要达到 100%。当达到 70% 时再扩大」。何时缩减规模总是不明确，而更像一种启发式办法，「如果咱们曾经放弃在 10% 上 10 分钟了，请缩减规模」。此外，人们总会假如 spot 实例是始终有的。
Lambda 的另一个暗藏劣势是非常容易以高精度跟踪老本。在 Kubernetes 中部署服务时，老本可能被其余每个节点对象或同一节点上运行的其余服务所覆盖。
GitOps
✅ 点赞
GitOps 目前在很大水平上扩大得相当好，咱们将其用于基础设施的许多局部：服务、Terraform 和配置等。次要毛病是流水线导向的工作流提供了一个清晰的图像：「这里是代表您提交的框，这些箭头从该框指向管道末端」。应用 GitOps 后，咱们不得不投资于工具来帮忙人们答复相似「我提交了代码：为什么还没有部署」的问题。
即便如此，GitOps 的灵活性曾经获得了巨大成功，我强烈推荐您公司采纳它。
优先解决外部效率而不是内部需要
✅ 点赞
很可能，您的公司并不是在销售基础设施自身，而是另一种产品。这给团队带来了压力，要求交付性能而不是扩大本人的工作量。但就像飞机通知你先戴上本人的氧气面罩一样，您须要确保您的团队高效运行。除了极少数例外情况外，我从未悔恨优先思考花工夫编写一些自动化或文档。
多个利用共享一个数据库
❌ 打脸
像大多数技术债权一样，咱们并没有做出这个决定，只是没有不做出这个决定。最终，有人心愿产品加上一个新性能，并创立了一个新表。这感觉很好，因为当初两个表之间有外键。但因为所有货色都属于某人，并且那个某人是表中的一行，你的整个技术栈的所有对象之间都有外键。
因为数据库被每个人应用，却没有任何人关怀它。初创公司没有雇佣 DBA 的侈靡条件，而所有无主物件最终将归基础设施团队所有。
共享数据库的最大问题包含：
- CRUD 在数据库中累积，并不分明是否能够删除。
- 当存在性能问题时，基础设施（不足深刻产品常识）必须调试数据库并找出应该重定向到谁。
- 数据库用户可能会推送破坏性代码到数据库中。这些破坏性操作可能会通过 PagerDuty 警报基础设施团队（因为他们领有该数据库）。让一个团队为另一个团队的问题而醒来感觉很蹩脚。对于应用程序所领有的数据库来说，在产生问题时应用程序团队是第一响应者。
尽管如此，我并不拥护想要共享繁多数据库的堆栈。只需意识到上述衡量，并确保您有治理它们的良好策略即可。
SaaS
没有尽早引入身份平台
❌ 打脸
我一开始应用 Google Workspace，用它来创立员工群组以调配权限。但它并不够灵便。回想起来，我心愿咱们早点抉择 Okta。它运行得十分好，简直与所有货色集成，并解决了许多合规性 / 平安方面的问题。尽早采纳身份解决方案，并只承受与之集成的 SaaS 供应商。
Notion
✅ 点赞
每家公司都须要一个搁置文档的中央。Notion 始终是一个很好的抉择，比我过来应用过的货色（维基、谷歌文档、Confluence 等）要容易得多。他们用于页面组织的数据库概念也让我可能创立相当简单的页面组织构造。
Slack
✅ 点赞
感谢上帝，我不再须要应用 HipChat 了。Slack 作为默认沟通工具十分棒，但为了缩小压力和乐音，我倡议：
- 应用 Thread 来压缩沟通
- 告知人们可能不会迅速回复音讯的冀望
- 不激励私信，并激励应用公共频道
从 JIRA 迁徙到 Linear
✅ 点赞
天壤之别。JIRA 如此臃肿，我放心在人工智能公司运行它会让它齐全变得无意识。当我应用 Linear 时，我常常会想「我是否能够做 X」，而后尝试了之后发现果然能够！
没有应用 Terraform Cloud
✅ 点赞
早些时候，我尝试将咱们的 terraform 迁徙到 Terraform Cloud。最大的毛病是我无奈证实老本正当。起初我把咱们迁徙到了 Atlantis，并且成果还不错。在 Atlantis 体现不佳的中央，咱们在 CI/CD 流水线中编写了一些自动化脚本来补救它。
应用 GitHub Actions 来做 CI/CD
✅ ❓微微点赞
咱们和大多数公司一样，在 GitHub 上托管咱们的代码。最后应用 CircleCI，但当初曾经转向 GitHub Actions 进行继续集成 / 继续部署。GitHub Actions 的次要毛病是对自托管工作流程的反对十分无限。咱们正在应用 EKS 和 actions-runner-controller 来托管在 EKS 中的自托管运行程序，但集成通常存在谬误（不过这些都能够解决）。心愿 GitHub 未来更加器重 Kubernetes 的自我托管性能。
DataDog
❌ 打脸
Datadog 是一个很棒的产品，但价格昂贵。不仅仅是低廉，我放心他们的老本模型对 Kubernetes 集群和 AI 公司特地不利。当您能够疾速启动和敞开多个节点，并应用 spot 实例时，Kubernetes 集群是最具老本效益的。Datadog 的定价模型基于您领有的实例数量，这意味着即便咱们一次最多只有 10 个实例运行，如果在那个小时内启动并敞开了 20 个实例，咱们将领取 20 个实例的费用。同样地，AI 公司偏向于大量应用 GPU。尽管 CPU 节点可能同时运行数十种服务，在许多用例之间摊派每个节点 Datadog 老本，而 GPU 节点可能只有一个服务在应用它，导致每项服务 Datadog 老本更高。
PagerDuty
✅ 点赞
PagerDuty 是一个很棒的产品，价格也正当。咱们从未悔恨抉择它。
软件
Schema migration 数据库变更
✅ ❓微微点赞
Schema 变更很难，无论你如何做，次要是因为它就是相当可怕。数据很重要，一个蹩脚的 Schema 变更可能会删除数据。在解决这个艰难问题的所有可怕办法中，我对将整个 schema 存入 git 并应用工具生成 SQL 以将数据库与 schema 同步的想法十分称心。
用 Ubuntu 作为开发服务器
✅ 点赞
最后我尝试让开发服务器与咱们的 Kubernetes 节点运行在雷同的根本操作系统上，认为这样会使开发环境更靠近生产环境。回想起来，这种致力并不值得。我很快乐咱们决定持续应用 Ubuntu 作为开发服务器的操作系统。它是一个受到良好反对的操作系统，并且领有大部分咱们须要的软件包。
AppSmith
✅ 点赞
咱们常常须要为外部工程师自动化一些流程：重新启动 / 降级 / 诊断等。对于咱们来说，制作 API 来解决这些问题很容易，但调试某人特定的 CLI/os/ 依赖装置等有点烦人。可能为工程师制作一个简略的 UI 与咱们的脚本进行交互十分有用。
咱们自行托管 AppSmith。它运行得…足够好。当然有一些事件咱们想要扭转，但对于「收费」价格而言曾经足够了。最后我摸索了与 retool 更深刻集成，但过后无奈证实那个值得付钱。
Helm
✅ 点赞
Helm v2 名誉不佳（有充沛理由），但 helm v3 曾经运行得足够好。在部署 CRDs 和教育开发人员为何他们的 Helm Chart 未能正确部署方面仍存在问题。然而总体来说，helm 作为打包和部署版本化 Kubernetes 对象的形式还算不错，Go 模板语言难以调试，但功能强大。
Helm Charts in ECR (oci)
✅ 点赞
最后咱们的 helm charts 存储在 S3 中，并通过插件下载。次要的毛病是须要装置自定义 helm 插件并手动治理生命周期。咱们起初转而应用 OCI 存储的 helm charts，这种设置没有呈现任何问题。
Bazel
❓ 不确定
偏心地说，很多聪明人喜爱 Bazel，所以我置信抉择它并不是一个坏主意。
在部署 Go 服务时，集体认为应用 Bazel 有点过头。如果你上一家公司用的是 bazel，并且你有点念旧，那么 Bazel 是一个很好的抉择。否则，咱们就引入了一个构建零碎，只有多数工程师能深刻理解；而与 GitHub Actions 相比，在那里仿佛每个人都晓得如何入手。
没有尽早应用 telemetry
❌ 打脸
咱们最后间接应用 DataDog 的 API 将指标发送到 DataDog。这使得很难将它们移除。
四年前，Open telemetry 并不那么成熟，但当初曾经好多了。我认为 metrics telemetry 依然有点不够成熟，但 tracing 十分杰出。我倡议任何公司从一开始就应用它。
应用 renovatebot 而不是 dependabot
✅ 点赞
我真诚地心愿咱们早点思考「放弃依赖项更新」。当你期待太久时，最终会失去十分古老的版本，降级过程漫长且不可避免地存在谬误。Renovatebot 在灵活性方面体现良好，能够依据您的需要进行定制。最大的毛病是它非常复杂且难以设置和调试。我想这可能是所有蹩脚抉择中最好的一个。
Kubernetes
✅ 点赞
您须要一个托管长时间运行服务的货色。Kubernetes 是一个受欢迎的抉择，对咱们来说成果很好。Kubernetes 社区在将 AWS 服务（如负载均衡器、DNS 等）整合到 Kubernetes 生态系统中方面做得十分杰出。
「任何具备许多应用形式的零碎都存在许多谬误应用的形式」
- Jack Lindamood
购买本人的 IP
✅ 点赞
如果您与内部合作伙伴单干，您常常须要为他们公布一个 IP 白名单。可怜的是，您可能会起初开发更多须要本人 IP 的零碎。购买本人的 IP 地址块是一个很好的办法，能够通过给内部合作伙伴提供更大的 CIDR 块来防止这种状况。
应用 Flux 做 K8s GitOps
✅ 点赞
在 Kubernetes 的晚期 GitOps 抉择中，须要在 ArgoCD 和 Flux 之间做出决定：我抉择了 Flux（过后是 v1）。它运行得十分好。咱们目前正在应用 Flux 2。惟一的毛病是咱们不得不开发本人的工具来帮忙人们了解其部署状态。
我据说 ArgoCD 很棒，所以如果你抉择了它，我置信也不错。
应用 Karpenter 做节点治理
✅ 点赞
如果您正在应用 EKS（而不是齐全在 Fargate 上），您应该应用 Karpenter。100%毫无疑问。咱们已经应用过其余主动缩放器，包含默认的 Kubernetes 主动缩放器和 SpotInst。在所有这些中，Karpenter 始终是最牢靠且老本效益最高的抉择。
应用 SealedSecrets 治理 K8s 密钥
❌ 打脸
我的最后想法是将机密治理推动到相似 GitOps 的货色。应用 sealed-secrets 的两个次要毛病是：
- 对于基础设施常识较少的开发人员来说，创立 / 更新秘密更加简单
- 咱们 失去了 AWS 围绕轮换秘密进行的所有现有自动化性能
应用 ExternalDNS 治理 DNS
✅ 点赞
ExternalDNS 是一个很棒的产品。它同步咱们的 Kubernetes -> Route53 DNS 记录，在过来的 4 年里简直没有给咱们带来任何问题。
应用 cert-manager 治理 SSL 证书
✅ 点赞
十分直观易配置，所有运行良好没有问题。强烈推荐应用它来为您的 Kubernetes 创立 Let’s Encrypt 证书。惟一的毛病是咱们有时会遇到古老（SaaS 问题对吧？）技术栈里客户不信赖 Let’s Encrypt，您须要为他们获取付费证书。
应用 Bottlerocket for EKS
❌ 打脸
咱们的 EKS 集群以前在 Bottlerocket 上运行。次要问题是咱们常常遇到网络 CSI 问题，调试 bottlerocket 镜像比调试规范的 EKS AMI 要艰难得多。应用 EKS 优化的 AMI 来作为咱们节点没有呈现任何问题，当呈现奇怪的网络问题时，咱们依然有一个后门来调试节点自身。
应用 Terraform 而不是 CloudFormation
✅ 点赞
应用基础设施即代码对于任何公司来说都是必不可少的。在 AWS 中，两个次要抉择是 CloudFormation 和 Terraform。我曾经应用过两者，并且没有悔恨抉择 Terraform。它很容易扩大到其余 SaaS 提供商（比方 Pagerduty），语法比 CloudFormation 更容易浏览，并且对咱们来说既不是阻碍也不会加速。
没有应用更多代码化计划（Pulumi, CDK 等）
✅ 点赞
尽管 Terraform 和 CloudFormation 是形容基础架构的数据文件（HCL 和 YAML/JSON），而像 Pulumi 或 CDK 这样的解决方案容许您编写执行雷同性能的代码。代码当然很弱小，但我发现 Terraform 的 HCL 具备肯定限度性质对于缩小复杂性是有好处的。并不是说无奈编写简单的 Terraform：只是在进行时更容易显著。
其中一些解决方案，比方 Pulumi，在很多年前就被创造进去了，而过后 Terraform 不足明天领有的许多性能。新版本的 Terraform 曾经集成了许多咱们能够应用以缩小复杂性的性能。咱们反而应用一个两头地带为咱们想要抽象化解决掉局部内容生成根本框架结构化 Terraform 代码。
没有应用 Network Mesh (istio, linkerd 等）
✅ 点赞
Network Mesh 十分酷，许多聪明人偏向于反对它们，所以我置信它们是好主见。可怜的是，我认为公司低估了事件的复杂性。我的个别基础设施倡议是「少即是多」。
Nginx 作为 EKS 网关的负载平衡
✅ 点赞
Nginx 老牌、稳固且通过实战测验。
Homebrew 来对立治理公司的脚本
✅ 点赞
您的公司可能须要一种散发脚本和二进制文件供工程师应用的办法。Homebrew 曾经足够好地为 Linux 和 Mac 用户提供了散发脚本和二进制文件的形式。
应用 Go 实现服务
✅ 点赞
Go 对新工程师来说很容易上手，总体而言是一个很好的抉择。对于大多数受网络 IO 限度的非 GPU 服务来说，Go 应该是您默认的语言选择。
局部观点必定会引发争议，真谛越辩越明，作者依据本人的实际分享了那么多，也的确引发了大家热烈的探讨。也欢送大家在评论区留言。
💡 更多资讯，请关注 Bytebase 公号：Bytebase