事故覆盤無疑是系統服務可用性管理或DevOps建設中非常重要的一個環節，但是如何做到高效，卻很難。我這裏對高效覆盤的基本原則做一些闡述。
背景：
我們先從最近的一則新聞說起，Google 在2020年12月14日凌晨發生一起全球Down機的事故，47分鐘內Google賬號服務不可用，導致依賴該賬號服務的各種Google產品服務包括Google Cloud Console以及Gmail/Docs和Youtube等都不能正常的使用。看到有同學搞笑說，SRE的聖經《SRE-Google運維解密》現在可以扔了。哈哈，當然這只是一句玩笑話。
其實現在的計算機系統是一個極其複雜，而且依賴很多的分佈式系統，出現事故是在所難免的，關鍵是如何對待事故。是把它視爲人爲錯誤（Human Error）導致，找到那個事故負責人，然後對他進行處罰，希望達到不再犯錯的目的，還是接受事故是不可避免的事實，進而從各種系統架構設計上/流程設計和執行上進行容錯性處理，把每次事故當作一次學習和改進的機會。這是一個傳統IT公司和高績效公司的關鍵區別之一。
傳統事故覆盤：Blame Game 或者甩鍋
我們先來看看傳統事故覆盤是如何進行的吧？很多時候跟電視劇或者電影上審問犯人有些類似，一羣人在一個房間裏，把“嫌疑工程師”放到一個“Hot Seat”上，然後進行各種追問，來找出這個事故的根本原因（Root Cause），並討論採取什麼行動計劃來確保這種事情不再發生。關鍵部分是對這個事故進行定級，和視事故的級別對事故人進行一定的處罰。此外還有一個長長的改進任務列表，列出各種長期或者短期的任務，從流程上或者意識上避免再犯類似的錯誤。往往能看到一些諸如參加安全操作培訓，以後線上操作更小心之類的改進事項。很遺憾任務列表上的任務往往很少得到跟進。
這種覆盤，是一種Blame Game（即甩鍋遊戲），是不適應現代快速發展的系統架構和雲基礎設施的要求的。在這種Blame Game的環境下，承擔責任的工程師，會以一種沉重的心情來進行事故覆盤，他最後會很不愉悅的快速接受責任認定，那麼事故過程中的各種場景不會得到很好的回放，也就不能充分說明當時的場景，同時因爲快速得出結論，事故中涉及到的各種架構問題和流程問題不能得到很好的澄清，也不能在團隊裏面促成很好的知識傳遞。那麼即使換了一個人，同樣的事故是不能避免發生的。
我不太認同這種Focus在責任事故和負責人認定的Blame Game，因爲現在的分佈式系統各種依賴，非常複雜，出現事故是在所難免的。首先，其中的網絡故障是非常難以避免的，而且不可控。其次，硬件設備也是非常容易出錯的，我們在IDC中購買和使用的硬件，都是相對廉價的設備（相對於專有的可靠性非常高的硬件），出錯率也是比較高的；最後，軟件是人寫的，是一定會出Bug的，即使我們把各種操作都自動化，那些自動化的腳本也是人寫的，也是會有Bug的。所以，在Google的SRE中寫到，爲什麼100%的可用性是不實際的目標。
另外，回到人爲錯誤上，犯錯誤本身就是做創新性工作的不可避免的副產品。現在的競爭環境下，要求我們以越來越快的速度進行迭代和試錯。所以每天10+的部署也是很正常的一件事情。在這種情況下，如果害怕事故，害怕出錯，是根本沒法做到如此之快的開發部署上線的。因爲在這種環境下，工程師會選擇能儘量少做就儘量少做，能儘量不做就不做，不會採取一些創新甚至冒險的方式。
最後，DevOps的實施離不開一個信任和合作的文化，而這種文化的建立，是需要在開發團隊（Dev）和運維（Ops）中建立起信任。很顯然，甩鍋遊戲會極大的破壞這種氛圍，導致無法真正建立起團隊的信任，即使他們兩個團隊被強行捏到一起。
現代的事故回顧：Blameless PostMortems
那麼，該如何進行高效的事故回顧呢？是不做了？還是把事故回顧當作一個很輕鬆的遊戲？都不是。正確的做法是本着非常嚴肅認真的態度，召集所有相關的人員，進行事故現場的回顧；然後進行認真的分析，對這種事故，我們如何能更快的發現？如何能更快的定位和止損？如何從架構上做出改進，來做到自動容錯？要點在於把每一次事故當做學習的機會。
我們來一起看看業內如何做的吧。
2012年著名電商Etsy的CTO在他們的Blog上發表文章，題目是“Blameless PostMortems and a Just Culture”, 闡述Blameless PostMortems的重要性和實施方法。該CTO是John Allspaw，不錯他就是在DevOps歷史上非常著名的演講Velocity 09上《10 deploys per day- Dev & Ops cooperation at flickr》的兩個主講人之一。他在該博文上描述在他們Etsy公司進行Blameless PostMortems的做法和考慮。爲什麼要這麼做呢？他解釋：在事故回顧中，希望涉及的工程師能給出現場的詳細信息，便於發現系統弱點或者流程缺失之處，詳細信息包括如下內容：
- 他觀察到了什麼現象
- 他做出什麼樣的判斷
- 他採取什麼樣的行動
- 行動得到什麼樣的結果
這些信息都只有在不害怕被懲罰的情況下才能詳細的給出。因爲認爲自己將受到譴責的工程師沒有動機去提供必要的詳細信息，以瞭解該事故的詳細原因。而如果對事故如何發生的瞭解不足，換一個人還會繼續發生。所以該辦法並不是保證工程師犯錯誤可以免除懲罰，而是更關注獲得重要現場信息來持續對系統進行改進，避免錯誤重複發生。因爲他相信，能獲得真實的一手信息來診斷並確保事故不在發生，比起指責甚至處罰事故負責的工程師，對公司的長久利益更重要。
無獨有偶，2015年Google發表的《SRE Handbook》中也專門提到如何做PostMortem，
這篇文檔中https://sre.google/sre-book/postmortem-culture/給出他們做事故覆盤的文化“Postmortem Culture: Learning from Failure”。還給出他們的模版（https://sre.google/sre-book/example-postmortem/）。在這個模版中，詳細給出了事故覆盤的各個部分，非常有用，可以參考。
總結：
最後說下，事故不可避免，事故覆盤同時也是一個學習機會。
參考文檔：
- Google對此次事故的官方說明 https://status.cloud.google.com/incident/zall/20013
- Blameless PostMortems and a Just Culture https://codeascraft.com/2012/05/22/blameless-postmortems/
- Postmortem Culture：Learning from Failure https://sre.google/sre-book/postmortem-culture/
- Google SRE postmortem Examples https://sre.google/sre-book/example-postmortem/