事故覆盤無疑是系統服務可用性管理或DevOps建設中很是重要的一個環節，可是如何作到高效，卻很難。我這裏對高效覆盤的基本原則作一些闡述。安全
背景：網絡
咱們先從最近的一則新聞提及，Google 在2020年12月14日凌晨發生一塊兒全球Down機的事故，47分鐘內Google帳號服務不可用，致使依賴該帳號服務的各類Google產品服務包括Google Cloud Console以及Gmail/Docs和Youtube等都不能正常的使用。看到有同窗搞笑說，SRE的聖經《SRE-Google運維解密》如今能夠扔了。哈哈，固然這只是一句玩笑話。架構
其實如今的計算機系統是一個極其複雜，並且依賴不少的分佈式系統，出現事故是在所不免的，關鍵是如何對待事故。是把它視爲人爲錯誤（Human Error）致使，找到那個事故負責人，而後對他進行處罰，但願達到再也不犯錯的目的，仍是接受事故是不可避免的事實，進而從各類系統架構設計上/流程設計和執行上進行容錯性處理，把每次事故看成一次學習和改進的機會。這是一個傳統IT公司和高績效公司的關鍵區別之一。less
傳統事故覆盤：Blame Game 或者甩鍋運維
咱們先來看看傳統事故覆盤是如何進行的吧？不少時候跟電視劇或者電影上審問犯人有些相似，一羣人在一個房間裏，把「嫌疑工程師」放到一個「Hot Seat」上，而後進行各類追問，來找出這個事故的根本緣由（Root Cause），並討論採起什麼行動計劃來確保這種事情再也不發生。關鍵部分是對這個事故進行定級，和視事故的級別對事故人進行必定的處罰。此外還有一個長長的改進任務列表，列出各類長期或者短時間的任務，從流程上或者意識上避免再犯相似的錯誤。每每能看到一些諸如參加安全操做培訓，之後線上操做更當心之類的改進事項。很遺憾任務列表上的任務每每不多獲得跟進。分佈式
這種覆盤，是一種Blame Game（即甩鍋遊戲），是不適應現代快速發展的系統架構和雲基礎設施的要求的。在這種Blame Game的環境下，承擔責任的工程師，會以一種沉重的心情來進行事故覆盤，他最後會很不愉悅的快速接受責任認定，那麼事故過程當中的各類場景不會獲得很好的回放，也就不能充分說明當時的場景，同時由於快速得出結論，事故中涉及到的各類架構問題和流程問題不能獲得很好的澄清，也不能在團隊裏面促成很好的知識傳遞。那麼即便換了一我的，一樣的事故是不能避免發生的。ide
我不太認同這種Focus在責任事故和負責人認定的Blame Game，由於如今的分佈式系統各類依賴，很是複雜，出現事故是在所不免的。首先，其中的網絡故障是很是難以免的，並且不可控。其次，硬件設備也是很是容易出錯的，咱們在IDC中購買和使用的硬件，都是相對廉價的設備（相對於專有的可靠性很是高的硬件），出錯率也是比較高的；最後，軟件是人寫的，是必定會出Bug的，即便咱們把各類操做都自動化，那些自動化的腳本也是人寫的，也是會有Bug的。因此，在Google的SRE中寫到，爲何100%的可用性是不實際的目標。oop
另外，回到人爲錯誤上，犯錯誤自己就是作創新性工做的不可避免的副產品。如今的競爭環境下，要求咱們以愈來愈快的速度進行迭代和試錯。因此天天10+的部署也是很正常的一件事情。在這種狀況下，若是懼怕事故，懼怕出錯，是根本無法作到如此之快的開發部署上線的。由於在這種環境下，工程師會選擇能儘可能少作就儘可能少作，能儘可能不作就不作，不會採起一些創新甚至冒險的方式。post
最後，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/