この利用ガイドではオンコール担当者(Responder)向けに、具体的なPagerDutyの利用方法を説明します。
インシデント対応前にどのような準備が必要になるのか、インシデント対応中と対応後にどのようなアクションが実行できるのか、網羅したつもりです。目次を一通り見ていただくと、PagerDutyで何ができるのか全体像を理解いただけるかと思います。
PagerDutyとは
2009年に米国で創業した「インシデント対応ソリューション」という分野を創った会社です。システム障害などの「インシデント」が発生した際に、AIや自動化を駆使して速やかな復旧と運用担当者の負担軽減を実現します。
様々な監視ツールやコミュニケーションツール、チケット管理ツール等が混在していたとしても、PagerDutyと連携させることでインシデントがシステム全体のどこに影響しているのか、リアルタイムで共有することができます。
また、対応履歴やMTTA/MTTRなどの運用指標が可視化されるため、継続的に運用プロセスを見直して改善するサイクルを回せるようになります。
インシデント対応前
自社のインシデント対応プロセスを確認する
重大インシデントの定義・その際の手順、インシデント対応中の体制・役割分担など、自社で決められたプロセスがあれば事前に目を通しておきます。
これからインシデント対応プロセスを整備する場合は、以下のドキュメントを参考にしてください:
PagerDutyユーザー登録
管理者がPagerDutyでユーザー登録を行うと、ユーザーにPagerDutyへのログインを案内するメールが届きます。
案内メール内の「Join Now」もしくはURLをクリックすると、ブラウザが開きパスワードの設定を求められます。パスワード入力後、電話番号やタイムゾーンなどの設定を促されるので、必要に応じて設定してください。
設定した内容は、後から変更可能です。
通知があれば、確実に気付けるよう準備する
PagerDutyに自分の連絡先(電話/SMS/Email/アプリ/Chat)を登録し、インシデントの緊急度(High-UrgencyまたはLow-Urgency)に応じて、どの連絡手段で通知を行うか設定します。
緊急のインシデントが発生した際に、すぐ気づけるようにしておくことが重要です。
具体的にはNotification Rulesの"When a high-urgency incident is assigned to me..."の箇所で、複数の連絡手段で1分毎に繰り返し通知が来るように設定します。
PagerDutyアプリは、スマートフォンのサイレントモード(Do Not Disturb)を無視するよう設定することも可能です。確実に通知音を鳴らしたい場合には、アプリで設定を有効にしてください。
モバイルアプリをインストールすると、PagerDuty電話通知の発信元番号が自動的にアドレス帳に登録・更新されます。PagerDutyから着信を受けた際、電話に出なくてもPagerDutyからの着信であることが分かるようになります。
なお、モバイルアプリは連絡帳へのアクセス権を要求しますが、これはPagerDutyの発信元番号をアドレス帳に追加する用途にのみ利用します。連絡先リスト内の番号に電話をかけたり、マーケティング等に利用することはありません。
オンコールスケジュールを確認する
My On-Call Shifts を利用すると、自分のオンコールスケジュールを確認できます。
Webアプリでは画面右上のアイコンの、プルダウンメニューから開くことができます。
もし変更が必要であれば、チームのメンバーと相談の上、スケジュールを変更します。
マニュアルでインシデントを起票する方法を確認する
最初にインシデントに気付くのが、監視ツールではなく、ユーザーや社員の場合もあります。何かが起こった場合に備えて、手動でインシデントを起票する方法を覚えておくと、解決までの時間を短縮するのに役立ちます。
PagerDutyでは、Webアプリやモバイルアプリの他、EmailやSlack/MS Teamsからもインシデントをトリガーすることができます。
参考: インシデントを起票する
インシデント対応中
インシデント対応に着手する - Acknowledge
PagerDutyから通知があり、自分が対応できる状況にあれば、まず行うことはAck(Acknowledge/確認応答)です。
Ackをしないと、インシデント対応に未着手とみなされ、繰り返し通知を受け取ることになります。一定時間を過ぎてもAckされない場合、バックアップの担当者に通知されます(自動エスカレーション)。
参考: インシデントをAckする
バックアップのオンコール担当者に対応を委任する - Escalate
PagerDutyから通知があった際、自分がすぐ対応できない状況であれば、Escalateを行います。Escalateの操作をすることにより、Escalation Policyに従って、次のオンコール担当者に通知が行われます。
応援を要請する - Add Responders 1
他のメンバーや専門家と一緒にインシデント対応を行う場合は、Add Responders機能で応援を要請することができます。
Add Respondersボタンをクリックし、UserまたはEscalation Policyを選択して、招集するメンバーを指定します。
他チームに対応を委任する - Reassign
他のメンバーやチームに対応を任せる場合は、Reassignが利用できます。
Add Respondersは引き続き自分もResponderとして対応を継続しますが、Reassignは自分がResponderから削除され、Reassign先のチームが対応を引き継ぎます。
Reassignを行うと、インシデントの状態がTriggeredに戻ります。
参考: インシデントの再割り当て
対応を一時保留する - Snooze
すぐに対応する必要がなく、後で対応を行う場合は、Snoozeを利用できます。
Snoozeを行う場合は、時間を指定します。指定した時間が経過した後は再度通知が行われるため、インシデントが対応されないまま放置されることを防げます。
Snooze後の通知は、現在のResponderに加えて、その時点のオンコール担当者にも送られます。
参考: インシデントのSnooze
アラートの内容を確認する
インシデントに紐づいているアラートの情報を確認し、どんな事象が発生しているのか調査します。
参考:
インシデントを統合/分割する
異なるアラート(監視項目)であっても、同じ原因により発生したのであれば、1つのインシデントにまとめて管理したい場合があります。その際は、別々のインシデントを1つに統合することができます。
参考: インシデントを統合(マージ)する
逆に、同じインシデント配下にあるアラートを他のインシデントに移動させることも可能です。
Intelligent Alert Grouping2を利用している場合は、上記の操作によってAlert Groupingのルールが更新されます。
参考: AIにフィードバックを行い、Grouping精度を高める
解決のヒントを得る
対応に関する指示や手順を確認する - Incident Notes
インシデントのNotes欄には、対応に関する注意事項や指示、手順書へのリンクなどが記載されている場合があります。
インシデント詳細画面を開き、Notesに指示等の記載があるか確認してください。
AIアシスタントを活用する - PagerDuty Advance 1 3
PagerDuty Advanceを利用すれば、PagerDutyに連携された様々なデータから、インシデント対応に必要な情報を速やかに取得することができます。
PagerDuty Advanceへの問いかけの例
- 「何があったの？」> インシデントの概要、影響を受けている関連サービス、過去の類似インシデントでの復旧手順2等
- 「最近の変更は？」> 最近のコード・構成変更の情報(Recent Changes2)
- 「誰がオンコール中？」> 現在のオンコール担当者名
インシデントの発生頻度を知る - Outlier Incident 2
類似するインシデントの発生頻度を3つのラベルに分類し、インシデント詳細画面のタイトルの下に表示します:
- Frequent: 過去30日間にサービス上で発生したインシデントのうち、20%以上を占めるインシデント
- Rare: 過去30日間にサービス上で発生したインシデントのうち、5％以下のインシデント
- Anomaly: 過去30日間にサービス上で発生したことのないインシデント
参考: Outlier Incident
過去の類似インシデントから対応のヒントを得る - Past Incidents 2
現在調査中のインシデントと類似した過去のインシデント5件と、過去6ヶ月の類似インシデント発生頻度が表示されます。
過去のインシデントのタイトルをクリックすると、その際の対応履歴を確認できます。
参考: Past Incidents
依存関係のある他サービスの状態を把握する - Service Graph
他サービスと依存関係がある場合、他サービス側の問題がインシデントの原因になっていることがあります。
関連するサービスの状態や発生している問題を確認することで、必要に応じて他チームとの連携を行い、原因特定を速やかに行うことができます。
Service Graphを開くには、上部メニューの Services > Service Graph をクリックするか、インシデント詳細画面でTechnical Service Dependencies欄内のView Service Graphボタンをクリックしてください。
参考: Service Graph
関連がありそうな他のインシデントを知る - Related Incidents 2
現在進行中の他インシデントのうち、調査中のインシデントに関連がある可能性のあるものを確認できます。
前述のService Graphでも表示される、依存関係のあるサービスで発生しているインシデントに加えて、発生時間が近く・内容が類似したインシデントもリストされます。
どのインシデントから着手すべきか見極める - Probable Origin 2
過去6ヶ月のインシデントが連鎖的に発生するパターンを分析し、現在調査中のインシデントの起点となる可能性が高いインシデントやサービスを提案する機能です。
複数のインシデントが同時発生している場合に、提案されたインシデント・サービスから調査を行うことで、速やかに原因に辿り着く可能性が高まります。
参考: Probable Origin
最近のコード・構成変更の情報を調べる - Recent Changes 2
コードやインフラ構成の変更など、Production環境に対して行った変更がインシデントの原因になる場合があります。(PagerDuty社内の統計では、約50%のインシデントが "変更" に起因しています。)
GithubやAnsible,ServiceNowなどの構成管理ツールを利用している場合、それらのツールをPagerDutyと連携させておくと、最近の構成変更の情報をインシデント詳細画面に表示することができます。
インシデント詳細画面には、関連が高いと推測される3つの変更が表示されます。その他の変更についても確認したい場合は、View Allをクリックしてください。
参考: Change Events
関係者に状況を共有する - Status Updates/Internal Status Page 1
インシデントの状況と影響範囲について、関係者に共有することは重要です。適切に状況が共有されると、インシデント対応チームは状況問い合わせへの対応ではなく、解決のための活動に集中することができます。
PagerDutyでは、20〜30分毎にStatus Updateを行うことを推奨しています。
影響範囲を修正する
Impacted Business Services欄には、依存関係のあるBusiness Serviceが関連付けられています。影響を受けているBusiness Serviceに過不足があれば、追加・削除を行います。
Subscriberを追加する
Status Updateを受け取る関係者を追加します。Managed Subscribersボタンをクリックすると、UserもしくはTeamを選択してSubscriberに追加できます。
Status Updateを作成・送信する
+New Updateボタンをクリックすると、Status Updateを作成・送信できます。
Status Updateテンプレートで事前に雛形を用意しておくと、スムーズに作成・送信が可能です。
Internal Status Page(上部メニュー Services > Internal Status Page)では、各Business Serviceの状況と、影響を与えているインシデント・最新のStatus Updateを確認することができます。
対応履歴を記録に残す - Add Note
インシデント対応の記録を残しておくことは重要です。振り返り(ポストモーテム)の中で運用プロセスの改善に利用したり、類似インシデントが発生した際の迅速な解決に役に立ちます。
Ops Guide: Incident Responseでは、インシデント対応の際にScribe(記録係)を任命し、対応履歴を残すことを推奨しています。
Notesは、Webアプリやモバイルアプリの他、SlackやMS Teamsからも追記することができます。また、JIRAやServiceNowと連携していれば、Notesの内容は双方向で同期されます。
なお、PagerDutyで行った操作の多くは、Timelineに自動記録されます。
記録係は、インシデントコマンダーが指示した内容や、決断、新たな発見、ToDoなど、重要なアクションを記録するようにしてください。
参考: インシデントにノートを追加する
自動診断・自動復旧を行う - Run Automation 1 4
ログの確認やサーバーの再起動など、インシデント対応に必要な作業をAutomation Actionに登録しておけば、担当者が選択して実行させることができます。
Webアプリから実行する場合は、インシデント詳細画面からRun Actionボタンをクリックし、実行するActionを選択します。
SlackやMS Teamsから操作する場合は、Run an Actionボタンをクリックしてください。
参考: PagerDuty Automation Actions
ワークフローを呼び出す - Incident Workflow 1
Incident Workflowを設定しておくと、インシデントのステータスに応じてワークフローを自動実行したり、担当者が1クリックで実行することができます。
例えば「インシデントのPriorityがP1になった際、War Room(緊急対策本部)を設置」等に利用できます。
追加の担当者の招集、Status Updateの送信や、Zoom会議の作成、Slackのインシデント専用チャンネルの作成、AWS Lambdaの実行5、30分毎にSlack Messageでリマインドを送る5等、様々な操作を一括で行うことができます。
Webアプリから実行する場合は、インシデント詳細画面で Run Workflowボタンをクリックします。
インシデント対応に関わるメンバーの役割と責任を明確にする - Incident Roles 5
インシデント・コマンダー、記録係などのインシデント・ロールを事前に定義しておくと、メンバーにロールを割り当てることができます。メンバーの役割を明確にしておくことで、インシデント対応を効率的に進めることができます。
インシデント・ロールの割り当ては、Webアプリの他、Slackからも行うことが可能です。
参考:
メンバーにタスクを割り当てる - Incident Tasks 5
インシデント・タスクをメンバーに割り当て、進捗を追跡することで、インシデント管理を強化することができます。
インシデント・タスクの作成・割り当ては、SlackまたはIncident Workflowsで行います。
参考: Incident Tasks
インシデント対応後
インシデントのステータスをResolvedに変更する
インシデントが解決したら、インシデントのステータスをResolvedに変更します。
Resolveボタンをクリックするとポップアップ画面が開き、Resolution Noteを記入することができます。"Post resolution note as a status update"にチェックをいれると、記入した内容をStatus Updateとして関係者に共有します。
ポストモーテムレポートを作成する 1
インシデント対応から学びを得て、運用プロセスを改善するには、ポストモーテムを行います。
PagerDutyでは、SlackやIncident Notesに残された情報から、簡単にポストモーテムレポートのドラフトを作成する機能があります。
インシデントのステータスをResolvedにした後のポップアップ画面、または上部メニューの Incidents > Postmortems > "+ New Report" から、レポート作成画面を開くことができます。
PagerDuty Copilotが有効になっていれば、生成AIがレポートの草稿を自動生成することもできます。(現在は英語による出力のみ)
ポストモーテムレポートに含める項目は自由に変更できる他、Incident TimelineやNotes、Slackに残された履歴をインポートして、簡単に対応履歴を作成することができます。
参考:
対応プロセスを改善する
インシデント対応で得た学びを元に、必要に応じて運用プロセスを修正します。
再発防止策に加えて、手順書の修正・Escalation Policy/Notification Rulesの変更・エスカレーションをためらわないようチームに周知する、などの対応が必要かもしれません。
今後も繰り返し発生する可能性のある作業については、自動化することも有効です。
Event Orchestration2やRunbook Automation4等を利用して自動化ができないか、検討してください。
FAQ
Q.PagerDutyアプリをスマートフォンにインストールしたのですが、Notification Rulesでアプリが選択肢に出てきません。
PagerDutyアプリを開いて、ログインしてください。
また、アプリの通知が有効になっているか確認してください。PagerDutyアプリの通知がスマートフォンで無効になっていると、Contact MethodsやNotification Rulesにモバイルアプリが表示されません。
参考: PagerDutyモバイルアプリ
Q.インシデントのステータスと各種操作の関係を教えてください。
PagerDutyでは、以下3つのステータスでインシデントを管理します。
- Triggered: インシデントが起票されたときのステータスで、まだ担当者が確定していない状態です。通知を受けたオンコール担当者がAck(確認応答)をすると、次のAcknowledgedに遷移します。Triggered状態のHigh-Urgencyのインシデントは、Escalation Policyに従って自動エスカレーションされます。
- Acknowledged: 担当者が確定し、現在対応中のインシデントです。インシデントが解決すると、Resolvedに遷移します。
- Resolved: 問題が修正され、インシデントが解決した状態です。ResolvedになったインシデントをTriggeredやAcknowledgedに戻すことはできません。
ステータスの遷移にはユーザーによる操作の他、アラートのステータスが関係します。
インシデントに紐づくアラートが全てResolvedになれば、インシデントのステータスもResolvedになります。逆に、インシデントのステータスがResolvedになると、そのインシデントに紐づくアラートのステータスもResolvedに変更されます。
Q.誤ってIncidentをResolveしてしまいました。StatusをTriggered等に戻せますか?
一度Resolvedになったインシデントを、TriggeredやAcknowledgedに戻すことはできません。新しくインシデントを起票してください。
Q.オンコールの度に、オンコールを知らせるメールが送られてきます。止める方法はありますか?
Notification Rules内の Before I go on-call or off-call... で設定が可能です。
Notification Rulesは、Webアプリ右上のユーザーアイコン > My Profile から開くことができます。
参考: ユーザー毎の通知先とNotification Rulesの設定
Q.Escalation PolicyのTimeoutを過ぎても、自動エスカレーションされません。
UrgencyがLowのインシデントは自動エスカレーションされません。Escalation Policy内の最初レイヤーのメンバーにのみ通知されます。
Q.Escalation PolicyのTimeoutが5分、Notification Ruleは10分までの設定がある場合、どのような動きになりますか?
Escalation Policy Timeoutが発生すると、通知先がEscalation Policyの次のレイヤーに移ります。つまり、5分以降のNotification Rulesの通知は行われません。
Q.アラートを送ったはずですが、PagerDuty上で見つかりません。
SuppressやSuspend(通知の一時停止/Pause)されたアラートは、インシデント一覧画面には出てきません。アラート一覧画面(上部メニュー: Incidents > Alerts)に表示されないか、確認ください。
監視ツールから複数回Eventを送信しても、同一のアラート(監視項目)の場合は、1つのアラートにまとめられます。Email連携であればメールの件名、Event API連携であればdedup_keyを参照し、値が同じであれば同一のアラートと判断します。
同一のアラートに属するEventは、アラート詳細画面のAlert Logで確認できます。
参考: