ブレームレス ポストモーテム キャンバス

この「非責任追求型」ポストモーテムテンプレートは、プロダクションで発生したインシデントに関する情報を収集するのに役立ちます。このプロセスに従うことは、事故に寄与した行動をしたエンジニアが詳細な説明を提供できることを意味します。

• どの時間にどのようなアクションを取ったか、

• どのような効果を観察したか

• 期待していたこと、

• 彼らが立てた仮定

• 事象が発生した際のタイムラインの理解。

• 罰や報復を恐れることなく、この詳細な報告を行えること。

以下のセクションを含む非責任的な事後分析

ステップ 1：要約（会議の前に事前入力）

問題の要約は、現時点で判明している事柄と顧客への影響に焦点を当てた高水準なものです。これを1、2文にまとめてください。

ステップ 2:ざっくりとしたタイムライン（会議前に記入）

問題の概略タイムライン。問題の進展度合いに応じて、このタイムラインは数分から数時間、さらには数日にわたることがあります。チームの対応時間を緊急時に改善することを主な焦点としている場合、これを秒単位にまで縮める必要があります。

タイムラインを取得するときは、次の点を必ず含めてください：

• 問題がいつ、どのプロセスで報告されたか

• 実行された操作

• チーム内外でのコミュニケーションが行われたとき

修復のためのアイデア

• 問題について話し合う際には、その問題に携わった全員を招待してください。これには、製品サポートチームと、関与する可能性があるカスタマーサポートチームのメンバーが含まれます。

• 要約とタイムラインを確認し、足りない部分を補った後、是正案に移りましょう。

• これらの質問は、チームが問題を主体的に考えるのを助けるために作成されています。チームの制御を超えていると感じる問題もあります（データセンターの停電など）。ただし、そのようなイベントでも、チームは災害への反応を改善することができます。

ステップ 3:どのようにしてこの問題や類似の問題を早期に検出できますか？

この問題、または非常に似たような問題が再び発生すると考えてください。サポートチームはどのようにしてこの問題をより早く検出し、顧客が発見する前に見つけることができますか？

ステップ 4:リアクト – このような問題に対する対応をどのように改善できますか？

問題が報告されたと仮定します。反応はどのくらい速かったですか？誰かが問題を見てくれるようにメールを送っている間に、時間を無駄にしたことはありませんか？

次回この問題が発生したとき、チームはどのようにすれば迅速かつ整理された方法で対処できるのでしょうか？

ステップ 5:クイックフィックス – どのようにすれば早く出血を止められますか？

この問題が再発した場合、顧客への影響を軽減するために提供できる回避策は用意されていますか？

これが時間とともに悪化するものである場合（DDOS 攻撃のように）、原因を突き止める間に洪水を遮断する迅速な方法がありますか？

ステップ 6:防止 - どのようにすれば将来的な問題の影響を防止または軽減できるでしょうか？

これは、事後分析でチームがよく尋ねる唯一の質問です。それは重要な質問であり、ここで多くの時間を費やすべきです。しかし、問題を予防する方法だけを尋ねることに限定してしまうと、あなた自身がコントロールできること（例えば、問題の発見方法、反応の仕方、迅速な修正など）に対する責任を取らないことにもなりかねません。

アイデアをブレインストーミングする際、テクニカルな修正に限定しないでください。より良いモニタリング、より良いコミュニケーションパス、より良いトレーニング、カスタマーサポートの人々がプロダクションサポートの人々を名前で知っていることを確認するなど。

ステップ 7:その他のリスク領域 - この同じ脆弱性を共有する他の領域は何ですか？

すべての問題は、システムが弱い部分を示すヒントです。見つける問題ごとに、影の中に潜んでいる見つかっていない問題が何十もある可能性があります。

キッチンでネズミを見かけたようなものです。「ねずみ」の問題ではなく、「ねずみたち」の問題です。

システムの他の部分でも、同じ設計の前提を共有する、または場合によっては同じコードを共有する可能性があります（とはいえ、誰かがコードをコピー・ペーストすることはないでしょうが）。

似たように脆弱な他の場所を探すために、数分間ブレインストーミングをしてください。

チームがストレスを抱え過労になると、このステップを飛ばしてしまいます。これはチームを先を見据えた考え方に導き、将来の問題発生を減少させるために最も重要な質問であると私は考えます。

ステップ 8:次のステップ（アクション）

問題が検出され、対応され、迅速に修正され、防止される方法を改善するためにできることをすべて特定した後、アプリケーションの他の注意が必要な領域を見つけたら、どのアクションを実行するかを決定する段階に進みましょう。

これらの優先順位をどのように決めるかはあなた次第です。ただし、いくつかのアドバイスがあります。

会議を出る前に、行動を予定する各項目に名前と日付を入れてください。

会議の中で誰かがある行動に情熱を持っている場合、それが最も重要な問題を解決することではないと思っていても、奨励してみてください。

名前と日付

一般的に、あなたが会議のために非難のない環境を作り出せるならば、チームはこのエクササイズを楽しむことが多いと私は感じています。彼らは問題を詳細に分析し、ブレインストーミングで解決策を考えるのが好きです。しかし、誰もが忙しくて、過労を感じています。この会議が、やるべきことの所有者と日付を明確にしない限り、改善が行われる可能性は極めて低いです。

「3 週間後に同じ問題が本番環境で発生したとき、今度はもっと大きな問題になっているでしょう。そのときに誰かが『ああ、修正について話してたね』と言うでしょう。」良い場所ではありません。

その対策として、グループが取ろうとしている各アクションの横に名前と日付があることを確認してください。

デイビッド・フリンクのブレイムレス・ポストモーテム・キャンバスに基づいて