「朝7時、Slack のアラートチャンネルが赤い ❌ で埋まっている。 の DAG が連鎖的に全滅。」── 一見悪夢だが、原因はだいたい最初の1ジョブの小さなエラー。あとはタスクの依存関係に沿って雪崩のように倒れていきます。
あの時こうすれば良かった、と思う症状
・夜中の通知で寝不足 ／ ・「朝のダッシュボードが昨日のまま」と社内から ／ ・1個のソース がたまにエラーで全パイプライン停止 ／ ・「とりあえず手動で再実行」が文化になってる
起きる仕組み（典型パターン）
- 1ソース API レートリミット：朝の集中アクセスで 429 エラー → 上流ジョブ失敗 → 下流が all_success トリガで止まる
- 2スキーマドリフト：データソース側に新カラム → ロード処理が NULL でこける（次回 EP.05）
- 3ストレージ容量切れ：tmp ディスクや のロード制限
- 4認証期限：サービスアカウントの credential 失効
- 5コンテナイメージ消失：依存イメージが registry から消えた
- 6 中間モデル test 失敗：1個の test 失敗で下流 all 中止
調査手順
- Airflow / Dagster の Gantt 表示：失敗の起点（最初に倒れたタスク）を特定
- ログを根元から：「最初のエラータスク」のログだけ詳しく読む。下流のは「上流失敗のため停止」で原因はそこにない
- 外部依存のステータス：ソース （Salesforce 等）のステータスページを確認
- 直近のデプロイ：昨日の master マージで何か変わったか
- リソース監視： Trusted Advisor / Stackdriver でリソース起因かチェック
短期対処（朝7時の動き）
- 1戦線整理：失敗タスク一覧を Slack に貼って共有（「今分かってる範囲」「これから調べる範囲」）
- 2再実行優先順位：本日中に必要なもの（朝のダッシュボード）を先に手動再実行
- 3応急対応：ソース取得できないなら昨日のデータでダッシュボード生成 + 「データ古い旨」のバナー
- 4マネージャに第1報：「失敗確認、原因調査中、〇時までに復旧見込み」
中長期対策（再発防止）
- リトライ + 指数バックオフ：API レートリミットは大半これで解決
- サーキットブレーカー：上流が連続失敗したら下流を起こさず alert のみ
- 冪等な設計：再実行で副作用が発生しないように（同じ insert を何度しても結果同じ）
- 設計：「朝9時までにダッシュボードが最新」を明示し、実績を測る
- カナリア・段階デプロイ：本番前に dev 環境でフルラン
- On-call ローテーション + Runbook：誰が起きるか、何を見るかを明文化
- Dead Letter Queue：失敗したメッセージを別キューに退避し、本流は止めない
ふくふくの進め方
障害復旧 + 再発防止のセットで2-4週間：① 全 DAG の依存グラフを描き ② 直近3ヶ月の障害頻度マップ ③ 致命傷タスクの top10 にリトライ・キャッシュ・サーキットを実装 ④ Runbook 化。お問い合わせ対応では「まず昨日の朝のログをください」から始めます。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。