SaaS 11 托管 年后的经验！
作者 | 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 团队。取得面子的睡眠，有很多商业利益，将其优先于团队可以处置的其余事情，这并不无私。
原文链接：
