在 《#066 上線前的排雷指南》，我們把測試策略談完了。程式碼準備好了，版號也確認了。很多剛進入專案現場的 PM，走到這一步時，常會自然地對工程師說一句，「好，那我們上線吧。」彷彿接下來只是工程師把程式推上去，系統就會自動開始運作。但是，有經驗的PM在這一刻應該會更加的緊張、小心，手手默默在發汗。
只要你的產品已經有真實用戶、有交易資料、有正在進行的營運活動，「上線」就絕對不是工程師單方面執行的一個動作。它是一場橫跨 IT、RD、QA、營運、客服，甚至行銷的共同作業。若沒有事前規劃，上線就不是發布，而是把風險直接留到正式環境。
更現實的是，上線失敗的代價通常不是單一功能異常而已。使用者可能在付款途中被中斷，客服可能在毫無準備的情況下被大量客訴湧入，行銷投放可能因連到異常頁面而直接浪費預算。最嚴重的情況，是版本上不去、資料又沒有完整備份，那就不是單純被責備，而是對整個產品營運造成實質威脅。
因此，這一篇要談的，不只是停機維護的流程，而是 PM 在這個階段真正該扮演的角色。你不需要親自輸入部署指令，但你必須知道每一個環節在做什麼、風險在哪裡，以及誰應該在什麼時間點做好什麼準備。因為這場行動若沒有總指揮，最後通常不會缺少執行，而是缺少節奏。
◆ 階段一 事前準備與公告
對外先安撫，對內先釐清
上線的準備工作，不是從停機當晚才開始，而是應該在前幾天，甚至更早就啟動。這一階段真正要做的，是預期管理。也就是說，先讓內部團隊知道自己要做什麼，也讓外部使用者知道系統在什麼時間會受到影響。
1. 敲定維護時間與 Go／No-Go 判斷點
停機時間通常會安排在流量最低的離峰時段，例如凌晨兩點到四點。這不是形式，而是為了降低對真實用戶的影響。
在正式上線之前，應該先召開發布前確認會議，逐項確認版本是否具備發布條件。若 QA 仍回報重大問題未解，或核心流程尚未完成驗證，PM 必須明確做出判斷。此時最重要的，不是「勉強上線」，而是果斷做出 No-Go 的決定。取消本次上線，有時候反而是保護產品與團隊最負責任的作法。
2. 跨部門同步，先把營運節奏處理好
上線從來不是 RD 的事而已。營運、客服、行銷都必須事先知道這次版本會在什麼時間點切換，以及切換後可能帶來哪些影響。
營運與行銷需要先確認，停機時段內是否安排了重大活動、直播或廣告投放。因為若一邊花錢導流，一邊讓使用者看到維護頁，那就不是效率問題，而是決策問題。
客服也需要事先收到一份可執行的資訊。這次更新哪些內容、預計停機多久、若超時未恢復時該怎麼回覆使用者、若新版上線後出現常見問題，第一線應如何說明。這些內容若沒有事先準備，等到電話與訊息同時進來，現場只會更混亂。
3. 對外發布維護公告
停機前幾天，通常就應透過官網、App 內公告、社群媒體，或必要時透過 Email，對外說明維護安排。
公告內容至少要包含兩件事。第一，維護起訖時間。第二，哪些服務會受到影響。
這樣做的目的，不只是告知，而是降低使用者對突發異常的焦慮。因為對使用者來說，不能使用本身不一定最讓人反感，最讓人反感的通常是「不知道發生了什麼」。
◆ 階段二 停機與備份
先切斷外部干擾，再把退路保留下來
時間一到，真正的發布作業才正式開始。這一階段最重要的關鍵，不是「趕快上版」，而是先把系統帶到一個安全、可控的狀態，並且保留退路。
1. 切換維護頁面
停機不應只是把伺服器停掉，讓使用者看到冰冷的錯誤畫面。比較成熟的做法，是先將外部流量導向一個明確的維護頁面，清楚說明目前正在進行系統升級，以及預計恢復時間。
這不只是體驗問題，也是風險管理問題。因為當使用者知道這是預期內的維護，而不是系統異常，後續的客訴與疑慮就會明顯降低。
2. 暫停背景排程
許多系統在背後都有固定排程，例如自動扣款、報表產生、Log 整理、資料同步、通知發送。這些工作若在更版過程中持續執行，很容易造成資料衝突、重複執行，或版本切換過程中的不一致。
因此，在正式部署之前，這些背景排程通常都需要先暫停。這不是額外程序，而是避免版本切換過程中產生新問題的基本動作。
3. 進行資料庫備份
這是整個停機流程裡，最不能省略的一步。
在正式環境套用任何新程式碼或資料庫異動之前，必須先完成完整的資料庫備份。
若沒有這份備份，後續一旦上版失敗、資料轉換異常、資料表結構不相容，團隊就會失去最後的退路。PM 在這裡不需要自己執行備份，但必須主動確認，備份是否已完成、備份檔是否可用，以及備份完成後才能進入下一個步驟。
◆ 階段三 上版本與資料轉換
真正的核心手術，從這裡開始
備份完成後，系統才進入真正的更版階段。這一段通常是技術操作最密集、也最需要節奏穩定的地方。
1. 部署新版程式碼
RD 依照既定計畫，將前端、後端的新版本部署到正式環境。這裡不是單純把檔案放上去而已，而是要確認各個服務、各個相依元件，以及相關設定值，都已切換到正確版本。
2. 執行資料庫異動
若這次更新涉及資料表結構變更，例如新增欄位、調整關聯、合併表格、資料格式轉換，那麼資料庫異動就會成為整個流程裡最敏感的一段。
這也是為什麼停機維護時間不能只是大概估算。資料量若很大，Migration 本身就可能需要數十分鐘，甚至更久。這段時間若估得太樂觀，後面的驗證、回復與決策時間就會被壓縮，風險也會跟著升高。
◆ 階段四 線上驗證與決策
不是程式碼上去了就算完成，而是要先確認能不能運作
版本與資料都已切換完畢，這時候系統其實還不能立刻對外開放。因為程式碼上去，只代表技術步驟完成，並不代表系統已經具備對外服務的條件。
1. 開放內部白名單測試
在這個階段，系統通常仍維持對一般使用者顯示維護中，但會透過白名單方式，讓特定 IP 或特定人員可以先進入正式環境驗證。
這個設計很重要，因為它讓團隊有機會先在真實 PROD 條件下確認核心流程，而不必立即面對全體使用者同時進站的風險。
2. 進行冒煙測試
這時候 PM、QA 與相關人員會用測試帳號，在正式環境裡走一次最核心的流程。
例如登入、首頁載入、下單、付款、核心功能顯示、新功能是否出現、最重要的資料是否正確。
這一段測試不求全面，但求準確。因為目的是判斷這一版是否已具備對外開放的條件，而不是在這裡重新做一次完整回歸測試。
3. 做出 Go 或退版的判斷
如果核心流程順利，系統狀態穩定，那就可以進入對外開放階段。
但若這個階段發現的是重大異常，例如一操作核心功能就崩潰，而且評估短時間內無法修正，PM 必須立即做決策。
此時最重要的，不是繼續勉強，而是果斷啟動 退版（Rollback）。
把程式退回穩定版本，把資料回復到安全狀態，寧可宣布本次上線延期，也不要讓真實用戶進入一個明顯異常的系統。
◆ 階段五 對外開放與營運監控
不是開門就結束，而是要開始觀察現場反應
通過內部驗證之後，系統終於可以對外開放。但這並不代表工作完成，而是另一段更接近營運現場的觀察開始。
1. 撤下維護頁，重新啟動背景排程
維護頁面撤下之後，外部流量重新導入系統。同時，先前暫停的背景排程也需要依序恢復運作，確保後續資料流程與服務機制恢復正常。
2. 客服與營運待命
PM 需要發布明確的內部通知，讓相關部門知道版本已上線。客服則應進入較高警戒狀態，因為停機後重新開放，通常會有一批原本被擋在門外的使用者重新進站，再加上新版介面或流程變動，也可能讓部分使用者短時間內不熟悉。
3. 監控系統狀態
RD 與 IT 在這一階段仍不能離開。他們需要持續觀察伺服器資源、錯誤日誌、回應時間與流量狀況。因為有些問題，只有在真實流量進來之後才會出現。內部幾位同仁測不出來，不代表正式環境不會出事。
這也是為什麼正式發布從來不是一個單點動作，而是一段持續觀察的過程，PM不一定有直接進行任何的操作，但是卻需要背負著「一切順利」的擔憂，等待的過程是非常煎熬難耐的，如果沒有和團隊有一個「版本更新的維護流程」，多半就會在群裡面一直問「好了沒？」，團隊往往也會因為這一句「好了沒」，變得相當沒有耐心。
◆ 廣三觀點
嗨，我是廣三。
很多剛進專案的 PM，會覺得停機維護只是工程師半夜在操作系統，自己似乎只是在旁邊等待結果。但我一直認為，上線流程是最能檢驗 PM 專案管理能力的一個場景。
因為在這兩個小時裡，你真正協調的不是程式碼，而是整間公司的營運節奏。你要確認行銷預算不被浪費，客服知道如何回應，營運明白哪些功能有變動，工程團隊有足夠的退路可以安全操作。也就是說，這不是技術作業而已，而是一場跨部門協同的發布行動。
一場成熟的停機維護，理想狀態應該是非常平穩、非常規律，甚至有點無聊。若上線當晚充滿驚喜、臨時修正、現場決策、誰都不確定下一步，那通常不代表團隊反應快，而是前面的準備工作做得不夠。
所以，真正成熟的 PM，不會把上線當成「按一個按鈕」，而是把它當成一場有節奏、有檢查點、有退路的跨部門作戰。當你能帶著團隊從公告、停機、備份、部署、驗證一路走到重新開放，你就不只是參與發布，而是在管理一次完整的產品風險轉換。
若你在PM這條路上感到迷茫，
或想更清楚了解自己的能力與定位，
歡迎試試這份《PM產品／專案雙軌分析報告》。
它不為了定義你，而是幫助你更看清自己。
歡迎關注：
官網：https://unityprosper.com/
部落格：https://hero-mi.com/
FB：https://www.facebook.com/DigiPRDCoachHeroMi
LINE OA：@hero-mi
《歡迎加我LINE，一起破局未來》
請於下方輸入電子郵件信箱，即可接收最新訊息。
探索更多來自 AI時代|PM破局未來 的內容
訂閱即可透過電子郵件收到最新文章。
留言