作者 | Alex Ghiculescu

策劃 | 云昭

Tanda（一款員工管理軟件）很快就要滿 11 歲了。一位讀者建議，回顧一下我在那段時間在互聯(lián)網(wǎng)上運行該應(yīng)用程序所學(xué)到的東西會很有趣。

我在這個職位上呆了很多年。坑很多、很深刻，正常運行的時間并不多。因為部署、托管、基礎(chǔ)設(shè)施管理，這可能是我十余年來工作中最具挑戰(zhàn)性，也是最令人沮喪的內(nèi)容。

主要是因為我經(jīng)常莫名掉進(jìn)坑里，很多時候都不知道自己在做什么。不幸的是，當(dāng)你有一個很多人使用的生產(chǎn)應(yīng)用程序時，你并不總是有時間可以正確地理解它。

這篇文章講述了我們經(jīng)歷的一些階段，希望如果您發(fā)現(xiàn)自己走在同一條道路上，您可以跳過一些最糟糕的部分。

1、第一階段：Heroku

我們從 Heroku 開始，因為在 2012 年，如果你完成了任何包含部署應(yīng)用程序的 Ruby on Rails 教程，你最終會獲得一個 Heroku 帳戶。

Heroku 的易用性是無與倫比的。但這對于以前從未部署過 Web 應(yīng)用程序的人來說意義不大。我知道互聯(lián)網(wǎng)指南的作者們都認(rèn)為這是部署應(yīng)用程序的最簡單方法，但我不明白它比之前的方法有多大改進(jìn)。

當(dāng)時我所了解的，全是它的弱點：

（1）規(guī)定性：Heroku 工作得很好，只要你完全按照預(yù)期使用它。我們的情況非常接近這個；一個帶有數(shù)據(jù)庫、一些后臺工作者和緩存的網(wǎng)絡(luò)應(yīng)用程序。

但我們有一個細(xì)微的差別，那就是我們的應(yīng)用程序，需要偶爾處理來自慢速客戶端（在信號不好的地方運行的手機或平板電腦）的長請求（文件上傳）。我們并沒有開創(chuàng)移動文件上傳的先河，但配置UnicornUnicorn以處理它們的正確方法與默認(rèn)設(shè)置完全不同，這讓我很傷心。因為我對部署 Web 應(yīng)用程序一無所知，所以我認(rèn)為這是 Heroku 的錯。

這些天我知道的多了一點，也能理解他們試圖做的事情的復(fù)雜性，但我懷疑我是唯一一個把他們的電梯推銷當(dāng)成你部署應(yīng)用程序所需的一切的人，有點太字面意思了。

（2）成本：Heroku 比運行自己的 VPS 等替代方案的成本要高得多。當(dāng)然，它做了更多！但是因為這是我第一次自己部署，所以我很不喜歡，并且在將它與替代品進(jìn)行比較時，只看到了“$”符號。

這不難理解，很多人現(xiàn)在的評價會比過去對它的評價相差很多。

無論如何，成本是最終導(dǎo)致我們從 Heroku 遷移的原因。我們最后一張 Heroku 發(fā)票是$104.95。（哈哈，記憶猶新。）

2、第二階段：Digital Ocean

進(jìn)入 Tanda 大約一年后，我有一名大學(xué)實習(xí)生，他對基礎(chǔ)設(shè)施和成本優(yōu)化非常感興趣。他基本上說服了我，為 Heroku 買單就像放火燒錢一樣。他是一個可愛的人，當(dāng)時我真的很感謝他的幫助，但 10 年后我可以誠實地說這是一個糟糕的建議（給我背了一個大鍋）。

放棄 Heroku 意味著替換 Heroku 所做的所有部分。我們沒有以完全自動化的方式來做，因為我們是小規(guī)模的！我們太小了，沒有意義。相反，我們只是在 Digital Ocean 的 UI 中指向并單擊一個服務(wù)器。然后我們設(shè)置一些Capistrano腳本來部署。在一個周末，我們將網(wǎng)站離線了一段短得離譜的時間，從 Heroku 下載數(shù)據(jù)庫，將其上傳到 Digital Ocean “droplet”（又名服務(wù)器），并更改了 DNS 記錄。我們已經(jīng)遷移過來了！

我們的第一個 Digital Ocean 發(fā)票是$28.93，第二個（第一個完整月）是$39.23。我認(rèn)為我每天節(jié)省 2 美元真是太聰明了。有一段時間它工作正常；事實證明，40 美元/月購買的服務(wù)器比我們運行我們非常小的應(yīng)用程序?qū)嶋H需要的要多得多。

當(dāng)我們開始更快地成長時，裂縫開始顯現(xiàn)。我們的客戶群規(guī)模每 9 個月翻一番，很快這意味著我們需要更多服務(wù)器。添加它們的過程是手動的、挑剔的，而且容易出錯。我想出了怎么做，但在添加額外的“硬件”時，我就犯胃疼。

當(dāng)我們的數(shù)據(jù)庫服務(wù)器開始超載時，問題才真正開始顯現(xiàn)。如果我們超過一天不部署站點，Postgres 就會耗盡內(nèi)存并被操作系統(tǒng)殺死。有時它會自行修復(fù)，但更常見的是需要有人通過 SSH 連接到應(yīng)用服務(wù)器并重新啟動它們。這是工作日中令人惱怒的地方，我至今仍能想起好幾次我在酒吧的廁所里，用手機重啟服務(wù)器的經(jīng)歷。

但我們遇到過的最糟糕的“Digital Ocean”事件，是他們一下子關(guān)閉了我們所有的水滴。輸入帳戶的信用卡已過期，無法輸入備用卡，帳戶上的聯(lián)系人電子郵件已轉(zhuǎn)到不受監(jiān)控的共享收件箱。因此，大概有一個月的時間，我們收到并忽略了賬單提醒，直到我們真正注意到一切都處于離線狀態(tài)并且沒有響應(yīng) SSH 時。這不完全是他們的錯，但在當(dāng)時感覺就像是一個狡猾、不穩(wěn)定的設(shè)置。

將近 10 年后寫下這一切，讓人感到非常后怕，令人震驚的是我們對其知之甚少，而我們卻僥幸逃脫了它。如果我有時光機，我會回去告訴自己在 Digital Ocean 上多花 10 倍（500美元/月真的不會傾家蕩產(chǎn)）并好好睡覺。

在使用 Digital Ocean 大約 3 年后，我們認(rèn)為該平臺對于我們不斷增長的需求來說太簡單了。我們開始與更大的客戶簽約，我們認(rèn)為我們需要一種更具企業(yè)精神的方法來托管我們的應(yīng)用程序。我們想要一個托管數(shù)據(jù)庫，而不是管理我們自己的 Postgres 我們自己的服務(wù)器。我們希望減少平臺停機時間。我們需要能夠自動縮放以響應(yīng)需求的波動，并且我們需要能夠?qū)Σ煌Y源組（……我們的 monorepo）的不同路由進(jìn)行負(fù)載平衡。我們認(rèn)為我們需要所有這些東西是合規(guī)的。

事后看來，這種邏輯大部分是倒退的。Auto Scaling是一種技術(shù)，不是AWS壟斷的產(chǎn)品。我們不應(yīng)該尋求更多的挑戰(zhàn)，而應(yīng)該找到一個足夠簡單的平臺，我們可以真正掌握它。（盡管托管數(shù)據(jù)庫是個好主意。）

放棄 DO 的唯一合理理由，是他們沒有澳大利亞數(shù)據(jù)中心，而我們有一些真正關(guān)心這一點的客戶。當(dāng)時可謂指日可待，它于2022 年底推出了。所以很高興我們沒有等到那個。

反正。我們需要升級。如果您想升級您的托管服務(wù)，您會打電話給誰？

3、第三階段：AWS

我們需要成為一個真正的企業(yè)，而真正的企業(yè)在 AWS 上托管他們的應(yīng)用程序。這就是我們所做的。具體來說，我們將確切的 Digital Ocean 基礎(chǔ)設(shè)施移植到了 AWS EC2 上。我們沒有利用任何其他平臺功能，我們只是像對待任何其他 VPS 一樣對待 AWS。

幾個月后，我得知我們有權(quán)聘請 AWS 客戶經(jīng)理。我從一位客戶那里了解到這一點，他也做了介紹。我非常興奮——我認(rèn)為客戶經(jīng)理能夠幫助我們快速成長并達(dá)到我們不再擔(dān)心擴展的必殺技。

在我們的第一次會議上，我們的客戶經(jīng)理帶來了他的解決方案架構(gòu)師。我從未見過解決方案架構(gòu)師，所以我真的不知道他們做了什么。這家伙所做的就是用“在沒有服務(wù)器的世界中如何工作？”來回答我們提出的所有問題。我真的不明白 AWS Lambda 會如何幫助我們（仍然不明白），但他除了提醒我們它的存在之外沒有任何有用的貢獻(xiàn)。

我對有一個客戶經(jīng)理感到非常興奮，所以有一段時間我因為不了解 Lambda 和不夠聰明而無法讓 AWS 工作而感到愚蠢。最終我意識到我不是問題所在。

大約一年后，另一個有趣的事件是我們耗盡了integers。我們的 Rails 應(yīng)用程序很老，幾乎每個表都使用整數(shù)作為其主鍵類型。較新版本的 Rails 創(chuàng)建了新表作為 bigints ，但我們團(tuán)隊中沒有人意識到這是一個問題，直到一個星期五（那是 13 號星期五！）我們無法將任何新行插入到大多是常用的書面表格。幸運的是，每個人都還在辦公室喝酒，所以我們能夠很快對事件做出反應(yīng)。真是個銘心刻骨的故事！

這一事件促使我們投入更多精力進(jìn)行監(jiān)控，以便在出現(xiàn)問題時能夠更快地做出響應(yīng)（這是一線希望）。這也讓我對 PostgreSQL 中其他隱藏的陷阱產(chǎn)生了終生的偏執(zhí)，我從未能夠完全擺脫這些陷阱（我不確定這是否是一線希望）。

最近，AWS 領(lǐng)域的主要項目大多與合規(guī)性相關(guān)。確保我們在其他國家/地區(qū)勾選 GDRP 和等效項的每個方框，從而獲得 SOC-2 認(rèn)證。對于所有這些事情，能夠指向亞馬遜標(biāo)志讓事情變得更容易一些，但并不是說我們想做的任何事情都因為在特定的云上而成為可能或不可能。

進(jìn)入 AWS 幾年后，我們開始覺得它在基礎(chǔ)設(shè)施方面很穩(wěn)定。我們已經(jīng)有一段時間沒有構(gòu)建我們的堆棧了，我們也沒有看到很大的需要——兩項重大成就！我們面臨的下一個主要挑戰(zhàn)是制度知識，或缺乏制度知識。在 Tanda 的歷史上，只有不到 10 人從事過“DevOps”（定義非常廣泛）。但是人來人往。目前有 2 人，1 人即將結(jié)束，因此團(tuán)隊中只有一名站點可靠性工程師的想法并不是很吸引人。

并不是說 SRE 完全獨立工作。一段時間以來，我們也對工程師進(jìn)行了隨叫隨到的輪換，但我們不太擅長培訓(xùn)人們處理 Rails 應(yīng)用程序之外的棘手部分。因此，隨叫隨到的人花了很多時間來確認(rèn)警報并對其進(jìn)行監(jiān)控，但只有在少數(shù)情況下，他們才能成功地解決問題并解決問題或顯著改進(jìn)系統(tǒng)。

基本上，這個系統(tǒng)是由個人才華的字符串和隨機爆發(fā)結(jié)合在一起的。這是一個糟糕的長期戰(zhàn)略。我們需要一個合適的團(tuán)隊結(jié)構(gòu)，這樣我們就永遠(yuǎn)不會依賴一個人來調(diào)試任何問題。

4、第四階段：平臺基礎(chǔ)架構(gòu)團(tuán)隊 (PIT)

為此，大約一年前，我們創(chuàng)建了一個平臺基礎(chǔ)架構(gòu)團(tuán)隊，向 CTO 匯報。該團(tuán)隊在每個時區(qū)都有幾個人，因此我們有 24 小時的 Ops、基礎(chǔ)設(shè)施和相關(guān)工作。

這是一大亮點——我終于不再待命了！

這也是我第一次真正感受到我們擁有一支正在培養(yǎng)專業(yè)知識的團(tuán)隊。經(jīng)過十年的擔(dān)心，我們知道的不夠多，事情以令人尷尬的方式崩潰，并且平臺不斷變化，擁有一個穩(wěn)定和專業(yè)的路線圖感覺很棒。

PIT 做的第一件事就是結(jié)束一堆半成品的正在進(jìn)行的基礎(chǔ)設(shè)施項目，并盡可能多地削減未使用的基礎(chǔ)設(shè)施。在此期間和正確記錄 oncall 流程之間，他們很快擺脫了很多復(fù)雜性。這使團(tuán)隊中的每個人都立即變得更有效率，并賦予他們對系統(tǒng)的所有權(quán)。

平臺基礎(chǔ)架構(gòu)團(tuán)隊的官方帽子，戴在我們的首席技術(shù)官 Leon 的頭上。

這項工作仍在進(jìn)行中，因為在復(fù)雜領(lǐng)域積累專業(yè)知識需要很長時間。但這是我有史以來第一次真正對團(tuán)隊充滿信心，并為他們在一年中所取得的成就感到自豪。

順便說一句，我們?nèi)栽?AWS 上，但這并不意味著我們不想再次更改平臺。探索外面的東西總是好的，我們花了一些時間來了解更多關(guān)于從云端遷移到托管數(shù)據(jù)中心的信息。只是，我們感覺現(xiàn)在還不需要這樣做。

5、如果我有時光機

如果我有一臺時光機回到 2012 年并給自己一些指示，我會說什么？

很多小技巧和三個大技巧。兩者都?xì)w結(jié)為多花一點錢，以避免很多麻煩。

盡可能長時間地使用托管服務(wù)。我們在僅僅幾個月后就離開了 Heroku，這對我們自己造成了很大的傷害。我們應(yīng)該堅持使用它多年 - 管理服務(wù)器浪費了太多時間，而這些時間本可以在關(guān)鍵的早期階段為我們完成。

盡快設(shè)置 PIT 。我應(yīng)該更早地組建一個想要在這個領(lǐng)域工作的專業(yè)團(tuán)隊。不是在 Heroku 時代，而是一旦我們達(dá)到真正的規(guī)模，它就變得站不住腳了。

多照顧一下自己。出于某種原因，我總是發(fā)現(xiàn)很難確定可以減少警報、簡化 oncall 或幫助我獲得更多睡眠的項目的優(yōu)先級。直到突然有一天，我突然爆發(fā)并重新分配了大量預(yù)算來建立 PIT 團(tuán)隊。獲得體面的睡眠，有很多商業(yè)利益，將其優(yōu)先于團(tuán)隊可以處理的其他事情，這并不自私。

原文鏈接：

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