編輯導語：任何一件事在完成之前，都需要做一個Checklist，從而檢查錯誤，規避風險。這對於上線來說，尤其重要，稍不注意就可能損害到用戶的體驗感。本文作者從準備階段、發布階段、驗證階段和異常處理四個方面，具體的談了談如何做上線的checklist，希望看後能夠對你有所幫助。
每次發版上線都是一個緊張且激動的時刻，為了保證上線順利，可以早點回家睡覺，上線清單一定提前準備好，做到心中有數。
上線的checklist可簡要分為以下3個部分：
一、準備階段
1. 上線前培訓
上線前給相關人員進行培訓。
首先：需要給客戶進行培訓，讓客戶提前了解改動的功能點。避免出現功能上線後，客戶並不知情，一臉蒙的情況。
其次：上線前也需要給客服等運維人員做好培訓，並告知可能遇到的問題以及對應的解決策略。
2. 數據資料
歷史數據是否做好備份，如果需要清空數據，需再次檢查執行任務的代碼是否準確，執行的時間是否明確。
新數據是否已經準備好，一旦發版成功後，可以及時導入新的數據。
3. 遺留問題
首先：確認全部上線的功能均經過測試驗證。
其次：明確測試結果，了解目前SIT和UAT的情況，是否還有遺留待解決的問題；明確對應遺留問題的原因，以及對應問題的解決時間和責任。
如帶問題部署到生產環境是否嚴重影響用戶體驗，這些都需要提前進行評估。
4. 壓測情況
是否有做壓測，基於壓測結果核對能否支撐大規模的業務場景（需要業務方提供或基於歷史數據進行模擬），並及時做好報備。
5. 埋點
對於新功能，上線前都需要做好埋點工作，並對同功能的歷史數據做好記錄，方便後續做數據分析和對比。
6. 文件報備
明確發版過程中是否需要停機，針對大公司，停機需要提前發停機發文，並告知各個相關系統。
7. 代碼合併
需要對最終發布的代碼做好打包合併，封版後不許改動，如果有則需要重新評估。
8. 代碼review
開發負責人重新對合併的代碼進行review，以免出現問題。
9. 配置文件
上線前的準備工作，配置文件、腳本、程序升級。
10. 小程序提審
如果是小程序，需要提前進行小程序的提審。
11. 日誌
建立快速的日誌清查和響應機制，一旦需要排查問題，這些日誌就是找到原因的關鍵。
12. 人員安排
如果涉及到多個系統，一定要預留相關系統的責任人，並確保功能驗證通過後再離開。
二、發布階段
1. 發版順序
本次功能上線涉及到的相關系統有哪些？
確定系統相互之間的依賴性，明確上線的前置條件及上線順序；確定哪些系統需要先發，哪些後發。
2. 調度執行
夜間是否有調度程序問題？（定時任務）調度什麼時候開始執行？以及什麼是時候終止？停止的調度什麼時候要回寫配置和啟動？
3. 發版模式
確定採取的發版模式是什麼？如灰度發版。
三、驗證階段
1. 功能驗證清單
可以分為兩版：
1）主流程版
針對核心功能進行快速驗證。
2）詳細版本
可以在主流程走通的情況下，再逐個驗證。
測試人員需要基於清單來驗證，可以更加高效，準確，以免遺漏關鍵核心驗證點。
2. 及時輸出缺陷
驗證過程中，及時報備問題，並告知對應的開發，把問題闡述清楚，附帶截圖；讓開發可以清晰是什麼問題，方便快速排查；測試人員需階段性地同步驗證進度和問題解決進展。
四、異常處理
回滾方案：
做好回滾的準備，相關責任人需明確該功能上線的回滾策略。並根據日常的用戶量，評判最晚可以接受的發版時間。
在不大規模影響生產環境用戶的情況下，明確最晚可以接受的系統切換時間；一旦到了時間，如沒有辦法解決發版中的嚴重阻斷性問題，採取版本回退方案。
五、小結
上線Checklist一定是不斷總結，不斷完善的清單列表，並根據上線需求的類別針對性地進行調整。
當然，心態和清晰的頭腦也是至關重要的。發版期間遇到問題時，一定要權衡利弊，優先處理問題，而不是規避責任。畢竟發版時間有限，一切都以風險最低，用戶體驗最佳為原則。
本文由@黑心老巫婆 原創發布於人人都是產品經理。未經許可，禁止轉載
題圖來自 Pexels，基於CC0協議