インシデントの事後レビューとは

完了

このラーニング パスの前のモジュールでも述べましたが、簡単に振り返ります。インシデントには、次のようなライフサイクルがあります。

上のフェーズでラベル付けされた円を使用した循環図は、フェーズからフェーズへの矢印を使用して次の円につながっています

インシデントは次のフェーズを経ていきます。

  • 検出:問題が発生したことを最初に気づいたときです (お客様からの通知または苦情の前に監視システムから気付くのが理想的)。
  • 対応:アクションに素早く移り、インシデント対応プロセスを実施し、状況のトリアージと緊急時の対応を試みます。
  • 修復:問題を特定し、システムまたはサービスを正常動作に戻すための作業を行います。
  • 分析:インシデントが発生した後、システムまたはプロセスで変更する必要があることを判断して、経験から学ぶことを試みます。
  • 準備:学習した内容に基づいて、信頼性とそのコンテキスト (プロセスなど) を改善できる変更を行います。

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

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

正式なレビューは、対応フェーズと修復フェーズの後に行われますが、インシデントが発生したことを示すアクション可能なアラートを受け取り、チーム メンバーに通知し、インシデントに関する会話を開始するとすぐに、分析の準備を始めます。

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

このプロセスの呼び方について、すべての人が同じ言葉を使うわけではありません。 次のように呼ばれます。

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

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

また、誰もがまったく同じことを行うわけではありません。 たとえば、多くの人はインシデントに関係するすべての人物を部屋に集めることから始めますが、他の人は、個々のインタビューによってレビューを作成してから、グループに報告します。

後者の方法は多くの場合、組織内のグループの状況では、単一の大きな会議を行うのが困難である場合に適しています。 たとえば、グループ ダイナミクス、性格、タイムゾーンが異なる環境に分散した状況などにより、そのように集まることが難しい場合、別の方法でレビューを行う方が簡単かもしれません。 チームと環境に対して最適な方法をとる必要があります。

どのように呼ぶ場合でも、どのように編成する場合でも、3 つの重要な点があります。

  • インシデント対応に "関係したすべての人物" をインシデントの事後レビューに含めてください。 これら人々の声をすべて含めることが重要です。複数の人々は同じ事象に対して異なる視点と記憶を持っているからです。
  • インシデントの事後レビューは、可能な限りイベントの発生後 "24 から 36 時間以内"に実行する必要があります。 脳科学により、人間の記憶は信頼性の低いものであることが確認されています。人は忘れるのです。 イベント後の経過時間が長いほど、記憶の詳しさや具体性が減少する傾向があります。
  • インシデント レビューは、非難がないものである必要があります。 これについては、次のユニットで詳しく説明します。

インシデントの事後レビューの目的

インシデントの事後レビューの目的は、チームが学習して改善できるようにすることです。 これらのシステムについて、また、うまくいったことやいかなかったことついて学習して、改善を加えたいのです。

同時に、生成したアクション項目 (レポート、タスク、バグ報告、チケット、フィードバック) は役に立ちますが、学習して改善するというこのプロセスの要点に対しては補助的なものです。 アクション項目のリストの生成は、せいぜい 2 番目の目標です。

自分の知識をチェックする

1.

失敗から学ぶために役立つプロセスの正しい名前は次のうちどれですか?

2.

インシデントの事後レビューは、インシデント ライフサイクルのどのフェーズで実施されますか?

3.

理想的には、いつインシデントの事後レビューを行うべきですか?