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

一、為什么要做故障復盤

互聯(lián)網(wǎng)產(chǎn)品的更新迭代是非?？斓模芏喙就瞥缑艚蓍_發(fā)，固定每周一個小版本，2周一個大版本的節(jié)奏，緊急線上問題、政策限制、實時熱點（如新疆棉事件）還需要加急發(fā)布。

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

規(guī)范的流程和高超的技術(shù)只是減少故障的發(fā)生頻次，故障難以避免；出了故障后，為什么要做故障總結(jié)呢？

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

二、什么情況下做復盤

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

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

以下情況都可以做復盤：

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

三、故障復盤形式

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

計算公示：

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

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

1. 會議復盤

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

參會人員：當事人及其leader 必須參加，產(chǎn)品經(jīng)理、開發(fā)、產(chǎn)品&開發(fā)負責人、業(yè)務同事及其Leader，關(guān)心故障問題的老板們。

會議紀要：復盤會議結(jié)束后，要形成會議紀要郵件發(fā)送參會人及其他周邊干系人，會議內(nèi)容參考復盤總結(jié)模板部分。

2. 郵件復盤

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

3. 文檔復盤

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

四、復盤總結(jié)模板

1. 故障標題

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

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

2. 故障影響

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

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

3. 事件回顧

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

例如：

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

4. 故障原因

分析總結(jié)故障發(fā)生的原因，以上述案例為例，

1）故障發(fā)生前導致故障的原因

首先是為什么出現(xiàn)這個線上Bug，代碼質(zhì)量，開發(fā)自測、QA測試、產(chǎn)品驗收為什么沒發(fā)現(xiàn)？是沒有自測還是測試用例執(zhí)行不充分？

2）故障發(fā)生后運營上報的原因

上線流程是不是不合理，監(jiān)控是不是沒覆蓋？

3）故障處理過程耗時

定位問題慢的原因？

5. 故障總結(jié)

• 故障發(fā)生暴露的問題；
• 責任認定，目的主要是厘清故障產(chǎn)生各相關(guān)者的權(quán)責關(guān)系，方便后期跟進改進。

6. 改進計劃

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

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

• 經(jīng)驗總結(jié)、知識分享；
• 監(jiān)控覆蓋；
• 系統(tǒng)或工具設(shè)計改造類；
• 流程類的、規(guī)則/規(guī)范類的、機制完善類；
• 系統(tǒng)、業(yè)務需求改造類的。

五、小結(jié)

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

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

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

本文由@數(shù)據(jù)干飯人 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議