案例分享|我們的一次線上事故復盤

7 評論 16221 瀏覽 25 收藏 6 分鐘

問題出現了并不可怕,只要我們追本溯源,找到問題根源所在,科學的解決問題,合理的制定流程,就能離成功更近一步。

線上事故,這應該是產品經理最怕的事情。很不巧,我的產品這幾天正好遇到了線上事故,在處理完問題之后,我對事故進行了復盤,警以為戒,希望各位輕拍。

“小凡,你看微博有用戶反饋xx問題?!?/p>

每次聽到運營妹子的聲音都會有種心驚肉跳的感覺,因為這悅耳的聲音背后往往意味著用戶吐槽,意味著線上bug。這不,昨天剛發布的版本出現了問題,用戶怒了。

問題是什么

我負責一款以內容為核心的工具型應用,在我們最新發布的版本中,我們對內容展示頁面進行了優化,索引詞會高亮顯示以幫助用戶更好地查看、理解內容。

但是上線后用戶反饋索引詞的順序有問題,全部提至了句首,導致句子全部錯誤,無法正常閱讀。

問題在哪里

程序設計錯誤

程序猿在做索引詞高亮處理時,程序邏輯設計不當,雖然對索引詞加了高亮,但是處理高亮詞是將整個句子視作一個詞條進行處理,提取索引詞后進行高亮處理,將高亮詞放回時,替換其到index=0的位置,導致索引詞顯示在句首。

功能測試遺漏

測試同學在做模塊化測試、全功能測試時,并未測試到該細節,導致該bug發布上線,當用戶反饋后才補充了內容測試相關case。

存在問題的原因

新代碼設計不合理

舊的邏輯是按照空格進行字符串的分割,將句子拆分為一個個詞,再去判斷是否有索引詞,如有則提取出來做高亮,而我們本次處理的內容由于語種特性并沒有空格。

程序猿并未考慮新需求的不同之處,依舊使用統一的處理方式,導致新的語種內容在呈現上出現異常。

正常處理邏輯應該是不按空格進行拆分,直接判斷例句中是否包含所查索引詞,如有并作高亮顯示。

提測單未寫明修改點

按規范每輪單元測試,需將新功能、修改點、可能涉及的影響都寫明,讓測試同學知曉以便進行全面測試。但在開發同學看來本功能較小,并未在單元提測中單獨標明。

測試未覆蓋內容版塊

測試針對新功能、UI和測試用例進行了測試,但是未考慮到本應用是重內容的應用,缺乏對內容的測試。

我們能做什么

安撫用戶

定位問題之后,運營同學第一時間與微博用戶聯系,先表達歉意,再標明程序猿正在修復中,請用戶耐心等待;同時發布正式通知,告知用戶問題已經開始修復,我們將盡快發布新版本以解決問題。

緊急修復

在運營同學發布通知的同時,程序員立即著手修復該bug,并針對此前忽略的內容問題進行復查,自測通過后移交測試人員。測試通過后,請教研同學配合進行內容測試,確保內容相關展示無誤。

盡快發版

蘋果應用商店的正常審核流程是3至7天不等(必須吐槽),但是緊急bug刻不容緩,不能走此正常流程。面對極其重視用戶體驗的蘋果,加速審核申請往往能幫你在數小時候審核通過。

必須讓蘋果知道你是非常重視用戶體驗的,而你的app現在出現了非常嚴重的bug,為了用戶的體驗你必須立刻發布一個版本,這樣加速審核通過的概率會很高。審核通過后,立即發布上架讓用戶更新,這時候用戶更新說明也是至關重要的,值得用心去寫。

我們應該做什么

上面幾個步驟重在解決已發生的問題,而在我看來更重要的是知道如何規避未來的問題。這就涉及修改流程了,我們是這么做的:

1.兩端開發人員系統梳理代碼邏輯,差異點、疑問點及時進行溝通、確認;

2.版本正式開發前,增加技術拆分會,確認開發思路和實現邏輯;

3.iOS開發人員加強代碼交叉review;

4.iOS開發人員加強自測,自測中加強與安卓端對照;

5.測試人員增補內容測試用例,加強兩端對照測試;

6.嚴格執行產品體驗會,發版前組織教研、內容、運營等人員進行產品體驗。

寫在后面

這次事故出現后,我們團隊迅速行動,從bug定位到新版本發布上線,只用了不到24小時,我想這也是值得欣慰的一點吧。

愿各位同行的產品都不會出現事故!

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 測試用例,不用回復

    來自河北 回復
  2. 好奇一點,聽上去本次更新的主要內容就是索引詞高亮功能,但這個主要功能的重大bug竟然沒有測試發現,聽上去很匪夷所思的感覺

    回復
    1. 這個功能點的確引發了bug,但只是本次迭代中非常小的一個功能點。

      回復
  3. 對我這樣剛轉行沒多久的小白來說,這都是寶貴的經驗,多謝分享!

    來自天津 回復
    1. 近期會總結下工作,還會寫幾篇工作中遇到的問題。 ??

      來自上海 回復