上線前,請先準備好這份 Checklist

編輯導語:任何一件事在完成之前,都需要做一個Checklist,從而檢查錯誤,規避風險。這對於上線來説,尤其重要,稍不注意就可能損害到用户的體驗感。本文作者從準備階段、發佈階段、驗證階段和異常處理四個方面,具體的談了談如何做上線的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一定是不斷總結,不斷完善的清單列表,並根據上線需求的類別針對性地進行調整。

當然,心態和清晰的頭腦也是至關重要的。發版期間遇到問題時,一定要權衡利弊,優先處理問題,而不是規避責任。畢竟發版時間有限,一切都以風險最低,用户體驗最佳為原則。

【來源:人人都是產品經理社區】

聲明:轉載此文是出於傳遞更多信息之目的。若有來源標註錯誤或侵犯了您的合法權益,請作者持權屬證明與本網聯繫,我們將及時更正、刪除,謝謝。 郵箱地址:[email protected]

版權聲明:本文源自 網絡, 於,由 楠木軒 整理發佈,共 1747 字。

轉載請註明: 上線前,請先準備好這份 Checklist - 楠木軒