こんにちわ、札幌オフィスのヨシエです。
今回はPagerDutyで発生するインシデントがどのようなものかを調べてみました。
インシデントの意味を考える
そもそもがこういった業界において「インシデント」と呼ばれる言葉はネガティブな印象が強いと思います。
JRPSの用語辞典ではインシデントをように紹介されております。
重大な事件・事故に発展する可能性を持つ出来事や事件のことです。
一般に、インシデントは、アクシデント（accident：偶発事故）やハプニング（happening：出来事）とは区別されます。
PagerDutyにおいてもインシデントは解決が必要とされる課題を示しております。
これはインシデントがトリガーされる(=作成される)タイミングが監視システム等からの通知によることから課題として認識されることにより、個人的には 「解決されることが前提の課題」 としてインシデントという言葉がとてもしっくり来ました。
一方、「解決が必要とされない課題」はトリガーされる必要はなく、監視システム等はこの課題をPagerDutyへ連携しないようにすることが効率的にPagerDutyを扱えるシステムなのかもしれません。
とはいえ状況によって、サービス開始直後のシステム、繰り返し引き継ぎされ続けたシステム、非常に多岐に渡るリソースを利用しているシステムなどを引き継いだ管理者/担当者がこの通知に関する取捨選択を行うことは難しいことと考えます。
このような場合を考慮すると、PagerDutyへ何でもかんでも投げ込むという運用でも利用することが出来ます。ただしそれは解決されることが大前提のため、解決というゴールが見えないインシデントが次々に作成された際にはせっかく導入したPagerDutyも実力を発揮出来ないと思います。
運用過程でよりよくツールを利活用するためにも余計な情報を通知しないという考え方を軸にシステムの運用基盤を作れると負担が減るのかもしれません。
インシデントに対して私見を記載しましたが、その上でPagerDutyではインシデントにステータスが付与され、それぞれの状態を管理することが出来ます。
ステータスとは
インシデントが発生した際、対象のインシデントに対応しているのか？対応してないか？を把握する状態を示すものです。
特に様々な通知を受けやすいため、ステータス把握ができないと誰が何を対応していいか関係者が把握できないため、「誰かがやってるだろう」という傍観者効果を生み出す可能性があります。
(傍観者効果とは端的に記載すると「私以外の誰がやってる/やるから大丈夫だろう」という意識で見て見ぬ振りが発生する心理効果です)
これを防ぐ観点、効率的なインシデント対応に向けてPagerDutyではインシデントごとにステータスを設けております。
このステータスは3つのステータスで構成されております。
Trigger
PagerDutyへ通知されたインシデントの初期状態がTriggerとして扱われます。 Trigger状態は誰も手つかずの状態として、指定されたエスカレーションポリシーに従って関係者に合わせた通知を行います。
Acknowledged
インシデントに対して関係者が確認した状態であり、担当者が「インシデントを認知しました、私がこのインシデントを対応します。」という意思表示のステータスと思われます。 ただし、この状態は「インシデントが発生していることは確認しているが、解決に向けて取り組みを開始している」という状態のため、インシデント自体は解決しておりません。
Resolved
「認知されたインシデントを解決した。」という状況を示すステータスとなります。
ざっくりとインシデントがトリガーされてから解決するまでの流れを書き出してみます。
今回はインシデントに対してどのように向き合うべきなのか、PagerDutyとしてどういう流れ対応を進めるのかを書き出してみました。
13
