功能生命週期（三）：部署、監控到事故處理

接續 開發到 Code Review。你的 PR merge 了，CI 全綠了，接下來呢？

先講結論

上線不是終點，是起點。沒有監控的上線就像閉著眼睛開車——不是不會撞，是你不知道什麼時候撞。

Phase 6：CI/CD 與部署

PR merge 後，Pipeline 自動跑：Lint → Unit Test → Integration Test → Build → Deploy Dev → E2E Test → Deploy Staging → QA 驗收 → Deploy Production。

每一步失敗都有意義：

• Lint 失敗 → 格式或潛在錯誤
• Unit Test 失敗 → 邏輯錯誤
• Build 失敗 → 依賴問題
• E2E 失敗 → 使用者流程斷了

CI/CD 設計見 CD。

環境分離

Google 登入在不同環境用不同的 OAuth credentials：

• Dev：localhost:3000/callback，本地開發
• Staging：staging.example.com/callback，QA 驗收
• Production：example.com/callback，正式環境

絕對不要用 Production 的 Google credentials 跑測試。 這不是建議，是命令。

環境分離見 環境分離。

Phase 7：上線後——真正的考驗

功能上線了。然後呢？

監控指標

你至少要盯這幾個數字：

• Google OAuth 成功率：正常 > 95%，低於 90% 告警（Google API 或你的 callback 有問題）
• 登入 API 回應時間 p99：正常 < 500ms，超過 1000ms 告警
• JWT 簽發失敗率：正常 0%，任何失敗都是嚴重問題

監控建置見 監控。

Log 要有追蹤能力

每個 request 要有 traceId，使用者回報問題時你才能把整條路徑串起來。

{
  "traceId": "abc-123-def-456",
  "event": "google_oauth_login",
  "userId": "user_789",
  "action": "account_linked",
  "isNewUser": false,
  "latencyMs": 342
}

Structured log 讓你能查「過去一小時多少登入失敗」，而不是在茫茫文字 log 裡撈針。Log 管理見 Log 管理。

出事了怎麼辦

上線第二天告警響了：成功率從 97% 掉到 60%。

這時候走事故管理流程（見 事故管理）：

1. 確認影響範圍——只有 Google 登入，還是整個登入掛了？
2. 用 traceId 追蹤失敗的 request
3. 快速判斷——我們的 bug？Google 維護？SSL 過期？
4. 應急處理——考慮 rollback
5. Post-mortem——確保不會再發生

如果你有 Debug 方法論，步驟 2 和 3 會快很多。

上線前 Checklist

在按「Deploy to Production」之前：

• PRD 經 PM + 工程師 review
• Acceptance criteria 都有測試
• API Spec 前後端已對齊
• Unit / Integration / E2E test 通過
• 沒有 hardcoded secret
• CI Pipeline 全綠
• Staging QA 通過
• Production 環境變數設定完成
• Rollback 計畫確認
• 監控 Dashboard + 告警規則就位
• On-call 工程師知道上線時間

系列回顧

七個階段走完了。回顧一下每個階段對應的文章：

• 需求釐清 → 好產品的定義
• 技術設計 → 系統規劃、API 設計
• 開發準備 → Proto 規劃、Git Flow
• 開發 → 測試策略、CommitLint
• Code Review → Code Review 方法論
• CI/CD → CD、環境分離
• 上線後 → 監控、Log 管理、事故管理

小功能每階段五分鐘，大功能每階段一週。方法論不是枷鎖，是護欄——不讓你走得更慢，讓你走得更穩。

---

一個「Google 登入」就要走七個階段、牽涉十幾篇文章的知識。你還覺得 PM 說的那句「很簡單啊」是真的嗎？