インシデントの事後分析プロセスの重要性

インシデントの事後分析のメリット

正式なインシデントの事後分析会議やまとめを、省略したくなるかもしれません。インシデントの原因を確信して、課題を修正できた自信がある場合は特にそうです。

あなたにとってはそれで良いかもしれません。しかしチームには、インシデントの原因を把握しておらず、あなたの明確な理解からメリットを得てチームや顧客へのサービスを改善できる人がいるかもしれません。

構造化されたコラボレーション プロセスに参加するように人々を結びつけることで、誰もが学んだことを共有してチーム内で信頼と回復性を構築できます。また、インシデントとチームがそれをどのように修復したかを文書化することで、今後のインシデントへの対応方法を周知できます。

またインシデントの事後分析から判明した重要なポイントを、顧客または組織の他の部門に公開できます。これは、インシデント発生時には密接に関与していなかったかもしれない人の信頼の再構築に、非常に役立ちます。組織内の他のチーム、特にリーダーは、将来のチームによる邪推を避けるため、問題の詳細と解決のために実施した手順を把握する必要がある場合があります。

パートナー、顧客、エンド ユーザーは、エクスペリエンスの向上のために何が起こったのか、どのようなステップを踏んだかを知りたい場合があります。インシデントの事後分析を一般公開された Web サイトで公開することは、すべてのケースで適切とまでは言えません。しかしながら、マーケティング チームまたは広報チームが表現の調整を支援して、閲覧者が有益な形で情報を入手できるようにしてサービスに対する信頼を高められます。

インシデントの事後分析のベスト プラクティス

インシデントの事後分析へのアプローチ方法は、ステップのチェックリストと同じくらい重要です。インシデントがきっかけで、緊張が高まることがあります。プロセスの関係者を動機付けて困難な問題に取り組む準備を整える鍵は、心理的な安心感を与えることです。

誰も責めることのない文化の確立

元 Etsy CTO の John Allspaw 氏は、「誰も責めることのない事後分析」に関する独創的な文章を執筆しました。インシデントの調査に対するこのアプローチによって、インシデントに関与する人は、罰や報復を恐れることなく、すべてのアクション、影響、何をいつ知ったかを説明できます。

このアプローチは、チームが情報をオープンに共有してインシデントの根本原因を突き止めるための鍵となります。叱責を恐れている人は、情報を隠すか責任逃れをしようとするかもしれません。これが起こると、人々は互いに信頼を失います。そして、組織はチームやシステムの回復力を醸成する機会を失います。Atlassian と Google を含む多くのチームではこれらの落とし穴を避けるために、誰も責めることのない事後分析を採用しています。

特定の人を責めず、建設的な議論を行う

事後分析会議とその後の所見の報告では、インシデントに対する責任を特定の個人に負わせる表現を避けてください。そうではなく、アクション、結果、影響に焦点を当てます。

会話を安全かつ客観的に保つことは重要ですが、インシデントの根本原因を突き止めることは、解決のために非常に重要です。会議では「5 つの Why」というテクニックを使用できます。まず、全員で問題の内容の理解を共有することから始めます。次に、それが起こった理由を聞いて、その質問に対する答えに「なぜ」と問います。これを少なくとも 5 回繰り返して、問題の原因となっているすべての深い要因を明らかにします。不都合な真実から目を背けようとしたり、安易な結論に走ったりしないようにしましょう。プレイブック プレイで、「5 つの Why」アプローチの詳細についてご確認いただけます。

すべての事後分析をレビューして、プロセスに反映させる

インシデントの事後分析レポートをレビューしなければ、それは書かないのと同じです。インシデントの事後分析レポートを作成したら、未解決の課題をクローズして将来考慮すべきアイデアを把握してレポートを完成させるために、そのレポートをレビューすることが重要です。このレビューが行われるまで、インシデントは本当の意味で解決されていないとすら言えるかもしれません。

これをどうやって実施しますか? エンジニアリング (およびカスタマー サポートやアカウント マネージャーなどの関心のある人) との定期的な会議を少なくとも月 1 回の頻度でスケジュールして、インシデントの事後分析レポートをレビューします。最近のレポートをレビューしたり、古いレポートをレビューして現在も関係する教訓を共有したりできます。

効果的なインシデントの事後分析計画

効果のある事後分析を行って継続的に改善を行うという文化を構築できるように、誰もが参加できるシンプルで反復可能なプロセスを組み込む必要があります。その方法は、文化とチームによって異なります。Atlassian では、当社に適した方法を開発しました。詳細については、Incident Handbook をご参照ください。

こちらから情報を発信しています。

ヒント 1: しきい値を設定する

組織内のインシデントには、明確で測定可能な重大度レベルが必要です。その重大度レベルは、事後分析プロセスをトリガーするために使用できます。たとえば、Sev-1 以上のインシデントは事後分析プロセスをトリガーして、重大度の低いインシデントについては事後分析の実施を任意にできます。しきい値を満たさないインシデントについて、チーム リーダーまたは経営陣が事後分析をリクエストする機会を許可することを検討してください。

ヒント 2: 先延ばしにしない

インシデント発生後は、少し休むことが大切です。しかし、事件事後分析の文書化を遅らせてはいけません。時間が空くと、重要な詳細を忘れる可能性があります。インシデントの解決から 24 ～ 48 時間以内に実施するインシデント後レビュー会議直後に、かつ 5 営業日以内にドラフトを作成するのが理想的です。

ヒント 3: 役割と担当者を割り当てる

インシデント後レビュー ミーティングでは、インシデントの事後分析に記録される詳細を熟議します。事後分析ドラフトを、特定の人に委任することをお勧めします。インシデントに精通していて、原因と緩和を理解できる技術と組織に関する知識がある人が理由です。

ヒント 4: テンプレートから作業する

テンプレートを使用すると、キーの詳細を残さないようにできます。これは、事後分析全体を通して一貫性を維持するための素晴らしい方法です。

ヒント 5: タイムラインを含める

タイムラインは、インシデントの文書化において非常に役立ちます。多くの場合、何が起こったかを手早く把握しようとする読者が最初に見るのがタイムラインです。できるだけ明確で具体的になるようにしてください。たとえば、「11 時頃」ではなく「11 時 14 分 (太平洋標準時)」とします。タイムスタンプを具体的にすることで忠実度の高いイベントの流れを表せるため、改善領域を特定しやすくなります。たとえば、影響が出始めた時刻から顧客に通知された時刻までの間隔が長すぎることがわかる場合があります。

含めるべき重要な時刻。

• 最初のアラートまたはチケット
• 最初のコミュニケーション アナウンス (内部や外部)
• ステータス ページの更新時刻
• 発生したすべての修復試行の時刻 (コードのロールバックなど)
• 解決された時刻

ヒント 6: 詳細を明確にする

詳細を疎かにすると、事後分析はほぼ確実に役に立たずに不明確になります。インシデント発生時に何が起こったのか、何が行われたかについて、できるだけ詳細を明確にします。「その後、パブリック コミュニケーションを行った」ではなく、「パブリック ステータス ページと Twitter アカウントで、インシデントを発表する最初のパブリック コミュニケーションを送信しました」とします。

可能な限り、リンクと名前、チケットとステータス更新へのリンク、インシデント状態ドキュメントへのリンク、監視チャートを含めます。関連するグラフィックやダッシュボードのスクリーンショットも、ためらわずに追加してください。インシデントの開始時刻と終了時刻を明確に示した監視システムのグラフ (たとえば、リクエスト レートの低下後の通常への復帰) は明確であるため、非常に有用です。同じ時間枠におけるデータベース接続、ネットワーク リンク状態、または CPU、メモリ、I/O、帯域幅消費など、その間にバックグラウンドで何が起こっていたかを示すグラフと組み合わせると、さらに有効です。

ヒント 7: インシデント メトリックをキャプチャする

インシデントの事後分析でメトリックを取得すると、課題とその影響にハード データが適用されます。これらのデータ ポイントによって、チームが正しい方向に向かっているかどうかを判断して、インシデント数、重大度、ダウンタイムを削減できます。一貫したメトリックを測定することで、一歩戻って、時間の経過に伴うインシデントの傾向を確認できます。

インシデントの事後分析の追跡で考慮すべきメトリック:

• ダウンタイムの時間 (分)。この数値の増減を追跡できます。
• インシデントの重大度。システムの相対的な信頼性を判断できます。
• MTTR (平均解決時間)。インシデントが最初に報告された時点からインシデント解決までの平均時間を測定します。

最も重要なことは、ステップを省略しないことです。チームとシステムの改善に役立つインシデントの事後分析を実施する鍵は、プロセスを確立して順守することです。

インシデントの事後分析テンプレートを使用して、プロセスを合理化する

チームがインシデントの事後分析レビューに関する文化を確立できるように、情報の把握、会議のスケジュール設定、再利用可能なチェックリストとテンプレートを使用する最終レポートの公開を簡単にできるようにします。反復可能なプロセスによって、一貫性を確保できて何を想定すべきか理解しやすくなるため、生産的な意識を持ってプロセスに取り組めます。

インシデントの事後分析プロセスの典型的なチェックリスト アイテム:

開催する必要がある会議:

• 情報収集会議
• レポートのレビュー
• レポートのプレゼンテーション

事前に収集する必要がある情報:

• 各会議の標準的な議題
• 参加者、関係者、レビュアー
• テンプレートを使用してインシデントの事後分析レポート作成を標準化する