incident-runbook-templates

インシデントランブックテンプレート

検知、トリアージ、緩和、解決、コミュニケーションを網羅する、インシデント対応ランブック向けの本番環境対応テンプレートです。

このスキルを使用する場面

• インシデント対応手順を作成するとき
• サービス固有のランブックを構築するとき
• エスカレーションパスを確立するとき
• 復旧手順を文書化するとき
• 発生中のインシデントに対応するとき
• オンコールエンジニアのオンボーディングを行うとき

中核となる概念

1. インシデントの深刻度レベル

深刻度	影響	対応時間	例
SEV1	完全な停止、データ損失	15 分	本番環境のダウン
SEV2	重大な機能低下	30 分	重要な機能の故障
SEV3	軽微な影響	2 時間	重要でないバグ
SEV4	ごくわずかな影響	翌営業日	見た目の問題

2. ランブックの構成

1. Overview & Impact
2. Detection & Alerts
3. Initial Triage
4. Mitigation Steps
5. Root Cause Investigation
6. Resolution Procedures
7. Verification & Rollback
8. Communication Templates
9. Escalation Matrix

詳細なパターンと実例

詳細なパターンのドキュメントは references/details.md にあります。上記のナビゲーション階層では不十分な場合は、そのファイルをお読みください。

ベストプラクティス

やるべきこと

• ランブックを最新に保つ - インシデントのたびにレビューする
• ランブックを定期的にテストする - ゲームデー、カオスエンジニアリング
• ロールバック手順を含める - 常に逃げ道を用意する
• 前提条件を文書化する - 手順が機能するために満たすべき条件
• ダッシュボードへのリンクを貼る - 緊張時に素早くアクセスできるように

やってはいけないこと

• 知識を前提にしない - 深夜 3 時の頭でも読めるように書く
• 検証を省かない - 各手順が機能したことを確認する
• コミュニケーションを忘れない - ステークホルダーに情報を共有し続ける
• 一人で対応しない - 早めにエスカレーションする
• ポストモーテムを省かない - すべてのインシデントから学ぶ

トラブルシューティング

ランブックの手順はステージングでは機能するが、実際のインシデント時に失敗する

手順は、健全な環境では真であるものの、障害発生時には当てはまらない前提条件をしばしば想定しています。ランブック内の各コマンドについて、前提条件のチェックと「このコマンドが失敗した場合の対処」の注記を追加してください。

# Step: Check pod status
kubectl get pods -n payments

# Prerequisites: kubectl configured, kubeconfig points to correct cluster
# If this fails: run `aws eks update-kubeconfig --name prod-cluster --region us-east-1`
# Expected output: pods in Running state

オンコールエンジニアがパニックになり、手順を順序どおりに進められない

ランブックの冒頭に、セクション番号に対応する番号付きチェックリストを追加してください。これにより、対応者は文書全体を読まなくても、緊張下で進捗を把握できます。

## Quick Checklist
- [ ] 1. Declare incident severity and open war room
- [ ] 2. Check service health (Section 4.1)
- [ ] 3. Check recent deployments (Section 4.1)
- [ ] 4. Roll back if deploy is suspect (Section 4.1)
- [ ] 5. Post initial notification to #payments-incidents
- [ ] 6. Escalate if > 15 min unresolved

ランブックが古くなっている — コマンドが古いクラスター名やエンドポイントを参照している

ランブックは手動で更新されるため劣化します。冒頭に「最終検証日」と担当者を記載し、すべての curl エンドポイントと kubectl コンテキスト名がまだ有効であることを検証する CI チェックを追加してください。

## Runbook Metadata
| Field | Value |
|---|---|
| Last verified | 2024-11-15 |
| Owner | @platform-team |
| Review cadence | After every SEV1/SEV2 |

エンジニアが作業に集中している間にステークホルダーへの連絡が遅れる

専任のインシデントコミュニケーター役（インシデントコマンダーとは別）を割り当て、その役割の唯一の仕事をステータス更新の投稿とします。コミュニケーションテンプレートに定例のアジェンダを追加してください。

Update every 15 minutes (even if no new information):
- Current status (Investigating / Mitigating / Monitoring)
- Impact (what is broken, who is affected, % of traffic)
- What we are doing right now
- Next update in: 15 minutes

データベースのランブックコマンドを誤って実行すると、さらなるダウンタイムを引き起こす

破壊的な SQL コマンドの前に明確な警告を追加し、実行前にドライラン出力の確認を必須にしてください。

-- WARNING: This terminates active connections. Verify count first.
-- DRY RUN (check count before terminating):
SELECT count(*) FROM pg_stat_activity WHERE state = 'idle' AND query_start < now() - interval '10 minutes';

-- EXECUTE only after verifying count is reasonable (< 50):
SELECT pg_terminate_backend(pid) FROM pg_stat_activity
WHERE state = 'idle' AND query_start < now() - interval '10 minutes';

関連スキル

• postmortem-writing - インシデント解決後に、ポストモーテムテンプレートを使って根本原因と再発防止策を記録します
• on-call-handoff-patterns - 引き継ぎを構造化し、次に対応する担当者が発生中のインシデントについて完全なコンテキストを持てるようにします