2 個工程師維運 8 個產品的營運心法
H
HarrysonTech Engineering
AI-driven tech team · 2 engineers · 8 active products · 0 on-call incidents（6 個月）
2 個工程師維運 8 個生產產品不崩潰的關鍵不是工作更努力，而是讓系統的大部分工作自動完成。海衫科技的做法：90% 的事件由自動化系統處理，人工只介入那 10% 真正需要判斷的問題。
📌 關鍵要點 Key Takeaways
- 自動化監控覆蓋 8 個產品，每分鐘 40 個健康檢查
- 事件 SOP 的核心是「先分流、再處理」，不是一看到告警就衝進去
- 優先級框架：P1（5 分鐘響應）、P2（30 分鐘）、P3（下個工作日）
- 外包判斷標準：重複性高 + 不需要產品知識 + 可以寫清楚 SOP
- 每週 1 小時的「技術債追蹤會議」防止問題累積成危機
核心原則：不要做系統可以做的事
工程師的時間只能用在三件事：設計系統、處理系統無法自動解決的問題、改進系統讓它能處理更多自動化。所有其他事情都應該被自動化或外包。
聽起來像廢話，但執行起來需要嚴格的自律。每次有問題發生，第一個問題不是「我怎麼解決這個問題」，而是「怎麼讓這個問題下次不需要我介入就能被解決」。
自動化監控：40 個健康檢查，全天候
8 個產品的監控設定，每分鐘執行 40 個健康檢查：
| 監控類型 | 工具 | 檢查頻率 | 告警閾值 |
|---|---|---|---|
| Endpoint uptime | BetterStack | 每分鐘 | 連續 2 次失敗 |
| Response time | BetterStack | 每分鐘 | P99 > 3 秒 |
| Error rate | Vercel Analytics | 即時 | 5xx > 1% |
| Database health | 自建腳本 | 每 5 分鐘 | 連接數 > 80% |
| API quota | 自建腳本 | 每小時 | 使用量 > 70% |
| SSL certificate | BetterStack | 每天 | 到期前 14 天 |
告警通道：全部走 Telegram bot。分兩個群組：
- #alerts-critical：P1 事件，所有人立刻看到
- #alerts-info：P2/P3 事件，每天統一處理
為什麼是 Telegram 不是 PagerDuty？PagerDuty 要 $19/用戶/月，功能 80% 我們用不到。Telegram 免費，bot 自己寫，2 小時搞定。
事件回應 SOP
收到告警的標準流程，不允許跳步驟：
- 確認（2 分鐘）：這是真實問題還是誤報？查監控 dashboard 確認
- 分類（3 分鐘）：P1（影響用戶）/ P2（有風險但用戶尚未受影響）/ P3（技術問題，低優先）
- 隔離（5 分鐘）：問題在哪一層？前端、API、資料庫、外部服務？
- 緊急緩解（15 分鐘）：先讓服務恢復，再找根本原因（rollback、feature flag 關閉、快取清除）
- 根本原因分析（事後）：問題真正的原因，防止復發的措施
P1：立即響應（5 分鐘內）
定義：用戶無法使用核心功能、資料遺失風險、安全漏洞
例子：API 全面 5xx、資料庫連接斷開、付款系統失敗
定義：用戶無法使用核心功能、資料遺失風險、安全漏洞
例子：API 全面 5xx、資料庫連接斷開、付款系統失敗
P2：今天內處理（30 分鐘內）
定義：部分功能異常、效能明顯下降、有復發風險的問題
例子：特定 API endpoint 慢 3 倍、某個功能對 5% 用戶失敗
定義：部分功能異常、效能明顯下降、有復發風險的問題
例子：特定 API endpoint 慢 3 倍、某個功能對 5% 用戶失敗
P3：排入工作計劃
定義：技術債、非關鍵 bug、優化機會
例子：測試覆蓋率降低、程式碼品質問題、文件不完整
定義：技術債、非關鍵 bug、優化機會
例子：測試覆蓋率降低、程式碼品質問題、文件不完整
優先級判斷的本質
大部分人的優先級判斷是錯的，因為他們用「緊急程度」代替「重要程度」。一個發瘋在 Slack 追問的用戶讓你感覺很緊急，但他的問題可能是 P3。一個沉默的資料庫問題可能是 P1。
我們用兩個維度判斷：
- 受影響用戶數：影響 1 個用戶和影響 1000 個用戶，優先級完全不同
- 有無可用替代方案：用戶可以用其他方式完成任務嗎？
這兩個維度決定優先級，不是「誰叫得最大聲」。
什麼要自己做，什麼要外包
外包判斷框架——同時滿足這三個條件才考慮外包：
- ✅ 重複性高：每週出現超過 2 次的相同任務
- ✅ 可以寫清楚 SOP：能用文字完整描述如何處理，不需要特殊判斷
- ✅ 不需要產品核心知識：外包方不需要理解我們的商業邏輯
我們目前外包的事：
- 客服第一線回覆（有 SOP 文件，AI 處理 90%，人工審核 10%）
- 社群媒體定期發文（有內容日曆，外包執行）
- 設計圖輸出（有設計系統，外包按規格輸出）
我們不外包的事：
- 技術架構決策
- 產品功能優先級
- 用戶研究與需求訪談
- 任何涉及客戶資料的操作
每週 1 小時技術債追蹤
技術債不管理就會累積成危機。我們每週一固定 1 小時：
- 回顧上週所有 P3 問題（15 分鐘）
- 評估技術債的「利息成本」：這個問題如果繼續放著，會讓每個相關功能的開發時間增加多少？（20 分鐘）
- 決定本週要處理哪些技術債（10 分鐘）
- 排入下週工作計劃（15 分鐘）
關鍵指標：我們追蹤「技術債利息總和」——所有現有技術債加起來讓我們每週多花多少時間。這個數字如果超過 4 小時/週，當週的新功能開發要讓位給技術債清理。
最重要的一件事
如果只能選一件事，那是：讓你的系統在你睡覺時能自我診斷和自我恢復。不是更努力工作，不是更快回應告警，而是讓系統在大多數情況下不需要你。
這需要前期投資——建立自動化監控、寫 runbook、設計 circuit breaker 和 fallback 機制。但這個投資的回報是：你可以在晚上睡覺、在週末不看手機，同時知道系統在正常運作。