Stratégies d'astreinte pour les équipes data

L’astreinte d’une équipe data diffère de l’astreinte en ingénierie logicielle. Un ingénieur logiciel en astreinte est généralement protégé de ses autres responsabilités pendant sa rotation. Les équipes data ne le sont généralement pas : la même personne qui gère un incident de qualité des données peut aussi participer à une sprint review, répondre à des questions des parties prenantes et continuer son travail sur les pipelines le même jour. La mécanique d’alerting (couverte dans Elementary Alert Routing with Filters et Elementary Alert Fatigue Reduction) ne fonctionne que si le processus humain autour de ces alertes est conçu pour cette réalité.

Triage : catégoriser avant d’agir

Un cadre de sévérité clair prévient deux modes de défaillance : tout traiter comme urgent (épuise les gens) ou ne rien traiter comme urgent (les parties prenantes détectent les problèmes avant l’équipe).

Les décisions de routage ici se connectent directement à la façon dont vous configurez le routage des alertes par filtres. Les défaillances critiques correspondent au statut d’échec strict (statuses:fail) combiné à un tag de criticité. Les défaillances de sévérité avertissement correspondent à statuses:warn. Les éléments de niveau info peuvent ne pas générer d’alertes en temps réel du tout — ils apparaissent simplement dans un rapport hebdomadaire ou une revue de dashboard.

La catégorisation est la plus importante quand un incident arrive à un moment inopportun. Sans cadre de triage, chaque alerte exige implicitement une attention immédiate. Avec un cadre, la personne en astreinte peut regarder l’alerte, confirmer qu’il s’agit d’un Avertissement, et planifier l’investigation pour le prochain jour ouvrable plutôt que de changer de contexte en pleine tâche.

Runbooks dans les métadonnées de test

Le coût en temps principal lors d’un incident n’est pas la résolution du problème — c’est de comprendre quel est le problème et où chercher. Les runbooks résolvent cela. La question est de savoir où les mettre pour qu’ils soient réellement accessibles quand quelqu’un en a besoin.

Intégrer des liens de runbook directement dans les métadonnées de test signifie qu’ils apparaissent dans l’alerte :

data_tests:
  - unique:
      column_name: customer_id
      config:
        meta:
          description: |
            Duplicate customer IDs detected.
            Runbook: https://docs.company.com/data/customer-dedup
            Contact: @data-platform-team

Quand ce test échoue, l’alerte inclut le champ description avec le lien du runbook. Les nouveaux membres de l’équipe peuvent résoudre le problème sans connaître la codebase ni demander qui contacter. La rotation d’astreinte cesse de nécessiter une mémoire institutionnelle.

Les bons runbooks pour les incidents data couvrent généralement :

• Ce que le test en échec vérifie et pourquoi c’est important
• Les causes racines courantes pour cette défaillance spécifique
• Quel système en amont vérifier en premier
• Où trouver les logs ou dashboards de monitoring pertinents
• Le chemin d’escalade si le runbook ne résout pas le problème

Court et spécifique vaut mieux que complet et générique. Un runbook qui traite les modes de défaillance réels que vous avez observés est plus utile qu’un document exhaustif qui prend 20 minutes à lire.

Métriques qui révèlent si l’astreinte fonctionne

Quatre métriques vous indiquent si votre processus d’alerting et d’astreinte est sain ou se dégrade :

Le volume d’alertes est la baseline. S’il augmente semaine après semaine sans croissance correspondante du nombre de modèles surveillés, quelque chose génère du bruit — probablement des tests qui devraient être réglés, supprimés ou supprimés.

Le taux de faux positifs est celui qui érode la confiance. Quand des alertes se déclenchent pour des conditions que l’équipe a décidé d’accepter, les gens apprennent à les ignorer. Suivez quel pourcentage d’alertes entraîne des changements réels (correctifs, seuils réglés, ou décisions explicites « nous acceptons cela »). Un pourcentage élevé d’alertes avec « aucune action prise » signale que les seuils des tests nécessitent du travail.

Le temps moyen d’acquittement (MTTA) mesure la vitesse de réponse. Si le MTTA se mesure en heures plutôt qu’en minutes, les alertes n’atteignent pas les bonnes personnes, ne les atteignent pas sur un canal qu’elles surveillent, ou il y en a trop pour que quiconque ressente de l’urgence.

Le temps moyen de résolution (MTTR) révèle si les runbooks et la documentation fonctionnent. Un MTTR long signifie souvent que la personne en astreinte doit investiguer depuis zéro à chaque fois — soit parce qu’il n’y a pas de runbook, soit que le runbook est obsolète, soit que le problème ne se reproduit pas assez souvent pour que la mémoire institutionnelle se forme. Quand le MTTR est systématiquement long pour le même problème récurrent, écrivez le runbook.

La note dbt Test Alert Routing and Ownership couvre la pratique complémentaire : convertir chaque nouvel incident sans test en test permanent. Le MTTR s’améliore quand les incidents sont prévenus ; le MTTA s’améliore quand les alertes sont bien routées et formatées.

Structure de rotation pour les équipes data

Quelques patterns qui tiennent compte de la réalité des responsabilités des équipes data :

Associer l’astreinte aux sprints de développement fonctionne bien. L’ingénieur en astreinte gère les incidents pendant sa rotation et utilise tout temps libre pour des améliorations qui réduisent les incidents futurs — réglage des seuils de test, écriture de runbooks pour les incidents qui n’en avaient pas, ajout d’intervalles de suppression aux tests bruyants. Cela évite que le travail d’astreinte ne soit perçu comme purement réactif.

La rotation hebdomadaire avec un document de passation prévient la perte de contexte. L’ingénieur sortant documente les problèmes ouverts, les problèmes récurrents et tout ce que l’ingénieur entrant doit savoir. C’est particulièrement important pour les problèmes « en cours d’investigation » — où quelqu’un a passé une heure à comprendre le problème et la prochaine personne devrait repartir de zéro sans passation.

La réponse par niveaux fonctionne pour les grandes équipes. Les ingénieurs juniors gèrent le triage initial et la résolution en utilisant les runbooks. Les problèmes complexes ou ceux sans runbook escaladent vers des ingénieurs seniors. Cela distribue la charge d’astreinte et expose les ingénieurs juniors à la gestion des incidents de façon structurée.

Pour les petites équipes data où tout le monde est en astreinte par défaut, rendre l’implicite explicite réduit les frictions : définir ce que « astreinte » signifie, quel est le temps de réponse attendu, et ce qui constitue un problème critique justifiant d’interrompre un travail de fond.