關注並將「人人都是產品經理」設為星標
每天早 07 : 45 按時送達
這幾年直播帶貨的熱潮一直高居不下，而由於疫情的衝擊，上半年很多傳統店鋪都開始在各種直播平臺進行帶貨；但直播並不是完全穩定，會遇到網絡、清晰度等等問題；本文作者分享了關於一次直播事故引發的異常狀態處理思考，我們一起來學習一下。
作者：百轉
微信公眾號：百轉進化論
題圖來自 Unsplash，基於 CC0 協議
全文共 4410 字，閱讀需要 9 分鐘
—————— BEGIN ——————
作為專注於搭建珠寶類垂直SaaS系統的服務商，疫情期間，我們順勢上線直播功能，幫助珠寶門店構建私域流量變現閉環。
上線後，發生一次直播事故。
珠寶店在做一場直播放漏活動中，由於推流端網絡不穩定，用戶數據斷崖下降，還留在直播間的用戶自嘲被「關小黑屋」了；我們監控到了這次事故並做了內部追責。
異常狀態處理不當的影響直播是一種對實時性要求較高的場景，若出現網絡異常的處理方式不當，主要有以下2個影響：
1. 無法正常上傳數據，影響主播主播端的網絡發生異常後，直播數據無法上傳，此時若反饋不及時，主播處於不知情的狀況。
如果主播繼續直播，這部分直播內容將會白費。如果直播間持續無內容產出，觀眾會意識到直播發生問題，產生疑慮，卻得不到說明；而主播由於不知情，沒有及時採取相應恢復、補救措施，浪費觀眾的時間，導致產生更大的怨氣。
更嚴重的是，異常情況一直沒得到妥善處理，主播直播過程中膽戰心驚，分心詢問觀眾來獲知直播間是否正常；觀眾會認為這個直播間不穩定，對主播降低信任，長此以往，影響主播和觀眾之間的關係。
一個無法沉澱好內容、好口碑、好粉絲關係的直播間，無法建立好主播IP。
2. 無法正常下載數據，影響觀眾觀眾端的網絡發生異常後，無法下載數據到觀眾本地頁面，導致頁面長時間加載，等待數據重傳，引發觀眾的不良情緒。
此時反饋不及時，沒有明確的操作指引解決方案，觀眾莫名其妙無處可去，停滯在這一個頁面，不知所措，會加重這種不良情緒。
這使我意識到，對異常情況的處理方式不當，輕則影響用戶使用產品的體驗，重則導致產品無法使用，喪失用戶對產品的認可。
什麼是異常狀態處理用戶在實際使用產品的過程中，進行的某種操作或是滿足了某項條件，往往會導致異常狀態的發生。
有的異常使產品呈現與用戶預期不符，有的異常使產品部分操作沒有反應，有的異常甚至使產品頻繁崩潰至完全無法操作，或局部或全面影響產品功能的使用。
我們應該設計配套的異常狀態處理方案，一般有兩種典型的模式。
1. 規避規避是系統和用戶共同參與，將異常狀態扼殺在萌芽之前，目的在於降低異常發生的可能性。這種模式需要用戶事先授權，在異常發生前接受行為告警，異常發生時上傳錯誤日誌。
若規避方案需要用戶參與決策，則由系統發起告警或請求幫助。多視頻網站，都會在用戶網絡環境從WIFI切換成4G時發起流量模式警告，發起請求讓用戶自行選擇，繼續觀看還是切換網絡。
2. 修復修復是系統和用戶共同參與，將產品從不可用狀態恢復至可使用狀態，不讓它升級、擴散，目的在於降低異常覆蓋的範圍以及影響的程度。
系統應具有智能修復異常狀態的能力，比如直播觀看中出現畫面銜接錯亂乃至花屏現象，系統會立刻對每一幀音頻、視頻的時間戳進行邏輯值矯正，使音畫實現同步。
部分系統無法智能修復的異常狀態，則由系統發起請求幫助，用戶參與修復；比如用戶上傳照片，由於訪問相冊的權限獲取失敗，系統需要提示用戶無法使用功能的原因，並發起請求，再次進行權限獲取。
異常狀態處理的兩種存在模式缺一不可。
兩種存在方式匹配進行，才是真正的異常狀態處理。
如何處理異常狀態1. 預判在討論如何處理異常狀態之前，要做的是預判——預先知道異常狀態有哪些，並判斷它會在哪裡發生，它具體的影響。
在這一步，極考驗邏輯完整性，一旦發生疏漏意味著對部分異常狀態喪失預判，處理更無從談起。
這時，我們可以通過窮舉法逐一列舉所有可能的異常狀態，通過犧牲時間換取預判的全面性，避免邏輯疏漏。
窮舉法的缺點在於效率低下，而在正常的產品設計中，時間往往是有限的；為了提高效率，我總結了三種窮舉的方向。
窮舉的第一個方向，是根據業務流程，窮舉各個角色的異常操作。
處於業務流程中的各個角色，在任何一個頁面，進行任何一項操作都可能發生異常。梳理業務流程，從每個節點窮舉出可能發生的異常操作就是最為直觀的方法。
梳理業務流程時發現，直播共涉及了四個角色，分別是：主播、業務系統、直播系統和觀眾：
文章開頭案例所涉及的直播事故，就是在主播直播過程中，由於網絡異常而導致的。
為了便於說明，我們不妨以主播正式開播為起始，到直播系統轉碼為結束，我們窮舉這個節點中，主播所有異常操作：
窮舉的第二個方向，是根據數據流向，窮舉影響數據的異常條件
產品正常使用過程中，必然伴隨著數據從前端上報、從後端下發的過程。
數據流轉中出現異常，比如前端無法把請求傳遞給後端，比如後端返回超時、後端返回錯誤信息，都意味著產品功能無法正常使用。
可見，異常狀態和數據息息相關；我繪製完業務流程圖，一般還會繪製數據流向圖，通過理順數據的流轉過程，輔助窮舉異常條件。
主播開播後的數據流向圖如下：
從中我們可以窮舉的影響數據的異常條件：
窮舉的第三個方向，是回溯歷史異常，窮舉遺漏的異常條件
回溯，指帶著發現問題的目的回顧過往經歷，以期得到解決方案。
人非聖賢，我們難以預判所有異常狀態，往往異常發生後才意識到它的存在；因此，對已發生的異常問題進行多維度的回溯分析，是必不可少的；一方面幫助我們快速透視化了解異常問題，一方面為我們窮舉的異常條件查漏補缺，避免下一次異常的發生。
雁過留痕，系統通常具有收集日誌的能力，記錄系統運行中的信息，同時監視系統中發生的事件，這就為回溯歷史異常提供了依據。
日誌擁有非常龐大的欄位表，囊括了異常發生時所有信息。
我們可以從以下幾個指標進行分析總結，找出可能觸發異常的規律：
2. 恢復預判所有異常狀態以後，亟待解決的就是兩件事：異常狀態發生前，我們如何掃清問題？異常狀態發生後，我們如何解決問題？
前者需要配備預防措施，後者需要配備恢復措施。
先說前者預防措施，既要起到降低異常發生率的作用，還要有預警閾值提醒用戶。
就像車輛行駛至意外高發地之前，在道路中設置的減速帶，既起到降低車速避免意外發生的作用，也起到提醒我們減速注意安全的作用，幫助我們防患於未然。
在直播中帶寬、流量超限的異常狀態，我們可以設置預警值，達到預警值時提前警告主播，這樣就能避免在直播過程中直接中斷，體驗極差。
再說後者恢復措施，分兩種：第一種是系統自動觸發，在異常狀態出現前或出現中，自動觸發重試性的保護邏輯或者恢復邏輯；第二種是引導用戶觸發，主要使用場景在於系統沒有辦法自動觸發，有義務讓用戶做選擇的異常情況。
部分直播會提供回放功能，支持緩存；比如教育類的課程，緩存失敗就是這類產品常見的異常狀態，系統應自動觸發重新下載的恢復邏輯，嘗試重連；如果仍緩存失敗，或因其他未知原因，系統沒辦法替用戶決定處理方式，這時應將主動權交給用戶自行選擇刪除任務或重啟任務。
很多用戶觀看直播時，受推流質量和網絡環境影響，清晰度的調整是一個動態平衡的過程。
在直播帶貨中，搞秒殺促銷，對延遲的要求特別高，一旦卡頓，系統會自動降低直播的清晰度；但在高價位貨品的場景中，用戶可能無法忍受看不清貨品細節的情況，系統在一定範圍自動微調清晰度的過程中，同樣會提供入口供用戶自行調整。
從中我們可以總結出，異常狀態的恢復一般以系統自動觸發為先，仍然無法完全解決問題才採用兩者結合的方式，引導用戶觸發。
3. 反饋確定出現異常狀態的恢復邏輯後，就來到反饋用戶的環節，我們首先需思考的是所有異常都應該提示用戶嗎？
若異常狀態發生後，通過系統自動觸發的恢復措施，能將異常狀態處理完畢，並且整個過程耗費的時間極短，短到用戶根本來不及感知異常的存在；這種情況下，維持系統穩定的形象，讓用戶保持「無知」，避免用戶對風險的擔憂，何樂而不為？
總結而言，在一定時間內系統有能力自行修復，無需用戶參與的異常狀態，可不反饋。
我在前面預判階段做數據流向圖時，前端請求超時，直接提示主播異常信息，這種方式是值得商榷的，可以調整成在一定時間內自動重連，儘量降低「騷擾「主播次數，反覆不成功再引導用戶觸發恢復邏輯。
調整如下：
確認這個異常狀態是否應該提示用戶後，我們需要思考的是提示誰？
在業務流程中，處於受異常狀態影響的角色就是我們應該提示的對象。
主播網絡出現異常，觀眾雖然無法參與解決主播的網絡問題，但毫無疑問屬於受異常狀態影響的角色，需要進行提示：
最後，我們應該思考如何提示用戶？
提示一般包括三個模塊：
提示：提示用戶目前的狀態，引發狀態的基礎原因；
操作：引導用戶如何解決問題；
反饋：問題是否成功解決。
我們可以看一下抖音在網絡異常情況下的提示信息，以簡單的文案和圖案為用戶解釋了目前遇到的問題，並提供了相應的解決方案：
網絡恢復正常後，抖音選擇了最簡單有效的反饋，就是讓異常狀態提示信息消失，即時展現正常短視頻內容。
4. 補償當異常狀態恢復和用戶反饋都做完後，我們需要考慮自己的「售後」了。
若異常狀態恢復時間較長甚至無法恢復，需要引導用戶至相應地方，降低產品跳出；若異常波及的範圍或產生的損害大，需要提供補償機制，確保用戶的損失降到最低。
下圖是淘寶直播中的一個異常狀態提示，可以看出不僅提出了解決方案「點擊重試」觸發恢復邏輯，同時也給出了「看看別的」選項；在用戶反覆重試都無法解決問題的情況下引導用戶觀看其他直播間內容，對於直播平臺來說，總比跳出APP要好。
若異常波及範圍大，需要後置為用戶提供補償，一方面安撫用戶彰顯產品信用，另一方面是針對受異常影響的活躍數據的一種挽回和提振。
例子，下圖是一款遊戲的補償獎勵方案：
總 結經此一役我意識到：一套專業、好用、高效的SaaS系統，針對異常狀態應該具備預判、恢復、反饋、補償的處理。
預判在異常狀態發生前，預設可能出現異常的條件，時刻監控用戶行為，當觸發條件時給出反饋，及時修復，避免異常。
在異常狀態發生後，同樣要給出反饋和提供修復機制，避免異常擴大。
最後提供補償，盡力為客戶挽回損失。
在日常產品工作中，仍要不斷監控、復盤所有業務節點和數據流向；異常狀態的處理註定永無止盡，寫出來是希望能和大家一起查漏補缺。
—————— / END / ——————
▼ 喜歡請分享&收藏，滿意點個讚，最後點「在看」 ▼