このラーニング パスの前のモジュールでこれを説明しましたが、簡単なレビューとして、インシデントには次のようなライフサイクルがあります。

インシデントは、次のフェーズを通過します。

• 検出:最初に問題があることに気付いたとき(理想的には、お客様が通知または苦情を行う前に監視システムから)
• 対応: アクションに取り組み、インシデント対応プロセスを関与させ、状況をトリアージし、緊急に対応しようとします。
• 修復: 問題を特定し、システムまたはサービスを作業順序に戻す作業を行います。
• 分析: インシデントの後、エクスペリエンスから学習を試み、システムまたはプロセスで変更する可能性のあるものを決定します。
• 準備: 学習した内容に基づいて変更を加え、信頼性とその周囲のコンテキスト (プロセスなど) を向上させることができます。

このモジュールのトピックは、主に分析フェーズ中に行われます。 インシデントから学ぶには、インシデント後のレビューを実施します。

重大なインシデントが発生するたびに、インシデント後のレビューを行う必要があります。

正式なレビューは応答と修復フェーズの後に行われますが、インシデントが発生したことを示す実用的なアラートを受け取り、チーム メンバーに通知し、インシデントに関する会話を開始するとすぐに、分析のステージを設定し始めます。

インシデント後レビューの定義

誰もがこのプロセスを参照するためにまったく同じ言語を使用しているわけではありません。 一部の人々はそれをそう呼びます。

• インシデント後のレビュー
• インシデント後の学習レビュー
• 事後評価
• 振り返り

このモジュールでは、"事後レビュー" という用語を使用します。

さらに、誰もがまったく同じ方法でそれについて行くわけではありません。 たとえば、多くの人は、インシデントに接続したすべてのユーザーを部屋に入れることから始めますが、他のユーザーは個々のインタビューを通じてレビューを作成し、グループに報告することを選択します。

後者の方法は、多くの場合、組織内のグループ設定で 1 つの大規模な会議が困難になる場合に適しています。 たとえば、グループのダイナミクス、パーソナリティ、タイムゾーンに分散したチームの分散特性がそのような集まりを妨げる場合、別の方法でレビューに取り組む方が簡単な場合があります。 チームと状況に最適な作業を行う必要があります。

何と呼ぶか、どのように整理するかは関係なく、次の 3 つの重要なポイントがあります。

• インシデント対応に 関与したすべてのユーザー をインシデント後のレビューに含める必要があります。 これらの声をすべて含めるのは重要です。これは、異なる人が同じイベントの異なる視点と回想を持つことになるためです。
• 可能であれば、イベント後 24 ~ 36 時間以内に インシデント後のレビューを実行する必要があります。 神経科学は、人間の記憶が悪名高く信頼性が低いことを確認しました。人々は物事を忘れる。 イベントの後に時間が経つほど、詳細で具体的な思い出が少なくなる傾向があります。
• インシデントレビューは、責任を問わないものでなければなりません。 これについては、次のユニットで詳しく説明します。

事後レビューの目的

インシデント後のレビューの目標は、チームが学習して改善できるようにすることです。 あなたが導入したシステムや仕組みについて、何がうまく機能し、何がうまく機能しなかったのかを学び、改善することができるようにしたいのです。

同時に、生成するアクション アイテム (レポート、タスク、バグ レポート、チケット、フィードバック) は役に立ちますが、プロセスのポイントまでの周辺機器であり、学習と改善が必要です。 アクション 項目の一覧の生成は、2 番目の目標として最適です。