PagerDutyのエスカレーションポリシーを作成してオンコール通知を自動化してみた
今回も前回に引き続きPagerDutyに関するブログです。
今回はPagerDutyがアラートを誰に送るのかを決めるエスカレーションポリシーについてです。 PagerDutyを使い実際に通知を受け取るには前回のブログで作成したサービスに加えてエスカレーションポリシーが必要になります。 今回はこのエスカレーションポリシーについて学んで実際に作成をしてみました。
PagerDutyのエスカレーションポリシーとは
エスカレーションポリシーは簡単に説明すると「アラートが発生した際に誰にどんな順番で通知するのか決めたルール」です。 具体的には、「最初の対応者がインシデントを確認することができない場合は次に誰にインシデント通知を送るのか？」といったようなルールのことです。
このルールを決めておくことでPagerDutyはインシデントを各対応者に自動で割り当てることが可能になり、ユーザーはアラートに対する細かい対応計画を立てることができます。
各サービスには必ずこのエスカレーションポリシーが必要になります。 サービスを作成する際に一緒にエスカレーションポリシーを作成することもできますが、今回はどんなポリシーが作れるのかを詳しく見ていきたいと思います。
作ってみた
PagerDutyの上部タブからPeople＞Escalation Polices＞New Escalation Policyと進みます。
必要な項目について埋めていきます。 名前は分かりやすいものをつけておきましょう。
次に必要なのがNotify the following user or schedulesの項目です。
ここでインシデントがトリガーされた時に通知するターゲット（ユーザーorスケジュール）を選択します。 アラート発生時に一番最初に通知したいユーザーを選べばOKです。ここでは複数のユーザーやスケジュールを選ぶことも可能です。複数選択した場合は同時に通知が飛んできます。
Assign via Round Robinにチェックを入れると、多数インシデントが発生した場合にスケジューリングされたユーザーにインシデント通知が公平に分散されるようになります。
次にAdd anew Escalation Ruleをクリックすると2つ目のルールを選択できます。 ここでは、最初のルールで誰も応答できなかった場合に誰に通知をするのかを決めることができます。
escalates after ? minの部分で何分間応答がなかった場合に次の対応者に通知をするのかを決めます。デフォルト設定は30分で最小1分から設定ができるようになっています。このようなルールを最大で20個追加していくことが可能です。
最後の項目にチェックを入れることで、最後の応答者からも応答がなかった場合に何回このルールを繰り返すのかを決定することができます。
エスカレーションポリシーを使ってみた
今回は下記の設定で「SampleEP-1」というポリシーを作りました。
- インシデントが発生した際に最初に「said」というユーザーに通知を送る
- 3分経っても応答がなかった場合には「said-sample1」というユーザーに通知を送る
- それでも応答がない場合にはこれらのエスカレーションルールを1度繰り返す
テスト用のサービスを作成して先ほど作成したエスカレーションポリシーを選択します。
作成したサービスとエスカレーションポリシーを対象にしたテストインシデントを作成しました。
1つ目のユーザー「said」に向けた通知はインシデント作成後すぐに来ました。
1つ目のアラート通知に対応せずに3分待つと今度は「said-sample1」に向けた通知が飛んできました。 しっかりとエスカレーションがなされています。
この後、2つ目の通知も対応せずにいるとまた「said」へ通知が飛んできたので、繰り返し設定もしっかり反映されていることが確認できました。
まとめ
今回はエスカレーションポリシーについて紹介しました。前回の統合（サービスの作成）の記事と併せ読んでいただければ、PagerDutyで通知のエスカレーションを行うことが可能になります。 例えば何人かの応答者に対して通知を送った後に、応答がなかった場合にはチーム全員に通知を行うなどのエスカレーションルールを追加して通知の見落としや対応までのタイムロスを減らすことが出来そうです。
PagerDutyは簡単に通知管理を行えるだけでなく、統合できるサービスやSaaSの数もかなり多いです。現状の通知管理に不安がある方エスカレーションの自動化に興味がある方はぜひ一度お使いのサービスやSaaSがPagerDutyと統合できるのか確認してみてはいかがでしょう。
