Healthchecks.io 在 2026 年 3 月做了一個有趣決策：把物件儲存從管理服務完全遷移到自託管。這不是什麼宏大的雲原生轉型，也不是因為預算削減，而是基於一個一人的團隊、在真實使用場景下的實際考慮。
背景：為什麼需要物件儲存
Healthchecks.io 是一個監控服務，用戶透過 HTTP 請求告訴它「我還活著」。當用戶用 POST 方法發送請求時，可以在請求體中包含任意資料——可能是日誌片段、除錯資訊，或是任何他們想追蹤的內容。Healthchecks.io 會儲存請求體的前 100kB。
如果請求體很小，直接存進 PostgreSQL 資料庫。如果比較大，就轉到 S3 相容的物件儲存。聽起來很合理：小資料走資料庫，大資料走物件儲存，標準做法。
問題在於「比較大」的定義。100kB 的閾值意味著大量的物件儲存操作。對於 Healthchecks.io 的使用模式來說，這就是每個足夠大的 ping 請求都會觸發一次 PutObject 操作。
管理物件儲存的問題
在 2022 年，Healthchecks.io 開始評估物件儲存提供者。AWS S3 的按請求計費模式會讓這種頻繁的 PutObject 操作變得很昂貴。更糟的是，AWS 受美國 CLOUD Act 管轄，Healthchecks.io 如果想把資料存到那裡，就需要在傳輸前加密，這會增加複雜度。
他們最初選擇了 OVHcloud。沒有按請求費用，是歐盟公司，效能也看起來不錯。但隨著時間推移，效能和可靠性問題開始增加。作者在文中描述這是一個「變得越來越糟」的過程——操作變慢、錯誤變多，最終開始尋找替代方案。
2024 年，他們遷移到 UpCloud。同樣沒有按請求費用，也是歐盟公司。服務品質有明顯改善：S3 操作更快了，錯誤和超時變少了。但好景不長，UpCloud 的效能也開始下滑。有時所有操作都會變慢，觸發超時限制。特別是 S3 DeleteObjects 操作，變得越來越慢。
這讓作者開始認真考慮自託管選項。
實際使用規模
在決定自託管之前，需要先搞清楚實際的需求。Healthchecks.io 在 2026 年 4 月的規模是：
- 1400 萬個物件，119GB
- 物件大小從 100 字節到 10 萬字節，平均 8KB
- 平均每秒 30 次上傳操作，經常尖峰到每秒 150 次
- 持續的上傳和刪除流動性
這不是一個超級巨大的規模。一切都還可以放進單一系統，做完整備份也還算快。如果需要數 TB 的儲存，整個考量就會完全不同。
更重要的是，物件儲存不是最核心的資料存儲。如果 PostgreSQL 資料庫掛了，服務就完全壞了，監控警報發不出去。但如果物件儲存掛了，用戶只是無法透過網頁介面或 API 檢視 ping 請求體，其他功能還是正常運作。如果一些請求體永遠丟失，這很糟糕，但沒有丟失 PostgreSQL 資料那麼嚴重。
延遲也很重要。Healthchecks.io 的程式碼中有一些地方會在 HTTP 請求/回應週期中執行 S3 操作。如果單個 S3 操作需要幾秒鐘，就會阻塞 web 伺服器程序。在使用 UpCloud 時，作者不得不加入一些負載丟棄邏輯，防止慢速 S3 操作升級成更大的問題。
自託管方案評估
作者實測了幾個開源自託管選項：Minio、SeaweedFS 和 Garage。
主要問題是運維複雜度。照著「快速開始」教學啟動一個基本叢集不算難，但要做到生產環境就完全是另一回事了。至少需要：
- 自動化叢集節點的設置
- 學習並測試更新流程
- 學習並測試故障節點更換流程
- 設定叢集特有的監控和警報
作者是一人團隊，已經在管理自託管的 PostgreSQL、HAProxy 負載平衡器和自託管郵件系統。他真的不想再接手另一個非平凡系統。簡單一點的方案會好很多。
Versity S3 Gateway 的選擇
最後他們選擇了 Versity S3 Gateway。這個工具很簡單：把本機檔案系統變成 S3 伺服器。S3 PutObject 操作就是在檔案系統上建立一個普通檔案，GetObject 就是讀取一個檔案，DeleteObject 就是刪除一個檔案。
不需要額外的資料庫存儲元資料。可以用任何備份工具做備份。升級流程就是替換一個執行檔並重啟 systemd 服務。用 Go 寫成，持續活躍開發中。作者找到並回報的一個 bug 在幾天內就修好了。
當然，使用檔案系統作為後端儲存的最大限制是可用性和持久性。物件存在單一系統上，可能隨時掛掉而且沒有預警。需要準備好應對這個場景。
實際部署架構
2026 年 3 月，Healthchecks.io 遷移到了基於 Versity S3 Gateway 的自託管物件儲存。
架構設計很直接：
- S3 API 在專屬伺服器上執行，監聽私有 IP 位址
- 應用伺服器透過 Wireguard 隧道連接
- 物件儲存在伺服器的本機磁碟（兩顆 NVMe 磁碟 RAID 1）
- 使用 Btrfs 檔案系統——不像 ext4，儲存大量小檔案不會有 inode 耗盡的風險
- 每兩小時，rsync 把新增和刪除的檔案同步到備份伺服器
- 每天備份伺服器做完整備份、加密後存到異地，保留最近 30 天的完整備份
在這個設定下，如果物件儲存伺服器的兩顆磁碟同時掛掉，系統最多會損失 2 小時尚未備份的 ping 請求體。這當然可以改善，但通常代價是額外的複雜度。
遷移後的結果
遷移到自託管後，S3 操作延遲下降了。
等待上傳到物件儲存的請求體佇列縮小了。
目前還沒有出現可用性問題，但新系統也才運行幾週。
資料處理者清單中少了一個條目——這在 GDPR 合規角度來說是有意義的。
成本增加了：租用一個額外的專屬伺服器比在管理物件儲存服務上儲存約 100GB 貴。但改善的效能和可靠性是值得的。
這不是「自託管比較好」的宣傳
讀這個故事的時候，很容易把它當成另一個「自託管比較好」的宣傳。但作者其實很謹慎。他們之所以選擇自託管，是因為：
- 規模還在可控範圍內——1400 萬個物件、119GB，不是 PB 級別
- 團隊規模小，一人團隊可以快速做決策並執行
- 原本的管理服務品質持續下滑，已經影響用戶體驗
- Versity S3 Gateway 的簡單性降低了運維負擔
- 成本增加有限，但換來了可控性和效能
如果規模再大幾個數量級，或者團隊需要更複雜的可用性保證，決策可能就會完全不同。
給台灣開發者的啟示
對於台灣的小型團隊來說，這個故事提供了幾個值得思考的角度。
首先是「合適的規模」。很多團隊一開始就選擇雲端的託管服務，因為覺得這是「正確的做法」。但如果你的使用模式特別——像 Healthchecks.io 這樣頻繁的小物件操作——託管服務的成本和效能可能並不理想。在還不大的規模下，自託管可能更合適。
其次是「簡單的運維」。一人團隊管理多個自託管系統聽起來很瘋狂，但如果每個系統都保持簡單——像 Versity S3 Gateway 那樣只是個檔案系統包裝——複雜度就會控制在合理範圍內。關鍵是選擇設計哲學符合你運維能力的工具。
然後是「監控資料收集的特殊性」。Healthchecks.io 的物件儲存不是核心資料，掛掉雖然不好但不是災難。這讓他們可以用簡單的架構換來更好的效能。如果你的系統每個部分都一樣重要，決策就會完全不同。
最後是「誠實評估管理服務的品質」。OVHcloud 和 UpCloud 在剛開始都表現不錯，但隨著時間推移品質下滑。這不是「雲端不好」的問題，而是需要持續監控你使用的服務品質。當服務品質影響到用戶體驗時，要有勇氣重新評估選項。
作者在文末說他很謹慎樂觀，認為新系統是改善，但如果有更好的權衡選項，他也願意再次遷移。這是一種務實的態度——不是追求完美，而是追求當前情況下的最佳權衡。
對於正在做類似決策的團隊來說，或許最有價值的不是結論（自託管比較好或雲端比較好），而是思考的過程：搞清楚你的實際規模和使用模式，誠實面對管理服務的優缺點，選擇適合你團隊規模和能力的方案，並保持開放心態隨時重新評估。
技術決策很少是黑白分明的，更多是在約束條件下找到最合適的灰色地帶。Healthchecks.io 的這個決策，只是一個在特定情境下合理的選擇而已。