軟體上線驗收清單：部署前、正式站快驗與回滾範本
發布群組顯示「部署成功」，客服打開正式站卻找不到新按鈕。工程師看到的版本沒錯，QA 也貼了通過截圖，最後才發現截圖來自測試站，正式站的功能開關只對內部帳號開放。這是虛構情境，但它很適合拿來檢查發布單：只寫「已上線」時，下一個接手的人能不能查出哪個環境、哪個版本、哪些人真的用得到？
一份軟體上線驗收清單，要能在三個時間點回答不同問題。部署前，這一版有沒有達到放行條件？部署後，正式站上的關鍵操作能不能走完？開放給使用者後，要看什麼訊號才能結束觀察？小團隊用一張發布單就能記完，重點是每個判斷都找得到證據和做決定的人。
部署前先核對驗過的是哪一版
工程師先寫清楚這次要改哪些元件、部署到哪裡、預計開放給誰。Web、API、設定和資料庫可能分開發布，有改動的就各自記版本或變更編號。只有「v2.8.0」時，很難分辨 QA 驗的是第一次打包，還是工程師隔天重打的那一份。發布單至少留一個能追到實際成品的識別，例如建置編號或部署工作連結。若有多個元件，再記錄部署順序和相依性。
產品或業務代表在測試環境做使用者驗收測試（UAT），用能反映日常工作的一組資料確認需求。寫「改期正常」還不夠。寫成「會員把週二的預約改到週三後，週二時段重新可約，週三只有一筆預約」，就能明確比對結果。接著用另一個會員帳號試同一筆預約，驗證權限限制。必驗項目以本次改動、原有關鍵流程和最有影響的失敗情境為主。
先約定誰驗、誰補環境、誰決定放行。假如 QA 沒拿到第二個測試帳號，權限檢查就記「受阻」，請帳號管理人補齊，補完再驗。如果該項是放行條件，先暫停。日程壓力要由決策人處理，驗收欄照實記錄。
部署時核對正式站，再做少量關鍵操作
部署人填上正式環境、實際版本、時間和部署紀錄。QA 先在系統的版本資訊或部署平台確認目前對外服務的是哪一版，再查看這次改動依賴的設定、功能開關和開放對象。碰到新版沒有生效、環境不明或設定差異，先釐清實際狀態，再跑後面的檢查。
正式環境的快速驗證（smoke test）挑幾條能立刻揭露問題的路徑。用核准的測試帳號登入、做一次本次新增的操作、再走一次受影響的既有流程。需要寫入時用可辨識、可清理的測試資料，先確認測試不會寄信或發通知給真實使用者。記下實際結果、時間和證據。若測試中發現 Bug，可把重現條件留在獨立 Bug 單，再連回這次發布。Bug 回報範本與重現步驟
發布後要看什麼，什麼情況先停
上線前就選好一個看得到使用者影響的指標，例如改期請求的失敗率，再寫明觀察區間、最低樣本和判斷人。計算失敗率時看失敗數也看請求數，並排除預期的權限拒絕等情況，避免把正常阻擋算成服務故障。已知會影響資料完整性或權限的問題可以另設立即停止條件。即使只出現一次跨帳號改期，也該先停用入口，保留證據查影響範圍。
回滾計畫至少寫明由誰執行、怎麼恢復原有使用方式、退完要重測什麼。若這次只新增可關閉的入口，可先關掉入口，再確認既有客服流程仍可運作。若有資料異動，還要確認舊版程式能否讀取新資料、受影響的寫入如何補救。關掉新入口可以阻止後續影響，已寫入的異常資料要另外核對和處理。分批開放時如何比較新版訊號、觀察多久，可以參考 Google SRE 的分批發布案例。
填寫範例：預約系統新增會員改期入口
以下是示範用的發布單，版本、時段、帳號與結果皆為虛構。這次沿用既有改期 API，前台新增入口，客服繼續使用原有流程，沒有資料庫結構變更。預計部署前台 v2.8.0（建置 482），先開給兩個內部測試帳號，通過正式站檢查才放給會員。部署由值班工程師負責，QA 留驗收證據，產品負責人決定放行。
| 階段與版本 | 實測與證據 | 判斷與下一步 |
|---|---|---|
| 測試站 v2.8.0／建置 482 | 週三 14:05（UTC+8），產品代表用測試預約 R-001 改期。原時段重新開放，新時段只保留一筆。附件 UAT-01 留存改期前後畫面。 | 改期通過。第二個測試帳號未開通，權限檢查受阻，暫不部署。 |
| 測試站補驗 同一建置 | 14:22，QA 用另一測試會員操作 R-001，系統拒絕且預約沒改動。證據 UAT-02 記錄拒絕畫面和預約狀態。 | 權限通過。產品負責人放行部署，正式站入口先限內部。 |
| 正式站快驗 v2.8.0／建置 482 | 15:03，部署紀錄 DEP-482 確認實際建置。15:12，QA 重測改期、跨帳號拒絕及客服原流程，結果記在 PROD-01。 | 三項通過，產品負責人放行會員使用並開始觀察。 |
| 會員開放後 觀察 30 分鐘 | 15:42，監控紀錄 MON-01 顯示 64 筆有效改期請求，其中 1 筆非預期失敗，約 1.6%。未發現重複預約或越權。 | 達成此批次約定的至少 50 筆請求，失敗率低於示範門檻 5%。結束觀察並開單追查那一筆失敗。 |
如果觀察期只收到 12 筆請求，這份單就維持「觀察中」，由值班人接手。若失敗率達到示範門檻，或出現越權、重複預約，產品負責人決定暫停，工程師關閉新入口，QA 確認會員看不到入口、客服仍能改期，再追查已產生的資料。30 分鐘、50 筆和 5% 都是本案例假設，實際數值要看原本的流量、失敗率和問題影響。
可複製的軟體上線驗收清單
把下方貼進發布單。有些項目不適用，例如這次沒有資料變更，可以寫下原因。每個必驗操作各複製一次「驗收明細」。
發布批次：[名稱／連結]
預定時段：[日期、時間、時區]
變更範圍：[功能／影響對象]
開放順序：[內部／部分用戶／全部]
目標環境：[測試站、正式站或其他]
版本與建置：[每個變更元件各一筆]
部署人：[姓名或當班角色]
驗收人：[UAT 與正式站各填一人]
放行與暫停決策人：[姓名或當班角色]
部署前
[ ] 核對 UAT 證據與待部署建置
[ ] 確認設定、權限、資料變更與相依性
[ ] 確認每個必驗項目都有通過證據
[ ] 確認回滾方法、執行者及退回後要測什麼
部署後
[ ] 填實際環境、建置、時間、部署紀錄
[ ] 核對入口、開放對象與權限
[ ] 跑正式站必驗操作及受影響的舊流程
驗收明細
操作與預期：[角色、步驟、可核對結果]
執行證據：[環境、建置、驗收人、時間、連結]
實際結果：[通過／失敗／受阻，加上觀察]
未完成時：[缺少條件、處理人、重驗時間]
觀察與決策
指標與門檻：[指標、樣本、觀察期限]
立即停止條件：[如越權或資料異常]
回滾與恢復：[步驟、執行者、重測結果]
最終紀錄：[放行部署／開放用戶／結束觀察／暫停／回滾]
決策證據：[決策人、時間、理由及連結]在 LIVO 留下同一批次的版本和驗收證據
啟用 LIVO 的「發布工作區」後，可按批次整理元件、環境和版本，連回關聯任務以及 QA／UAT 證據。部署仍由團隊使用自己的工具執行。建議把同一批次的決策與證據放在一起，下一班接手就能直接查到目前是等部署、等驗收，還是仍在觀察。查看 LIVO 發布工作區功能
如果團隊有例行發布和高風險發布兩種情境，可先保留共同的核對項目，再按變更風險增加資料恢復、權限或監控檢查。Google SRE 的上線清單設計
常見問題
UAT 通過就可以上線嗎？
先核對待部署的是同一個建置，必要設定與放行條件已齊備，再決定是否部署。正式環境還要檢查版本、入口、權限和關鍵操作，因為設定與整合可能和測試站不同。
每次上線都要用同一份清單嗎？
版本、部署人、驗收人、必驗結果和停止條件可以共用。只改頁面文案時，核對新文案和相關連結即可；改到登入、權限或資料時，再加入對應的角色測試與復原驗證。
發現非必驗項目失敗，怎麼決定要不要放行？
記錄實際影響、受影響的對象、替代做法和處理期限，交由發布決策人確認。影響還不明時先補查；已碰到發布前約好的停止條件，就依計畫暫停或回滾。
