oncall-runbook

オンコール対応ランブックのスキル

サービスの完全なオンコール対応ランブックを作成します。午前3時にアラートを受けたオンコールエンジニアが、誰にも助けを求めず自信を持って対応するために必要な情報をすべて提供します。

優れたオンコール対応ランブックは、「最初に何をすればよいのか」という問題を解消し、平均解決時間（MTTR）を短縮します。落ち着いてドキュメントを読んでいる人ではなく、ページ通知を受けて対応が必要なオンコールエンジニア向けに書かれています。

必要な入力情報

すでに提供されていない場合は、次の情報を尋ねてください。

• サービス名とその機能
• チームとテックリードの名前
• アラート一覧 — 現在オンコールに通知されるアラートの名前
• 監視環境 — Datadog / Grafana / CloudWatch / PagerDuty など
• よくある障害モード — 最も頻繁に発生する障害と、その解決方法
• エスカレーション先 — オンコール担当者が解決できない場合の連絡先
• デプロイ環境 — オンコール担当者がロールバックできるか。方法は？
• サービスの依存関係 — このサービスが依存するものと、このサービスに依存するもの

出力形式

---

オンコール対応ランブック：[サービス名]

チーム： [チーム名] | テックリード： [名前] PagerDuty サービス： [リンク] | エスカレーションポリシー： [ポリシー名] 最終更新日： [日付] | 次回レビュー： [日付 + 90 日]

このサービスのオンコール担当が初めてですか？ まず[開発者向けオンボーディングドキュメント]を読んでください。アーキテクチャと仕組みを説明しています。このランブックは、サービスの内容を理解していることを前提としています。

---

クイックリファレンス

ダッシュボード： [リンク — ページ通知を受けたとき最初に開くもの] ログ： [リンク — ログの確認場所] ランブック一覧： 通知されたアラートへ移動 → [以下のアラート一覧] 30 分以内に解決できない場合： [名前] に [Slack / PagerDuty] でエスカレーション

ロールバックコマンド（覚えておいてください）：

[rollback command — e.g. kubectl rollout undo deployment/[service-name]]

---

エスカレーションマトリクス

状況	エスカレーション先	方法	どのくらい経過したら
アラートの原因を特定できない	[テックリードの名前]	Slack の DM / 電話	30 分
アラートにインフラ変更が必要	[プラットフォームチーム]	Slack の #platform	直ちに
顧客に影響する問題	[CSM / サポートリード]	Slack の #incidents	直ちに（P1）
データベースの問題	[DBA またはデータチーム]	Slack / PagerDuty	直ちに
[特定の依存先] が停止	[[依存先] のオンコール担当]	PagerDuty / Slack	直ちに
長時間の停止（1 時間超）	[エンジニアリングマネージャー]	電話	1 時間

連絡先：

名前	役割	Slack	電話
[名前]	テックリード	@[handle]	[番号]
[名前]	エンジニアリングマネージャー	@[handle]	[番号]
[名前]	プラットフォーム / インフラ	@[handle]	[番号]
[プラットフォームチーム]	インフラのオンコール担当	#platform	PagerDuty

---

サービスアーキテクチャ（概要）

[Upstream callers]
        │
        ▼
[This Service]
        │
        ├──→ [Primary Database]
        ├──→ [Cache — e.g. Redis]
        └──→ [Downstream Service / Queue]

このサービスが停止した場合に影響を受けるもの： [下流の利用者一覧] これらが停止した場合に影響を受けるもの： [上流の依存先一覧]

---

アラート対応ランブック

アラート：[アラート名 1 — 例：HighErrorRate]

意味： [平易な説明 — 例：「過去 5 分間に API リクエストの 5% 超が 5xx エラーを返しています」] 重大度： P1 / P2 / P3 SLO への影響： あり / なし — [ありの場合：このアラートは、エラーバジェットの消費速度が [X] 倍であることを示します]

ステップ 1 — 確認して状況を評価する

# Check current error rate
[query or dashboard link]

# Check which endpoints are erroring
[query or command]

ステップ 2 — 最近の変更を確認する

# Any deploys in the last hour?
[command or link to deployment log]

# Recent config changes?
[where to check]

ステップ 3 — 依存関係を確認する

# Is the database healthy?
[health check command or link]

# Is [downstream service] healthy?
[health check command or link]

ステップ 4 — 原因を特定する

確認された内容	意味	対応
[エラーパターン 1]	[原因]	[対応]
[エラーパターン 2]	[原因]	[対応]
[エラーパターン 3]	[原因]	[対応]
明確なパターンがない	原因不明	[名前] にエスカレーション

ステップ 5 — 修正または影響を軽減する

# If caused by bad deploy — roll back:
[rollback command]

# If caused by [specific issue]:
[fix command]

# If caused by upstream dependency:
[mitigation — e.g. enable circuit breaker, reduce traffic, etc.]

解決後：

• エラー率が平常値に戻ったことを確認する
• 下流のサービスに影響がなかったことを確認する
• P1 の場合：インシデント後レビューを開始する — [incident-postmortem スキル]を参照
• 解決内容の概要を #incidents に投稿する

---

アラート：[アラート名 2 — 例：HighLatency]

意味：［例：「P99 応答時間が 3 分以上連続して 1 秒を超えています」］ **重大度：**P1 / P2 / P3 **SLO への影響：**あり — レイテンシ SLO 違反

ステップ 1 — 影響範囲を評価する

# Check which endpoints are slow
[query or dashboard — broken down by endpoint]

# Check if latency is across all regions or localised
[query or command]

ステップ 2 — よくある原因と対処法

原因	シグナル	対処法
データベースの低速クエリ	ダッシュボードで DB レイテンシの急上昇を確認	［スロークエリログを確認：command］
キャッシュミスの急増	ダッシュボードでキャッシュヒット率の低下を確認	［コマンドまたは操作］
メモリ不足／GC	サービスのダッシュボードでメモリ使用量の増加を確認	［コマンドまたは操作 — 例：再起動、スケールアップ］
上流サービスの遅延	トレースで外部呼び出しに時間がかかっていることを確認	[service] のオンコール担当者にエスカレーション
トラフィックの急増	ダッシュボードでリクエスト数の急増を確認	［スケールアップ：command］

ステップ 3 — 20 分以内に解決しない場合はエスカレーションする PagerDuty / Slack で [Tech lead] に連絡します。

---

アラート：[アラート名 3 — 例：DatabaseConnectionPoolExhausted]

意味：［例：「サービスが利用可能なデータベース接続をすべて使用しており、新しいリクエストは失敗します」］ **重大度：**P1 **SLO への影響：**あり — 直ちにエラーが発生します

即時の緩和策：

# Restart the service to flush stale connections
[restart command]

# Check current connection count
[DB connection query]

安定化後に根本原因を診断する：

# Check for long-running queries holding connections
[query]

# Check if a recent deploy changed connection pool config
[where to check]

解決策：［例：「設定でプールサイズを増やす／長時間実行中のクエリを終了する／サービスをスケールする」］

---

アラート：[アラート名 4 — 例：QueueBacklogHigh / ConsumerLag]

意味：［例：「メッセージキューのバックログが 10,000 件を超えており、コンシューマーが処理に追いついていません」］ **重大度：**P2 **SLO への影響：**状況によります — キューが滞留すると、下流システムへのデータ到着が遅れます

ステップ 1 — コンシューマーの状態を確認する

# Are consumers running?
[command]

# Consumer error rate?
[dashboard or query]

ステップ 2 — メッセージの内容を確認する

# Are there poison messages causing retries?
[command to inspect dead-letter queue or failed messages]

ステップ 3 — 対処方法

条件	対処
コンシューマーが停止している	コンシューマーを再起動します：[command]
キューに有害なメッセージがある	DLQ に移動します：[command]
コンシューマーは正常だが処理が遅い	コンシューマーをスケールします：[command]
上流が速すぎるペースで生成している	[upstream service] の担当者にエスカレーション

---

アラート：[同じパターンに従ってアラートを追加する]

---

診断用チートシート

迅速な診断に使う一般的なコマンドです。変更せずに貼り付けて実行してください。

# Service health
[health check command]

# Recent logs (last 100 lines)
[log command]

# Error logs only
[error log filter command]

# Current pod / instance status
[kubectl get pods / aws ecs describe-tasks / etc.]

# Restart the service
[restart command]

# Roll back to previous version
[rollback command]

# Database connection count
[DB query]

# Cache hit rate
[cache stats command]

# Current request rate
[metrics query]

---

便利なダッシュボードリンク

ダッシュボード	URL	用途
サービス概要	[Link]	最初に確認する場所 — エラー率、レイテンシ、リクエスト数
データベース	[Link]	接続数、低速クエリ、レプリケーション遅延
インフラストラクチャ	[Link]	CPU、メモリ、ディスク
キュー／コンシューマー	[Link]	バックログの深さ、コンシューマーのスループット
上流の依存関係	[Link]	依存関係の健全性を一目で確認

---

インシデントの連絡

インシデントを宣言したら：

すぐに #incidents に投稿します：

🔴 INCIDENT — [Service Name]
Status: Investigating
Impact: [Who is affected and how]
Paged: [Your name]
Next update: [Time — max 30 min from now]

インシデントが継続している間は、30 分ごとに更新します：

🔴 UPDATE — [Service Name] — [Time]
Status: [Investigating / Identified / Mitigating / Resolved]
Latest: [One sentence on what you found or did]
Next update: [Time]

解決時：

✅ RESOLVED — [Service Name] — [Time]
Duration: [X minutes]
Impact: [Summary of who was affected]
Cause: [One sentence]
Follow-up: [PIR required? Yes/No — link when created]

---

オンコールの引き継ぎ

各オンコールシフトの終了時に、このテンプレートを使用します：

--- ON-CALL HANDOFF: [Service Name] ---
Date: [Date]
Outgoing: [Your name]
Incoming: [Next on-call name]

INCIDENTS THIS SHIFT:
- [Incident summary — date, duration, cause, resolution, follow-up required]

OPEN ISSUES TO WATCH:
- [Anything not fully resolved / trending in the wrong direction]

CHANGES SINCE LAST HANDOFF:
- [Deploys, config changes, infra changes that affect on-call awareness]

RUNBOOK GAPS FOUND:
- [Anything you had to figure out that isn't documented — please add it]

ANYTHING ELSE:
- [Notes for incoming on-call]

---

品質チェック

• オンコールへの通知を伴うすべてのアラートにランブックの項目がある — 項目のないアラートがない
• ロールバックコマンドが正確で、最近テストされている
• エスカレーション先の連絡先に、最新の電話番号と Slack ハンドルが登録されている
• 診断コマンドが動作する — 最近、少なくとも 1 人が実行している
• 引き継ぎテンプレートがシフト交代のたびに使われている — インシデント時だけではない
• 「ドキュメントに記載されておらず、調べる必要があったこと」を、インシデントのたびにこのランブックへ追加している

アンチパターン

• 「ログを確認する」のような曖昧な診断手順でアラート対応手順書を書かないでください。各手順には、実行する正確なコマンド、ダッシュボードのリンク、またはクエリを明記してください。
• 具体的なオンコール対応がないアラートを対応手順書に含めないでください。対応方法が定義されていないまま誰かに通知するアラートは、解決につながるのではなく、混乱を招きます。
• ロールバックコマンドを文書化せず、テストもしないままにしないでください。一度も実行したことのないロールバック手順は、最も必要なときに失敗します。
• 電話番号と Slack ハンドルを記載せずにエスカレーション先を列挙しないでください。メールのみのエスカレーション経路は、午前3時のインシデントでは役に立ちません。
• 対応手順書を一度書いただけで、恒久的なものとして扱わないでください。対応手順書はインシデントの後に古くなります。インシデントが発生するたびに、関連する対応手順書の項目を見直してください。