鐵人檔案
這是一個正在正式站上線的訂閱制服務的真實維運紀錄，不是概念展示。系列依序記錄技術架構、十個真實踩過的地雷（SQL跳脫、時區換算、資料單位混淆等）、訂閱分級與第三方訊息平台整合、AI內容生成的容錯設計，以及自動巡檢代理與CI/CD部署驗證機制。誠實記錄Claude Code在架構決策、地雷排查與日常維運代理中實際扮演的角色，給想一個人維運商業服務的開發者一份可直接參考的實戰紀錄。
先講清楚這是什麼、不是什麼 我一個人維運一個正在正式站上線、有真實付費訂戶的訂閱制資訊服務。它不是 side project 等級的玩具： 三端同步：網頁版...
一個違反直覺的決定 教科書會告訴你：開發環境要盡量貼近正式環境，資料庫當然要用同一種。我反著做——本機開發用 DuckDB，正式站用雲端代管的 Postgres...
一份放在專案根目錄的文件 Claude Code 有一個約定：專案根目錄放一份 CLAUDE.md，每次它在這個專案工作，都會先讀這份文件。官方定位是「專案說明...
事故現場 某天正式站一個查詢功能整天回 500。本機重現：完全正常。測試：全綠。程式碼 diff 看了三遍：沒有任何可疑之處。這種「本機好好的、正式站死了」的事...
事故現場 一次部署後，正式站起不來。不是某個 API 變慢、不是某個功能報錯——是整個服務開機失敗，健康檢查全紅，所有使用者看到的是服務中斷。 回滾之後查原因，...
事故現場 使用者回報：某個「以昨天為基準」的數字不對。我看：明明是對的。過幾個小時再看：欸，又對了？ 這種「時對時錯、無法穩定重現」的 bug 最消耗心力。最後...
事故現場 有一個「當某項量測值出現異常放大時通知使用者」的警報功能，上線好幾週，一次都沒觸發過。沒有人回報 bug——因為「沒有通知」看起來就像「最近沒有異常」...
事故現場 一個「跟上一期資料比較變化幅度」的功能，偶爾會顯示出離譜的變化率——明明實際變化不到 1%，畫面上卻顯示出好幾倍的跳動。而且無法穩定重現：同一筆資料，...
事故現場 服務裡有個「跟基準值比較的變化率」顯示。某天我自己看著畫面覺得不對勁：那個變化率跟我在別的地方看到的數字對不上，差距還不小。 追查後發現：計算用的基準...
事故現場 前端的時間序列圖表上線後，有使用者反應：圖上標的時間點怪怪的，事件明明發生在下午，圖上卻標在早上。 第一反應當然是「又是後端時區問題」（畢竟才剛被 D...
