インシデント重大度1～5の基本

インシデントは、発生するかどうかが問題になるのではありません。いつ発生するかです。システムのクラッシュ、ソフトウェアの障害、ベンダーのサービス停止はいつでも起こり得ます。こうしたインシデントに対する備えは組織の責任であり、インシデントの重大度はその対策に必要な手段の1つです。

インシデントはビジネスや顧客にさまざまな影響をもたらします。インシデントの重大度は、その影響を分類し、対応方法を決める基準になります。重大度を適切に活用すれば、以下のメリットを実現できます。

• 迅速に対応する
• MTTR (平均修復時間)を短縮する
• 問題が顧客に与える影響について、関係者にできるだけ正確に理解してもらう

この記事では、インシデントの重大度の概要、活用方法、優先度との違いについて説明します。

重大度とは？

重大度は、インシデント管理プラクティスの重要な要素の1つで、イベントがビジネスに与える影響の大きさを示します。イベントには、機器やソフトウェアの障害といった内部的なものと、セキュリティ侵害やベンダーのサービス停止といった外部的なものがありますが、いずれも顧客へのサービス提供能力に特定の影響を及ぼします。重大度はその影響の大きさを表します。

(SIEMの機能を使えば、セキュリティインシデントのイベントをより効率的に管理できます)

組織にもよりますが、重大度は一般的に1～3、4、または5の範囲で設定します。重大度1 (SEV 1)が最も重大度が高く、最大の数(3、4、または5)が最も低いことを示します。

重大度について統一された定義はありません。組織とユーザーにとって何が重要かによって各組織が独自に定義します。3段階で十分な場合もあれば、5段階に分けるのが効果的な場合もあります。5段階に分ける場合の定義は以下のようになります。

重大度を使うメリット

インシデントが発生したとき、チームは以下の点を把握する必要があります。

• 問題の対応を指揮する責任者
• チームメンバー間の連絡方法
• 問題の深刻度
• チームが実行できる問題解決手段
• インシデントの報告および追跡方法

たとえば、すべてのユーザーに影響を与えるサービス停止が発生した場合、一般的にはチーム全員で対応に当たります。ただし、全員が1つの問題に集中するのは非生産的で、多くの場合、作業の重複や矛盾、混乱が生じて逆効果になります。重大度とその重大度に応じたプロセスをあらかじめ定義しておけば、より適切に対応できます(インシデントコマンダーを指定して、誰が問題解決の指揮を執るかを明確にしておくとさらに効果的です)。

インシデントの管理計画に重大度の定義を組み込むことをお勧めします。これにより、チームが上記の点を事前に把握し、インシデントの重大度が特定された時点ですばやく行動できるようになるため、対応を大幅に効率化できます。

インシデント重大度の例

前述のインシデント発生時の確認ポイントを踏まえて、SEV 1の定義の例を見てみましょう。

• 問題の対応を指揮する責任者：関連部門の最高責任者、またはあらかじめ指定された管理チームのメンバー
• チームメンバー間の連絡方法：オープンコールブリッジ(Webや電話などを使った会議システム)
• 問題の深刻度：顧客の大多数に影響を与える
• チームが実行できる問題解決手段：本番環境のプロセスの再起動を含め、あらゆる手段を講じる
• インシデントの報告および追跡方法：責任者が経営幹部に1時間ごとに状況を報告する

一方、SEV 5の定義の例は以下のようになります。

• 問題の対応を指揮する責任者：エンジニアまたは開発者
• チームメンバー間の連絡方法：インシデント追跡システムを使用
• 問題の深刻度：緊急性のない軽微な問題
• チームが実行できる問題解決手段：本番環境で変更が可能な時間帯にのみ対応
• インシデントの報告および追跡方法：エンジニアがインシデントまたはソフトウェア追跡システムで問題を追跡

重大度は、インシデント対応に関与するすべての人が参照する共有情報です。重大度が定義され、その対応手順が明確になっていれば、適切なチームがすばやく問題解決に取り掛かることができます。逆に重大度が定義されていなければ、誰がどのように対応すべきかを判断するのに時間がかかったり、混乱が生じてさらなる問題を生み出したりすることになります。

(Splunkソリューションがインシデント管理プロセス全体をどのように支援するのか、こちらをご覧ください)

インシデントの重大度と優先度の違い

重大度と優先度は一見同じように見えます。SEV 1のインシデントが発生した場合、SEV 2よりも優先して対応すべきであることは明らかです。では、重大度と優先度の違いは何でしょうか。

• 重大度は影響の大きさを基準とします。上記の表に示したように、重大度はユーザーやサービスへの影響の度合いに応じてレベル分けされます。
• 優先度は緊急性を基準とします。優先度は、問題をどのくらいすばやく修正すべきか、どの問題に最初に対処する必要があるかを示します。

優先度と重大度は、多くの場合、完全に一致します。すべてのユーザーがサービスを利用できなくなるような障害は、優先度が高く、重大度も1です。ただしこれは、技術的な問題とビジネス上の優先順位が一致しているケースです。以下のように、場合によっては優先度と重大度が一致しないこともあります。

• 本番環境に新機能をリリースする場合、優先度は高いかもしれませんが、サービスに問題があるわけではありません。インシデントは発生していないため、重大度は割り当てられません。
• モバイルアプリケーションのUIに恥ずかしいタイプミスがあり、早急に修正する必要がある場合、テクノロジーチームはSEV 5インシデントとして分類するかもしれませんが、優先度は高くなります。

優先度と重大度が一致しないことがあっても、どちらも状況を伝えるために重要な情報であることは間違いありません。重大度では、問題がいかに深刻であるかを関係者に伝えることができます。優先度では、次に取り組むべき作業を技術担当者に伝えることができます。

インシデント重大度の定義：ベストプラクティス

インシデントの重大度の考え方はいたってシンプルです。しかし残念ながら、その導入の道のりはシンプルとは言えません。ブログ記事やホワイトペーパーからコピーして今日から実践というわけにはいきません。次のような要素を考慮して、組織に適した定義を考える必要があります。

• ユーザーコミュニティ
• ソフトウェアおよびハードウェアシステム
• ビジネス要件

それでも、以下のベストプラクティスを取り入れれば、重大度の定義(および順守)に役立ちます。

統一が重要

ベストプラクティス：組織全体でレベルと定義を統一する

特に大規模な組織の場合、アプリケーションやソフトウェアスタックごとに異なるインシデント重大度を設定しても問題ないと思うかもしれません。しかし、そもそも重大度を設定することの大きな利点の1つは、インシデントに関する情報を明確に伝えられることです。重大度の設定や定義が複数あると、関係者がインシデントの影響の大きさを正しく理解できず、混乱が生じます。さらに、各アプリケーションを担当するエンジニアや開発者も混乱する可能性があります。

シンプルに保つ

ベストプラクティス：重大度のレベル数は必要最小限にする。多すぎるのも少なすぎるのも良くない

レベル数が多すぎると、すぐに混乱を招きます。インシデントの重大度を設定する理由の1つは、インシデントの発生時に重大度を割り当てることで、すばやく対応に取り掛かれるようにするためです。レベル数が多すぎると、その判断が遅れます。逆に少なすぎると、インシデントの違いがわからなくなります。インシデントごとに微妙な(またはそこそこ大きな)違いがあっても、同じカテゴリに入れられてしまうと、真の重大度を適切に把握できなくなります。

では、実際にはどのようにすればよいでしょうか。まず、関係者を集めて計画を立てます。過去のインシデントを調べ、それぞれのインシデントが、提案したどのレベルに当てはまるかを確認します。その結果を、当時の根本原因分析と照らし合わせます。入念に検討し、必要であればレベル分けを調整します。

重大度を割り当てるための明確なガイドラインを設定する

ベストプラクティス：重大度をすばやく判断できるようにする

インシデントに適切な重大度をすばやく割り当てることができなければ、重大度を定義した意味がありません。そのため、重大度を簡単かつ正確に割り当てられるようにするためのガイドラインを設定します。インシデントがどの重大度に該当するかを議論するのは時間の無駄です。

まずはレベルを定義してから、ガイドラインの設定に取り組みます。その際は、以下のような測定可能な影響を基準にします。

• 影響を受けるユーザーの割合
• 機能のカテゴリ
• システムへの影響

インシデントの重大度を活用

これまでの説明で、インシデントの重大度とその活用方法を十分にご理解いただけたのではないでしょうか。重大度は情報を共有するための一種のツールです。うまく活用すれば、問題の影響の大きさを正確に伝え、適切なチームにすばやく対応してもらうことができます。また、重大度と優先度はどちらもインシデントに関連しますが、まったく違う概念であることも覚えておきましょう。