Effective Postmortems

効果的なポストモーテムを書けば、失敗からすばやく学ぶとともに、皆のためのシステムやプロセスを改善することができます。詳細で正確なポストモーテムを書き、最も価値を引き出せるようにしたいものです。このガイドでは、ポストモーテムを効果的にする上で私たちができることをリストします。

すべきこと#

タイムラインでは発生した出来事を正確に表現するようにしてください。
新たな参加者が理解できない可能性のある技術的な専門用語や略語がある場合は、説明を入れましょう。
影響を受けたサービスの健全性と回復力に対する自分たちの理解に対し、今回のインシデントがどうはまってくるかを議論しましょう。.

避けるべきこと#

本当にそうでないかぎり「機能停止（outage）」の言葉を使うのは避けましょう。インシデントの影響を正確に反映したいのに対し、多くの場合「機能停止」という言葉の指す意味はあまりにも広すぎます。実態は全くそうでなかったとしても、顧客はなにも使えなかったのだと思ってしまうでしょう。
物事の詳細や出来事を「よく見せよう」と思って改変してはなりません。私たちは、ポストモーテムにおいて自分たち自身に対しても誠実である必要があります。そうでないと、ポストモーテムの有効性が失われてしまいます。
誰かを名指しして、恥をかかせてはいけません。ポストモーテムは特定の誰かを責めることのないもの（blameless）でなければなりません。誰かが変更をデプロイしてなにかが壊れたとしても、それは彼らのせいではなく、壊れるような変更をデプロイさせてしまったシステムを持っている自分たちの責任だと考えるのです。

提案事項#

「ヒューマンエラー」という概念を避けましょう。これは前述した「名指しと面目つぶし」の話とも関係しますが、微妙な違いがあります。失敗の原因が、行動を取った人間に「根ざしている」ことはめったになく、たいてい複数の要因が絡んでいるのです。たとえば人間の実行したスクリプトにレートリミットの考慮がなかった、ドキュメントの内容が古かったといったことであり、対処が可能で、かつ対処すべきなのはそのような事柄です。
「もしもの現実」の議論を、タイムラインや説明セクションに持ち込むのは避けましょう。たとえば「早朝にサービスXに対するトラフィックが上昇しはじめ、リクエストへの応答が止まってしまった。 もしサービスXが リクエストに対するレートリミットを設けていたならば、応答は止まらなかった だろう。 」「この夜からサービスXの応答はスローダウンしはじめたが、CPU使用率の上昇を検知するための モニタリングが不十分だった。 」といったもので、これら二つの例では実際の問題に関する説明と仮説上の修正内容が混ざっています。改善内容と問題の説明はしっかり分けて、各々が適切に議論されるようにしましょう。
以下の動画は、上記のポイントをさらに詳細に解説したものです：
"Three analytical traps in accident investigation"
"Two views on Human Error"

レビュー#

私たちは、スケジュールされたミーティングの前にポストモーテムをレビューするための専用Slackルームを設けています。私たちが求めるのはこのような内容です：

十分な詳細が提供されているか？
なにがうまくいかなかったかを指摘するだけでなく、根底にある問題の原因まで深掘りできているか？
「なにが起きたか」と「どうやって直すか」を分離できているか？
提示されたアクションアイテムは理にかなっているか？スコープがうまく設定されているか？
ポストモーテムがしっかり書かれ、理解できるものになっているか？
対外メッセージは顧客の理解を得られるものになっているか、それとも反感を買う可能性がありそうか？

ポストモーテムのレビューはタイプミスの指摘のように重箱の隅をつつくものではありません。（もちろん、対外メッセージにはスペルミスが散見されるようなものであってはなりませんが）ポストモーテムから最大の恩恵を得る上で、価値ある変更に対する建設的なフィードバックを提供するために行います。

具体例#

以下は、他社のポストモーテムの事例として参考になるものです。