データパイプライン障害対応の成否は、技術力ではなく「事前準備の質」で9割決まります。具体的には、(1)障害検知の自動化、(2)エスカレーションフローの文書化、(3)復旧手順のRunbook整備、(4)ポストモーテムの習慣化の四点です。これらが揃っていれば、真夜中の障害でも当直担当者が迷わず対応でき、翌朝には復旧済み・原因分析済み・再発防止策まで揃っている状態を作れます。
本記事では、データパイプライン障害を分類し、検知から復旧・振り返りまでのエスカレーションフローを設計する方法を解説します。D-10(データSLA)と組み合わせて運用することで、基盤の信頼性を「数値で語れる」状態に引き上げられます。
データパイプライン障害の分類
障害対応を設計する第一歩は、どんな種類の障害が起こり得るかを分類することです。データパイプラインの障害は、原因・影響範囲・緊急度の3軸で分類すると整理しやすくなります。特に「サイレント障害」(ジョブは成功ステータスなのにデータが異常)は検知が最も難しく、D-03(データ品質管理)のチェック機構と併用する必要があります。
| 障害タイプ | 原因 | 影響範囲 | 緊急度 |
|---|---|---|---|
| ジョブ失敗 | エラー終了、タイムアウト | 単一DAG配下 | 中 |
| スキーマ変更 | ソースDBのカラム追加・削除 | 下流全モデル | 高 |
| データ量急増 | キャンペーン、障害後リラン | 後続ジョブのタイムアウト | 中 |
| 依存サービス障害 | クラウドDWH障害、API停止 | 基盤全体 | 最高 |
| 権限エラー | IAM・GRANT変更の副作用 | 特定テーブル | 中 |
| サイレント障害 | ロジックバグ、データ品質劣化 | 見逃されると広範 | 高 |
エスカレーションフローの設計
エスカレーションフローとは、障害を検知してから復旧・振り返りまでの一連の対応プロセスを、誰が・いつ・何をするかのタイムラインで定めたものです。このフローが文書化されていないと、障害のたびに「誰が対応するのか」という調整で時間を浪費し、本来注力すべき原因究明が後手に回ります。基本形は「検知→判断→一次対応→復旧→振り返り」の5ステップです。
特に重要なのは「判断」のステップで、検知されたアラートが本当に対応必要なのか、影響範囲はどこまでか、誰をエスカレーション対象に含めるかを10分以内に決める必要があります。ここが曖昧だと、深夜にSlackの通知が鳴り続けるのに誰も動き出さない事態が発生します。
【エスカレーションフロー】
[1.検知]
監視システム --> アラート発報
|
v
[2.判断] <-- 10分以内
一次受けエンジニアが影響範囲を評価
|
+-- Tier1影響あり --> オンコール責任者+SRE召集
+-- Tier2影響あり --> 担当エンジニアのみ対応
+-- Tier3/影響小 --> 翌営業日対応
|
v
[3.一次対応] <-- 30分以内
利用者通知 + 暫定回避策の適用
|
v
[4.復旧] <-- SLAに従った時間内
Runbookに基づく復旧手順の実行
|
v
[5.振り返り] <-- 翌営業日〜1週間以内
ポストモーテム作成 + 再発防止策の合意
※ 各ステップの時間目標はSLA Tierに応じて調整。障害検知の自動化
障害検知の自動化は、オーケストレータのコールバック機能を使うのが最もコストパフォーマンスの良い方法です。B-03(Airflow入門)やB-04(Dagster入門)で解説しているように、DAG失敗時にフックを呼び出し、Slackやメール、PagerDutyへ通知を飛ばせます。サイレント障害を検知するには、dbt testやGreat Expectationsといったデータ品質チェックを通常パイプラインに組み込むことが不可欠です。
# Airflow DAG失敗時のSlack通知設定
from airflow.providers.slack.notifications.slack import SlackNotifier
from airflow.models import DAG
from datetime import datetime
dag = DAG(
dag_id="sales_daily_etl",
start_date=datetime(2026, 1, 1),
schedule="0 2 * * *",
on_failure_callback=SlackNotifier(
slack_conn_id="slack_default",
channel="#data-alerts",
text="ETL failed: {{ dag.dag_id }} / {{ ts }}",
),
)上記の設定により、DAGが失敗した瞬間にSlackの#data-alertsチャンネルへ通知が飛びます。「通知が多すぎて無視されるアラート疲れ」を避けるため、Tier1のDAG失敗のみPagerDuty、Tier2以下はSlackのみ、といった段階的な通知設計を推奨します。
復旧パターンとリカバリ手順
復旧手順はRunbook(標準対応手順書)として文書化しておくことが鉄則です。障害発生時に一からSlackで議論していては時間がかかりすぎるため、「よくある障害パターン」についてはあらかじめ定型化しておきます。C-09(パイプライン設計パターン)で触れている冪等性の設計が、復旧作業の容易さを左右します。
| 障害パターン | 復旧手順 | 所要時間の目安 |
|---|---|---|
| ジョブ失敗(瞬間的エラー) | Airflow UIから手動リトライ | 10分以内 |
| スキーマ変更 | dbtモデル修正+再実行 | 1〜4時間 |
| データ量急増 | クラスターサイズ拡張後リラン | 30分〜2時間 |
| 依存サービス障害 | 復旧待機+回復後リラン | サービス次第 |
| 権限エラー | 権限復元+リラン | 30分以内 |
| サイレント障害 | 原因特定+部分リラン+下流再集計 | 4〜24時間 |
Runbookには、手順だけでなく「確認コマンド」「ロールバック手順」「他チームとの連絡先」も記載します。深夜対応のオンコール担当が、最低限の文脈しかない状態でも復旧作業に着手できるレベルの詳細度が理想です。
ポストモーテムの実践
ポストモーテム(postmortem、事後分析)は、障害対応の「最も重要な部分」です。復旧して終わりではなく、なぜ起こったか・なぜ早く検知できなかったか・なぜ復旧に時間がかかったかを構造的に分析し、再発防止策を合意します。ポストモーテムで最も大切なのは「個人を責めない文化」(blameless culture)で、人を責めた瞬間に次の障害報告が隠蔽されるようになります。
ポストモーテムのテンプレートは、(1)発生時刻とSLA違反の有無、(2)影響範囲、(3)タイムライン(検知・一次対応・復旧)、(4)根本原因(5Whys分析)、(5)再発防止のアクションアイテム、(6)うまくいったこと・改善すべきこと、の6セクションが定番です。アクションアイテムは必ずオーナーと期日を設定し、1か月後にフォローアップする運用が効果的です。
インシデント管理のベストプラクティス
インシデント管理を成熟させるベストプラクティスは、「オンコールローテーションの均等化」「Runbookの継続更新」「ポストモーテムの公開」の三点です。オンコールが特定の担当者に偏ると、その人が退職した瞬間に基盤の信頼性が崩壊します。チーム内で公平にローテーションし、知識を分散させることが持続性の条件です。
Runbookは一度書けば終わりではなく、障害が起こるたびに更新します。ポストモーテムのアクションアイテムに「Runbook更新」を含めるのが習慣化のコツです。さらに、ポストモーテムは社内で公開し、他チームも学びを共有できる状態を作ると、組織全体の耐障害性が向上します。「自分のミスを見られたくない」という心理的抵抗を乗り越えるには、blameless cultureの徹底しかありません。
まとめ
パイプライン障害対応は、事前準備がすべてです。障害検知の自動化、エスカレーションフローの文書化、Runbookの整備、ポストモーテムの習慣化。この4点が揃えば、どんな障害でも冷静に対応できる組織が作れます。障害はゼロにはできませんが、「対応力」は設計と訓練で確実に向上します。
よくある質問
Q. データパイプライン障害の主な原因は?
ソースシステムのスキーマ変更、データ量の急増によるタイムアウト、依存サービスの障害、権限変更の副作用の4つが主要因です。これに加えて「ロジックバグによるサイレント障害」も見逃せない存在で、監視が成功ステータスを返していても中身のデータが異常という事態が起こり得ます。
Q. 障害発生時に最初にやるべきことは?
影響範囲の特定です。どのダッシュボード・レポートが影響を受けるかをデータリネージで即座に把握し、利用者へ通知します。初動での通知は「いま障害対応中」というシグナルを送るだけでも、利用者の信頼維持に大きく寄与します。沈黙は最悪の選択です。
Q. ポストモーテムは必ず実施すべきですか?
SLA違反を伴う障害では必須です。根本原因・影響範囲・再発防止策を文書化し、チーム全体で共有することで組織の耐障害性が向上します。軽微な障害でも、「再発時に同じ原因なら実施」というルールにすると、学習機会を逃さず、かつ負担も現実的な範囲に収まります。