← Retour au blog

SLA de données et qualité gérée

Lucian BLETAN

La fiabilité des données ne s’obtient pas par hasard. Pour les jeux de données critiques, l’approche “au mieux” ne suffit plus. Un SLA (Service Level Agreement) de données formalise l’engagement du producteur envers ses consommateurs. Il définit des objectifs mesurables (SLO) sur la fraîcheur, la disponibilité ou l’exactitude, et est soutenu par des tests automatisés et un processus d’incident clair. C’est la différence entre un simple fichier et un produit de données fiable.

gestion d'incident

surveillance automatisée

engagement de service (sla)

dataset critique

sont vérifiés par

sont vérifiés par

si échec, déclenche

ventes.orders_v

définit des objectifs (slo)

- fraîcheur < 3h
- disponibilité > 99.5%

tests & monitoring

alerte & post-mortem

prérequis

  • Une liste des 10-20 jeux de données les plus critiques et de leurs propriétaires.
  • Un outil simple pour exécuter des tests planifiés (ex: dbt, Airflow, un simple cron).
  • Un canal défini pour la gestion des incidents (ex: une liste de diffusion, un canal Slack, un projet Jira).

idées clefs

  • SLO mesurables: Se concentrer sur des objectifs chiffrés et non ambigus : fraîcheur maximale, pourcentage de disponibilité, latence.
  • Tests de base: Commencer avec des tests simples sur le schéma (pas de colonne manquante) et les bornes (valeurs plausibles).
  • Gestion des erreurs connues: Documenter les problèmes connus et les plans de contournement pour les utilisateurs.
  • Processus d’incident: Définir qui est contacté en cas d’alerte (on-call) et les délais d’intervention attendus.

pas à pas

étape 1: écrire le sla

Le SLA doit être un document court et technique, idéalement un fichier de configuration versionné avec le code du produit de données.

# sla/ventes.orders_v.yml
dataset_id: ventes.orders_v
owner: team-sales-data

# Service Level Objectives (SLO)
slo:
  # La donnée ne doit jamais avoir plus de 3 heures de retard.
  freshness_max_hours: 3
  # Le service doit être disponible 99.5% du temps sur un mois.
  availability_pct_monthly: 99.5

# Marge d'erreur tolérée avant de violer le SLA
error_budget_pct: 1.0

# Qui contacter en cas d'alerte
on_call_contact: "sales-data-oncall@data.pm"

étape 2: instrumenter les mesures

Pour chaque SLO, mettez en place une requête de monitoring simple qui peut être exécutée automatiquement.

-- Requête pour mesurer la fraîcheur actuelle du dataset ventes.orders_v
-- Doit être exécutée toutes les 15 minutes, par exemple.
SELECT
    EXTRACT(EPOCH FROM (NOW() - MAX(order_update_ts))) / 3600 AS current_freshness_hours
FROM
    ventes.orders_v;

étape 3: alerter, investiguer et apprendre

Quand une mesure dépasse un seuil, une alerte doit être déclenchée. Chaque incident est une opportunité d’amélioration.

Processus d’incident simple

  1. Alerte: freshness_hours > 3 -> Une alerte est envoyée à sales-data-oncall@data.pm avec l’ID INC-ORD-FRESH-123.
  2. Accusé de réception: L’ingénieur d’astreinte confirme la prise en charge.
  3. Résolution: Le problème est corrigé (ex: relance d’un job).
  4. Post-mortem: Dans les 48h, un bref rapport est écrit :
    • Résumé du problème.
    • Analyse des causes (méthode des 5 pourquoi).
    • Actions correctives datées et assignées pour éviter que le problème ne se reproduise.

exemples

cas: sla pour une métrique de revenu

Un SLA pour une vue agrégée critique utilisée par le département finance.

# sla/metrics.revenue_daily_v.yml
dataset_id: metrics.revenue_daily_v
owner: team-finance-data

slo:
  freshness_max_hours: 24 # Doit être à jour chaque jour ouvré à 9h
  availability_pct_monthly: 99.9 # Très critique

quality_tests:
  - name: "no_negative_revenue"
    query: "SELECT COUNT(*) FROM metrics.revenue_daily_v WHERE daily_revenue_eur < 0"
    threshold: 0
  - name: "no_future_dates"
    query: "SELECT COUNT(*) FROM metrics.revenue_daily_v WHERE report_date > CURRENT_DATE"
    threshold: 0

erreurs courantes et solutions

  • Symptôme: Les SLA sont vagues et sujets à interprétation (“la donnée doit être de bonne qualité”).

    • Cause: Manque de métriques chiffrées.
    • Correctif: Toujours utiliser des chiffres, des unités et des fenêtres de temps précises (ex: “fraîcheur maximale de 4 heures”).

  • Symptôme: On découvre des problèmes de qualité des semaines plus tard, par hasard.

    • Cause: Absence de tests automatisés.
    • Correctif: Mettre en place au moins 3 tests de base : fraîcheur, non-nullité sur les clés primaires, et bornes sur les métriques importantes.

  • Symptôme: L’équipe d’astreinte est submergée d’alertes inutiles.

    • Cause: Seuils d’alerte trop sensibles ou alertes sur des assets non critiques.
    • Correctif: Définir des seuils réalistes basés sur l’historique. Ne mettre des alertes bloquantes que sur les datasets véritablement critiques.

  • Symptôme: Le même incident se produit tous les deux mois.

    • Cause: Pas de processus de post-mortem ou pas de suivi des actions.
    • Correctif: Rendre le post-mortem obligatoire pour tout incident majeur. Suivre les actions correctives dans un backlog avec des tickets assignés et des dates limites.

faq

  • Quelle est la différence entre un SLA et un SLO ? Le SLA (Service Level Agreement) est le contrat global, l’engagement formel. Le SLO (Service Level Objective) est une métrique précise et mesurable à l’intérieur de ce contrat (ex: availability > 99.5%).

  • Faut-il mettre un SLA sur tous les jeux de données ? Non, ce serait contre-productif. Concentrez vos efforts sur les 10% de datasets qui sont vitaux pour l’entreprise. Pour les autres, une surveillance de base est suffisante.

tags