这篇文章讲述了我们经历的一些阶段，希望如果您发现自己走在同一条道路上，您可以跳过一些最糟糕的部分。

作者 | Alex Ghiculescu

策划 | 云昭

(相关资料图)

Tanda（一款员工管理软件）很快就要满 11 岁了。一位读者建议，回顾一下我在那段时间在互联网上运行该应用程序所学到的东西会很有趣。

我在这个职位上呆了很多年。坑很多、很深刻，正常运行的时间并不多。因为部署、托管、基础设施管理，这可能是我十余年来工作中最具挑战性，也是最令人沮丧的内容。

主要是因为我经常莫名掉进坑里，很多时候都不知道自己在做什么。不幸的是，当你有一个很多人使用的生产应用程序时，你并不总是有时间可以正确地理解它。

这篇文章讲述了我们经历的一些阶段，希望如果您发现自己走在同一条道路上，您可以跳过一些最糟糕的部分。

1、第一阶段：Heroku

我们从 Heroku 开始，因为在 2012 年，如果你完成了任何包含部署应用程序的 Ruby on Rails 教程，你最终会获得一个 Heroku 帐户。

Heroku 的易用性是无与伦比的。但这对于以前从未部署过 Web 应用程序的人来说意义不大。我知道互联网指南的作者们都认为这是部署应用程序的最简单方法，但我不明白它比之前的方法有多大改进。

当时我所了解的，全是它的弱点：

（1）规定性：Heroku 工作得很好，只要你完全按照预期使用它。我们的情况非常接近这个；一个带有数据库、一些后台工作者和缓存的网络应用程序。

但我们有一个细微的差别，那就是我们的应用程序，需要偶尔处理来自慢速客户端（在信号不好的地方运行的手机或平板电脑）的长请求（文件上传）。我们并没有开创移动文件上传的先河，但配置UnicornUnicorn以处理它们的正确方法与默认设置完全不同，这让我很伤心。因为我对部署 Web 应用程序一无所知，所以我认为这是 Heroku 的错。

这些天我知道的多了一点，也能理解他们试图做的事情的复杂性，但我怀疑我是唯一一个把他们的电梯推销当成你部署应用程序所需的一切的人，有点太字面意思了。

（2）成本：Heroku 比运行自己的 VPS 等替代方案的成本要高得多。当然，它做了更多！但是因为这是我第一次自己部署，所以我很不喜欢，并且在将它与替代品进行比较时，只看到了“$”符号。

这不难理解，很多人现在的评价会比过去对它的评价相差很多。

无论如何，成本是最终导致我们从 Heroku 迁移的原因。我们最后一张 Heroku 发票是$104.95。（哈哈，记忆犹新。）

2、第二阶段：Digital Ocean

进入 Tanda 大约一年后，我有一名大学实习生，他对基础设施和成本优化非常感兴趣。他基本上说服了我，为 Heroku 买单就像放火烧钱一样。他是一个可爱的人，当时我真的很感谢他的帮助，但 10 年后我可以诚实地说这是一个糟糕的建议（给我背了一个大锅）。

放弃 Heroku 意味着替换 Heroku 所做的所有部分。我们没有以完全自动化的方式来做，因为我们是小规模的！我们太小了，没有意义。相反，我们只是在 Digital Ocean 的 UI 中指向并单击一个服务器。然后我们设置一些Capistrano脚本来部署。在一个周末，我们将网站离线了一段短得离谱的时间，从 Heroku 下载数据库，将其上传到 Digital Ocean “droplet”（又名服务器），并更改了 DNS 记录。我们已经迁移过来了！

我们的第一个 Digital Ocean 发票是$28.93，第二个（第一个完整月）是$39.23。我认为我每天节省 2 美元真是太聪明了。有一段时间它工作正常；事实证明，40 美元/月购买的服务器比我们运行我们非常小的应用程序实际需要的要多得多。

当我们开始更快地成长时，裂缝开始显现。我们的客户群规模每 9 个月翻一番，很快这意味着我们需要更多服务器。添加它们的过程是手动的、挑剔的，而且容易出错。我想出了怎么做，但在添加额外的“硬件”时，我就犯胃疼。

当我们的数据库服务器开始超载时，问题才真正开始显现。如果我们超过一天不部署站点，Postgres 就会耗尽内存并被操作系统杀死。有时它会自行修复，但更常见的是需要有人通过 SSH 连接到应用服务器并重新启动它们。这是工作日中令人恼怒的地方，我至今仍能想起好几次我在酒吧的厕所里，用手机重启服务器的经历。

但我们遇到过的最糟糕的“Digital Ocean”事件，是他们一下子关闭了我们所有的水滴。输入帐户的信用卡已过期，无法输入备用卡，帐户上的联系人电子邮件已转到不受监控的共享收件箱。因此，大概有一个月的时间，我们收到并忽略了账单提醒，直到我们真正注意到一切都处于离线状态并且没有响应 SSH 时。这不完全是他们的错，但在当时感觉就像是一个狡猾、不稳定的设置。

将近 10 年后写下这一切，让人感到非常后怕，令人震惊的是我们对其知之甚少，而我们却侥幸逃脱了它。如果我有时光机，我会回去告诉自己在 Digital Ocean 上多花 10 倍（500美元/月真的不会倾家荡产）并好好睡觉。

在使用 Digital Ocean 大约 3 年后，我们认为该平台对于我们不断增长的需求来说太简单了。我们开始与更大的客户签约，我们认为我们需要一种更具企业精神的方法来托管我们的应用程序。我们想要一个托管数据库，而不是管理我们自己的 Postgres 我们自己的服务器。我们希望减少平台停机时间。我们需要能够自动缩放以响应需求的波动，并且我们需要能够对不同资源组（……我们的 monorepo）的不同路由进行负载平衡。我们认为我们需要所有这些东西是合规的。

事后看来，这种逻辑大部分是倒退的。Auto Scaling是一种技术，不是AWS垄断的产品。我们不应该寻求更多的挑战，而应该找到一个足够简单的平台，我们可以真正掌握它。（尽管托管数据库是个好主意。）

放弃 DO 的唯一合理理由，是他们没有澳大利亚数据中心，而我们有一些真正关心这一点的客户。当时可谓指日可待，它于2022 年底推出了。所以很高兴我们没有等到那个。

反正。我们需要升级。如果您想升级您的托管服务，您会打电话给谁？

3、第三阶段：AWS

我们需要成为一个真正的企业，而真正的企业在 AWS 上托管他们的应用程序。这就是我们所做的。具体来说，我们将确切的 Digital Ocean 基础设施移植到了 AWS EC2 上。我们没有利用任何其他平台功能，我们只是像对待任何其他 VPS 一样对待 AWS。

几个月后，我得知我们有权聘请 AWS 客户经理。我从一位客户那里了解到这一点，他也做了介绍。我非常兴奋——我认为客户经理能够帮助我们快速成长并达到我们不再担心扩展的必杀技。

在我们的第一次会议上，我们的客户经理带来了他的解决方案架构师。我从未见过解决方案架构师，所以我真的不知道他们做了什么。这家伙所做的就是用“在没有服务器的世界中如何工作？”来回答我们提出的所有问题。我真的不明白 AWS Lambda 会如何帮助我们（仍然不明白），但他除了提醒我们它的存在之外没有任何有用的贡献。

我对有一个客户经理感到非常兴奋，所以有一段时间我因为不了解 Lambda 和不够聪明而无法让 AWS 工作而感到愚蠢。最终我意识到我不是问题所在。

大约一年后，另一个有趣的事件是我们耗尽了integers。我们的 Rails 应用程序很老，几乎每个表都使用整数作为其主键类型。较新版本的 Rails 创建了新表作为 bigints ，但我们团队中没有人意识到这是一个问题，直到一个星期五（那是 13 号星期五！）我们无法将任何新行插入到大多是常用的书面表格。幸运的是，每个人都还在办公室喝酒，所以我们能够很快对事件做出反应。真是个铭心刻骨的故事！

这一事件促使我们投入更多精力进行监控，以便在出现问题时能够更快地做出响应（这是一线希望）。这也让我对 PostgreSQL 中其他隐藏的陷阱产生了终生的偏执，我从未能够完全摆脱这些陷阱（我不确定这是否是一线希望）。

最近，AWS 领域的主要项目大多与合规性相关。确保我们在其他国家/地区勾选 GDRP 和等效项的每个方框，从而获得 SOC-2 认证。对于所有这些事情，能够指向亚马逊标志让事情变得更容易一些，但并不是说我们想做的任何事情都因为在特定的云上而成为可能或不可能。

进入 AWS 几年后，我们开始觉得它在基础设施方面很稳定。我们已经有一段时间没有构建我们的堆栈了，我们也没有看到很大的需要——两项重大成就！我们面临的下一个主要挑战是制度知识，或缺乏制度知识。在 Tanda 的历史上，只有不到 10 人从事过“DevOps”（定义非常广泛）。但是人来人往。目前有 2 人，1 人即将结束，因此团队中只有一名站点可靠性工程师的想法并不是很吸引人。

并不是说 SRE 完全独立工作。一段时间以来，我们也对工程师进行了随叫随到的轮换，但我们不太擅长培训人们处理 Rails 应用程序之外的棘手部分。因此，随叫随到的人花了很多时间来确认警报并对其进行监控，但只有在少数情况下，他们才能成功地解决问题并解决问题或显着改进系统。

基本上，这个系统是由个人才华的字符串和随机爆发结合在一起的。这是一个糟糕的长期战略。我们需要一个合适的团队结构，这样我们就永远不会依赖一个人来调试任何问题。

4、第四阶段：平台基础架构团队 (PIT)

为此，大约一年前，我们创建了一个平台基础架构团队，向 CTO 汇报。该团队在每个时区都有几个人，因此我们有 24 小时的 Ops、基础设施和相关工作。

这是一大亮点——我终于不再待命了！

这也是我第一次真正感受到我们拥有一支正在培养专业知识的团队。经过十年的担心，我们知道的不够多，事情以令人尴尬的方式崩溃，并且平台不断变化，拥有一个稳定和专业的路线图感觉很棒。

PIT 做的第一件事就是结束一堆半成品的正在进行的基础设施项目，并尽可能多地削减未使用的基础设施。在此期间和正确记录 oncall 流程之间，他们很快摆脱了很多复杂性。这使团队中的每个人都立即变得更有效率，并赋予他们对系统的所有权。

平台基础架构团队的官方帽子，戴在我们的首席技术官 Leon 的头上。

这项工作仍在进行中，因为在复杂领域积累专业知识需要很长时间。但这是我有史以来第一次真正对团队充满信心，并为他们在一年中所取得的成就感到自豪。

顺便说一句，我们仍在 AWS 上，但这并不意味着我们不想再次更改平台。探索外面的东西总是好的，我们花了一些时间来了解更多关于从云端迁移到托管数据中心的信息。只是，我们感觉现在还不需要这样做。

5、如果我有时光机

如果我有一台时光机回到 2012 年并给自己一些指示，我会说什么？

很多小技巧和三个大技巧。两者都归结为多花一点钱，以避免很多麻烦。

尽可能长时间地使用托管服务。我们在仅仅几个月后就离开了 Heroku，这对我们自己造成了很大的伤害。我们应该坚持使用它多年 – 管理服务器浪费了太多时间，而这些时间本可以在关键的早期阶段为我们完成。

尽快设置 PIT 。我应该更早地组建一个想要在这个领域工作的专业团队。不是在 Heroku 时代，而是一旦我们达到真正的规模，它就变得站不住脚了。

多照顾一下自己。出于某种原因，我总是发现很难确定可以减少警报、简化 oncall 或帮助我获得更多睡眠的项目的优先级。直到突然有一天，我突然爆发并重新分配了大量预算来建立 PIT 团队。获得体面的睡眠，有很多商业利益，将其优先于团队可以处理的其他事情，这并不自私。

原文链接：

https://ghiculescu.substack.com/p/11-years-of-hosting-a-saas