はじめに

私自身が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	外部システムへの通知設定（例：社内チャット、他ツール連携）

インシデント（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（一時ミュート）手順：
1. 「Services」メニューから対象 Service を選択
2. 「Maintenance Mode」タブを開く
3. 「+ Create Maintenance Window」をクリック
4. サイレンス期間を設定
  - 例：4/29 22:00 ～ 4/30 02:00
5. 必要に応じて複数の Service を選択
6. 保存

チーム管理

チーム機能とは

エスカレーションポリシー、ユーザー、スケジュール、サービスなどをチーム単位でグループ化・制御

チームの作り方

管理画面の「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：辞退がインシデント履歴に記録される