インシデント後の適切なレビューの特性とコンポーネント
- 3 分
インシデントの事後レビューとは何か、インシデント対応プロセスにおけるその役割、および実施すべきタイミングを把握しました。 このユニットでは、インシデント後のレビューが最も効果的なものの詳細について少し詳しく説明します。
インシデントは異なるため、インシデント後レビューの正確な構成も異なる場合があります。 ただし、プロセスを実行するための強固な基盤を提供できる良いレビューの一般的な特性とコンポーネントがいくつかあります。
該当しないもの
インシデント後のレビューを適切に行う特性を理解する前に、そうでないものを考慮する必要があります 。
- ドキュメントやレポートではありません。 "レビュー" は簡単に要約として考え、実際には、概要レポートはインシデント後のレビューに従うことがよくあります。 ただし、これらはインシデント対応ライフサイクルの分析フェーズの 2 つの異なる部分です。
- 因果関係の決定ではありません。 レビューでは、障害の原因となった要因を確認しますが、目的は原因を特定することではありません (特に根本原因は 1 つではありません。複雑なシステムは、一連の要因によってほぼ常に失敗します)。 学習と改善のために、インシデントのすべての側面に関する情報を考え、共有することです。 アクション 項目の一覧ではありません。 最終的には、レビューで学習した結果としてこのようなリストが表示されることがありますが、これは焦点ではありません。 バグ 報告システムのチケット キューまたはバグ レポートの項目の一覧が表示されないが、以前よりもシステムの詳細を把握している場合、レビューは成功しました。
インシデント レビューは、何よりも 会話です。 これは、チームが、その時点で知っていた内容と現在の知識を確認し、システムの各部分 (人間の部分を含む) が問題に対応してどのように連携するか、または連携しないかを調査し、より深く理解できる、定義された空間です。
特性とコンポーネント
前のユニットで説明したように、インシデント レビューは 非難を受けないように する必要があります。システムの人間の部分とどのようにやり取りしたかを調べる必要がありますが、誰かに"障害がある" というラベルを付けるためにこれを行う必要はありません。人々ではなく、テクノロジの失敗とプロセスに焦点を当てる必要があります。
このことを反映するように質問を構成してください、例えば：
- 適切な意思決定を行うために必要なコンテキストをキーボードの人に与えられなかった監視の欠陥は何でしたか?
- ツールに "データベース全体を破棄する" オプションがあったのはなぜですか?
- または、より良い点: この機能を実行する前にツールが確認を求めなかったのはなぜですか?
問題が発生した場合、責任転嫁したくなることがあります。 ただし、次の重要な点を覚えておく必要があります。
解雇することで信頼性を達成することはできません。
「責任ある」人を見つけて解雇することを目的とした恥と非難や調査は、より信頼性の高いシステムにはつながりません。 代わりに、経験の浅い、あるいは機能不全の運用チームや、行動を恐れるスタッフにつながります。
誰が何をし、その反応を行ったのかを探すのではなく、知識とコンテキストの検索としてレビューにアプローチします。
レビューはテクノロジの失敗に関するものの、人のプロセスほど技術的なプロセスではありません。 インシデントに関与した人々に話しかけ、さらに重要なことに耳を傾けます。 心を開いておきます。 異なる人は異なる視点を持ち、誰もが同意するわけではないので、パースペクティブの組み合わせは学習プロセスにとって非常に重要です。
インシデント後のレビューは、正直な問い合わせです。 そのため、次の重要なコンポーネントが採用されています。
- 議論
- 話し合い (Discourse)
- 異議
- 発見
これらの "4 Ds" は、インシデント後のレビューを構築できるフレームワークを作成します。これにより、より信頼性の高いシステムと、連携する生産性の高いチームが作成されます。
次のユニットでは、インシデント後の効果的なレビューを作成するために従うことができるプロセスについて詳しく説明します。