インシデント対応のライフサイクルとは?

重要なポイント: インシデント対応のライフサイクルは、チームがインシデントを検出し、対応を調整して解決し、学んだことを次の準備に反映させるために従う、反復可能で周期的なプロセスです。

• 概要: 最初のアラートから事後分析までに何が起こるかを定義する段階的なフレームワーク (アトラシアン の 7 つのステップや NIST の 4 つのフェーズなど) です。

• 重要な理由: インシデントを 1 回限りのイベントではなくサイクルとして扱うことで、各停止をより優れた検出ルール、より迅速な対応、そしてインシデントの再発減少へと変えることができます。

• Jira Service Management が役立つ理由: アラート、コミュニケーション チャンネル、重大度、エスカレーション、インシデントのタイムラインを一元化することで、すべての段階を 1 か所で管理し、事後分析に完全な記録を残すことができます。

インシデント対応のライフサイクルは、チームがサービスの停止やセキュリティの脅威を検出し、対応を調整して伝達し、サービスを復元し、次のインシデントをより早く検知してより早く解決できるように何が起こったかを分析するための、段階的なフレームワークです。これは直線ではなくサイクルです。サービスが再び「稼働中」になったからといって作業が終わるわけではありません。事後分析、ロードマップの変更、そして改善されたランブックこそが、次のインシデントを防ぐものだからです。

考え方によって、サイクルをステージに分割する方法はいくつかあります。このガイドでは、アトラシアンが自社のインシデント対応で使用している 7 つのステップ、NIST の 4 フェーズモデル、そして DevOps チームがその両方をどのように適応させているかについて説明します。

Atlassian のインシデント対応のライフサイクル

1. インシデントを検出する

Atlassian のインシデント検出は通常、モニタリング ツールとアラート ツールから始まります。ただし、お客様やチーム メンバーからインシデントについて最初に知ることもあります。

インシデント アラートは異なるソースから発信されるため、多様なアラートとレポート ツールを統合するソリューションがあることによって、まとまりのない面倒な対応と、結束してコラボレーションできる対応との違いが生まれます。Jira Service Management などのソリューションによって、チームはすべての監視、ログ、CI/CD ツール全体でのアラートをカスタマイズして絞り込み検索を行って、アラートで疲弊せずにすばやく一丸となってインシデントに対応できるようになります。

2. チームのコミュニケーション チャンネルを設定する

初期の重要なステップは、インシデント チームのコミュニケーション チャンネルを設定することです。この時点での目標は、専用の Slack チャンネルやビデオ カンファレンス ブリッジなど、よく知られている場所にチームのコミュニケーションを集中させることです。

Jira Service Management では、インシデント対応の調整のプロセスがスムーズになります。チームが、Slack やビデオ会議など、チームに最適な方法でコミュニケーションできるだけでなく、自動化やカスタマイズによって顧客とのコミュニケーションもより簡単に行えます。外部とのコミュニケーションについては、ステップ 4 で説明します。

3. 影響を評価して、重大度レベルを適用する

ここで、インシデントの影響を評価すべきです。これにより、チームが他の誰に連絡して顧客や関係者に何を伝えるべきかを決定できるようになります。重大度の割り当ては、インシデントの影響を特定するだけでなく、解決プランや外部とのコミュニケーションの基盤も構築します。Jira Service Management では、インシデントをエスカレートして重大度を割り当てると、自動化アクションおよび対応者への通知がトリガーされ、解決の進捗状況を把握できます。

4. 顧客に伝える

アトラシアンでは、社内外の関係者にできるだけ早く伝えることを目指しています。迅速かつ正確に伝えることで、顧客や組織のその他の関係者との信頼関係を築くのに役立ちます。前述のように、コミュニケーション方法をカスタマイズできることによって、チームは思いどおりの方法で業務を行えるようになり、より迅速な解決が容易になります。また、コミュニケーションをカスタマイズできることで、チームは送信するメッセージや送信するタイミングを管理できるようにもなります。さらに、チケット内からの自動返信が直接顧客に送信されるため、インシデント発生中にチームの時間を節約できます。

5. 適切な対応者にエスカレートする

最初の対応者はしばしば、Jira Service Management のアラート ツールを使用して他のチームに通知することで、インシデントに他のチームを参加させる必要があります。関連するチケットをグループ化し、適切な対応者を直接チケットにタグ付けすることによって、対応者を直接インシデント チケットに参加させます。このようにして、通知を調整し、全員が状況を完全に把握できます。

6. インシデント対応ロールを委任する

別のチーム メンバーが対応に参加するのに応じて、インシデント マネージャーがこれらのメンバーにロールを委任します。ここで、明確なロールと責任を概説する、適切なインシデント対応プレイブックを事前に作成しておくと便利です。インシデント対応チームの個人はそれぞれのロールに精通しており、インシデント時の自分の責任について把握しています。

7. インシデントを解決する

現在または差し迫ったビジネスへの影響が終了したら、インシデントが解決したと言えます。その時点で緊急対応プロセスは終了して、チームはクリーンアップ タスクと事後分析に移行します。

インシデント管理ソリューションでは、強固なインシデント タイムラインを維持するのが理想的です。Jira Service Management を利用すると実現できます。対応者は、後で重要なインシデント データにアクセスしてレポートを作成でき、チームが将来、同様のインシデントを回避して根本原因を見つけられるようにします。万が一同様のインシデントが起きた場合、事後分析はリソースとしても機能します。

NIST インシデント対応のライフサイクル

もう 1 つの業界標準のインシデント対応のライフサイクルは、米国国立標準技術研究所 (NIST) に由来します。NIST は、インシデント対応やサイバーセキュリティなどのトピックに関する基準と慣行を設定する政府機関です。

NIST はアトラシアンと同様、すべてのインシデントを防げるわけではないと考えています。このため、準備することが最善です。

「リスク評価の結果に基づく予防アクティビティにより、インシデントの数を減らせますが、すべてのインシデントが防げるわけではありません。したがって、インシデントの迅速な検出、損失と破壊の最小化、悪用される弱点の軽減、IT サービスの復元には、インシデント対応機能が必要になります」— NIST

NIST のインシデント対応のライフサイクルでは、インシデント対応を「準備」、「検出と分析」、「封じ込め、根絶、回復」、「イベント後のアクティビティ」の 4 つのフェーズに分けています。

フェーズ 1: 準備

準備フェーズは、インシデント対応に備えるために組織が実施する作業が対象です。これには、適切なツールとリソースの確立や、チームのトレーニングが含まれます。このフェーズには、インシデントが発生しないようにするための作業が含まれます。

フェーズ 2: 検出と分析

NIST によると、インシデントを正確に検出して評価することは往々にして、多くの組織にとってインシデント対応における最も困難な作業となります。

フェーズ 3: 封じ込め、根絶、回復

このフェーズでは、インシデントの影響を可能な限り小さく保って、サービスの中断を軽減することに重点を置きます。

フェーズ 4: イベント後のアクティビティ

インシデント後の学習と改善は、インシデント対応の最も重要な作業の 1 つでありながら、最も軽視されるものです。このフェーズでは、インシデントとインシデント対応の取り組みを分析します。ここでの目標は、インシデントが再発生する可能性を制限して、将来のインシデント対応アクティビティを改善する方法を特定することです。

これら 4 つのフェーズは、SP 800-61 Rev. 2 に由来します。NIST の 2025 年の改訂版 (Rev.3) では、インシデント対応が Cybersecurity Framework 2.0 の機能を中心に再編成されていますが、4 フェーズモデルは依然として最も広く参照されているバージョンです。

現代の DevOps チームのインシデント対応

過去 10 年間、DevOps の取り組みは、チームがソフトウェアを構築、デプロイ、運用する方法を再構築するのに役立ってきました。加えて、これらのチームがインシデントに対応する方法に関する革新が行われました。

インシデント管理に対する DevOps のアプローチは、効果的なインシデント管理のための従来の手順と劇的に違うわけではありません。DevOps インシデント管理では、最初からオンコールを含む開発者チームを関与させることと役職ではなく専門知識に基づいて作業を割り当てることを、明示的に重視しています。

インシデント対応と継続的な改善

この記事は、サイクルと直線の違いについて説明することから始まりました。これらすべてのインシデント管理アプローチに共通していること、すなわち、これらのアプローチが直線的ではないことにお気付きでしょう。各アプローチには、同じ基本コンポーネント パーツが含まれています。すなわち、インシデントを定義、検出、識別する方法、インシデントに迅速に対応して軽減するための措置を講じる方法、インシデントを分析して将来の検出と対応を向上させる方法です。すでに発生したインシデントをそのインシデントのためだけに分析しても無意味です。時間を遡って、起こったことを変えることはできません。インシデントから学習するのは、今後の検出と対応を改善するためです。不断の継続的な学習と改善が、チームがそのサイクルを終わらせるのです。

(非線形) インシデント対応のプロセスには、不確定要素が多数存在します。Jira Service Management などのインシデント管理ソリューションを利用すると、統合されたコミュニケーション ツールやコラボレーション ツールによって、各ステップを簡単に追跡できます。アラートを一元化し、チームを柔軟にまとめて、インシデントにすばやく対応し解決できます。