ストーリー

データオブザーバビリティの5本柱

監視すべき5つの領域

データオブザーバビリティの全体像:

┌──────────────────────────────────────────────┐
│         データオブザーバビリティ                   │
│                                              │
│  ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌────┐│
│  │ 鮮度  │ │ 量   │ │スキーマ│ │ 分布  │ │系譜 ││
│  │      │ │      │ │      │ │      │ │    ││
│  │ 最終  │ │レコード│ │ 構造  │ │ NULL │ │依存 ││
│  │ 更新  │ │ 数   │ │ 変更  │ │ 率   │ │関係 ││
│  └──┬───┘ └──┬───┘ └──┬───┘ └──┬───┘ └─┬──┘│
│     │        │        │        │        │    │
│     └────────┴────────┴────────┴────────┘    │
│                      │                       │
│              ┌───────┴────────┐              │
│              │  異常検知エンジン  │              │
│              │  (ML + ルール)   │              │
│              └───────┬────────┘              │
│                      │                       │
│              ┌───────┴────────┐              │
│              │ アラート + 対応  │              │
│              │ Slack/PagerDuty │              │
│              └────────────────┘              │
└──────────────────────────────────────────────┘

データオブザーバビリティツール

主要ツール比較

Elementary（dbtネイティブ）の例

# dbt_project.yml
# Elementary パッケージで異常検知テストを定義

models:
  - name: slv_orders
    columns:
      - name: total_amount
        tests:
          - elementary.column_anomalies:
              # 過去30日間の統計から異常を検知
              timestamp_column: order_date
              where: "order_date >= CURRENT_DATE - 30"
              anomaly_sensitivity: 3  # 3σ以上で異常
      - name: order_id
        tests:
          - elementary.volume_anomalies:
              # レコード数の異常を検知
              timestamp_column: order_date
              anomaly_sensitivity: 3

アラート設計

アラートの分類

アラート疲れの防止

データインシデント管理

インシデント対応フロー

データインシデント対応フロー:

1. 検知 (MTTD: Mean Time to Detect)
   └── アラート受信 → インシデント起票

2. 影響分析 (MTTI: Mean Time to Identify)
   ├── リネージで影響範囲を特定
   ├── 影響を受けるダッシュボード/レポートを特定
   └── ステークホルダーに影響を通知

3. 根本原因分析
   ├── リネージで上流をたどる
   ├── 品質チェックログを確認
   └── ソースシステムの変更を確認

4. 修復 (MTTR: Mean Time to Resolve)
   ├── データの修正（再処理/パッチ）
   ├── パイプラインの修正
   └── 品質チェックの追加

5. 振り返り
   └── ポストモーテム → 再発防止策

データSLAの定義

「データオブザーバビリティは、SREのオブザーバビリティをデータに適用したものだ。サイレントデータ障害を検知できる仕組みがなければ、誤ったデータで意思決定するリスクを常に抱えることになる」 — 田中VPoE

まとめ

チェックリスト

• データオブザーバビリティの5本柱を説明できる
• 主要ツールの特徴を比較できる
• アラート設計と誤検知対策を理解した
• データインシデント管理フローとSLAを定義できる

次のステップへ

次は「演習：データガバナンス基盤を設計しよう」です。Step 4で学んだデータ品質、リネージ、カタログ、オブザーバビリティを統合したガバナンス基盤を設計します。

推定読了時間: 30分