インシデントレポートとポストモーテムの違い

インシデントレポート（システム障害報告書）

障害発生によって不利益が生じたユーザーに対して障害の説明をするための（事後）報告書…というのが一般的な定義のようです ...が、エンジニアが直接社外向け・ユーザー向け報告書を書くというより、エンジニアが書くのは上司や経営層に向けた報告書になるのが実際ではないかと思います。

ポストモーテム

障害から学び、よりよいサービスにするために改善・再発防止のフォローアップアクションを記録するために書かれたドキュメント。 ドキュメントそのものというより、再発防止策を決めて施行するまでのアクションを指す場合もあるようです。

2つの違いは？

インシデントレポートにも再発防止策は書きますし、実際に施行したかどうかは管理されるでしょう。 ポストモーテムでも、障害そのものの説明は欠かせないはずです。 違いは内容ではなく、目的にありそうです。

　▶　ステークホルダーへの説明責任を果たすために作成されるものか：インシデントレポート

　▶　障害から学び、その学びをチーム全体に共有するためのものか：ポストモーテム

ポストモーテムの内容に必要なもの

ポストモーテムの目的を「学びと共有」と定義すると、例えば - 開発責任者が誰 - 障害による被害が何円だと想定されるのか …といった、”報告書であれば必須であろう”要素は（そこから学びが無ければ）不要です。

@弊社でのポストモーテム

弊社では、ポストモーテム用のフォーマットは以下のようになっています。

# 概要
* xx

# 影響
* xx

# 原因
* xx

# 対応者
* xx

# 一次対応
* xx

# 根本対応/再発防止策
* xx

わりとざっくりしているように見えるかもしれませんが、目的を考えると相当妥当だなと感じています。 つまり、共有したい学びにフォーカスして柔軟に記載できるのです。 インシデント発生時の対応連携に課題があればタイムラインを書けばいいですし、そうでなければ書かずにメインの学びにフォーカスできます。

弊社ではポストモーテムを書いた後にエンジニアが集まって振り返り・情報共有を行うので 網羅的に情報を残すというより、 - 執筆者が、書きながら当時を振り返れるように - インシデントに直接対応しなかったメンバーも、手短に情報共有もらえるように というところに重点を置いているのかなと思っています。

余談：印象に残ったポストモーテム

個人的に印象に残っている弊社でのポストモーテムとして、「メール送信ループ内で、ループの一番最初の宛先を固定で入れ続ける処理になっていたため1名にしかメールが送られていなかった」というケースがあります。 これ、不具合の経緯を共有するのにすごく抵抗があるというか、"やらかしてしまった"気持ちがあったと思うのです。 それでも迅速に、かつ冷静に障害の原因を究明・共有してくれた姿勢、 開発メンバー全体でも、レビュー時やテスト時に発見できなかった事実と持続可能な対応方法について議論していた姿がすごく印象に残っています。 入社早々にあったポストモーテムということもあり、「前向きな開発メンバーがいるところに入社したなあ」とポジティブになれた思い出にもなりました。

おわりに

個人的に、インシデントそのものの報告とは別に、インシデント発生時・発生後の動きがもっといろんな会社から情報共有があってもいいのになあ、と思いこの記事を書きました。 是非この記事を目にした方は出せる範囲で情報共有をして頂けると、障害対応がよりよくなっていく　のではないでしょうか。