團隊這幾天有發生需要回顧的問題，馬上收到這篇。剛好拿出來推給各位朋朋：
Postmortem Culture: Learning from Failure - sre.google

The cost of failure is education.

什麼是事後檢討（Postmortem）？什麼時候要寫？

事後檢討就是在翻車之後，把「我們翻車了，翻了三圈半、我們都幹了些什麼來把車翻回來、到底為什麼會翻車、後續要怎麼避免翻車」等資訊記錄下來的東東。

The primary goals of writing a postmortem are to ensure that the incident is documented, that all contributing root cause(s) are well understood, and, especially, that effective preventive actions are put in place to reduce the likelihood and/or impact of recurrence.

寫一份事後檢討的主要目標是確保事件被記錄下來，所有貢獻的根本原因都被充分理解，尤其是要採取有效的預防措施來減少再次發生的可能性和/或影響。

那什麼時候會需要寫檢討？這篇文章列了幾個狀況：

  • 一定比例的使用者不能使用
  • 掉資料
  • 工程師被叫去 on-call 退版
  • 花了有夠解還沒處理完問題
  • 監控整個失敗，拖到被人發現

Image

無責任文化

既然都要寫檢討了，大多時候就是有事情搞砸了。為了不要讓寶貴的學習機會淪為情緒發洩和攻擊別人的場合，這篇文前半段就開始提了「無責任（Blameless）」

用我們比較熟悉的話來說，就是「對事不對人」，把目光放在「我們的服務哪些方面還可以改進」，藉此得到變得更強大的機會

從另一方面來說，如果放任大家互咬、培養出互相指責的扭曲文化，那很多問題就會被蓋牌，這樣其實更危險🤔

For a postmortem to be truly blameless, it must focus on identifying the contributing causes of the incident without indicting any individual or team for bad or inappropriate behavior.

為了使事後檢討是真正無責任（Blameless）的，它必須專注於確定事件的發生原因，而不指責任何個人或團隊的不良或不適當行為。

A blamelessly written postmortem assumes that everyone involved in an incident had good intentions and did the right thing with the information they had. If a culture of finger pointing and shaming individuals or teams for doing the “wrong” thing prevails, people will not bring issues to light for fear of punishment.

一份無責任的事後檢討假設參與事件的每個人都有良好的意圖，並根據他們所擁有的信息做出正確的決策。如果存在一種指責和羞辱個人或團隊做出“錯誤”決策的文化，人們將因為害怕受罰而不敢揭示問題。

補充：如果想要看一些反例，可以讀前陣子的這篇〈迷失在阿里雲的年輕人〉裡
「濫用的 Code Review 和故障復盤」這一小節。

事後檢討的審查標準

寫完檢討書 v1 之後，會先在團隊內請資深工程師幫看一下 O 不 OK。要看的點有：

  • 相關的資料有沒有被收集起來給後人參考？
  • 影響評估有沒有完整？
  • 根本原因的分析有沒有足夠深入了？
  • 後續的行動計劃和修復工作都列好了嗎？有排好優先順序了嗎？
  • 我們有沒有跟利害關係人（stakeholders）說過結果了？

都搞定之後就可以開始散佈出去了，希望其他人能從我們翻車的姿態中學會教訓。

Wheel of Misfortune!

這句有點咒語的 Feel，不知道怎麼翻，「衰鬼之輪」嗎？

後半段一些文化相關的東西，像是讀書會、每月檢討等等的都很平常，但這個輪子還蠻有趣的

基本上就是大家（抓著新來的菜鳥 SRE）一起，把過去的某次事故報告給調出來，現場就開始當劇本來跑團：

New SREs are often treated to the Wheel of Misfortune exercise (see Disaster Role Playing), in which a previous postmortem is reenacted with a cast of engineers playing roles as laid out in the postmortem. The original incident commander attends to help make the experience as “real” as possible.

新進的 SRE（網站可靠性工程師）通常會參與「厄運之輪」的練習（參見災難角色扮演），在這個練習中，以前的事故回顧會被重新演繹，工程師們扮演著事故回顧中所規定的角色。原始的指揮官也會參與其中，以盡可能使體驗更加「真實」。

事故還可以放個幾年之後拿出來當桌遊(?)，有種挺歡樂的感覺。這樣我很願意好好寫檢討書耶 xD

今天嘗試用新的格式來推薦，本來想說看能不能縮短每次整理心得的時間

不過反正每次要打利害關係人，都會打成厲害關西人，選字的時間就比縮短的時間久了，根本沒差= =

那麼，今天的轉貼就到這邊。我們明天見～