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

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 のインシデント管理機能のすべてによって、チームがインシデントに対応して解決し、インシデントから学べる方法をご覧ください。