如何優雅的完成一次事故覆盤【轉載】
對於如何主導一次事故覆盤很有講究和方法。對於主導事故覆盤的人我們這裡稱其為“覆盤owner”：有的公司是QA，有的公司是測試、開發或者其他角色來承擔。
覆盤owner僅僅是個會議記錄儀：參會的各個角色討論，owner無法發表任何意見。
覆盤到的原因不是根本原因：表面原因，解決不了問題。
主體責任方搞錯了：後面又要拉起第二次覆盤。或者一味的去追責任方的責任，而忽略了事故本身的原因分析。
改進措施非常難以落地：比如改進措施嚴重依賴人的自覺，或者實施高複雜度的流程。
覆盤owner對這個產品或專案非常不熟悉。
覆盤前對情況一無所知，完全不知道是什麼影響，什麼問題。
對原因沒有刨根究底，或者被參加覆盤的某個角色單方面誤導了，導致沒有挖掘到根本原因。
沒有拉對人蔘會，比如有時候要拉入當事人的直接領導，甚至更高層的領導。
設計改進措施的時候，過度依賴人本身的自覺性或能力，沒有考慮自動化。
是否有錄單事故單，先要求錄單責任人（運維、客服：不同公司有不同的要求）把事情發生經過寫清楚。
找客服或產品運營同事確認具體的影響（事故越大，越要確認清楚，參見“瞭解事故影響小貼士”），找運維和涉及的開發問原因，根據原因涉及到的干係人及其部門，來定確定需要拉的非本產品或專案的人員和對應的覆盤負責人。
對事故的關鍵原因做個初步判斷，便於會上引導原因分析。
覆盤會要拉上的人有（根據實際情況裁剪）： 責任方人員（可能是：產品、測試、開發、運維等），責任方人員的直接領導，產品受影響方的開發（產品、測試等），產品受影響方的開發（產品、測試等）的領導，產品受影響方的“事故介面人”，根據嚴重情況有可能要拉上部門經理。
瞭解事故影響小貼士
影響的表現是什麼：在使用者端表現出來是什麼操作或什麼服務受到了什麼影響。
影響的範圍是什麼：是所有使用者還是特定使用者，是必現還是有機率出現。
影響是如何恢復的：使用者不需要任何操作直接恢復，還是需要一定的操作後才能恢復，例如重啟，清快取操作等。
事故恢復後是否還可能存在其他服務的受損：例如歷史記錄被清空，資訊或列表被清空等。
會議現場：引導大家按照順序進行復盤。順序如下：
review事故發生過程——> 事故原因討論——>改進措施討論——>定級定責——>總結陳詞。
注意對以下事項的把控和確認：check影響範圍和時長，定級，原因是否ok，改進措施是否可以落地，改進措施落地時間。
原因的追溯：多問幾個為什麼，尤其對一些明顯看起來打太極的人。
會議結束：記得簡單清晰概括原因、責任人、改進措施等，不要留存模糊的地方。
覆盤後：事故報告和改進措施落地跟進開發在事故單系統（如果沒有系統，則通過郵件方式提供）裡面把改進措施寫清楚。
兩天內出具事故報告，傳送給參會人員，並抄送與這個事件相關的人，或者關注這事件的領導。
跟進改進措施是否按時落地，並進行記錄和定期更新完成狀態。
Tips碎碎念對於跨部門的事故，由事故的責任方主導事故覆盤，如果你負責的產品或專案團隊不是責任方，那麼催促對方團隊的事故介面人儘快拉起，並提供自己方的干係人，並積極參加覆盤會。
要確認的資訊在會上都確認清楚，不要等會下再來重複確認。
注意控制會議時間，不要太長。另外，說話語氣要肯定。
對跨部門的事件覆盤注意引起共鳴，覆盤會上還在注意氛圍與節奏的把控，不要讓覆盤會變成追責討論會。
發出覆盤報告要檢查的幾個點：檢查標題 ，檢查正文是否通暢，是否有錯別字。
無論如何，能否有效覆盤，並且通過覆盤能挖掘出產品或專案的真實問題，“覆盤owner”起到重要作用。
要做好事故覆盤，“覆盤owner”要做到的關鍵點：覆盤前心中有數，拉到合適的人蔘加覆盤會，覆盤中按照步驟引導覆盤，覆盤後跟進措施落地。