誰在維運這個服務

維運的是一個人。把這件事寫在這裡,是因為你要把訊息流交給我之前,應該先知道規模——而不是等出事那天才發現。

現在的真實狀態截至 2026-08-30

機房台灣單一地點的單一主機。沒有跨區、沒有多可用區。

單點

Kafka 副本數全部 topic 都是 RF=1。磁碟或 broker 故障,保留期內的訊息可能永久遺失。

資料庫複本Postgres 單實例、零複本、無自動切換。復原的唯一路徑是從備份還原。

備份排程每天執行一次,並把最新的 dump 上傳到異地物件儲存。

每日

實際資料缺口排程在「20 小時內已有備份」時會略過產生新 dump,所以新 dump 的間隔可能超過一天。寫這頁的當下,最新一份是 38 小時前的。

最長約 40 小時

備份涵蓋範圍只有 Postgres(帳號、topic 設定、金鑰雜湊)。Kafka 裡的訊息不在備份內。

不含訊息

備份加密異地物件儲存上的 dump 未加密。dump 內含 email 與雜湊後的密碼、API key。

無

還原演練做過一次,不是「設定好了」。細節見下。

1 次

站外探測目前沒有。監控只看得到內網,整機或家用網路斷線時,察覺故障這一段沒有自動化。

無

出事的時候會怎樣

單機故障會中斷服務,直到我把它拉起來。沒有自動切換,而且因為沒有站外探測,我可能不是第一個知道的人。

資料庫壞掉時可以從備份還原,而且這件事真的演練過——不是「排程設好了」,是實際取回來還原過一次:52 KB 的 dump,pg_restore 花 235 ms,schema 版本與租戶數都對得上。

但那次演練有四個限制,一起講才誠實:還原目標是空的臨時容器,沒有模擬覆蓋既有正式資料;用的是當天才剛上傳的備份,沒驗長期存放的完整性;資料庫只有 9 MB,時間不能往上外推;帳本不變量驗的是 0 == 0,零付費期間本來就驗不到東西。

你會失去的是最後一份備份之後的資料。備份排程每天跑,但它在「20 小時內已有備份」時會略過產生新的一份,所以兩份新 dump 之間可能隔超過一天——寫這頁的當下,最新一份是 38 小時前的。而且 Kafka 裡的訊息完全不在備份範圍內,還原資料庫救不回訊息。

因為上面每一條都寫在這裡,而不是等你踩到才發現。文件裡也寫了它會怎麼壞——投遞語義依接收方式而異、SSE 的重播是有界的、長輪詢是 at-most-once。

適合拿來跑非核心的業務事件:通知、稽核軌跡、agent 觸發、內部整合。如果事件會直接影響付款、庫存或其他核心交易,現在的 RF=1 與單一機房不適合你,這不是謙虛。

寫信給我,我本人會回:alderflux@gmail.com