Production Release 與 Post-Release 監控
一句話總結：選對 Release Window、做完 Smoke Test、盯好監控指標。Release 不是部署到 Production 就結束了——後面的監控和覆盤一樣重要。
結論先講：週五下午不 Release。這不是迷信，是血淚教訓。出了問題你要嘛週末加班，要嘛等週一才處理——兩個都是爛選項。
Release Window：什麼時候上線
| 時段 | 推薦度 | 原因 |
|---|---|---|
| 週二~週四上午 | 最佳 | 全員在線，有充足時間監控 |
| 週一上午 | 可以 | 但週一早上通常比較混亂 |
| 週五 | 避免 | 出問題要週末加班 |
| 週末/假日 | 禁止 | 除非有特殊原因 |
| 任何日下午 4 點後 | 避免 | 處理時間不足 |
最佳 Release Window：週二至週四，上午 10:00 - 12:00，確保下午有充足的監控時間。
部署策略選擇
根據風險等級選策略：
| 策略 | 適用場景 | 回滾速度 |
|---|---|---|
| Rolling Update | 常規 Release、無狀態服務 | 中 |
| Blue-Green | 需要快速回滾 | 極快（切換流量） |
| Canary | 大型變更、不確定性高 | 快（停止金絲雀） |
Feature Flag 啟用順序
如果這次 Release 有 Feature Flag 控制的功能：
- 部署程式碼——所有 Flag 預設關閉
- Smoke Test——確認部署成功、現有功能正常
- 逐步啟用——按優先順序和風險等級逐一開啟
- 每個 Flag 開啟後觀察 15-30 分鐘
- 有異常就關 Flag——不需要 rollback 整個 deployment
這就是 Feature Flag 的威力。出問題時關一個開關，比 rollback 整個部署快得多也安全得多。
Smoke Test
部署完成後立即跑 Smoke Test。這不是完整的功能測試，是快速確認「系統基本上沒壞」：
基礎設施： Container 正常運行、Health check 回 200、DB/Redis 連線正常、第三方 API 通。
核心流程： 首頁載入、登入成功、關鍵 API 端點回應正常、核心業務流程走得通。
監控確認： Error Rate 沒升高、Response Time 正常、CPU/Memory 穩定、Log 沒有異常錯誤。
Smoke Test 不過就不繼續。不要抱著「先上線看看」的心態——這個心態是所有 Release 災難的共同起源。
Post-Release 監控
Release 不是部署到 Production 就結束了。
| 時間段 | 關注重點 | 行動 |
|---|---|---|
| 0-2 小時 | 立即影響 | 全團隊在線，密切監控 |
| 2-24 小時 | 短期穩定性 | On-call 持續監控 |
| 24-72 小時 | 中期穩定性 | 正常輪值，關注趨勢 |
技術指標： Error Rate、Latency P95/P99、Throughput、CPU/Memory、DB 連線數和慢查詢。
業務指標： 訂單數/交易量、用戶活躍數、轉換率、客訴數量。
業務指標很容易被忽略。技術指標全部正常，但訂單量掉了 30%——可能是某個結帳流程的小改動導致使用者卡住了。這種問題光看技術指標看不出來。
監控期間的事故回應
| 異常等級 | 觸發條件 | 行動 |
|---|---|---|
| 關注 | 輕微波動但在閾值內 | 持續觀察 |
| 警告 | 接近閾值 | 通知 on-call 排查 |
| 嚴重 | 超出閾值 | 啟動事故流程，評估 Rollback |
| 緊急 | 核心功能不可用 | 立即 Rollback |
更多事故處理的流程，參考 事件管理方法論。
Release 覆盤
每次 Release 後都要覆盤。不需要像 Post-mortem 那麼正式，但要記錄：
- 做得好的地方（保持）
- 需要改善的地方（改進）
- 行動項目（有負責人、有到期日）
## Release Retrospective — v2.5.0
### 做得好
- Feature Freeze 按時執行，沒有例外
- Smoke Test 15 分鐘內完成
### 需要改善
- Migration Dry-run 只做了一次，建議至少兩次
- Release Notes 在 Release 當天才寫
- 客服團隊 Release 當天才被通知
### 行動項目
| # | 項目 | 負責人 | 到期日 |
|---|------|--------|--------|
| 1 | Release Notes 改為 Freeze 時草擬 | PM | 下次 Release |
| 2 | 客服通知提前到 T-3 天 | RM | 下次 Release |
| 3 | Migration Dry-run 至少兩次 | DBA | 下次 Release |覆盤最重要的是行動項目要進 Jira/Linear，有人負責、有截止日。「記下來了」但沒有追蹤的行動項目等於沒有。下次覆盤第一件事：上次的行動項目做了嗎？
Release Notes：對不同人說不同的話
| 受眾 | 內容 |
|---|---|
| 工程團隊 | 技術變更、Known Issues、環境變數變更 |
| 產品/業務 | 新功能說明（附截圖）、Bug 修復、行為變更 |
| 終端用戶 | 新功能亮點（用人話寫）、改善項目 |
工程師寫給用戶的 Release Notes 常見的問題：「修復了 Redis connection pool exhaustion 導致的 timeout」。使用者看到會問：「所以這跟我有什麼關係？」正確寫法：「修復了偶爾出現的頁面載入緩慢問題」。
這篇的重點回顧
選對 Release Window（週二~週四上午）。Smoke Test 不過就不繼續。Post-Release 監控分三個階段（0-2h 密集、2-24h on-call、24-72h 正常輪值）。同時看技術指標和業務指標。每次 Release 後覆盤，行動項目進追蹤系統。Release Notes 對不同受眾用不同語言。
系列文章：
- Release 方法論（一）：Release vs Deploy
- Release 方法論（二）：Code Freeze 與 QA 驗證
- No-Go
- 你在這裡 → Release 方法論（四）：Production Release 與 Post-Release
- Release 方法論（五）：Release Cadence、Hotfix 與反模式
「最好的 Release 是無聊的 Release——按照 checklist 做完，指標正常，收工下班。」