Close

インシデント管理改善への道はここから始まります

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

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

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

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

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

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

OpsGenie のロゴ

Atlassian のインシデント管理の詳細を見る

迅速で単純明快なインシデント管理プロセスを実現することは、これまで以上に重要になっています。

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

重大度レベルとは?

インシデントの重大度レベルは、インシデントがビジネスに与える影響の指標です。通常、重大度の数値が小さいほど、インシデントの影響は増加します。

たとえば Atlassian では、SEV (重大度) 1 のインシデントを「非常に大きな影響がある重大なインシデント」として定義しています。これには、顧客データの損失、セキュリティの侵害、すべての顧客を対象としたクライアント向けサービスのダウンなどが含まれます。

SEV 2 のインシデントは、「重大な影響がある深刻なインシデント」です。これには、顧客の一部を対象としたクライアント向けサービスのダウンや、システム内の重要な機能の停止などが含まれます。

また SEV 3 のインシデントは、「影響の少ない軽微なインシデント」です。たとえば、顧客に軽微な不便が生じているシステムの不具合などです。

Atlassian では SEV 3 のインシデントについては日中/勤務時間内に処理できますが、SEV 1 および SEV 2 のインシデントではオンコールの専門家宛てにアラートが生成されて時間に関係なく即時に修正されます。

重大度 説明
1 非常に大きな影響がある重大なインシデント
  • Jira Cloud のような顧客向けサービスの1つが、すべての顧客でダウンしている。
  • 機密情報やプライバシーが侵害された
  • 顧客データの損失
2 重大な影響がある深刻なインシデント
  • 顧客向けサービスの1つを一部の顧客が使用できない状態。
  • コア機能 (たとえば、git push、課題作成) が重大な影響を受けている
3 影響の少ない軽微なインシデント
  • 顧客が少し不便だと感じているが、回避方法がある
  • 使用可能なパフォーマンスが低下

重大度レベルは、影響を迅速に把握して IT チームと DevOps チーム向けの優先順位を設定する上で役に立ちます。

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

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

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

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

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

一見すると、インシデントの重大度はインシデントの優先順位と同じように見えます。しかし結局のところ、悲惨な結果が伴う重大なインシデントは、それほど重大でないインシデントよりも先に対処する必要があります。

それにもかかわらず、実際にはほとんどの企業では事態はさらに複雑です。

重大度は影響の指標です。インシデントがユーザーに与える影響はどれくらいですか? インシデントはユーザーのシステム全体をダウンさせますか? ユーザーは重要なタスクを完了できなくなりますか? あるいは、ただユーザーをイライラさせて、タスクをより困難にしているのですか?

一方、優先順位は緊急性の指標です。この課題をどれくらい迅速に修正する必要がありますか? 最初に修正する必要がある課題はどれですか?

場合によっては、2 つの指標が完全に一致します。企業全体のシステムを停止させる重大度の高いインシデントが、ほぼ確実に DevOps チームと IT チームが重点を置く最優先事項であることもあります。

しかし、優先順位と重大度が一致しないこともあります。たとえば、Web サイトのホームページの見出しに誤字があるとします。これは、実際には Web サイトの機能に影響しないため、重大度が低い課題です。ユーザーは依然として、必要なことは何でも実行できます。従業員は依然として、必要なことを実行できます。

しかし企業としては、ブランドの標準による理由や混乱を引き起こすため、あるいは単に見た目が悪いためという理由から、この修正を優先順位が高いもの見なす場合があります。したがって、このインシデントの重大度は低いが優先順位は高くなる可能性があります。

同様に、アプリがクラッシュするインシデントがあるとします。ユーザーが必要な操作を行えないため、このインシデントの重大度は高くなります。ただし、このインシデントはユーザーの 0.05% のみに影響を与えているとします。一般的に「システムがクラッシュしている」ということは、全員が総力を挙げることではありますが、より広範囲に影響を与える他のインシデントが存在する場合、このような課題は最優先事項にならない可能性があります。

どちらの指標もインシデント管理では重要ですが、この両方が一致する場合と一致しない場合を認識することが重要です。重大度が高くても優先順位リストの上位に自動的に押し上げられるわけではなく、優先順位が高くてもシステムがダウンしているとは限りません。

優先順位の方が重大度よりも実用的であるため、Atlassian では Opsgenie で主な指標として使用しています。また、重要度は優先順位を動かす重要な要因であることが多いため、Atlassian では独自のインシデント管理プラクティスとしてインシデント ハンドブックで明確な定義を定めています。

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

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

  • 技術チームの規模
  • オンコールスケジュール
  • 1 日のサービスのトラフィックが多い時間帯と少ない時間帯
  • インシデントの頻度

どうしてでしょうか? これらの各要因が SEV レベルの定義方法に影響を与える可能性があるためです。

たとえば、1 つのタイムゾーンで現地市場にサービスを提供するアプリでは、午前 2 時から午前 7 時の間に大きなギャップが生じることがあります。したがって、午前 3 時にシステム全体がダウンした場合、これはピーク時のシステム停止と同じ SEV レベルになるでしょうか?

または、小規模なチームが SEV 3 と見なされる多くのインシデントを抱えているスタートアップ企業の場合はどうでしょうか? 3 つのインシデントが一度に発生した場合に、この企業は SEV 3 レベルにこだわり、インシデントの優先順位をチームに解決させるべきでしょうか? それとも、インシデントを SEV 3、4、または 5 にさらに分類して、顧客向けシステムの機能の部分的な喪失、パフォーマンスの課題、より軽微なインシデント (システムの使いやすさには影響しないが最終的には修正する必要があるバグなど) を区別する必要があるでしょうか?

ここで重要なことは、自社のビジネス、チームについて、および自社に役立つ SEV レベルと優先順位レベルに関する定義を把握することです。

アトラシアンの第 3 階層 第 4 階層 第 5 階層
SEV 1

非常に大きな影響がある重大なインシデント。

例: Jira のような顧客向けサービスの 1 つが、すべての顧客でダウンしている。

SEV 2

重大な影響がある深刻なインシデント。

例: 顧客向けサービスの 1 つがダウンしていて一部の顧客が使用できない状態。

SEV 3 影響の少ない軽微なインシデント。

例: システムのバグのために、顧客に軽微な不便が生じている。

迅速に対処しなければ、深刻なインシデントになる可能性があるインシデント。

例: ごく一部の顧客の機能が部分的に失われている。

SEV 4 顧客を苛立たせているが、システム全体の機能には影響しないサポート リクエスト。

製品の使いやすさに影響を与えるが停止することはない軽微なインシデント。

例: 平均より遅いロード時間。

SEV 5

製品の使いやすさに影響しないバグやサポート課題。

例: ロゴが間違った場所に表示される、または見出しの最後の文字が部分的に不明瞭である。

次の記事
Cost of downtime