互聯網人故障復盤流程

編輯導語：我們在日常工作中很多時候都需要復盤，特別是在完成一個項目或者遇到技術問題時，復盤可以更好的解決問題，避免后續再次發生，也能得到很多經驗；本文作者分享了關于互聯網人在遇到故障時的復盤流程，我們一起來了解一下。

一、為什么要做故障復盤

互聯網產品的更新迭代是非常快的，很多公司推崇敏捷開發，固定每周一個小版本，2周一個大版本的節奏，緊急線上問題、政策限制、實時熱點（如新疆棉事件）還需要加急發布。

頻繁的變更過程就難以避免不出故障，“常在河邊走，哪能不濕鞋”。

規范的流程和高超的技術只是減少故障的發生頻次，故障難以避免；出了故障后，為什么要做故障總結呢？

1. 復盤成長，這是最主要的價值。吃一塹長一智，通過復盤總結教訓，后期工作中規避問題再發生；
2. 組織過程資產沉淀，故障總結文檔可以作為部門的組織過程資產為他人提供前車之鑒，新人入職或新接手項目后可以快速了解之前發生過什么，自己如何重蹈覆轍；
3. 給老板交代，出了問題后，尤其是線上生產問題，影響大的時候要逐層匯報，有故障復盤，過程清晰明了，溝通效率更好；
4. 給業務交代，產品Bug、系統故障往往會造成業務損失，要擺好姿態，厘清權責，給業務一個態度和交代。

二、什么情況下做復盤

很多人不愿意做復盤，出來問題修復后，想著是能不讓別人發現盡量不讓別人發現；否則背著Bug后績效C、D沒跑了，或者是“懶”，“好了傷疤忘了疼”。

故障和績效各家公司的標準不一樣，有的公司推崇的文化是鼓勵員工主動復盤，但對個人而言，復盤更多的是自己的事情。

以下情況都可以做復盤：

• 產品變更發布后，產生Bug；
• 未做變更但產品或服務突然不可用（系統攻擊、或機房故障）；
• 操作故障，如產品、運營、研發在使用產品時的操作引發的隱在問題；
• 產品或服務遭到輿論導向的客訴；
• 誤操作，由于未按照流程、沒看清楚、沒確認好等無心操作，帶來的人為故障；
• 復盤時間要求：1個工作日以內（24小時），趁熱打鐵，涼了就沒那么“刻骨銘心”了。

三、故障復盤形式

按照故障影響范圍和對業務造成的損失，每個公司都會對故障進行定級，以電商公司為例，可能會用損單量指標作為故障分級的標準。

計算公示：

損單量=故障持續時長*昨日（或上周同期或近七日日均）同時段平均訂單，到小時或者分鐘級別。

故障級別和損單量的關系與公司業務量級以及對故障的容忍度有關。示例如下，P0為最高級故障。

1. 會議復盤

P0、P1級故障，典型故障、業務比較關注呼聲較高的，可以組織會議復盤，當面溝通效率更高、能快速平息故障，解決問題。

參會人員：當事人及其leader 必須參加，產品經理、開發、產品&開發負責人、業務同事及其Leader，關心故障問題的老板們。

會議紀要：復盤會議結束后，要形成會議紀要郵件發送參會人及其他周邊干系人，會議內容參考復盤總結模板部分。

2. 郵件復盤

P2~P3故障，影響范圍小，業務關注度低的可以采用郵件復盤的方式，把復盤過程郵件抄送相關方，如當事人leader 必須參加，產品經理、開發、產品&開發負責人、業務同事及其Leader，關心故障問題的老板們。

3. 文檔復盤

P4及以下故障，業務影響很小，團隊內做好復盤文檔沉淀，作為組織過程資產存檔。

四、復盤總結模板

1. 故障標題

【故障級別】+日期+業務描述+故障簡介+復盤總結+責任人，方便信息同步，如很多新聞用XX事件，七一五事件等。

例如：【P0故障】20210401-小程序金剛位頁面跳轉異常-復盤總結-張三。

2. 故障影響

為什么把故障影響放到最前面？故障復盤內容一般會比長，尤其是老板們每天看的郵件、匯報很多，沒時間把所有內容全部讀一遍的，把故障影響提前告訴他們，他們自己心里有桿秤，要不要繼續關注和跟進下去。

故障影響，一般是描述故障帶來的業務損失、產品、用戶體驗損失等多維度的影響分析。

3. 事件回顧

從故障開始、發現、修復、修復完成的詳細過程，需要包含When、Who、Where、What，即什么時間，誰，做了什么事情，目的是；通過詳細的過程描述，方便發現故障和處理故障過程中暴露出的問題，作為后續改進的依據。

例如：

• yyyy-M-dd hh:mm 故障因xx開始
• yyyy-M-dd hh:mm 運營張三發現故障 （或收到監控報警）
• yyyy-M-dd hh:mm 張三把問題反饋給開發李四
• yyyy-M-dd hh:mm 李四驗證發現問題確實存在，企業微信拉群，并通知上級領導報備故障
• yyyy-M-dd hh:mm 李四通過代碼、監控日志找到問題所在，確認影響范圍及故障發生時間點
• yyyy-M-dd hh:mm 李四定位問題后，通知上級領導及運營張三準備做回滾（代碼修復），預計XX時間完成
• yyyy-M-dd hh:mm 李四確認問題已修復，群內同步
• yyyy-M-dd hh:mm 張三確認問題已修復，故障處理已結束
• 故障從XXX-XXX持續時長：XX小時XX分

4. 故障原因

分析總結故障發生的原因，以上述案例為例，

1）故障發生前導致故障的原因

首先是為什么出現這個線上Bug，代碼質量，開發自測、QA測試、產品驗收為什么沒發現？是沒有自測還是測試用例執行不充分？

2）故障發生后運營上報的原因

上線流程是不是不合理，監控是不是沒覆蓋？

3）故障處理過程耗時

定位問題慢的原因？

5. 故障總結

• 故障發生暴露的問題；
• 責任認定，目的主要是厘清故障產生各相關者的權責關系，方便后期跟進改進。

6. 改進計劃

根據故障復盤發現的問題，制定出可實施的改進計劃。日后同類型的錯誤自己及相關的同事都去避免發生改進計劃包括todolist、跟進人、deadline。

改進計劃可以包含但不限于：

• 經驗總結、知識分享；
• 監控覆蓋；
• 系統或工具設計改造類；
• 流程類的、規則/規范類的、機制完善類；
• 系統、業務需求改造類的。

五、小結

出問題不可怕，可怕的出問題不復盤，同樣的問題重復犯。

不管公司怎么要求，復盤和成長是自己的事情，成長的過程犯錯誤交學費在正常不過。

 

作者：千冰儀，微信號公眾號：數據干飯人，主要從事數據中臺產品體系建設，包括：開發套件、數據資產、BI應用、精準營銷平臺、機器學習平臺等。

本文由@數據干飯人 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議