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

検出、トリアージ、軽減、解決、コミュニケーションをカバーする本番対応インシデント対応ランブックテンプレート。

このスキルを使う場面

• インシデント対応手順の作成
• サービス固有のランブックの構築
• エスカレーションパスの確立
• リカバリ手順のドキュメント化
• アクティブなインシデントへの対応
• オンコール エンジニアのオンボーディング

主要な概念

1. インシデント重大度レベル

重大度	影響	応答時間	例
SEV1	完全障害、データ喪失	15 分	本番環境ダウン
SEV2	大幅な劣化	30 分	重要機能の障害
SEV3	軽微な影響	2 時間	非重要バグ
SEV4	最小限の影響	営業日翌日	見た目の問題

2. ランブック構成

1. 概要と影響
2. 検出とアラート
3. 初期トリアージ
4. 軽減ステップ
5. 根本原因調査
6. 解決手順
7. 検証とロールバック
8. コミュニケーション テンプレート
9. エスカレーション マトリックス

ランブック テンプレート

テンプレート 1: サービス障害ランブック

# [サービス名] 障害ランブック

## 概要

**サービス**: Payment Processing Service
**オーナー**: Platform Team
**Slack**: #payments-incidents
**PagerDuty**: payments-oncall

## 影響評価

- [ ] どの顧客が影響を受けていますか?
- [ ] トラフィックの何パーセントが影響を受けていますか?
- [ ] 財務的な影響はありますか?
- [ ] 被害範囲はどのくらいですか?

## 検出

### アラート

- `payment_error_rate > 5%` (PagerDuty)
- `payment_latency_p99 > 2s` (Slack)
- `payment_success_rate < 95%` (PagerDuty)

### ダッシュボード

- [Payment Service Dashboard](https://grafana/d/payments)
- [Error Tracking](https://sentry.io/payments)
- [Dependency Status](https://status.stripe.com)

## 初期トリアージ (最初の 5 分)

### 1. スコープを評価

```bash
# サービスの健全性を確認
kubectl get pods -n payments -l app=payment-service

# 最近のデプロイを確認
kubectl rollout history deployment/payment-service -n payments

# エラー率を確認
curl -s "http://prometheus:9090/api/v1/query?query=sum(rate(http_requests_total{status=~'5..'}[5m]))"
```

### 2. クイック ヘルスチェック

- [ ] サービスに到達できますか? `curl -I https://api.company.com/payments/health`
- [ ] データベース接続? コネクションプール メトリクスを確認
- [ ] 外部依存関係? Stripe、銀行 API のステータスを確認
- [ ] 最近の変更? デプロイ履歴を確認

### 3. 初期分類

| 症状 | 考えられる原因 | セクション |
| ---- | ------------ | --------- |
| すべてのリクエストが失敗 | サービスダウン | セクション 4.1 |
| 高レイテンシ | データベース/依存関係 | セクション 4.2 |
| 部分的な障害 | コードバグ | セクション 4.3 |
| エラーのスパイク | トラフィック急増 | セクション 4.4 |

## 軽減手順

### 4.1 サービス完全ダウン

```bash
# ステップ 1: ポッドのステータスを確認
kubectl get pods -n payments

# ステップ 2: ポッドがクラッシュループしている場合、ログを確認
kubectl logs -n payments -l app=payment-service --tail=100

# ステップ 3: 最近のデプロイを確認
kubectl rollout history deployment/payment-service -n payments

# ステップ 4: 最近のデプロイが疑わしい場合はロールバック
kubectl rollout undo deployment/payment-service -n payments

# ステップ 5: リソース制約がある場合はスケールアップ
kubectl scale deployment/payment-service -n payments --replicas=10

# ステップ 6: リカバリを確認
kubectl rollout status deployment/payment-service -n payments
```

### 4.2 高レイテンシ

```bash
# ステップ 1: データベース接続を確認
kubectl exec -n payments deploy/payment-service -- \
  curl localhost:8080/metrics | grep db_pool

# ステップ 2: スロークエリを確認 (DB 問題の場合)
psql -h $DB_HOST -U $DB_USER -c "
  SELECT pid, now() - query_start AS duration, query
  FROM pg_stat_activity
  WHERE state = 'active' AND duration > interval '5 seconds'
  ORDER BY duration DESC;"

# ステップ 3: 必要に応じて長時間実行クエリを終了
psql -h $DB_HOST -U $DB_USER -c "SELECT pg_terminate_backend(pid);"

# ステップ 4: 外部依存関係のレイテンシを確認
curl -w "@curl-format.txt" -o /dev/null -s https://api.stripe.com/v1/health

# ステップ 5: 依存関係が遅い場合、サーキットブレーカーを有効化
kubectl set env deployment/payment-service \
  STRIPE_CIRCUIT_BREAKER_ENABLED=true -n payments
```

### 4.3 部分的な障害 (特定のエラー)

```bash
# ステップ 1: エラーパターンを識別
kubectl logs -n payments -l app=payment-service --tail=500 | \
  grep -i error | sort | uniq -c | sort -rn | head -20

# ステップ 2: エラー トラッキングを確認
# Sentry にアクセス: https://sentry.io/payments

# ステップ 3: 特定のエンドポイントの場合、フィーチャーフラグを有効化して無効化
curl -X POST https://api.company.com/internal/feature-flags \
  -d '{"flag": "DISABLE_PROBLEMATIC_FEATURE", "enabled": true}'

# ステップ 4: データ問題の場合、最近のデータ変更を確認
psql -h $DB_HOST -c "
  SELECT * FROM audit_log
  WHERE table_name = 'payment_methods'
  AND created_at > now() - interval '1 hour';"
```

### 4.4 トラフィック急増

```bash
# ステップ 1: 現在のリクエスト率を確認
kubectl top pods -n payments

# ステップ 2: 水平スケーリング
kubectl scale deployment/payment-service -n payments --replicas=20

# ステップ 3: レート制限を有効化
kubectl set env deployment/payment-service \
  RATE_LIMIT_ENABLED=true \
  RATE_LIMIT_RPS=1000 -n payments

# ステップ 4: 攻撃の場合、疑わしい IP をブロック
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: block-suspicious
  namespace: payments
spec:
  podSelector:
    matchLabels:
      app: payment-service
  ingress:
  - from:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
        - 192.168.1.0/24  # 疑わしい範囲
EOF
```

## 検証ステップ

```bash
# サービスが健全であることを確認
curl -s https://api.company.com/payments/health | jq

# エラー率が正常に戻ったことを確認
curl -s "http://prometheus:9090/api/v1/query?query=sum(rate(http_requests_total{status=~'5..'}[5m]))" | jq '.data.result[0].value[1]'

# レイテンシが許容範囲であることを確認
curl -s "http://prometheus:9090/api/v1/query?query=histogram_quantile(0.99,sum(rate(http_request_duration_seconds_bucket[5m]))by(le))" | jq

# 重要なフローのスモークテスト
./scripts/smoke-test-payments.sh
```

## ロールバック手順

```bash
# Kubernetes デプロイメントをロールバック
kubectl rollout undo deployment/payment-service -n payments

# データベース マイグレーションをロールバック (該当する場合)
./scripts/db-rollback.sh $MIGRATION_VERSION

# フィーチャーフラグをロールバック
curl -X POST https://api.company.com/internal/feature-flags \
  -d '{"flag": "NEW_PAYMENT_FLOW", "enabled": false}'
```

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

| 条件 | エスカレーション先 | 連絡方法 |
| ---- | ---------- | ------ |
| 解決されていない SEV1 が 15 分以上 | Engineering Manager | @manager (Slack) |
| データ侵害の疑い | Security Team | #security-incidents |
| 財務への影響 > $10k | Finance + Legal | @finance-oncall |
| 顧客コミュニケーション必要 | Support Lead | @support-lead |

## コミュニケーション テンプレート

### 初期通知 (社内)

```
🚨 INCIDENT: Payment Service Degradation

Severity: SEV2
Status: Investigating
Impact: ~20% の支払いリクエストが失敗
Start Time: [TIME]
Incident Commander: [NAME]

Current Actions:
- 根本原因を調査中
- サービスをスケールアップ中
- ダッシュボードを監視中

#payments-incidents で更新
```

### ステータス更新

```
📊 UPDATE: Payment Service Incident

Status: Mitigating
Impact: ~5% の失敗率に減少
Duration: 25 分

Actions Taken:
- デプロイ v2.3.4 → v2.3.3 をロールバック
- サービスを 5 → 10 レプリカにスケール

Next Steps:
- 継続的に監視中
- 根本原因分析進行中

ETA to Resolution: ~15 分
```

### 解決通知

```
✅ RESOLVED: Payment Service Incident

Duration: 45 分
Impact: ~5,000 件の影響を受けたトランザクション
Root Cause: v2.3.4 のメモリリーク

Resolution:
- v2.3.3 にロールバック
- トランザクションは自動再試行で成功

Follow-up:
- ポストモーテム予定 [DATE]
- バグ修正進行中
```

テンプレート 2: データベース インシデント ランブック

# データベース インシデント ランブック

## クイック リファレンス
| 問題 | コマンド |
|-----|--------|
| 接続を確認 | `SELECT count(*) FROM pg_stat_activity;` |
| クエリを終了 | `SELECT pg_terminate_backend(pid);` |
| レプリケーション ラグを確認 | `SELECT extract(epoch from (now() - pg_last_xact_replay_timestamp()));` |
| ロックを確認 | `SELECT * FROM pg_locks WHERE NOT granted;` |

## コネクション プール 枯渇
```sql
-- 現在の接続を確認
SELECT datname, usename, state, count(*)
FROM pg_stat_activity
GROUP BY datname, usename, state
ORDER BY count(*) DESC;

-- 長時間実行接続を識別
SELECT pid, usename, datname, state, query_start, query
FROM pg_stat_activity
WHERE state != 'idle'
ORDER BY query_start;

-- アイドル接続を終了
SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE state = 'idle'
AND query_start < now() - interval '10 minutes';

レプリケーション ラグ

-- レプリカのラグを確認
SELECT
  CASE
    WHEN pg_last_wal_receive_lsn() = pg_last_wal_replay_lsn() THEN 0
    ELSE extract(epoch from now() - pg_last_xact_replay_timestamp())
  END AS lag_seconds;

-- ラグが 60s を超える場合、以下を検討:
-- 1. プライマリ/レプリカ間のネットワークを確認
-- 2. レプリカのディスク I/O を確認
-- 3. 回復不可能な場合はフェイルオーバーを検討

ディスク容量が重大

# ディスク使用量を確認
df -h /var/lib/postgresql/data

# 大きなテーブルを検出
psql -c "SELECT relname, pg_size_pretty(pg_total_relation_size(relid))
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC
LIMIT 10;"

# VACUUM でスペースを回復
psql -c "VACUUM FULL large_table;"

# 緊急の場合、古いデータを削除またはディスクを拡張

## ベストプラクティス

### すべきこと
- **ランブックを常に最新に保つ** - すべてのインシデント後にレビュー
- **ランブックを定期的にテスト** - ゲームデー、chaos engineering
- **ロールバック ステップを含める** - 常にエスケープハッチを用意
- **前提条件をドキュメント化** - ステップが機能するために真である必要があること
- **ダッシュボードへのリンク** - ストレス下での迅速なアクセス

### してはいけないこと
- **知識を仮定しない** - 午前3時の脳向けに書く
- **検証をスキップしない** - 各ステップが機能したことを確認
- **コミュニケーションを忘れない** - ステークホルダーに知らせ続ける
- **一人で作業しない** - 早期にエスカレーション
- **ポストモーテムをスキップしない** - すべてのインシデントから学ぶ

## トラブルシューティング

### ランブックのステップは本番環境では機能するが、実際のインシデント中に失敗する

ステップは多くの場合、健全な環境では真だが障害中には真でない前提条件を仮定します。ランブックの各コマンドについて、前提条件チェックと「このコマンドが失敗した場合」のメモを追加してください:

```bash
# ステップ: ポッドのステータスを確認
kubectl get pods -n payments

# Prerequisites: kubectl 設定済み、kubeconfig が正しいクラスタを指している
# 失敗時: `aws eks update-kubeconfig --name prod-cluster --region us-east-1` を実行
# 期待される出力: Running 状態のポッド

オンコール エンジニアがパニックになり、ステップを順序を無視して実行する

ランブックの上部に番号付きチェックリストを追加して、セクション番号を反映させます。応答者はストレス下での全文を読まなくても進行状況を追跡できます:

## クイック チェックリスト
- [ ] 1. インシデント重大度を宣言し、ウォールームを開く
- [ ] 2. サービスの健全性を確認 (セクション 4.1)
- [ ] 3. 最近のデプロイを確認 (セクション 4.1)
- [ ] 4. デプロイが疑わしい場合はロールバック (セクション 4.1)
- [ ] 5. #payments-incidents に初期通知を投稿
- [ ] 6. 解決していない > 15 分の場合はエスカレーション

ランブックが古い — コマンドが古いクラスター名またはエンドポイントを参照する

ランブックは手動で更新されるため劣化します。上部に「Last Verified」日付とオーナーを含め、すべての curl エンドポイントと kubectl コンテキスト名がまだ有効かどうかを検証する CI チェックを追加してください:

## ランブック メタデータ
| フィールド | 値 |
|---|---|
| Last verified | 2024-11-15 |
| オーナー | @platform-team |
| Review cadence | すべての SEV1/SEV2 の後 |

ステークホルダーへのコミュニケーションが遅れる — エンジニアが集中している間に

専任のインシデント コミュニケーター ロール (インシデント コマンダーと別) を割り当てます。唯一の役割はステータス更新を投稿することです。コミュニケーション テンプレートに定期的なアジェンダを追加してください:

15 分ごとに更新 (新しい情報がなくても):
- 現在のステータス (Investigating / Mitigating / Monitoring)
- 影響 (何が壊れているか、誰が影響を受けているか、トラフィックの %)
- 今すぐ行っていること
- 次の更新: 15 分後

データベース ランブック コマンドが実行時に誤りで追加のダウンタイムを引き起こす

破壊的な SQL コマンド前に明示的な警告を追加し、実行前にドライラン出力チェックを要求してください:

-- 警告: これはアクティブな接続を終了します。実行前にカウントを確認してください。
-- ドライラン (終了前にカウントを確認):
SELECT count(*) FROM pg_stat_activity WHERE state = 'idle' AND query_start < now() - interval '10 minutes';

-- カウントが妥当 (< 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 - シフト ハンドオフを構造化して、引き継ぎ応答者がアクティブなインシデントの完全なコンテキストを持つようにする