編輯導語：任何一件事在完成之前，都需要做一個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協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部