データSLA設計の本質は、「データの鮮度・品質・可用性について、利用者と提供者の期待値を言語化して合意する」ことです。SLAは技術文書ではなくビジネス契約であり、「KPIダッシュボードは毎朝9時までに前日分が反映されていて、欠損率0.1%以下、月間稼働率99%」といった形で明文化します。SLAがない基盤では、障害のたびに「これは障害なのか仕様なのか」という不毛な議論が発生し、信頼関係は少しずつ削られていきます。

本記事では、データSLAの定義、含めるべき要素、Tier別の設計、合意形成プロセス、監視と違反対応、ベストプラクティスまでを解説します。D-03(データ品質管理)やA-16(データコントラクト)と連動させると、設計の完成度がさらに高まります。

データSLAとは何か

データSLA(Service Level Agreement)とは、データの鮮度(freshness)・品質(quality)・可用性(availability)について、提供者と利用者が取り交わす明示的な合意です。「毎日朝9時までに前日分のデータが更新される」「月次売上テーブルの欠損率は0.1%以下」「BIダッシュボードの稼働率は99%以上」といった具体的な数値目標が含まれます。SLAは一方的な宣言ではなく、双方が合意した約束である点がポイントです。

なぜSLAが必要かというと、暗黙の期待値は必ずずれるからです。データエンジニアは「概ね朝10時までに更新されれば問題ない」と考えている一方、営業は「朝8時には最新データでダッシュボードを見られるはず」と思い込んでいる。このギャップは、明文化された合意がない限り埋まりません。A-17(データプロダクト)の考え方を導入している組織では、SLAはプロダクト仕様書の一部として扱われます。

SLAに含めるべき要素

データSLAに含めるべき要素は、大別して「鮮度」「品質」「可用性」「エスカレーション」の4カテゴリです。技術的な数値目標だけでなく、違反時の対応プロセスまで含めて初めてSLAとして機能します。「SLA違反時は24時間以内に原因報告を書面で提出する」「Tier1のSLA違反は経営会議への報告対象とする」といった運用ルールも必須要素です。

カテゴリ指標例
鮮度(Freshness)SLA更新時刻毎朝9:00までに前日23:59分まで反映
鮮度(Freshness)最大遅延許容時間SLA時刻から30分以内の遅延まで許容
品質(Quality)欠損率必須カラムの欠損率0.1%以下
品質(Quality)重複率主キー重複0件
品質(Quality)一貫性上流と下流の行数差0.01%以内
可用性(Availability)月間稼働率99.5%以上(Tier1)
エスカレーション通知時限違反検知から15分以内に担当者へ通知
エスカレーション報告義務原因と対応策を24時間以内に書面化
【SLA構成概念図】

[利用者] <--- 合意 ---> [提供者(データ基盤チーム)]
    |                         |
    |   [データSLA]            |
    +--> 鮮度: 9:00までに更新 <-+
    +--> 品質: 欠損率0.1%以下 <-+
    +--> 可用性: 月99.5%     <-+
    +--> エスカレーション       |
             |                 |
             v                 v
        [監視システム] --> 違反検知 --> [通知・対応フロー]

※ SLAは提供者の一方的宣言ではなく、利用者との合意事項。

データの重要度に応じたSLA階層設計

全テーブルに同じSLAを適用するのは非現実的です。データには重要度の差があり、取締役会で使うKPIダッシュボードと、個人が一時的な調査で作ったアドホックテーブルでは、求められるSLAが全く違います。一般的には、Tier1(業務クリティカル)、Tier2(業務重要)、Tier3(参考情報)の3階層に分けて、それぞれに異なるSLAを定義します。

Tier対象例鮮度SLA稼働率違反時の対応
Tier1経営KPI、請求データ、規制報告毎日9:00まで99.9%即時対応、1時間以内復旧目標
Tier2部門KPI、営業ダッシュボード毎日12:00まで99.5%当日中対応、4時間以内復旧目標
Tier3アドホック分析、実験データベストエフォート95%次営業日対応

階層設計のポイントは、「Tierを上げるには申請と承認が必要」というルールを設けることです。自然に任せるとすべてのテーブルが「重要です」と主張され、Tier1がインフレを起こします。Tier1への昇格には、オーナー部門の部長承認とデータ基盤チームのキャパシティ確認をセットで求めるとバランスが取れます。

SLAの合意形成プロセス

SLAは書いて配布するものではなく、利用者と一緒に作るものです。合意形成のプロセスは、(1)現状把握、(2)利用者ヒアリング、(3)ドラフト作成、(4)合意会議、(5)文書化と公表、の5段階で進めます。特に重要なのは「現状把握」です。現状でどれくらいの鮮度・品質・稼働率が達成できているかを測定せず、利用者の希望だけを聞いて甘い約束をしてしまうと、運用開始直後から違反連発のSLAが生まれます。

合意会議では、「利用者の希望」と「基盤の現状」のギャップを見える化し、どこまで引き上げるか、それに必要な投資はどの程度か、を同じテーブルで議論します。この過程でSLAの数値は必ず現実的な線に収斂します。合意が取れたら、SLAを社内Wikiで公開し、四半期ごとの達成率レビューをセットにして運用サイクルに組み込みます。

SLAの監視と違反時の対応

SLA監視の基本は、データ鮮度チェックの自動化です。各テーブルの最終更新時刻を定期的にチェックし、SLA時刻を過ぎても未更新の場合にアラートを発する仕組みを整えます。C-10(監視設計)で解説するように、監視対象はデータ層とパイプライン層の両方に仕掛けるのが原則です。

-- データ鮮度チェックSQL例(Snowflake)
SELECT
  table_name,
  MAX(updated_at) AS last_updated,
  TIMESTAMPDIFF('MINUTE', MAX(updated_at), CURRENT_TIMESTAMP()) AS staleness_min
FROM analytics.critical_tables
GROUP BY table_name
HAVING staleness_min > 60;

違反検知時の対応は、D-11(インシデント管理)で解説する一般的なインシデント対応フローに準じます。特にSLA違反は「事実」として記録し、月次・四半期で達成率を集計して公開することが重要です。達成率が慢性的に低いSLAは、目標自体を見直す必要があります。

SLA運用のベストプラクティス

SLA運用を形骸化させない最大のコツは、「四半期ごとの達成率レビュー」と「SLAの継続的な見直し」の二つです。達成率が95%を切ったSLAは、目標が高すぎるか、基盤の実力が追いついていないかのどちらかです。前者なら目標を現実的な線に引き下げ、後者なら基盤強化の投資計画を立てます。「目標を下げるのは敗北」と感じる気持ちもありますが、達成できないSLAを掲げ続ける方が組織の信頼を損ねます。

もう一つの定番は、「SLAに関連するアラート疲れを避ける」ことです。Tier3まで厳密にアラート化すると通知が止まらなくなり、肝心のTier1アラートが埋もれます。Tier1は即時通知(PagerDuty等)、Tier2は営業時間内通知(Slack)、Tier3は日次ダイジェスト、といったレイヤリングが現実的です。D-13(データ鮮度管理)で詳しく解説しています。

まとめ

データSLAは技術文書ではなくビジネス合意書です。数値目標を書くだけでなく、違反時の対応プロセスまで含めて合意し、四半期ごとに達成率をレビューする。この運用サイクルが回って初めて、SLAは基盤の信頼性を支える柱として機能します。Tier1から始め、段階的に対象を広げていく現実的なアプローチが成功の秘訣です。

よくある質問

Q. データSLAとは何ですか?

データの鮮度(いつまでに更新されるか)、品質(精度・完全性の基準)、可用性(ダウンタイム許容量)についてのサービスレベルの合意です。提供者と利用者の双方が合意する必要があり、違反時の対応プロセスまで含めることが求められます。

Q. 全テーブルにSLAを設定すべきですか?

いいえ。ビジネスインパクトの高いTier1テーブル(KPIダッシュボード、請求データ、規制報告)から始め、段階的に拡大するのが現実的です。全テーブルに同じ厳しさのSLAを適用すると、運用負荷が爆発して本当に重要な違反が見過ごされるリスクが高まります。

Q. SLA違反が発生した場合どう対応すべきですか?

事前に定めたエスカレーションフローに従い、影響範囲の特定、利用者への通知、根本原因分析、再発防止策の順で対応します。対応の遅延そのものがSLAのさらなる違反を生むため、通知時限と報告フォーマットをSLA本文に明記しておくと運用がスムーズです。