インシデント後の適切なレビューの特性とコンポーネント

インシデントの事後レビューとは何か、インシデント対応プロセスにおけるその役割、および実施すべきタイミングを把握しました。 このユニットでは、インシデント後のレビューが最も効果的なものの詳細について少し詳しく説明します。

インシデントは異なるため、インシデント後レビューの正確な構成も異なる場合があります。 ただし、プロセスを実行するための強固な基盤を提供できる良いレビューの一般的な特性とコンポーネントがいくつかあります。

該当しないもの

インシデント後のレビューを適切に行う特性を理解する前に、そうでないものを考慮する必要があります 。

• ドキュメントやレポートではありません。 "レビュー" は簡単に要約として考え、実際には、概要レポートはインシデント後のレビューに従うことがよくあります。 ただし、これらはインシデント対応ライフサイクルの分析フェーズの 2 つの異なる部分です。
• 因果関係の決定ではありません。 レビューでは、障害の原因となった要因を確認しますが、目的は原因を特定することではありません (特に根本原因は 1 つではありません。複雑なシステムは、一連の要因によってほぼ常に失敗します)。 学習と改善のために、インシデントのすべての側面に関する情報を考え、共有することです。
• アクション 項目の一覧ではありません。 最終的には、レビューで学習した結果としてこのようなリストが表示されることがありますが、これは焦点ではありません。 バグ 報告システムのチケット キューまたはバグ レポートの項目の一覧が表示されないが、以前よりもシステムの詳細を把握している場合、レビューは成功しました。

インシデント レビューは、何よりも 会話です。 これは、チームが、その時点で知っていることを確認し、現在知っていることを確認し、システムの各部分 (人間の部分を含む) が問題に対応するためにどのように連携するか、または連携しないかを調査し、より深く理解できる、定義された空間です。

特性とコンポーネント

責任追及しない

前のユニットで説明したように、インシデント レビューは非難を受けないようにする必要があります。非難なしとは、「誰も説明責任を負わない」または「間違いが起こらなかったふりをする」という意味ではありません。つまり、インシデントを理解する作業と、インシデントに対する障害を割り当てる作業を意図的に分離します。 責任のないレビューでは、関係するすべての人が良い意図で行動し、その時点で利用可能な情報、ツール、コンテキストで最善を尽くしたと仮定します。 目標は、なぜ人々がその時その瞬間に取った行動が彼らにとって理にかなっていたのかを明らかにすることで、人間の要素を含むシステムが実際にどのように動作するかを学ぶことです。

システムの人間の部分とどのようにやり取りしたかを調べる必要がありますが、誰かに"障害がある" というラベルを付けるためにこれを行う必要はありません。人々ではなく、テクノロジの失敗とプロセスに焦点を当てる必要があります。

このことを反映するように質問を構成してください、例えば：

• 適切な意思決定を行うために必要なコンテキストをキーボードの人に与えられなかった監視の欠陥は何でしたか?
• ツールに "データベース全体を破棄する" オプションがあったのはなぜですか?
• または、より良い点: この機能を実行する前にツールが確認を求めなかったのはなぜですか?

問題が発生した場合、責任転嫁したくなることがあります。 ただし、次の重要な点を覚えておく必要があります。

解雇することで信頼性を達成することはできません。

「責任ある」人を見つけて解雇することを目的とした恥と非難や調査は、より信頼性の高いシステムにはつながりません。 結果として、経験の浅いあるいは能力不足の運用チームや、行動を躊躇する担当者に陥ります。

誰が何をし、その反応を行ったのかを探すのではなく、知識とコンテキストの検索としてレビューにアプローチします。

レビューはテクノロジの失敗に関するものの、人のプロセスほど技術的なプロセスではありません。 インシデントに関与した人々に話す (さらに重要なこととして、耳を傾ける)。 心を開いておきます。 異なる人は異なる視点を持ち、誰もが同意するわけではないので、パースペクティブの組み合わせは学習プロセスにとって非常に重要です。

インシデント後のレビューは、正直な問い合わせです。 そのため、次の重要なコンポーネントが採用されています。

• 議論
• 話し合い (Discourse)
• 異議
• 発見

これらの "4 つの Ds" は、インシデント後のレビューが体現すべき考え方に役立つニーモニックです。 これらのフレームワークは、信頼性の高いシステムと連携する生産性の高いチームを作成するレビューを構築できるフレームワークを作成します。

次のユニットでは、インシデント後の効果的なレビューを作成するために従うことができるプロセスについて詳しく説明します。