ストーリー
田
田中VPoE
エスカレーションフローを設計した。次は「対応者が何をするか」の手順書だ。ランブックとプレイブック — この2つの違いを理解しているか？
あなた
ランブックは具体的な手順書、プレイブックはもう少し高レベルの対応方針…でしょうか？
あ
田
田中VPoE
概ね正しい。ランブックは「この手順通りに実行すれば解決する」もの。プレイブックは「この状況ではこのアプローチで調査・判断する」もの。前者は自動化の候補、後者は判断力が必要なものだ
あなた
使い分けが重要なんですね
あ
田
田中VPoE
そうだ。そして、ランブックは書いて終わりではない。テストされていないランブックは「ないのと同じ」だ
ランブックとプレイブックの違い
定義
| 概念 | 定義 | 特徴 |
|---|---|---|
| ランブック（Runbook） | 特定の問題に対する手順化された対応マニュアル | 判断不要、手順通りに実行すれば解決 |
| プレイブック（Playbook） | 状況に応じた調査・判断のガイドライン | 判断が必要、フレームワークを提供 |
使い分け
| 状況 | 適切なドキュメント | 例 |
|---|---|---|
| 既知の問題で対応手順が確立 | ランブック | DBコネクション枯渇時のプール再起動 |
| 未知の問題で調査が必要 | プレイブック | レイテンシ劣化時の原因調査手順 |
| 定型的な運用作業 | ランブック | デプロイ手順、証明書更新 |
| 複合的なインシデント | プレイブック | 複数サービスにまたがる障害の切り分け |
ランブックの設計
テンプレート
# ランブック: [問題名]
## メタ情報
- 最終更新: YYYY-MM-DD
- 作成者: [名前]
- レビュアー: [名前]
- 関連アラート: [アラート名]
- 想定対応時間: XX分
## 症状
- [どのような症状が出ているか]
## 影響
- [ユーザーへの影響]
- [ビジネスへの影響]
## 前提条件
- [必要な権限]
- [必要なツール]
## 手順
1. [具体的なコマンドや操作]
2. [次のステップ]
3. [確認方法]
## 確認方法
- [問題が解決したことの確認手順]
## エスカレーション
- [この手順で解決しない場合の連絡先]
## 根本原因対応
- [この問題の再発を防ぐための長期的な対策]良いランブックの条件
| 条件 | 説明 |
|---|---|
| コピーペースト可能 | コマンドはそのままコピーして実行できる |
| 前提知識不要 | 初めての人でも手順通りに実行できる |
| 確認ステップ付き | 各手順の後に「正しく実行されたか」の確認方法がある |
| 最新である | 定期的にテスト・更新されている |
| 自動化候補の明示 | 将来的に自動化すべき手順にマークがある |
プレイブックの設計
テンプレート
# プレイブック: [状況名]
## メタ情報
- 最終更新: YYYY-MM-DD
- 対象: [どのような状況で使用するか]
## 症状パターン
- パターンA: [症状の説明] → セクション1へ
- パターンB: [症状の説明] → セクション2へ
## セクション1: [調査アプローチ名]
### 調査手順
1. [何を確認するか]
2. [どのツールを使うか]
3. [結果の解釈方法]
### 判断基準
- [結果がXの場合] → [アクションA]
- [結果がYの場合] → [アクションB]
## 判断のフレームワーク
- [影響度の評価方法]
- [緊急度の評価方法]
- [対応方針の決定基準]プレイブック例: レイテンシ劣化
# プレイブック: レイテンシ劣化の調査
## 症状
P99レイテンシがSLO閾値を超過
## 調査フロー
1. 影響範囲の特定
- 全エンドポイント or 特定エンドポイント？
- 全ユーザー or 特定リージョン？
2. 原因の切り分け
├── アプリケーション層
│ ├── 最近のデプロイ → デプロイ履歴を確認 → ロールバック検討
│ ├── メモリリーク → ヒープダンプ解析
│ └── スレッド枯渇 → スレッドダンプ解析
├── データベース層
│ ├── スロークエリ → クエリログ分析
│ ├── ロック競合 → ロック状態確認
│ └── 接続プール枯渇 → コネクション数確認
├── インフラ層
│ ├── CPU/メモリ逼迫 → リソースメトリクス確認
│ ├── ネットワーク遅延 → traceroute / ping
│ └── ディスクI/O → I/Oメトリクス確認
└── 外部依存
├── CDN → CDNステータス確認
├── 外部API → 外部APIのレスポンスタイム
└── DNS → DNS解決時間
3. 対応方針の決定
- 即座に復旧可能（ロールバック等）→ 実行
- 調査が必要 → SMEを招集
- 外部要因 → 回避策の検討ランブックの運用
ライフサイクル管理
| フェーズ | 活動 | 頻度 |
|---|---|---|
| 作成 | インシデント対応後に新規作成 | インシデント発生時 |
| レビュー | 技術的正確性のピアレビュー | 作成時 |
| テスト | 手順通りに実行して動作確認 | 四半期ごと |
| 更新 | 環境変更に伴う手順更新 | 変更時 |
| 廃棄 | 不要になったランブックの削除 | 年次レビュー |
ゲームデイ（訓練）
| 項目 | 内容 |
|---|---|
| 目的 | ランブックの有効性とチームの対応力を検証する |
| 頻度 | 月1回 |
| 進め方 | 模擬インシデントを発生させ、ランブック通りに対応 |
| 評価 | 対応時間、手順の正確性、改善点の発見 |
| 成果物 | ランブックの更新、新規ランブックの作成 |
まとめ
| ポイント | 内容 |
|---|---|
| ランブック | 手順化された対応マニュアル。自動化の候補 |
| プレイブック | 調査・判断のガイドライン。判断力が必要な場面用 |
| 運用の鍵 | 定期的なテストとゲームデイによる検証 |
チェックリスト
- ランブックとプレイブックの違いを理解した
- ランブックのテンプレートと品質基準を理解した
- ゲームデイの重要性を理解した
次のステップへ
次は「オンコールの健全性管理」です。オンコール体制を持続可能に維持するためのメトリクスと改善手法を学びましょう。
推定読了時間: 30分