PagerDutyでのインシデント管理¶

はじめに¶

EponaではOperation-Lessの観点から、SaaSの利用を推奨しています。
本ガイドでは、PagerDutyというSaaSによるインシデント管理について記載します。

PagerDutyについて¶

システムが成長していくに従って、複数のアプリケーションやSaaSが組み合わさるようになると、運用面で以下のような課題が起きがちです。

複数の監視ツールからバラバラにアラートが届き、それぞれの監視ツールの画面を見てメッセージを確認しなければならない
発生内容を目で見て、誰に連絡を取るかをオペレーターが逐一判断しなければならない
夜間休日など連絡がつきにくい場合に、オペレーターが手動で何度も電話をかけなければならない
連絡が取れたのか、現状誰が対応しているのかが、連絡をした当人達にしかわからない

PagerDutyを導入することで、複数のツールからのアラートを集約し、適切な担当者へ自動的に通知（電話、SMS、メール、モバイルアプリ）することが可能になります。これにより、以下のようなメリットがあります。

アラートをPagerDutyに集約できる。これにより「まずはPagerDutyを見ればよい」と最初のアクションを統一できる
発生内容、発生箇所に応じた担当者へ自動的に連絡できる
連絡が取れない場合、他の連絡方法（電話に出なければSMSなど）に切り替えたり、他の担当者に掛け直すなどの対応が自動的に行われる
PagerDutyのWeb UIを見ることで、誰が応答・担当しているのか状況を把握できる

機能の詳細については製品のサポートページをご参照ください。

前提事項・事前準備¶

本ガイドにおいては以下の準備ができていることを前提とします。

PagerDutyユーザー登録が済んでいること

なお、設定例ではDatadogからのアラートを受け取る例を紹介しています。こちらを実施する場合には以下の準備が必要となります。

Datadogユーザー登録が済んでいること

設定後のイメージ¶

Pageduty設定後のインシデント管理の流れは以下のとおりです。

Datadogからメトリクスのしきい値超えやエラーログなどのアラートがPagerDutyに送られます
PagerDutyは受信したアラートをもとに連絡先を判断し、順番に通知します。このとき、インシデント情報も作成されます
通知を受け取ったユーザーは、PagerDuty上のインシデント情報を参照し、ステータスを更新します - インシデントのステータスについてはこちらを参照してください
問題が解消したら、インシデントのステータスを更新して、インシデントをクローズします

クイックスタートガイドでは、ユーザー -> オンコールスケジュール -> エスカレーションポリシー -> サービスの順に設定するよう解説されていますので、ここでも同様の順に記載します。

ユーザー¶

PagerDutyにユーザーを追加するには、権限のあるユーザーでログインし、招待メールを送付する必要があります。ユーザーを追加する手順についてはこちらを参照してください。
招待メールを受け取ったユーザーは、パスワード及びユーザープロファイルを設定します。ユーザープロファイルの情報としては、主に連絡先（Contact Information）と通知ルール（Notification Rules）を設定します。

役割¶

各ユーザーに設定できる役割（権限）の内容についてはこちらを参照してください。

利害関係者（サービス利用者やお客様）用にインシデント情報の参照のみのユーザーを作成する機能もあります。
この機能により、状況を個別に連絡しなくとも、PagerDutyを参照していただくだけで情報共有が可能となります。
なお、この機能を利用する場合はビジネスプランもしくはデジタルオペレーションプランでの契約が必要となります。詳細はこちらをご確認ください

連絡先（Contact Information）¶

電話番号、SMS、メール、モバイルアプリを設定できます。
なお、着信は海外からとなるため、電話番号、SMSについては国コード「+81」付きで設定してください。

通知ルール（Notificaton Rules）¶

複数の連絡方法がある場合に、どの連絡方法を使うかを設定できます（まずメールで通知して、10分間応答がなければ電話をかけるなど）。
また、インシデントの緊急度によって連絡方法を変えることもできます（緊急度が低いものはメール、高いものは電話など）。
他には、自分がオンコール（インシデント連絡を受ける）状態になることを忘れないよう、事前にリマインドするような設定（オンコールバックオフ）も可能です。

オンコールスケジュール¶

オンコールスケジュールではユーザーの担当日・担当時間を設定します。

基本的には、ローテーションタイプ（週次／日次など）とハンドオフ時間（交代時間）の設定で作成できます
ユーザー・ローテーションタイプ・ハンドオフ時間を設定すると、PagerDuty側でオンコールシフトを自動的に割り当てます
ただし、自動割当では24時間年中無休の想定で割り当てられるため、平日／休日や日中／夜間など細かく制御する場合はスケジュールの制限にて設定してください
平日と休日でローテーションを分けるような場合はスケジュールレイヤーを分けることで設定できます

エスカレーションポリシー¶

エスカレーションポリシーでは、サービスで発生したインシデントを、誰にどの順番で連絡するかを設定します。

連絡先としては、オンコールスケジュールまたはユーザーを指定可能です
連絡順のことをレベルといいますが、同一レベルには5人（または5スケジュール）を設定可能です
インシデントがトリガーされると、PagerDutyはエスカレーションポリシーの最初のレベルに通知しようとします
- オンコールスケジュールが指定されていた場合は、その時間帯にオンコールとなるユーザーをPagerDutyが自動的に判断し、そのユーザーに通知します
通知後、一定期間内にインシデントが確認されない場合、インシデントは次のレベルにエスカレーションされ、以下同様に続きます
もし最後までエスカレーションしてもインシデントが確認されない場合、再度最初のレベルから連絡し直すよう設定できます
次のレベルにエスカレーションするまでの時間（タイムアウト時間）や、最初のレベルから連絡し直す回数は、エスカレーションポリシーの画面で設定可能です

注意事項¶

オンコールスケジュールおよびエスカレーションポリシーの設定に関して、いくつか注意点があります。

オンコールスケジュール内でオンコールとなるのは1ユーザーのみ¶

たとえば、シフトを組んでインシデントの実対応をする担当者とは別に、発生したことを常に知っておきたい人がいたとします。
PagerDutyではスケジュールレイヤーという、サイクルが違うスケジュールを層（レイヤー）を分けて登録する設定がありますので、それを使って以下のようにスケジュールを設定したとしましょう。

レイヤー１：担当者A…インシデント連絡を常に受け取りたい担当者（常にオンコール）
レイヤー２：担当者B/C/D…交代でインシデント実対応をする担当者（1日交代でオンコール）

しかし、このように設定したとしても、担当者Aに通知されることはありません。

PagerDutyの仕様上、ある時間帯にオンコールとなるのは1ユーザーのみであり、同一時間帯に複数のユーザーが重なっていた場合は、画面上最も下のレイヤーのユーザーが使用されるからです。

上の例で上下を逆にした場合、担当者Aには通知されますが、担当者B/C/Dには通知されなくなります

最終的に誰に連絡されるかは画面上のFinal Scheduleに表示されていますので、そちらを確認してください。

同一時間帯に複数のユーザーに通知したい場合は、ドキュメントで紹介されているように、個人別のオンコールスケジュールを作成してエスカレーションポリシーに設定する必要があります。

オンコールとなっているユーザーが1人もいない場合、インシデントは作成されない¶

スケジュールの制限などで個別にスケジュールを設定すると、スケジュール間に隙間のできる場合があります。
この隙間の時間帯にインシデントが発生した場合、該当レベルはスキップされて次の連絡先にエスカレーションされます。ただし、最後まで行ってもオンコールとなっているユーザーが見つからない場合は、インシデントは作成されません （参考）。
最終的に、いつ誰がオンコールとなるのかはエスカレーションポリシーの設定画面のScheduleタブなどで確認できますので、忘れずに確認してください。

サービス¶

サービスは、インシデントの発生元となるアプリケーションやコンポーネント等を指す概念です。
サービスの設定では、システムがどのようなサービスによって構成されるのか、各サービスがどんなイベントに対して誰（エスカレーションポリシー）に連絡するかを設定します。

インテグレーション¶

PagerDutyでは様々な外部サービスとのインテグレーションを行うことができ、別サービスからのインシデント作成、別サービスへのインシデント通知といったことが可能になります。

インシデントの作成¶

PagerDutyでは、以下のようなツールと統合して、インシデントを作成可能です。

外部サービス（インテグレーション）
AWS CloudWatchやDatadogなどからのイベントを検知します。統合可能なサービスについてはインテグレーションライブラリを参照してください
電子メール
電子メールをトリガーとしてインシデントを発生させることが可能です。詳細はメール統合ガイドを参照してください
API
PagerDutyのAPIを直接コールしてインシデントを発生させることが可能です。詳細は開発者用ドキュメントを参照してください

ガイドの後半にDatadogと統合する場合の設定例を記載していますので、あわせてご確認ください。

インシデントの通知¶

インシデント連絡はユーザーの連絡先宛に行われますが、拡張機能を使うことでチャットツールなどの外部サービスへの通知ができます。 EponaでサポートしているSlackやMicrosoft Teamsに対する通知ももちろん可能です。

イベントルール¶

インテグレーションから受け取ったイベントの内容に基づいて、インシデントの発生を抑止したり、重大度を割り当てるなどのルールを設定できます。
詳細はサービスイベントルールを参照してください。

なお、ここで設定できる「重大度」と、インシデントの「緊急度」は別の概念です。詳細はこちらを参照してください

アサインと通知¶

誰に通知を送るかを設定します。以下のような項目を設定可能です。

通知先となるエスカレーションポリシー¶

どのエスカレーションポリシーでインシデント連絡するかを指定します。

緊急度¶

インシデントの緊急度を設定できます。なお、デフォルトではすべて緊急度「高」となります。以下のような設定が可能です。

緊急度を一律に設定（高または低）
発生時間帯に応じて高／低を切り替え
イベントの重大度に応じて高／低を切り替え

ユーザーの通知ルールで緊急度別の連絡方法を設定していた場合には、ここで判定した緊急度により連絡先が決定されます。

未解決インシデントに対するアクション¶

インシデントが放置されないよう、確認応答のタイムアウトや自動解決の設定が可能です。なお、デフォルトではいずれもオフとなっています。

確認応答のタイムアウト
インシデントが放置されないように、確認応答後、一定時間経過しても解決しない場合はリマインドするよう設定できます
- エスカレーションポリシーにもタイムアウトの設定がありますが、これは確認応答が「ない」場合にいつまで待つかを設定するものです。
  これに対して確認応答のタイムアウトとは、確認応答が「あった」場合に、解決までどれくらい待つかを設定するものです

自動解決
インシデントが一定時間更新されない場合に、自動的にステータスを更新するよう設定できます

設定例¶

ここでは、Datadogのアラートを受け取ってインシデントを発生させる例を紹介します。詳細な設定手順についてはこちらを参照してください。

PagerDuty側でデフォルトのエスカレーションポリシーを設定しておく¶

事前準備として、PagerDuty側のエスカレーションポリシーを設定しておきます。これがないとインシデント通知を受け取れません。
[People]-[Escalation Policies]でエスカレーションポリシーの設定画面が表示されますので、 Notifyに通知を受け取れるユーザーを設定してください。
デフォルトではメールアドレスが有効になっていると思われますので、問題なければそのままユーザーを指定してください。

PagerDuty側でDatadogと接続するサービスを作成する¶

まずPagerDuty側で、Datadogと統合するサービスを作成します。
メニュー[Services]-[Service Directory]をクリックしてService Directory画面を表示します。 +New Serviceでサービスの登録画面を表示します。
Nameに任意の名称（ここではDatadog testとしておきます。この名称は後で使いますので控えておいてください）を入力します。
Integration typeのプルダウンでDatadogを指定します。その他の項目は初期設定で構いませんので、[Add Service]でサービスを作成します。

登録後、[Integrations]タブのIntegrationsでDatadogのIntagration Keyが発行されていることを確認してください。

Datadog側でPagerDutyとのインテグレーションを設定する¶

続いてDatadog側で、PagerDutyとの接続設定を行います。
メニューの[Integrations]-[Integrations]をクリックしてIntegrations画面を表示します。検索バーでPagerDutyと入力し、表示されるアイコンの+Install（2回目以降は+Configure）を選択します。

Configurationタブをクリックし、Alert With PagerDutyをクリックします。 PagerDutyの認証画面が表示されるので、PagerDutyのログインID/PWDでログインします。

Configure the Datadog integration.という画面が表示されます。
今回は先にPagerDuty側のサービスを作成しておいたので、Use an integration on an existing serviceで、先程作成したサービス名を選択します。
選択したらFinish Integrationで設定を終了します。

DatadogのIntegrations画面が表示されます。すでにサービス名やIntegration Keyはセットされているので、そのままUpdate Configurationで設定を終了します。

DatadogのアラートでPagerDutyのインシデントを発生させる¶

DatadogのアラートでPagerDutyのインシデントを発生させてみます。なお、アラートの詳細に関してはこちらもあわせて参照してください。

Datadogのメニューで[Monitors]-[New Monitor]をクリックします。Monitorの種類は任意ですがここではLogsを使用します。

このMonitorはしきい値超えによりアラートを発生させるため、Set alert conditionsで任意のしきい値を設定します。ここではAlert thresholdを10、Warning thresholdを5にします。

Say what's happeningのEditタブでアラートのタイトルを設定しておきます。名称は任意ですがPagerDuty testとしておきます。

Notify your teamにPagerDutyの宛先を指定します。先程作成したサービス名で@pagerduty-SERVICE_NAMEという宛先が選択できるようになっていますので、それを選択します。

Test Notificationをクリックすると発生させるアラートの種類を選択できます。任意ですがAlertを選択してRun Testをクリックします。

PagerDutyにログインし、インシデントが作成されることを確認してください。また、事前に設定したエスカレーションポリシーのユーザーに通知が送られていることも確認してください。

通知を受けてからの流れ¶

PagerDutyから実際にインシデント連絡を受け取った後の流れは、以下のようになります。

インシデントのステータスをTriggered->Acknowledgedに更新する
インシデント情報を確認する - 必要に応じてインシデント元（Datadogなど）の情報を参照したり、別の担当者にアサインし直す
問題が解消したらインシデントのステータスをResolovedに変更する

公式ドキュメントのインシデントのライフサイクルもあわせてご参照ください。

インシデントのステータスについて¶

インシデントにはステータスがあり、PagerDutyはステータスによって通知を続けるかどうかを判断しています。

発生したインシデントはTriggeredというステータスになっており、このステータスである限り、インシデントはエスカレーションポリシーに従って通知され続けます。

通知を受領したユーザーがステータスをAcknowledgeにすることで、インシデントのエスカレーションは止まります。ただし、Web UIからステータスをTriggeredに戻すことができ、その場合は再度最初から通知をやり直します。

ステータスがResolvedになったインシデントに関しては、ステータスを変更したり、再度通知を送ることはできません。

公式ドキュメントの説明もあわせて参照してください。

公式ドキュメント上明記されていませんが、同一タイトルのインシデントは、最初のインシデントがResolvedされるまでは再作成されません

インシデント連絡の受領〜ステータスの更新¶

通知を受領したユーザーは、インデントのステータスを更新します。

SMSが届いたり電話に出ただけでは、ステータスはAcknowledgedにはならず、一定時間経過するとインシデントは次のレベルへエスカレーションされます
設定によっては、同時に複数の経路（電話とSMSなど）で通知されることもありますが、どれか１つで対応すればOKです
ステータスはResolvedが優先されます。電話でResolvedしたあと、SMSでAcknoledgedしたとしても、ステータスはResolvedのままです

ステータスはWeb UIで更新できますが、通知を受けた際の操作でも更新可能です。詳細は公式ドキュメントの通知の内容と動作を参照してください。

インシデント情報の確認¶

Web UIでインシデントの詳細情報を確認できます（モバイルアプリでも一部の情報が参照できます）。

インシデント一覧¶

Web UIの[Incidents]メニューを選択すると、現在発生しているインシデントの一覧が表示されます。

Open: ステータスがTriggered, Acknowledgedのインシデントが表示されます
Triggered: ステータスがTriggeredのインシデントが表示されます
Acknowledged: ステータスがAcknowledgedのインシデントが表示されます
Resolved: ステータスがResolvedのインシデントが表示されます
Any Status: 全インシデントが表示されます

インシデント一覧のTitle欄の右下の#にインシデント番号が表示されていますので、その番号でインシデントを特定してください。インシデント一覧の右上にあるGo to Incident #で直接表示もできます。
また、自分がアサインされたインシデントのみ表示したいときはAssigned to meを選択してください。

インシデント情報（単票）¶

Alertsに、PagerDutyがインシデントを発生させる原因となった情報が表示されています。通知元がDatadogの場合、画面下部のLINKSやCLIENTのリンクによりDatadogの画面に遷移し、メトリクスやログの詳細を確認できます。

Timelineにインシデントに関する操作履歴が表示されています。対応経緯など確認したいときに参照してください。

画面右のNotesに、調査した内容などのメモを残すことができます。ここに記入した内容はTimelineにも表示されるため、Timelineに情報を集約できます。

インシデント対応が完了したら、ステータスをResolvedに変更します。画面右上のResolveをクリックしてください。

インシデントの委任¶

他のユーザーに対応を委任する場合はReassignをクリックしてください。Search for an Escalation Policy, User, Levelと表示されているテキストボックスを選択すると、委任先を指定できます。

Escalation Policy
指定したエスカレーションポリシーの先頭からインシデントを通知します
User
指定したユーザーにインシデントを通知します
Level
現在のエスカレーションポリシー内の指定したレベルにインシデントを通知します

詳細は公式ドキュメントを参照してください。

その他の操作については公式ドキュメントのインシデントの編集を参照してください。

インシデントのレポート¶

Web UIの[Analytics]メニューにより、インシデントの発生件数や対応時間に関するレポートを表示できます。
詳細は公式ドキュメントの基本的なレポートを参照してください。

※ このドキュメントはクリエイティブコモンズ(Creative Commons) 4.0 の「表示—継承」に準拠しています。

※ このドキュメントに記載されている会社名、製品名は、各社の登録商標または商標です。