インシデントの重大度レベルの把握

インシデントを特定して優先順位付けし、迅速な解決を実現する

インシデント管理には、基本的な事実が 3 つあります。

1 つ目は、インシデントは避けられないという事実です。これは特に、成長と革新をし続けている企業に当てはまります。

2 つ目は、健全なビジネスには強力なインシデント管理プラクティスが不可欠であるという事実です (また、それが脆弱である場合は、従業員の時間と満足度およびビジネスの収益の両方に大きな代償が伴います)。

3 つ目は、すべてのインシデントが同等に作成されるわけではないという事実です。1 つのデータベースからデータが失われることは、すべてのデータベースからデータが失われることと同義ではありません。ユーザーの 20％ に影響を与えるシステム停止に対処することは、90％ または 100％ の影響を与えるシステム停止に対処することとはまったく異なります。ピーク時のシステム停止の処理は、ほとんどの顧客が眠っているときにシステムを処理するときよりも多くのストレスがかかります。書類上は同じに見える 2 つのインシデントであっても、内面ではまったく異なります。

このため、堅牢なインシデント管理プログラムを持つ企業はインシデントの重大度レベルを明確に定義して、インシデントの発生時に優先順位を付けるための明確なベスト プラクティスを備えています。

重大度レベルとは?

インシデントの重大度レベルは、インシデントがビジネスに与える影響の指標です。通常、重大度の数値が小さいほど、インシデントの影響は増加します。たとえばアトラシアンでは、SEV (重大度) 1 のインシデントを「非常に大きな影響がある重大なインシデント」として定義しています。これには、顧客データの損失、セキュリティの侵害、すべての顧客を対象としたクライアント向けサービスのダウンなどが含まれます。SEV 2 のインシデントは、「重大な影響がある深刻なインシデント」です。これには、顧客の一部を対象としたクライアント向けサービスのダウンや、システム内の重要な機能の停止などが含まれます。また SEV 3 のインシデントは、「影響の少ない軽微なインシデント」です。たとえば、顧客に軽微な不便が生じているシステムの不具合などです。アトラシアンでは SEV 3 のインシデントについては日中/勤務時間内に処理できますが、SEV 1 および SEV 2 のインシデントの場合はオンコールの専門家宛てにアラートが生成されて時間に関係なく即時に修正されます。

重大度レベルは、影響をすばやく把握し、IT チームと DevOps チームの優先順位を設定するのに役立ちます。SEV レベルの定義が明確であればあるほど、チームの認識が揃って、インシデントが発生したときに迅速かつ適切に対応できる可能性が高くなります。重大度レベルが明確に定義されていないと、インシデントを解決するのではなく、インシデントの緊急性を定義して説明するために大切な時間を無駄に費やしてしまいがちです。

重大度レベルが役立つタイミングと場所

SEV レベルのコア バリューは、チームの時間を節約できることです。重大度レベルが定義されて各レベルに対応するための明確なロードマップが描かれているチームは、すぐに修正に取り組めます。重大度レベルが定義されていないチームは、インシデントの重要性、担当者、対処方法を確認するために、重大なインシデントの最初の極めて重要な時間を費やすことになります。

インシデントが重大であるほど、インシデントの解決方法やコミュニケーション計画だけでなく、明確な SEV レベルと優先順位を事前に計画して、できる限り多くの時間を節約することが重要になります。

重大度と優先順位との違い

一見すると、インシデントの重大度はインシデントの優先度と同じように見えます。結局のところ、悲惨な結果が伴う重大なインシデントは、それほど重大ではないインシデントよりも先に対処する必要があるからです。しかし、実際のところ、ほとんどの企業にとって、事態はそれほど単純ではありません。重大度は影響の指標です。インシデントがユーザーに与える影響はどれくらいか? インシデントはユーザーのシステム全体をダウンさせるか? ユーザーは重要なタスクを完了できなくなるか? それとも、単にユーザーを苛立たせて作業を困難にしているだけか? 一方、優先度は緊急性の尺度です。この課題をどのくらいの速さで修正する必要があるか? 最初に修正する必要がある課題はどれか? 場合によっては、この 2 つの指標は完全に一致します。会社全体がダウンするような重大度の高いインシデントも、DevOps チームや IT チームが注力すべき最優先事項でしょう。ただし、優先度と重大度が一致しない場合もあります。たとえば、Web サイトのホームページの見出しに誤字があるとします。これは、実際には Web サイトの機能に影響しないため、重大度が低い課題です。ユーザーは依然として、必要なことは何でも実行できます。従業員は依然として、必要なことは何でも実行できます。しかし企業としては、ブランドの維持という観点から、また混乱を引き起こすという理由や単に見た目が悪いという理由で、この修正を優先度の高いものと見なすことがあります。つまり、このインシデントの重大度は低いが優先度は高いということになるのです。同様に、アプリがクラッシュするインシデントがあるとします。ユーザーが必要な操作を行えないため、このインシデントの重大度は高くなります。しかし、このインシデントがユーザーの 0.05% のみに影響を与えているとするとどうでしょう。一般的に「システムがクラッシュしている」ということは、全員が総力を挙げて対処することですが、より広範囲に影響を与える他のインシデントが存在する場合、このような課題は最優先事項にならない可能性があります。どちらの指標もインシデント管理では重要ですが、この両方が一致する場合と一致しない場合を認識することが重要です。重大度が高いからといって、自動的に優先順位リストの一番上に移動するわけではなく、優先度が高いからといって、システムがダウンしているとは限りません。優先度の方が重大度よりも実用的であるため、アトラシアンでは主要な指標として使用しています。また、優先順位を決定づける鍵となるのは重大度であることが多いため、Incident Handbook には独自のインシデント管理プラクティスの明確な定義を設定しています。

組織のインシデント重大度レベルの定義

すべてのインシデントが同等に作成されるわけではなく、すべての組織がインシデントを同じ方法で処理するわけではありません。重大度レベルとそれに関するプロセスと期待値を設定する場合は、インシデントの影響に加えて次の要因を考慮する必要があります。

• 技術チームの規模

• オンコールスケジュール

• 1 日のサービスのトラフィックが多い時間帯と少ない時間帯

• インシデントの頻度

その理由は、これらの各要因が SEV レベルの定義方法に影響を与える可能性があるためです。たとえば、1 つのタイム ゾーンで現地市場にサービスを提供するアプリでは、午前 2 時から午前 7 時の間は使用に大きなギャップが生じる可能性があります。したがって、午前 3 時にシステム全体がダウンした場合、これはピーク時のシステム停止と同じ SEV レベルになるでしょうか? または、小規模なチームが SEV 3 と見なされる多くのインシデントを抱えているスタートアップ企業の場合はどうでしょうか? 3 つのインシデントが一度に発生した場合に、この企業は SEV 3 レベルにこだわり、インシデントの優先順位をチームに判断させるべきでしょうか? それとも、インシデントを SEV 3、4、または 5 にさらに分類して、顧客向けシステムの機能の部分的な喪失、パフォーマンスの課題、より軽微なインシデント (システムの使用には影響しないが最終的には修正する必要があるバグなど) を区別する必要があるでしょうか? ここで重要なことは、自社のビジネスやチームについて理解し、自社に合った SEV レベルと優先順位レベルの定義を把握することです。

インシデントをエスカレートするインシデント管理ソリューションは不可欠です。それにより、適切なチームがすぐに集まって解決を開始できます。

アラートやオンコール スケジュール、協調的なコミュニケーション、堅牢なレポートと分析機能など、Jira Service Management のインシデント管理機能のすべてによって、チームがインシデントに対応して解決し、インシデントから学べる方法をご覧ください。