インシデントとはなにか？

まずインシデント対応プロセスを定義する前に、何がインシデントで何が重大インシデントか定義します。

インシデントとはなにか？#

顧客がPagerDutyを利用する上で、計画していないサービス停止やパフォーマンス劣化です。

重大インシデント（major incident）とはなにか？#

複数のチームで協力して対応が必要なインシデントです。

インシデント対応（incident response）とはなにか？#

インシデントの対応や管理をする体系的なアプローチです。 そのゴールはインシデントを解決するだけでなく、被害を最小に抑え、復旧時間とコストを削減できるよう状況に対処することです。

インシデント対応プロセスのトリガーはなにか？#

私たちのインシデント対応プロセスは、重大インシデントに対して開始します。 効果的に対応できて、すばやく問題解決できるフレームワークを提供します。 私たちのインシデント対応プロセスは、自動化された監視やアラート、あるいは人手による手動アクションのいずれかの方法でトリガーできます。

自動化された監視#

システム全体を通して様々なメトリクスを監視することで、人の手によって対応すべき状態にあるかを検知します。 監視するメトリクスと何を監視すべきかを決めるために、以下の質問をします。 もしいずれかの答えが "No" の場合は、インシデント対応プロセスをトリガーする必要があります。

1. PagerDutyの顧客は、全てのプラットフォームで、PagerDutyのインシデント対応機能を利用できるか？
   • たとえば、PagerDutyがサポートしている全ての方法で、インシデントに応答、割り当て、解決ができるか？
2. 顧客はSLAの範囲内で通知を受け取っているか？

人によるエスカレーション#

自動化はプロセスの一部に過ぎません。 機能の一部で必要な監視ができていない箇所があるかも知れません。 その場合はあらかじめ準備されたインシデント対応プロセスをトリガーできることが重要です。 例えばサポートチームがシステムの問題が報告されたとき、私たちの対応が必要になります。 PagerDutyの従業員はいつでもインシデント対応プロセスをトリガーできます。

計画外のサービス停止やパフォーマンス劣化が発生すると、PagerDutyの従業員は必要だと判断した場合にトリガーします。

インシデントの深刻度#

私たちの深刻度の定義では、ガイドラインに基づいて、インシデントがどの程度深刻であると 考えられるか を分類しています。 これはインシデント対応者に、対応の種類を示すことができます。 例えば深刻度が高くなると、システムを正常に戻すために高いリスクの意思決定ができます。

深刻度は複雑な応答が必要か、準備された対応が必要になるかを判断するのに役立ちます。 しかしこれは、重大インシデントを白黒はっきりと定義するものではありません。 もし深刻度の定義によりカバーされて無くても、インシデント対応が必要だと思われる場合は、インシデント対応が必要になります。 「これは重大インシデントか？」がわかればよいのです。 深刻度レベルは後からも決めることができ、対応プロセスをトリガーするものではありません。

気持ちの入れ替え#

インシデント対応プロセスにおける重要な考えの１つに、インシデント中に気持ちの入れ替えが重要というのがあります。 私たちはこれを、「平時（Peacetime）と戦時（Wartime）」の気持ちの入れ替えと呼んでいます。 この考え方はインシデント発生中の意思決定プロセスが変化し、日中のオペレーションよりもリスクの高い行動ができるということです。 この考えを理解するのは難しいかも知れませんが、平時の考え方に考えが固まり、潜在的にリスクのあるアクションをしたくないという理由で、インシデント対応プロセスが滞ってしまう可能性があります。 平時と戦時の考えについては、トレーニングガイドに詳しく記述されています。