深刻度レベル

インシデント対応プロセスの最初のステップは、何がインシデントを引き起こしているかを特定することです。そのあとインシデントは深刻度によって分類され、通常は数字が低いと深刻度が高くなる "SEV" の定義が利用されます。運用上の問題はこの深刻度レベルによって分類され、一般的には深刻度の高い問題を解決するにはリスクの高い行動を取ることができます。 SEV-3を超える深刻度は機械的に重大インシデント (Major Incident) とみなされ、通常のインシデントよりも優先的に対応されます。

常に最悪の事態を考える

もしインシデントのレベルがわからない場合（SEV-2かSEV-1かわからない場合など）は、より深刻度の高い方に分類します。インシデント対応中は、深刻度を議論したりそれを決める時間ではありません。深刻度の高いものとして扱い、後のポストモーテムで振り返りましょう。

SEV-3は重大インシデントか？

全てのSEV-2は重大インシデントですが、全ての重大インシデントがSEV-2に分類される必要はありません。問題の深刻度が低くても、連携した対応が必要な場合は、インシデント対応プロセスをトリガーします。インシデントコマンダーが、インシデント対応が必要かどうかを意思決定します。

深刻度解説典型的な対応

SEV-1

深刻度	解説	典型的な対応
SEV-1	外部への告知と幹部との連絡が必要な、致命的な問題システムは致命的な状態で、多くの顧客に影響がある状態。長期的にわたり機能が利用できず、SLAを破っている。顧客データが漏洩する可能性のある脆弱性が報告されている。	重大インシデント対応 Slackでインシデント司令官を呼び出す`!ic page`. インシデント発生中を読む社内のステークホルダーに通知する外部へ通知する
SEV-2	顧客が製品を利用するのに影響がある致命的なシステムの問題通知パイプラインに重大な障害が発生している。インシデント対応の機能（応答、解決、など）が利用できない。 Webアプリが利用できないか、多くのユーザーにパフォーマンス劣化が発生している。重大インシデントに対するPagerDutyの監視システムが停止している PagerDutyの従業員がインシデント対応が必要だとみなしたイベント	重大インシデント対応 Slackでインシデント司令官を呼び出す`!ic page`. インシデント発生中を読む
このラインを超えるのは「重大インシデント」と扱います。私たちのインシデント対応プロセスは、あらゆる重大インシデントに対してトリガーされるべきです。
SEV-3	サービスオーナーが直ちに対応する必要がある、安定性や一部の顧客に影響がある軽微な問題。一部の機能が使えないが、多くの顧客には影響しない。何もしなければSEV-2になる可能性があるもの。サービスの冗長度がないもの（もう1つのノードが停止すると障害になる）。	サービスチームへの緊急度の高いページ最優先で問題に取り掛かる。影響するシステムのエンジニアと連絡をとり、原因の特定する。最近の開発によるものならロールバックする。ステータスを監視して事態が悪化しているか、いつから悪化しているかを知らせる。エスカレーションする可能性のある人にSlackで通知する。必要ならインシデント対応を発動する(`!ic page`)。
SEV-4	顧客が製品を使うのには影響しない、軽微な問題パフォーマンス問題（遅延など） 1つのホストでの障害（クラスタから1つのノードが抜けるなど）遅延したジョブによる障害（イベント、通知パイプラインには影響しない） Cronの障害（イベント、通知パイプラインには影響しない）	サービスチームへの緊急度の低いページ最優先で問題に取り掛かる（通常のタスクよりも上）。ステータスを監視して事態が悪化しているか、いつから悪化しているかを知らせる。
SEV-5	製品を利用する顧客には影響しない、表面的な問題やバグシステムを使う上で即座に影響しないバグ	JIRAチケット JIRAチケットを作成して影響のあるシステムのオーナーに割り当てる。

外部への告知と幹部との連絡が必要な、致命的な問題

システムは致命的な状態で、多くの顧客に影響がある状態。
長期的にわたり機能が利用できず、SLAを破っている。
顧客データが漏洩する可能性のある脆弱性が報告されている。

重大インシデント対応

Slackでインシデント司令官を呼び出す!ic page.
インシデント発生中を読む
社内のステークホルダーに通知する
外部へ通知する

SEV-2

顧客が製品を利用するのに影響がある致命的なシステムの問題

通知パイプラインに重大な障害が発生している。
インシデント対応の機能（応答、解決、など）が利用できない。
Webアプリが利用できないか、多くのユーザーにパフォーマンス劣化が発生している。
重大インシデントに対するPagerDutyの監視システムが停止している
PagerDutyの従業員がインシデント対応が必要だとみなしたイベント

重大インシデント対応

Slackでインシデント司令官を呼び出す!ic page.
インシデント発生中を読む

このラインを超えるのは「重大インシデント」と扱います。私たちのインシデント対応プロセスは、あらゆる重大インシデントに対してトリガーされるべきです。

SEV-3

サービスオーナーが直ちに対応する必要がある、安定性や一部の顧客に影響がある軽微な問題。

一部の機能が使えないが、多くの顧客には影響しない。
何もしなければSEV-2になる可能性があるもの。
サービスの冗長度がないもの（もう1つのノードが停止すると障害になる）。

サービスチームへの緊急度の高いページ

最優先で問題に取り掛かる。
影響するシステムのエンジニアと連絡をとり、原因の特定する。
最近の開発によるものならロールバックする。
ステータスを監視して事態が悪化しているか、いつから悪化しているかを知らせる。
エスカレーションする可能性のある人にSlackで通知する。
必要ならインシデント対応を発動する(!ic page)。

SEV-4

顧客が製品を使うのには影響しない、軽微な問題

パフォーマンス問題（遅延など）
1つのホストでの障害（クラスタから1つのノードが抜けるなど）
遅延したジョブによる障害（イベント、通知パイプラインには影響しない）
Cronの障害（イベント、通知パイプラインには影響しない）

サービスチームへの緊急度の低いページ

最優先で問題に取り掛かる（通常のタスクよりも上）。
ステータスを監視して事態が悪化しているか、いつから悪化しているかを知らせる。

SEV-5

製品を利用する顧客には影響しない、表面的な問題やバグ

システムを使う上で即座に影響しないバグ

JIRAチケット

JIRAチケットを作成して影響のあるシステムのオーナーに割り当てる。

具体的に

これらの深刻度の解説は、PagerDutyの社内で利用している定義から、より一般的な説明に置き換えています。読者の内部ドキュメントとして利用する場合は、ユーザーやアカウントの何%に影響しているかなどを元にした、具体的な定義を作ることをお勧めします。通常はメトリクスに基づいて深刻度を定義するのが望ましいです。