監控與維運：睡覺時產品也在跑

一個人做產品第 11 / 18 篇

本篇是「一個人做產品」系列的第 11 / 18 篇。你可以從系列總覽開始閱讀，也可以直接接著看本文。

凌晨四點的維運噩夢

你正在做一個很好的夢，手機突然震動。

不是鬧鐘。是一封信：「您的網站 bobo-example.com 已經連續無回應 15 分鐘。」

你從床上跳起來，打開筆電，一邊揉眼睛一邊 SSH 進 server。查了 20 分鐘，發現是資料庫連線數爆了。重啟服務、清理連線、確認恢復正常。回到床上已經凌晨五點，六點半又要起床上班。

如果你做產品做得夠久，這種故事你一定經歷過。

好消息是：2026 年，一個人的維運不需要這麼痛苦。你需要的是一套最小化但有效的監控系統，加上自動化的故障恢復機制。讓產品出問題時，它先自己試著修自己，真的修不好再叫你。

監控金字塔：先搞對優先順序

大公司的監控系統動輒幾十個 dashboard、上百條 alert rule。你不需要那些。

一個人做產品，監控有四個層級，按優先順序排列：

         ┌─────────┐
         │ 商業指標 │  ← 每週看一次就好
         ├─────────┤
         │ 效能指標 │  ← 有空再看
         ├─────────┤
         │ 錯誤追蹤 │  ← 每天掃一眼
         ├─────────┤
         │ 可用性   │  ← 最重要，必須自動告警
         └─────────┘

層級 1：可用性監控（必做）

你的網站活著嗎？ 這是最基本也是最重要的問題。

工具	免費方案
UptimeRobot	50 個監控點
Better Stack	10 個監控點
Cloudflare Health Checks	Pro 方案起（付費）；Free 方案僅有 Passive Origin Monitoring

我自己的 bobo-blog 就是用 UptimeRobot，免費 50 個監控點對個人專案綽綽有餘。如果你已經在 Cloudflare 生態系裡，Health Checks 也是現成的選項。

設定方式很簡單：

註冊 UptimeRobot（免費）
新增你的網站 URL 和 API 健康檢查端點
設定告警通知：email + Slack（或 Telegram）
設定檢查頻率：每 5 分鐘

五分鐘設定完，你的網站掛了你就會知道。這是投資報酬率最高的五分鐘。

層級 2：錯誤追蹤（強烈建議）

網站活著，不代表沒有錯誤。用戶可能遇到 500 error、JavaScript crash、API timeout，但因為其他功能正常所以你不知道。

Sentry 是 Solo Builder 的最佳選擇：

免費方案：每月 5,000 筆錯誤事件，夠用
支援幾乎所有語言和框架
自動分組重複的錯誤
附上完整的 stack trace 和用戶環境資訊

// Astro 專案整合 Sentry，一行搞定
import * as Sentry from '@sentry/astro';

Sentry.init({
  dsn: 'https://xxx@sentry.io/yyy',
  tracesSampleRate: 0.1, // 只取樣 10%，省額度
});

傳統做法 vs. AI 加持做法

傳統做法：

收到 Sentry 告警
打開 Sentry dashboard 看 stack trace
花 30 分鐘讀 log、找問題
花 30 分鐘寫修復
部署、驗證

AI 加持做法：

收到 Sentry 告警
把 error 訊息和 stack trace 丟給 Claude Code
AI 直接在你的 codebase 裡找到問題根因
AI 提出修復方案，你 review 後 approve
CI/CD 自動部署

同一個 bug，從一小時變成十五分鐘。

而且 Claude Code 可以做得更進階——設定一個 Sentry webhook，錯誤發生時自動觸發 AI 分析：

你是一個 on-call SRE。以下是一個 production error：

Error: Connection pool exhausted
Stack trace: [完整 stack trace]
頻率: 過去 10 分鐘發生 47 次
影響範圍: /api/courses 端點

請分析：
1. 最可能的根本原因
2. 立即的緩解措施（不需要改 code 的）
3. 長期修復方案
4. 這個問題是否需要立即修復，還是可以等到明天

層級 3：效能監控（有空再做）

效能問題通常不會讓產品掛掉，但會慢慢侵蝕用戶體驗。

好消息是：如果你的產品部署在 Cloudflare Workers 或 Vercel，你已經有了免費的效能數據。

Cloudflare Analytics：request count、response time、error rate、bandwidth
Vercel Analytics：Web Vitals（LCP、INP、CLS）
Google Search Console：Core Web Vitals（SEO 相關）

這些數據不需要每天看。每週花 10 分鐘掃一眼趨勢就好。 重點是看「有沒有突然變差」，而不是追求每一個毫秒的優化。

層級 4：商業指標（每週看一次）

這不是傳統意義上的「監控」，但對 Solo Builder 來說一樣重要：

每日活躍用戶數
新增註冊數
付費轉換率
流失率

這些指標告訴你產品的健康狀況——不是技術健康，而是商業健康。

用一個簡單的 Google Sheet 或 Notion database 就夠了。不需要花時間建 dashboard。

告警設計：少即是多

監控最常犯的錯是告警太多。

如果你每天收到 20 封告警信，你會開始忽略它們。然後真正重要的告警出現時，你也會忽略。

告警的黃金法則

只在「需要你做某件事」的時候才告警。

情境	要不要告警	原因
網站掛了	✅ 告警	需要你處理
5xx 錯誤率超過 5%	✅ 告警	需要你檢查
回應時間超過 3 秒	❌ 不告警	記錄就好，不緊急
磁碟空間超過 80%	✅ 告警	需要你清理，但不急
每日用戶數下降 10%	❌ 不告警	每週 review 時看就好
SSL 憑證即將過期	✅ 告警	需要你處理（或設定自動更新）
CPU 使用率偶爾 spike	❌ 不告警	正常現象

告警通知管道

通知管道大概就 Email、Slack/Discord、Telegram Bot、SMS/電話這幾種。Email 適合當所有告警的備份，建議必開；Slack 或 Discord 適合非緊急但需要注意的事，開一個 #alerts 頻道就好；Telegram Bot 手機通知即時，隨時隨地都收得到；SMS 或電話留給網站掛掉這種極度緊急的狀況，只在深夜啟用。

我的設定是：所有告警走 Telegram Bot，只有「網站完全掛掉超過 10 分鐘」才觸發 SMS。

這樣白天我在上班時，Telegram 通知會靜靜地出現在手機上，我空閒時看一下就好。但半夜網站掛了，SMS 會叫醒我。

Self-Healing：讓產品自己修自己

最理想的狀態是：問題發生了，但你根本不需要知道，因為系統自己修好了。

這不是科幻小說。以下是幾個實用的 self-healing 模式：

模式 1：Health Check + 自動重啟

大部分雲端平台都支援 health check：

Cloudflare Workers：Workers 本身是 serverless，不需要重啟；若使用 Durable Objects，可設定 alarm 作為重啟機制。

Cloud Run：設定 liveness probe，不健康時自動重啟 instance：

{
  "livenessProbe": {
    "httpGet": { "path": "/health" },
    "initialDelaySeconds": 10,
    "periodSeconds": 30,
  },
}

模式 2：部署失敗自動 Rollback

# GitHub Actions - 部署後驗證，失敗就回滾
- name: Deploy
  run: wrangler deploy

- name: Health check
  run: |
    sleep 10
    STATUS=$(curl -s -o /dev/null -w "%{http_code}" https://your-site.com/health)
    if [ "$STATUS" != "200" ]; then
      echo "Health check failed! Rolling back..."
      wrangler rollback --message "CI auto-rollback: health check failed"
      exit 1
    fi

模式 3：Circuit Breaker

當外部服務（第三方 API、資料庫）出問題時，不要無限重試，而是快速失敗並降級：

// 簡單的 circuit breaker
class CircuitBreaker {
  private failures = 0;
  private lastFailTime = 0;
  private readonly threshold = 5;
  private readonly resetTimeout = 60_000; // 1 分鐘

  async call<T>(fn: () => Promise<T>, fallback: T): Promise<T> {
    if (this.failures >= this.threshold) {
      if (Date.now() - this.lastFailTime < this.resetTimeout) {
        return fallback; // 降級回應
      }
      this.failures = 0; // 嘗試恢復
    }
    try {
      const result = await fn();
      this.failures = 0;
      return result;
    } catch {
      this.failures++;
      this.lastFailTime = Date.now();
      return fallback;
    }
  }
}

這段 code 的意思是：如果某個外部服務連續失敗 5 次，就暫時放棄呼叫它，改用降級方案（例如快取的舊資料）。一分鐘後再試試看有沒有恢復。

用戶不會看到錯誤頁面，你也不會被半夜叫起來。

AI 輔助故障診斷

當問題真的需要你介入時，AI 是你最好的 on-call 夥伴。

用 Claude Code 診斷問題

凌晨被叫起來的時候，你的腦袋是不清楚的。這時候讓 AI 幫你思考：

我的產品在凌晨 3:47 開始出現以下錯誤：

[貼上錯誤訊息和 log]

環境：
- Cloudflare Workers
- D1 資料庫
- 最近一次部署是昨天下午 3 點

請幫我：
1. 分析最可能的原因（按可能性排序）
2. 每個可能原因的驗證方式
3. 建議的修復步驟
4. 判斷這是否需要立即修復，還是可以等到早上

關鍵是最後一點：判斷要不要現在處理。 很多時候，半夜的問題其實沒那麼緊急——某個非核心功能出錯、某個 edge case 才會觸發的 bug。AI 可以幫你冷靜判斷。

備份策略：你一定會感謝自己的

備份是最無聊的主題，但也是最重要的。

備份的唯一規則

如果你沒有驗證過 restore，就等於沒有備份。

我見過太多人設定了自動備份，安心地跑了一年，等到真的需要 restore 時才發現備份檔案是壞的。

Solo Builder 的最小備份清單

備份對象	工具	頻率	驗證頻率
資料庫	D1 自動備份 / Cloud SQL 自動備份	每日	每月測試 restore
程式碼	Git（GitHub/GitLab）	每次 commit	N/A（Git 就是版本控制）
設定檔	Infrastructure as Code（wrangler.jsonc）	隨程式碼一起	每次部署就是驗證
用戶上傳檔案	R2 / Cloud Storage + 跨區複製	即時	每季抽檢
環境變數和密鑰	1Password / Bitwarden	有變更時	每季確認

自動化備份驗證

用 AI 幫你寫一個簡單的備份驗證腳本：

請幫我寫一個 shell script：

1. 從 D1 備份中 restore 到一個測試 database
2. 執行幾個基本查詢，確認資料完整
3. 比較備份資料的 row count 和 production 的 row count
4. 結果寄到我的 email
5. 刪除測試 database

這個 script 會用 cron 每月跑一次。

休假測試：你的產品能自己活兩週嗎？

這是我用來衡量維運成熟度的測試：

如果你完全消失兩週——不看 email、不登入 server、不部署任何東西——你的產品還能正常運行嗎？

如果答案是「不確定」，你需要補強以下幾個環節：

休假前的 checklist

自動備份有在跑，且最近一次 restore 測試通過
監控告警設定好，會通知到手機
SSL 憑證不會在你休假期間過期
沒有需要手動續約的服務（網域、雲端帳單）
客服 auto-reply 已更新，告知回覆會延遲
CI/CD pipeline 不需要手動 approve
資料庫不會在兩週內把空間用完
帳單設定了自動扣款

如果你能自信地在每一項打勾，恭喜——你建立了一個真正自動化的產品。

Runbook：寫給未來的你

最後一個建議：把你的維運步驟寫下來。

Runbook 是一份「出了某某問題，按照這些步驟處理」的文件。

你可能覺得「我自己的東西我當然記得怎麼處理」。但相信我，凌晨四點被叫起來的你，和白天清醒的你，是兩個完全不同的人。

AI 幫你寫 Runbook

以下是我的產品架構：
- 前端：Astro，部署在 Cloudflare Pages
- API：Cloudflare Workers
- 資料庫：D1
- 檔案儲存：R2

請幫我建立一份 Runbook，涵蓋以下常見情境：

1. 網站完全無法存取
2. API 回應時間異常
3. 資料庫連線錯誤
4. 部署失敗
5. SSL 憑證問題

每個情境包含：
- 確認問題的步驟
- 排查清單（按可能性排序）
- 修復步驟
- 修復後的驗證方式

把 Runbook 放在你的 repo 裡（例如 docs/runbook.md）。這樣你在半夜打開終端機時，第一件事不是亂猜問題在哪，而是打開 Runbook 按步驟走。

更好的做法是：把 Runbook 也餵給 AI。 當問題發生時，你可以跟 AI 說「參考我們的 Runbook，幫我排查這個問題」，讓 AI 幫你走流程。

真實案例：bobo-blog 的監控架構

我的部落格 bobo-blog 部署在 Cloudflare Workers 上。以下是我的監控設定，給你參考：

層級	工具	設定
可用性	UptimeRobot	每 5 分鐘 ping 首頁和 `/health`
錯誤	Cloudflare Workers Analytics	監控 4xx/5xx 比例
效能	Cloudflare Analytics	每週看 P95 回應時間
部署	GitHub Actions	部署後自動跑 health check

為什麼這麼簡單？因為 Cloudflare Workers 是 serverless——我不需要管 server、不需要監控 CPU 或記憶體、不需要擔心 process crash。平台幫我處理了大部分的維運問題。

這就是第 6 章：選對平台省 80% 的事的延伸——選對基礎架構，你的維運負擔會大幅降低。

本章重點回顧

🏗️ 監控四層金字塔：可用性 > 錯誤追蹤 > 效能 > 商業指標，按優先順序建立
🔔 告警的黃金法則：只在「需要你做某件事」時才告警，否則你會開始忽略告警
🔧 Self-healing 模式：health check + 自動重啟、部署失敗自動 rollback、circuit breaker
🤖 AI 是你最好的 on-call 夥伴——半夜被叫起來時，讓 AI 幫你冷靜判斷和排查
💾 備份的唯一規則：沒有驗證過 restore 就等於沒有備份
📋 寫 Runbook，寫給凌晨四點腦袋不清楚的自己
🏖️ 「休假測試」：如果你消失兩週，產品還能活嗎？

下一步

到這裡，你的產品已經穩定運行了——有用戶在用、有客服在處理問題、有監控在守護。

接下來的問題是：這個 side project，值不值得更認真？

如果你開始有穩定的用戶、甚至有人付費了，你可能會想：「我是不是應該把這個東西做大？要怎麼定價？什麼時候該考慮離職全職做？」

下一章，我們來聊從 side project 到 Micro SaaS 的轉變——這是每個 Solo Builder 遲早會面對的抉擇。

👉 第 12 章：從 Side Project 到 Micro SaaS