データパイプラインは、運用に乗ると必ず夜中に止まります。私たちが5年継続している案件でも、月に1〜2回は何かしらの障害が起きています。重要なのは「障害をゼロにする」ではなく「夜中に人間が起きなくても自動で復旧する、もしくは朝の業務開始までに対処できる」状態を作ることです。
監視設計の3階層
重要なのは、すべてのアラートを「即時対応」にしないことです。私たちが入る前は「全部で SEV1 扱い、毎晩誰かが起きる」状態のチームをよく見ます。3階層に分けるだけで、夜中の起床は1/10以下になります。
（Service Level Objective）の決め方
「うちのデータパイプラインの SLO は何ですか？」と聞かれて即答できる組織は、ほぼありません。SLOは具体的な数字で書きます。
| 対象 | SLI | SLO | 違反時の対応レベル |
|---|---|---|---|
| 日次バッチ | 完了時刻 | 毎日朝7時までに完了 | L2（朝対応） |
| ダッシュボード | 可用性 | 99.5% / 月 | L3（即時） |
| データ鮮度 | 最新データの遅延 | 30分以内 | L2 |
| スキーマテスト | 失敗率 | 0% / リリース時 | L2（PR出し直し） |
Runbook：障害対応を「読めば分かる」状態に
Runbook（障害対応手順書）は、書いているチームが少ないです。「何かあったら詳しい人を呼ぶ」運用は、その人が休みのとき詰みます。Runbook の最低構成は3項目です：症状・原因候補・対処手順。
Runbook テンプレート
Markdown
# [Pipeline名] 障害対応 Runbook
## 症状- アラート文言: `...`- 影響範囲: 〇〇のBIダッシュボード、〇〇への配信
## 原因候補（過去発生順）1. **ソースAPIのレート制限**（70%） - 確認: `curl -I https://api.../usage` で残量チェック - 対処: 翌時間まで待つ、もしくは緊急増枠2. **{{snowflake|*}} 容量上限**（20%） - 確認: ウェアハウス使用量 - 対処: 一時的にサイズ拡大3. **{{dbt|*}} スキーマテスト失敗**（10%） - 確認: dbt artifact / Slack ログ - 対処: 該当モデルを除外して継続、原因はチケット化
## エスカレーション- 30分対処できない → 〇〇さん（Slack DM）- 朝までに復旧見込み無し → 〇〇さん（電話）に Runbook を量産させる
Runbook は数が多いほど価値が出ますが、書くのが面倒で続きません。Claude Code に過去の障害ログから雛形を作らせると、運用ノウハウの蓄積が一気に進みます。
プロンプト例（Claude Code）
以下は過去6ヶ月の障害インシデントログです。
パイプライン別に Runbook を生成してください。
## 出力フォーマット
- 各パイプラインに対して、症状 / 原因候補（発生頻度順）/ 対処手順 / エスカレーション先
- 過去ログから「再発するパターン」を見つけて頻度%付きで列挙
- 対処手順はコマンドレベルで具体的に
## 入力
@incidents/2025-12.csv
@incidents/2026-01.csv
@incidents/2026-02.csv
... 想定される実行結果（例示）
## 生成された Runbook 一覧
### 1. `pipeline_sales_daily` Runbook
- 6ヶ月で 12回 障害発生
- 主原因: Salesforce {{api|*}} レート制限（67%）/ Snowflake 容量（25%）/ その他（8%）
- 対処手順を3パターン分、コマンドレベルで生成 → `runbooks/sales_daily.md`
### 2. `pipeline_finance_monthly` Runbook
- 6ヶ月で 4回 障害発生
- 主原因: 月初負荷集中（75%）/ ストレージ上限（25%）
- 対処手順を生成 → `runbooks/finance_monthly.md`
### 3. `pipeline_marketing_realtime` Runbook
- 6ヶ月で 8回 障害発生
- 主原因: Pub/Sub 遅延（50%）/ {{bigquery|*}} ストリーミング失敗（38%）/ その他（12%）
- 対処手順を生成 → `runbooks/marketing_realtime.md`
合計 `runbooks/` に12ファイル生成。各ファイル ~80行、コマンドコピペで対応可能なレベル。監視設計チェックリスト
- □ アラートを3階層に分けて Slack チャンネルを分けた
- □ 各パイプラインに SLO を定義した
- □ Runbook を全パイプラインに用意した
- □ PagerDuty / OpsGenie の onCall 設定がある
- □ 月次でアラート量と SLO 違反をレビューしている
- □ Runbook を3ヶ月に1回見直している
次回予告
EP.05 では、データカタログを「使われる」状態にする現実解を、ツール選定からメタデータ運用、形骸化回避まで実例で解説します。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。