適切なインシデントの事後レビューの特徴と要素
これまでで、インシデントの事後レビューとは何であるか、インシデント応答プロセスにおけるその役割、およびそれを実行するべきタイミングがわかりました。 このユニットでは、何がインシデントの事後レビューを最も効果的なものにするかの詳細を少し深掘りします。
さまざまなインシデントがあるため、インシデントの事後レビューの正確な設定もさまざまである場合があります。 ただし、このプロセスを実行するための強固な基盤を提供できる優れたレビューにはいくつかの共通の特徴と要素が存在します。
該当しないもの
優れたインシデントの事後レビューを可能にする特徴を理解するには、それが該当 "しない" ものについて考える必要があります。
- ドキュメントやレポートは該当しません。 "レビュー" を書面上の要約と捉えることは簡単であり、実際、インシデントの事後レビューの後に要約レポートが出されることはよくあります。 しかし、これらは、インシデント対応ライフサイクルの分析フェーズの 2 つの異なる要素です。
- 原因の特定は該当しません。 レビューでは、失敗の原因となった要素を確認しますが、その目的は、元凶を特定することではありません (特に単一の根本原因を特定することではありません。複雑なシステムは、寄与する複数の要因のセット全体が原因で失敗することがほとんどです)。 学習と改善のためにインシデントのあらゆる側面に関する情報を検討し共有することこそが該当するものです。 アクション項目の一覧は該当しません。 最終的にはレビューにおいて判明したことの結果としてそのようなリストが出来上がるかもしれませんが、これは焦点ではありません。 終了後にチケット キュー内の項目リストやバグ報告システム内のバグ報告がなくても、システムについての理解度が以前よりも深まっているのであれば、そのレビューは成功といえます。
インシデント レビューは、なんといっても会話です。これは、チームが当時把握していたことと現在把握していることを確認し、(人間的要素を含む) システムの各要素が問題への対応の際にどのように連携して機能するのか、あるいはしないのかを調査して理解を深めることができるように定められた時間です。
特徴と要素
前のユニットで説明したように、インシデント レビューは非難がないようにする必要があります。システムの人間的要素がどのようにそれに作用したかを調べる必要はありますが、これを行うのは、誰かに "責任がある" というレッテルを張るためではありません。人ではなく、テクノロジとプロセスの失敗に焦点を当てる必要があります。
次のように、これを反映するように質問を構成します。
- キーボードを前にした人に適切な判断を行うために必要なコンテキストを提供できなかった私たちの監視の欠点は何だったのだろうか?
- そもそも、ツール内に "データベース全体を破棄する" 選択肢が存在していたのは何故なのか?
- あるいは、さらに良いのは:このツールはなぜこの関数を実行する前に確認を要求しなかったのだろうか?
問題が発生すると、犯人捜しの誘惑にかられることがあります。 ただし、次の重要な点に注意してください。
信頼性を高めるための道を閉ざしてはいけません。
恥をかかせたり非難したりすること、あるいは "責任がある" 人物を見つけて解雇することを目的とする調査は、より信頼性の高いシステムの実現には繋がりません。 逆に、行動することを恐れる経験不足な運用チームや従業員を生み出すか、そのような存在さえいなくなることに繋がるでしょう。
レビューを知識とコンテキストを見つけるためのものとして利用します。犯人捜しをし、そしてそれに対する反応をするものではありません。
レビューはテクノロジの失敗に関するものですが、技術的なプロセスというよりは、人間的なプロセスであると言えます。 インシデントに関与した人達に話しかけ、その人達の話を聞くこと (こちらの方がより重要です) が重要です。 偏見を持たないでください。 さまざまな人がさまざまな視点を持ち、全員が同意するとは限りません。そして、そのような視点の組み合わせが学習プロセスにとって非常に重要です。
インシデントの事後レビューは、素直な探究です。 そのため、次の主要な要素を含んでいます。
- 考察 (Discussion)
- 話し合い (Discourse)
- 異議 (Dissent)
- 発見 (Discovery)
これら "4 つの D" によって、より信頼性の高いシステムと、互いに連携するより生産的なチームを生み出すことができるインシデントの事後レビューを構築できる枠組みが出来上がります。
次のユニットでは、効果的なインシデントの事後レビューを構築するためのプロセスについて詳しく説明します。