作者 | 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