障害から学ぶために役立つプラクティス
インシデントの事後レビューから得られる価値をなくす、あるいは少なくとも制限する一般的な陥りやすい問題について説明しましたが、次の論理的な質問は "代わりに行うべきことはなにか" です。
このユニットでは、インシデントの事後分析プロセスを改善できる 4 つの便利なプラクティスについて説明します。
プラクティス 1:進行役付きのインシデントの事後レビューを実行する
インシデントの事後レビューは、ドキュメントまたはレポートではないことが既にわかっているので (理想的には対話です)、1 人の人物が議論を行わずになにが起こったかに関する "事後評価" を記述しても役立つインシデントの事後レビューにはなりません。 その人物がどれほど知識があっても、どれほどインシデントに深くかかわっていても、1 つの観点からだけでは、多くのことが学べません。
インシデントに関与していた人物を同時に集めることが最初のステップです。 多くの場合、会議でディスカッションをガイドできる進行役を用意するとうまくいきます。 進行役は、実際にはインシデントに関与していない "中立" な人物であることが理想です。 インシデントを語るにあたって、先入観による考えや個人的な利益を持っているように見えない進行役であれば、すべての人がより詳しく学ぶことができます。
会議の正確な形式は、チーム、スケジュール、インシデントの性質によって異なりますが、基本的なガイドラインを次に示します。
- マラソンでなく、会議:会議は長くする必要はありません。 一般に、60 分から 90 分が、ほとんどの人物が完全に集中して効果的に参加できる最大の時間です。そのため、会議を 1 時間半までに制限します。
- 会議前の準備:会議時間をより効果的に使用するために、進行役は対応チームの一部のメンバーとの 1 対 1 のインタビューを行って、インシデントの概要と会議での議題についてのアイデアを得るとよいでしょう。 個人間の問題について懸念がある場合や、性格的に会議が難しい場合 (または、個人が何らかの理由で人前で発表することに不安がある場合)、個々のインタビュー結果をグループに報告できます。
- すべてのインシデントに必須なわけではない:これは学習プロセスであり、"学習することを学ぶ" ので、小さなことから始めます。 すべてのインシデントに対してこれを行う必要はありません。 取捨選択できます。 小さいインシデントから始めたり、1 か月に 1 回だけのレビュー会議から始めたりすることができます。
インシデントの事後レビュー会議は、問題が発生した原因、正しく行われたこと、どうすれば将来よりよくエラーを処理できるかを確認する機会です。 最終的な目標は、信頼性を高めることです。
プラクティス 2:より良い質問を聞く
言葉が重要であることは既にわかっていますが、インシデントの事後レビューにおいて、これは特に質問に当てはまります。 通常、具体的な質問によって、より有用な回答を得ることができます。
具体的には、"なぜ" の代わりに、"どのように" または "なにを" とたずねることをお勧めします。
人は、"なぜ" それを行ったか、"なぜ" それが起きたかを説明するよう問われると、身構える傾向にあります。 "なぜ" から始まる質問は、多くの場合、判断、批判、または非難のような印象を受けます。 人に行動を正当化せざるを得ない状態にしてしまいます。また、その行動をとった理由や、行動の結果として発生した結果について、理由を常に把握しているわけではありません。 また、問題の原因や結論に直接飛びついてしまい、議論できる豊富な情報を飛ばしてしまう可能性があります。 たとえば、"システムが動作を停止したのはなぜですか" と質問すると、"ディスクがいっぱいになったため" という答えが返ってくる可能性があります。これは、"ディスクに問題が発生したことにどのように気づきましたか?" や、さらには "まず最初にシステムで確認したことはなんですか、確認することにした理由はなんですか?" などの重要な質問を飛ばしてしまいます。
ただし、インシデントの要因を追求できない、またはインシデントに応じて何をすべきかをその人が決定した理由を理解する機会がなくなるわけではありません。単に、理由を尋ねるのに使う言葉に注意を払う必要があるというだけです。
"なぜそれを実施したのですか?" と聞かないでください。
代わりに、"その変更を決定する際、なにが要因だったのですか?" と聞いてください。
"このようなことがカナリアで捉えられなかったのはなぜですか?" と聞かないでください。
代わりに、"通常、カナリアはこの種の問題を捉えるためにどの程度効果がありますか?" と聞いてください。
インシデントの事後レビューは学ぶためであることに注意してください。 インシデントに関与したそれぞれの人物は、若干異なる視点を持っている可能性があります。 これらの複数の視点と解釈を明らかにする質問をすれば、さらに詳しく学ぶことができます。
多くの場合、"通常" の運用がどのように行われるかをたずねることで、特定のインシデントについて質問することと同様の学びが得られます。
より良い質問をする方法の詳細については、次のリソースを参照してください。
プラクティス 3:うまくいったことを確認する
障害から学ぶことを考える際、重大な障害やその他のインシデントが発生した場合でも、問題が発生したことに加えて、うまくいっていることもあります。 インシデントを一度限り、または極端な条件の結果だという私たちの見方とは異なり、ほとんどの複雑なシステムでは多くのうまくいっている理由と同じ理由で失敗が起きます。
否定的な部分に質問を集中するのは人間の性質です。 しかし、うまくいったことを確認することによって、それ以外の方法では得られない洞察を得ることもできます。
障害がどのように発生したかを尋ねるだけでなく、復旧方法についても、その人の意見を聞いてください。
復旧作業に貢献した、洞察、ツール、スキル、および人物を知る必要があります。 これらは、再現できるようにしたいものです。したがって、この情報は、今後の計画に役立ちます。
このコンテキストでは、関係者がどのように事実を知りえたのか、どのような基準で意思決定をしたのかを確認する必要があります。 だれかが情報を共有したおかげで発生していた状況の謎が解けた、重要な瞬間はありましたか。 どのようにして知ることができたのでしょうか。 どこから情報が得られたのでしょうか。
テーマとパターンを探します。 最後に、何がうまくいったのかを認識するために、"以前は知らなかったが、今は知っているということはありますか?" と質問します。インシデント、インシデント対応とレビュー プロセスにより、学びが得られたのであれば、これももう 1 つのうまくいったことです。
これにより以前の点が思い出されます。障害を回避する方法と同様に、私たちの対応能力を向上させる方法についても多くの学ぶべきことがあります。
プラクティス 4:レビューと計画会議を別々にする
直近のインシデントを解決した後は、修復項目と将来の軽減策について話したいのが自然であり、そうすべきです。ただし、これらのトピックはインシデントの事後レビュー会議の一部としては行いません。 インシデントの事後レビュー会議には目的があります。そのため、その会議で修復項目を扱うと、その目的があいまいになります。
ベスト プランとしては、インシデントの事後レビューの 1 日または 2 日後に、修復項目を検討し、計画に関する問題を議論することをお勧めします。 これは、より小さなグループで行うことをお勧めします。
これは、次の 2 つの形で役立ちます。
- インシデントの事後レビューに役立ちます。 問題を解決する方法に重点を置かないことで、結論に飛びつくことを避けやすいからです。
- 1 日または 2 日時間を置くと、最も "注ぐ労力に対する効果が高い" 修復項目を特定するのに役立ちます。最小限の労力で最大限の効果を出します。 無意識は役立ちます。必要なのは、時間を与えることです。