はじめに
私自身がPagerDuty入門するために最低限知っておきたい基本をおさえるために書きましたが、PagerDuty入門する方の一助になれば幸いです。
1. 基礎知識
PagerDutyとは
-
インシデント管理・アラート通知サービス
-
なぜ必要か
- システムは絶対にいつか壊れる
- 壊れたときに「即座に気づき」「最短で復旧」できる体制が命綱になる
- そのような体制を構築するために、PagerDutyでは最初に動く人（On‑Call）を決めて、通知して、対応を標準化する仕組みを持っています
- 以下のような状況を防ぐことが可能です
- 誰も気づかない or 24 時間モニターに張り付く
- 気づいても誰が動くか曖昧
- PagerDuty自体には「監視」の機能はない
- 監視機能を持つあらゆるツールと連携し、それらから受け取るアラートを元にインシデントを検知することができる
-
通常のアラートツールとの違い（オンコール管理、エスカレーション）
観点 通常のアラートツール PagerDuty（インシデント管理ツール） 目的 単に「異常があるよ」と通知する 「異常が起きた → 誰が対応する → どう解決する」を管理する 役割 アラート発砲・可視化 インシデントの責任者決定、通知、エスカレーション、復旧指揮 流れの管理 通知したら終わり インシデント対応全体のライフサイクルを管理 エスカレーション 基本なし（手動） 自動エスカレーション（誰も反応しない場合、次の担当へ） On‑Call管理 手動／外部ツール依存 組み込みでスケジュール・ローテーション管理できる 複雑なルーティング 難しい（モニタリングツール側で頑張る） ルールベースで細かく通知先・優先度を制御できる 対応記録（履歴） 基本ない 誰がいつ何をしたか対応履歴が残る ポストモーテム サポートされない 対応後の事後分析フローまで組み込み可能 SLA／SLOサポート 直接対応なし MTTA, MTTR など指標管理・改善サイクルを回せる
-
-
つまり、「検知」だけじゃなく「対応・解決まで含めた本格運用」を担っているのが PagerDuty
-
通常のアラートツールの例
ツール 役割 CloudWatch Alarm AWS リソースの閾値超えアラート Datadog Monitor メトリクスベースアラート、通知まで Prometheus Alertmanager アラートをルーティング・グルーピング
基本コンポーネント
サービス（Service）
-
障害検知とインシデント管理の単位
例 Service で管理するもの API サーバ（api.example.com） この API が異常になったら誰が対応するか管理 DB サーバ（Aurora DB Cluster） DB 接続エラー時に特定チームへ通知する設定 課金システム（Billing Service） 課金障害が起きたら即対応チームへエスカレーション モバイルアプリ通知基盤（Push Notification Service） プッシュ通知遅延・失敗時に即対応する -
Service に設定できるもの
項目 説明 Integration どこからアラートを受け取るか（Datadog, CloudWatch, Prometheus など） Escalation Policy 誰に通知するか、反応がなかったら次に誰に通知するか Alert Grouping 似たアラートをまとめるか（ノイズ削減） Severity（重大度） インシデントを SEV‑1, SEV‑2, SEV‑3… に自動分類するか Response Plays 定型の対応手順（例：Slack 通知 → Jira チケット自動作成） Webhook 外部システムへの通知設定（例：社内チャット、他ツール連携） -
PagerDuty でアラートを受け取る基本ステップ（Service Integration）
-
Service を作成する（または選択する）
- どの Service でアラートを受け取るか決める（例：
API Server Serviceなど）。
- どの Service でアラートを受け取るか決める（例：
-
Integration（連携設定）を追加する
- Service 内で「どこからアラートを受け取るか」を登録。ここが超重要！
-
モニタリングツール側で連携設定をする
- Integration で発行された API Key／Endpoint URL を使って、モニタリングツールから PagerDuty へアラートを送る
-
-
具体例：Datadog 連携手順（Service Integration）
-
PagerDuty で Service を作成
- 「Services」→「+ New Service」
- 作成方法
- Integrationでdatadogを選択する必要がある
- 作成されたServiceのIntegrationにIntegration Key／URL が発行されていて、これをDatadogのモニタに登録することでPagerDutyとDatadogの紐付けが可能
- PagerDutyのServiceとDatadogのモニターの紐付けはDatadog側で行うことになるということです
-
Datadog 側で設定
- Datadog Integration GuideのIn Datadogを参照してください
- DatadogのモニターとPagerDutyのServiceの紐付けの方法
-
-
具体例：Datadog 連携手順（Global Integration）
- Event Orchestrationを使って設定することもできる
- PagerDuty 設定ガイド (検知編2) - Global Integrationの設定
-
よくあるミス注意
- Integration Key を間違える → アラートが PagerDuty に届かない
- モニタリングツール側で通知条件を忘れる → 異常が起きてもアラートが飛ばない
- Service と Escalation Policy を紐付け忘れる → アラートは届くけど誰にも通知されない
インシデント（Incident）
-
インシデントライフサイクル
ステータス 概要 Triggered 監視システムからイベント受信してインシデントが作成された状態 Acknowledged 担当者が ack して(インシデントのステータスをAcknowledgedに変えること)対応中を宣言した状態 Resolved 事象を復旧し Resolvedした状態 -
インシデントライフサイクル詳細
-
Triggered（発生）
- 監視システムからのアラートにより自動でインシデントが作成される
- 割り当て先（通知先）はエスカレーションポリシーによって決定
- 通知手段：プッシュ通知、電話、Slack、メール、SMSなど
- 通知ルール設定はこちら
-
Acknowledged（認識）
- 担当者がack（受領）することで対応中を宣言
- エスカレーションが停止される
- 確認タイムアウトまでに解決されなければ、再度Triggeredに戻り通知が再開
-
Resolved（復旧）
- 障害が解消されたらResolvedステータスでクローズ
- 対応履歴は記録され、ポストモーテムなどに活用可能
-
ルーティング（Routing）
オンコールスケジュール
オンコールとは
- インシデント発生時に即対応すること
- 深夜・休日も含めて「この時間帯はこの人が責任持って見てます」体制を整える必要がある
オンコールスケジュールとは？
-
誰がいつ対応するかを PagerDuty の Schedule で管理することができます
-
設計パターン例
パターン 内容 特徴 1週間交代制 1人が 1週間オンコール 安定・週明けでローテ 1日交代制 毎日担当者が変わる 負担を細かく分散 シフト制 日勤／夜勤などに分ける 24時間体制向き 休日専用ローテ 土日祝だけ専用 On‑Call 平日と休日で体制分離 -
オンコール運用で意識すべきポイント
項目 内容 スケジュール透明化 誰が今 On‑Call か全員が見えるように シフトの公平性 負担が偏らないようローテーション設計 Runbook 整備 迷わない対応手順書を整備 インシデント自動化 検知・初動を自動化し負担軽減 休息確保 On‑Call 明けは休憩を取らせバーンアウト防止
On-call Scheduleの作成方法
エスカレーションポリシー
基本概念
- インシデーションポリシーは、複数のエスカレーションルールで構成
- ルール数は最大 20 個、推奨は最低 2 つ
- 各ルールには少なくとも 1 つのターゲット（ユーザー or スケジュール）が必要
- 個人を直接ターゲットにしない（属人化リスク）
動作フロー
- インシデント発生時、最初のルールで通知を試行
- エスカレーションタイムアウト 内に応答がないと次のルールへ
- ユーザーがインシデントを確認すると、エスカレーション停止・通知停止
- ポリシーは最大 9 回まで繰り返し可能
エスカレーションポリシー設計
-
エスカレーションレベルを決める =>「何段階で通知を流すか？」をまず設計
レベル 通知先 役割 Level 1 Primary On-Call 最初に通知される人 Level 2 Secondary On-Call or チームリード Primary が無反応だったら Level 3 マネージャー or SRE リーダー 最後の砦（放置させない） -
通知間隔（タイムアウト）を決める =>「どれくらい待って次のレベルに流すか？」を設計
レベル間タイムアウト コメント 5分 標準的（PagerDuty 推奨） 2〜3分 クリティカルなシステム向け -
ターゲットを決める => 基本は スケジュール（Schedule） を使う
レベル 通知先 Level 1 Primary Schedule Level 2 Secondary Schedule Level 3 マネージャー個別 or 特別チーム -
ループ設定を考える
通知
通知方法
- SMS
- 電話
- メール
- アプリ Push
サイレンス設定
- 特定の期間、特定の Service やアラートを一時的に抑制
-
Maintenance Mode（一時ミュート）手順：
- 「Services」メニューから対象 Service を選択
- 「Maintenance Mode」タブを開く
- 「+ Create Maintenance Window」をクリック
- サイレンス期間を設定
- 例：4/29 22:00 ～ 4/30 02:00
- 必要に応じて複数の Service を選択
- 保存
チーム管理
チーム機能とは
- エスカレーションポリシー、ユーザー、スケジュール、サービスなどをチーム単位でグループ化・制御
チームの作り方
- 管理画面の「Teams」タブを開く
- 「+ New Team」をクリック
- 名前（例：
Platform Team）と説明を入力 - メンバーを追加（招待 or 既存ユーザー選択）
- Service、Escalation Policy、Schedule を割り当てる
チーム機能の構成
| 機能 | 説明 |
|---|---|
| Team | オンコール担当・エンジニアをまとめたグループ |
| Team-owned Services | チームが責任を持つ Service |
| Team-owned Schedules | チームのオンコールスケジュール |
| Team-owned Escalation Policies | チーム内で定義された通知ルール |
| Team visibility | 他チームへの表示可否（権限分離） |
Responders を追加する
追加の支援を受けるために、オープンインシデントに応答者を追加します。
- [Incidents] メニューを開く
- 対象のインシデントをクリックして詳細を開く
- インシデント詳細画面の右上にある 「Add Responders」ボタンをクリック
- 追加したいユーザーまたはチームを選択
- 検索バーで名前やチーム名を入力できる
- 1人でも複数でもOK
- 必要に応じて **メッセージを追加（任意）
- 例：「DB の状況確認お願いします」
- 「Send Request」ボタンをクリックしてリクエストを送信
追加されたレスポンダーの動作
- PagerDuty から即時通知が飛ぶ（プッシュ通知、電話、SMS など設定に応じて）
- 通知を受けた人は Accept（受諾） か Decline（辞退） を選択可能
- Accept：インシデントの参加者リストに追加（対応開始）
- Decline：辞退がインシデント履歴に記録される