フレームワーク活用ガイドひとことで言うと#
Google が提唱したSRE（Site Reliability Engineering）の原則――SLI/SLO による目標設定、エラーバジェット、トイル削減、ポストモーテム――をデータパイプラインとデータ基盤に適用し、データの鮮度・完全性・正確性を「運に任せず」エンジニアリングで担保するアプローチ。
押さえておきたい用語#
- SLI（Service Level Indicator）
- データの信頼性を測る定量指標。例: パイプラインの成功率、データ到着までのレイテンシ、NULL率など。
- SLO（Service Level Objective）
- SLI に対する目標値。例: 「日次バッチの成功率 99.5% 以上」「データ鮮度 2時間以内」。
- エラーバジェット（Error Budget）
- SLO の余裕分。100% − SLO で算出され、許容される障害の量を表す。バジェットが残っていれば新機能開発に投資し、枯渇したら信頼性回復に集中する。
- トイル（Toil）
- 手作業で繰り返される運用タスクのこと。自動化すべき対象であり、トイル率 50% 以下を維持するのが SRE の基本方針。
- ポストモーテム（Postmortem）
- 障害発生後に行う振り返り文書。原因・影響・タイムライン・再発防止策を記録し、個人ではなくシステムの改善に焦点を当てる。
データ信頼性エンジニアリングの全体像#
こんな悩みに効く#
- データパイプラインの障害が頻発し、分析チームの信頼を失っている
- 障害対応が属人化しており、特定のエンジニアがいないと復旧できない
- 「データがおかしい」と言われて初めて問題に気づく（受動的な検知）
- 品質改善と新機能開発のどちらを優先すべきか判断基準がない
基本の使い方#
すべてのパイプラインに同じ水準を求めるのは非現実的。まず影響度でティアを分ける。
- Tier 1: 売上・課金に直結するデータ（例: 請求データ、KPIダッシュボード）
- Tier 2: 意思決定に使われるデータ（例: 週次レポート、ABテスト結果）
- Tier 3: 探索的分析に使われるデータ（例: ログデータ、アドホック集計）
- Tier 1 から SLI/SLO を設定し、段階的に拡大する
データ領域の代表的な SLI は4つ。
- 鮮度（Freshness）: データが期待通りの時刻までに到着しているか。SLO 例: 「毎朝9時までに更新完了、月間達成率 99%」
- 完全性（Completeness）: レコードの欠損がないか。SLO 例: 「日次データの欠損率 0.1% 以下」
- 正確性（Accuracy）: 値が正しいか。SLO 例: 「売上金額の誤差率 0.01% 以下」
- 可用性（Availability）: クエリが正常に返るか。SLO 例: 「データウェアハウスの稼働率 99.9%」
SLI を自動で計測し、SLO を下回りそうなときにアラートを発火させる。
- 監視ツール例: dbt tests、Great Expectations、Monte Carlo、自作SQLチェック
- アラートはバーンレート（エラーバジェットの消費速度）で発火させると、単発エラーでのノイズを減らせる
- 各アラートに対応するランブック（手順書）を用意し、誰でも初動対応できる状態にする
障害が起きたら個人を責めず、システムの弱点を記録して対策する。
- ポストモーテムのテンプレート: 影響範囲、タイムライン、根本原因、再発防止アクション
- トイル（手作業の運用タスク）を棚卸しし、自動化の優先順位をつける
- エラーバジェットが枯渇したら新機能開発を止め、信頼性回復にリソースを集中させる
具体例#
年商50億円のEC企業。データ基盤チーム4名が120本のパイプラインを運用しているが、月平均18件の障害が発生していた。分析チームからの信頼は低く、「データが来てないんだけど」というSlack通知が毎朝のように飛んでくる状態だった。
Tier 分けの結果:
- Tier 1（6本）: 売上日次集計、在庫同期、レコメンドエンジン用データ
- Tier 2（22本）: マーケティングダッシュボード、ABテスト集計
- Tier 3（92本）: ログ集計、アドホック用中間テーブル
Tier 1 に設定した SLO:
- 鮮度: 毎朝8時までに更新完了（月間達成率 99%）
- 完全性: レコード欠損率 0.05% 以下
- 正確性: 売上金額の誤差率 0.01% 以下
導入した監視: dbt tests で完全性・正確性を毎回チェックし、失敗時に PagerDuty 経由でオンコールに通知。鮮度は Airflow の SLA 機能で監視した。
6か月後の成果:
- Tier 1 の月間障害件数: 8件 → 2件
- 全体の障害件数: 月18件 → 月9件（Tier 2 以下も波及効果あり）
- 分析チームからの信頼度アンケート: 5点満点で2.1 → 3.8に改善
- トイル率: 62% → 38%（手動リトライの自動化が最大の寄与）
従業員200名のBtoB SaaS 企業。データプラットフォームチーム6名が、プロダクトチームからの「新しいデータマートを作ってほしい」という要求と、既存パイプラインの障害対応に追われていた。どちらを優先すべきか基準がなく、マネージャーの感覚で判断していた。
エラーバジェットの設計:
- 課金データパイプラインの SLO: 月間成功率 99.5%
- エラーバジェット: 月間バッチ回数 720回（1時間ごと × 30日）のうち3.6回が許容される障害
運用ルール:
- エラーバジェット残量 50%以上: 新機能開発に工数の60%を割り当て
- エラーバジェット残量 20〜50%: 新機能と信頼性改善を50:50
- エラーバジェット残量 20%以下: 新機能開発を凍結し、信頼性回復に全集中
導入前後の比較（四半期）:
- 新データマートのデリバリー数: 4本 → 6本（優先順位が明確になり無駄が減った）
- 課金データの障害件数: 月平均5.2件 → 月平均1.8件
- チームの残業時間: 月平均32時間/人 → 月平均18時間/人
- 「何を優先すべきか」の議論に費やす会議時間: 週3時間 → 週30分
従業員40名の金融系スタートアップ。規制当局への報告データを扱っており、データの正確性は事業存続に関わる。しかし障害対応は「直ったからOK」で終わることが多く、同じ障害が四半期に3回以上再発するパターンが5件あった。
ポストモーテムの導入:
- テンプレートをNotionに用意: タイトル、影響範囲、タイムライン、根本原因（5 Whys）、再発防止アクション、担当者、期限
- すべてのTier 1障害で48時間以内にポストモーテムを作成するルールを設定
- 毎週金曜に15分の「ポストモーテム読み合わせ会」を実施し、チーム全体で学びを共有
「blame-free」の徹底:
- ポストモーテムから個人名を排除し、「オペレーターがXを実行した」ではなく「手順書にXの記載がなかったため、Yが発生した」と書くルールを制定
- マネージャーが率先して自分の判断ミスをポストモーテムに書き、心理的安全性を示した
1年後の成果:
- 四半期に3回以上再発する障害: 5件 → 0件
- ポストモーテムから生まれた改善アクション: 累計47件（うち自動化施策22件）
- 規制当局への報告データの修正依頼: 年8回 → 年1回
やりがちな失敗パターン#
- 全パイプラインに同じ SLO を設定する — Tier 3 のログ集計に 99.9% の SLO を課すと、アラート疲れでチームが疲弊する。ビジネスインパクトに応じたティア分けが前提
- SLO を 100% にする — 100% は達成不可能であり、エラーバジェットがゼロになるため判断基準として機能しない。最初は 99〜99.5% から始めて実績を見ながら調整する
- 監視だけ入れて対応を整備しない — アラートが鳴っても「誰が対応するのか」「最初に何をするのか」が決まっていなければ混乱するだけ。ランブックとオンコール体制はセット
- ポストモーテムが犯人捜しになる — 個人を責めると報告が隠蔽され、組織の学習が止まる。「blame-free」を掲げるだけでなく、マネージャーが率先して自分のミスを書くことで文化を作る
まとめ#
データ信頼性エンジニアリングは、SRE の SLI/SLO・エラーバジェット・トイル削減・ポストモーテムという4つの柱をデータ基盤に適用することで、「壊れたら直す」から**「壊れにくい仕組みを作る」**へ転換するアプローチである。すべてを一度に整える必要はない。まず最も重要なパイプラインにSLOを1つ設定し、監視とランブックを整備するところから始めれば、チームの信頼性文化は確実に変わり始める。