インシデント事後レビューのベスト プラクティス

インシデント事後レビューへのアプローチは、完了させる必要があるタスクと同じくらい重要です。インシデントが発生すると緊張感が高まる可能性があります。ユーザーがプロセスに真摯に向き合って困難な問題に取り組む準備を整えるためには、心理的な安心感を持ってもらう必要があります。

インシデント事後レビューのベスト プラクティス

誰も責めない文化を確立する – インシデントに関与したユーザーが罰や報復を恐れることなく、すべての行動、影響、把握していた状況や時期について説明できるようにします。このアプローチは、チームが情報をオープンに共有して、インシデントの根本原因を突き止めるための鍵となります。叱責を恐れている人は、情報を公開しなかったり責任逃れをしたりするかもしれません。こうした事態が起こると、人々は互いに信頼を失います。

誰かのせいにしようとしない – インシデント事後レビューのミーティングとその後の記述において、特定の個人にインシデントの責任を問うような言葉を使うのは避けましょう。代わりに、行動、結果、影響に焦点を当てます。

建設的な批評を行う – 会話を安全かつ客観的に行うことは重要ですが、問題を解決するにはインシデントの根本原因を突き止めることも不可欠です。不都合な真実から目を背けようとしたり、安易な結論に走ったりしないようにしましょう。ミーティングでは「なぜなぜ分析」というテクニックを使用して、問題の原因となっている深い要因をすべて明らかにできます。アトラシアンのプレイブックで「なぜなぜ分析」の実行方法をご確認ください。

すべてのインシデント事後レビューをレビューする – インシデント事後レビューをレビューしなければその後に活かせません。インシデント事後レビューの下書きを作成したら、未解決の課題を完了して将来考慮すべきアイデアを把握し、レポートを完成させるためにもそのアイデアをレビューすることが重要です。エンジニアリング (そしてカスタマー サポートやアカウント マネージャーなどの関心があると思われる人) と定期的な会議を少なくとも月 1 回の頻度でスケジュールして、インシデント事後レビューをレビューしましょう。最近のレビューや古いレポートを振り返ることで、関連する教訓を共有できます。

インシデント事後レビュー計画の作成

効果的にインシデント事後レビューをして継続的に改善する文化を構築するためには、誰もが参加できるシンプルで反復可能なプロセスを組み込む必要があります。これを行う方法は文化やチームによって異なりますが、インシデント事後レビューを実施してチームとシステムを改善するための鍵は、プロセスを定めてそれに固執することです。アトラシアンがインシデント事後レビューのプロセスをどのように実行しているかをご確認ください。

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

1. レビューが必要なインシデントを判断する

組織内のインシデントには、明確かつ測定可能な重大度レベルが必要です。これらの重大度レベルは、インシデント事後レビュー プロセスをトリガーするために使用されます。たとえば、重大度 1 以上のインシデントはインシデント事後レビューをトリガーして、重大度の低いインシデントについてはインシデント事後のレビューを任意に指定できます。チーム リーダーまたは経営陣によってインシデントのレビューが必要であると判断されたインシデントについては、インシデント事後レビューをリクエストする機会を与えることをご検討ください。

2. インシデントから 2 日以内にレビューの下書きを作成する

インシデントを解決したら、休憩して少し休むことも大切です。しかし、インシデント事後レビューを書くことを遅らせることは避けましょう。時間をかけすぎると、重要な詳細が失われたり忘れられたりする可能性があります。インシデント チームとのミーティングの直後、インシデント解決から 24～48 時間 (かつ 5 営業日以内) に下書きを作成するのが理想的です。

3. ロールと所有者を割り当てる

ミーティングを開いて、レビューに記録される詳細を熟議します。レビューの下書き作成は、特定のユーザーに委任することをお勧めします。できれば、インシデントに精通していて、原因と緩和策を理解するために必要なレベルの技術的/組織的知識を持っているユーザーが理想です。

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

テンプレートによって、重要な詳細情報を余すことなく記述できます。これは事後分析全体で一貫性を保つ優れた方法です。インシデント事後レビュー テンプレートで開始する一例をご参照ください。

5. タイムラインを含める

タイムラインは、インシデントのドキュメント化において非常に役立ちます。多くの場合、何が起こったのかを手早く把握しようとする読者が最初に見るのはタイムラインです。インシデントのアクティビティ フィードを使用すると、いつ何が起きたのかを確認できます。できるだけ明確かつ具体的に記録しましょう。たとえば「11 時頃」ではなく「太平洋標準時間の午前 11 時 14 分」とします。

含める重要な時刻は次のとおりです。

• 最初のアラートまたはチケット

• 最初のコミュニケーション アナウンス (内部や外部)

• ステータス ページの更新時刻

• 発生したすべての修復試行の時刻 (コードのロールバックなど)

• 解決された時刻

6. できるだけ多くの詳細を追加する

詳細を疎かにすると、インシデント事後レビューは役に立たず不明確な内容となってしまいます。インシデント発生時に起こった事象とそれに対する対処について、できるだけ詳細を明確にします。「その後、パブリック コミュニケーションを行った」ではなく「パブリック ステータス ページと Twitter アカウントで、インシデントを発表する最初のパブリック コミュニケーションを送信しました」とします。課題、ステータスの更新、ドキュメント、モニタリング チャートへのリンクをできるだけ多く含むようにしましょう。また、関連するスクリーンショットもできるだけ添付します。

7. インシデント メトリックを取得する

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

考慮すべきメトリックは次のとおりです。

• ダウンタイムの時間 (分)。この数値の増減を追跡できます。

• インシデントの重大度。システムの相対的な信頼性を判断できます。

• 平均解決時間 (MTTR)。インシデントが最初に報告された時点からインシデント解決までの平均時間を測定します。