Staging 驗收與 Go/No-Go 決策
一句話總結：Staging 驗收不是再跑一次 QA，是在接近 Production 的環境裡確認「整體行為是否如預期」。Go/No-Go 是多方利害關係人的共同決策，不是某個人拍腦袋。
結論先講：如果你的 Staging 環境跟 Production 差距很大，那 Staging 驗收就是在演戲。Go/No-Go 會議沒有 Rollback Plan 就不准喊 Go。
Staging：Production 的鏡像
Staging 驗收的定位不同於 QA。QA 環境做功能測試，Staging 做的是「在接近 Production 的環境中，整體行為是否正常」。
Staging 環境要做到：
- 部署方式跟 Production 一樣（同一條 CI/CD pipeline、同樣的部署指令）
- 使用脫敏後的生產資料（不是空資料庫或幾筆測試資料）
- 第三方服務用 Sandbox 但配置結構一致
- SSL/TLS、DNS、Reverse Proxy 配置跟 Production 一致
如果你的 Staging 用的是 SQLite 但 Production 用 PostgreSQL，那你的 Staging 驗收基本上沒有意義。
UAT：讓非技術的人來確認
UAT（User Acceptance Testing）不是找 Bug——那是 QA 的工作。UAT 是讓 PM、業務負責人、客服主管來確認：
- 做出來的東西是不是他們要的
- 操作流程順不順暢
- 業務規則對不對（價格計算、折扣邏輯、權限控制）
- 跟其他系統的串接正不正常
「PM 說這不是我要的」這種事，應該在 Staging 被發現，不應該在 Production 被發現。
效能驗證
在 Staging 跑效能測試，確認新版本沒有效能退化：
- 核心 API 的 P95/P99 回應時間在 SLA 範圍內嗎？
- 預期負載下系統穩定嗎？
- CPU、Memory 用量合理嗎？有 Memory Leak 嗎？
- 跟當前 Production 版本比較，效能有退化嗎？
Data Migration Dry-run
如果這次 Release 有 DB Schema 變更或資料遷移，必須在 Staging 做 Dry-run：
- 執行 Migration——確認腳本可以跑
- 計時——記錄需要多久，評估對 Production 的影響（需不需要停機？）
- 驗證資料——Migration 後資料正確嗎？
- 測試 Rollback——Migration 能回滾嗎？回滾後資料完整嗎？
第四點最關鍵。我見過太多 Migration 只寫了 up 沒寫 down。出了問題之後才發現回不去。
Go/No-Go：不是一個人的決定
Go/No-Go 是整個 Release 流程中最關鍵的決策點。它不是 PM 一個人說了算，也不是 Tech Lead 一個人說了算。
RACI 矩陣：
| 角色 | 職責 |
|---|---|
| Release Manager（R） | 收集所有資訊、召開會議、執行決策 |
| Tech Lead（A） | 做最終技術決策。有權叫停 |
| PM + QA Lead（C） | 提供功能和品質層面的意見 |
| EM + 下游團隊（I） | 被告知決策結果 |
Go/No-Go Checklist
逐項確認：
品質門檻：
- P0 Bug = 0
- P1 Bug = 0（或有風險簽核）
- 回歸測試通過率 > 95%
- 核心流程 100% 通過
- QA Sign-off 完成
Staging 驗收：
- UAT 完成且 PM 簽核
- 效能驗證通過
- Data Migration Dry-run 通過
準備度：
- Rollback Plan 就緒且在 Staging 驗證過
- 監控 Dashboard 準備好
- On-call 人員排定
- Release Notes 寫好
時機：
- 不是週五下午
- 不在重大活動期間
- Release Window 內有足夠人員在線
- 下游團隊已通知且準備就緒
Rollback Plan 審查
在 Go/No-Go 會議中，Rollback Plan 必須被明確審查：
| 項目 | 必須回答的問題 |
|---|---|
| 觸發條件 | 什麼指標超過什麼門檻就觸發？ |
| 執行步驟 | 任何 on-call 工程師都能執行的逐步指令？ |
| 資料回滾 | 有 Migration 的話，回滾後資料怎麼處理？ |
| 時間預估 | Rollback 需要多久？ |
| 驗證方式 | 回滾完成後怎麼確認系統恢復正常？ |
沒有 Rollback Plan = 不准 Go。 這是硬規矩。「出問題再想辦法」不是 Plan。
溝通計畫
Release 不只是工程師的事。溝通計畫涵蓋：
- T-2 天：通知工程團隊 Release 時間和範圍
- T-1 天：通知客服團隊新功能和常見問題預備
- T-0（Release 時）：Slack Release 頻道即時更新進度
- T+1 小時：發送 Release 結果通知
外部溝通（如適用）：Release Notes 發布、用戶公告、API 變更通知。
這篇的重點回顧
Staging 不是再跑一次 QA，是在 Production-like 環境做整體驗證。UAT 讓非技術的人確認「這是我要的」。Go/No-Go 用 RACI 矩陣明確責任，用 Checklist 確保無遺漏。Rollback Plan 是 Go 的必要條件。溝通計畫讓所有利害關係人不被 Release 嚇到。
系列文章：
- Release 方法論（一）：Release vs Deploy
- Release 方法論（二）：Code Freeze 與 QA 驗證
- 你在這裡 → Release 方法論（三）：Staging 驗收與 Go/No-Go
- Release 方法論（四）：Production Release 與 Post-Release
- Release 方法論（五）：Release Cadence、Hotfix 與反模式
延伸閱讀：
「Go/No-Go 會議最好的結果是無聊——每一項都打勾，沒有爭議，30 分鐘散會。」