Points clés à retenir

  • Le terme « temps d'arrêt des données » temps d'arrêt les périodes pendant lesquelles les données sont manquantes, inexactes ou indisponibles à des fins opérationnelles.
  • temps d'arrêt prolongés temps d'arrêt la confiance dans les analyses et peuvent entraîner des défaillances opérationnelles coûteuses ainsi que prise de décision mauvaises prise de décision.
  • observabilité proactive des données observabilité et de résoudre rapidement les problèmes liés aux pipelines, ce qui réduit considérablement la durée des temps d'arrêt.
  • En surveillant la fraîcheur, le volume et les modifications apportées au schéma, les entreprises peuvent garantir un accès continu à des données fiables.

La définition de Data temps d'arrêt

Le temps d'arrêt des données désigne toute période pendant laquelle les données sont inexactes, manquantes, incomplètes, retardées ou autrement indisponibles pour l'utilisation. Ce temps d'arrêt peut affecter les analyses internes, les tableaux de bord destinés aux clients, les systèmes de décision automatisés ou les pipelines d'apprentissage automatique.

Contrairement aux p temps d'arrêt s système traditionnelles, qui sont souvent clairement mesurables, l'temps d'arrêt des données peut être silencieuse et insidieuse. Les pipelines de données peuvent continuer à fonctionner, les tableaux de bord peuvent continuer à se charger, mais les informations traitées ou affichées peuvent être erronées, incomplètes ou en retard. Cela rend la situation d'autant plus dangereuse que les problèmes peuvent passer inaperçus jusqu'à ce qu'ils causent des dommages importants.

3 causes liées aux données temps d'arrêt

Pour prévenir l'temps d'arrêt , il est essentiel d'en comprendre les causes profondes. Celles-ci se répartissent généralement en trois grandes catégories :

1. Pannes techniques

Il s'agit notamment de problèmes d'infrastructure ou de système qui empêchent la collecte, le traitement ou la transmission correcte des données. En voici quelques exemples :

  • Pipelines ETL (extraction, transformation et chargement) défaillants.
  • Les pannes de serveur ou les pannes de nuage.
  • Les modifications de schéma qui rompent les dépendances de données.
  • Problèmes de latence ou de délai d'attente dans les API et les sources de données.

Même les systèmes de données les plus sophistiqués peuvent connaître des temps d'arrêt s'ils ne sont pas correctement entretenus et surveillés.

2. Erreurs humaines

L'homme est souvent le maillon faible de tout système, et les systèmes de données ne font pas exception. Les erreurs les plus courantes sont les suivantes :

  • Travaux ou scripts mal configurés.
  • Suppression ou modification involontaire de données.
  • Logique incorrecte dans les transformations de données.
  • Mauvaise communication entre les équipes d'ingénieurs et les équipes commerciales.

En l'absence de contrôles et de processus appropriés, même une erreur mineure peut entraîner des problèmes majeurs de fiabilité des données.

3. Facteurs externes

Parfois, des événements indépendants de la volonté de l'organisation contribuent au temps d'arrêt données. Il s'agit notamment de

  • Défaillances des fournisseurs tiers.
  • Changements réglementaires affectant le flux ou le stockage des données.
  • Les incidents de cybersécurité tels que les attaques de ransomware.
  • Catastrophes naturelles ou pannes d'électricité.

Même s'il n'est pas toujours possible de les éviter, l'impact de ces événements peut être atténué grâce à une préparation adéquate et à des redondances.

Comment prévenir Data temps d'arrêt

La prévention du temps d'arrêt des données nécessite une approche holistique qui associe la technologie, les processus et les personnes.

Configurez l'observabilité des données sur vos systèmes les plus critiques jeux de données

Sélectionnez les 10 à 20 tables dont dépendent vos tableaux de bord, rapports et modèles d'IA les plus importants. Configurez des alertes sur chaque table pour :

  • Actualité : la table n'a pas été mise à jour à l'heure prévue.
  • Volume : le nombre de lignes diminue ou augmente de manière significative par rapport à sa fourchette habituelle.
  • Schéma : une colonne est ajoutée, supprimée ou son type est modifié.
  • Répartition : les valeurs s'écartent de leur tendance historique.

Utilisez la détection « anomalie » en complément des seuils statiques afin de repérer les changements pour lesquels aucune règle n’a été définie. Redirigez chaque alerte vers le responsable désigné de l’ jeu de données concernée plutôt que vers un canal partagé. Désactivez les alertes pendant les fenêtres de maintenance planifiées afin d’éviter les fausses alarmes.

Données de test au sein de vos pipelines

Ajoutez des contrôles à chaque étape de transformation afin que les données manifestement erronées ne soient jamais transmises :

  • Les tests de schéma permettent de vérifier que les colonnes et les types de données correspondent bien à ce qui était prévu.
  • Les tests de valeur nulle et d'unicité permettent de détecter les clés manquantes et les enregistrements en double.
  • Les tests de plage et de référencement permettent de détecter les valeurs impossibles et les lignes orphelines.
  • Les contrôles de fraîcheur permettent de vérifier que les données sources sont bien arrivées avant l'exécution de la tâche.

Exécutez-les avec les tests dbt ou Great Expectations dans le cadre de chaque tâche. Lorsqu'un test échoue, arrêtez la tâche ou mettez le lot en quarantaine au lieu de transmettre les lignes erronées en aval.

Éviter les ruptures de schéma grâce aux contrats de données

Commencez par toutes les sources dont les modifications de schéma ont provoqué des dysfonctionnements au cours des 90 derniers jours. Définissez pour chacune d’elles un contrat de données précisant le schéma, les exigences en matière d’actualité des données, les règles de qualité et le responsable. Effectuez des vérifications de ces contrats dans le cadre de l’intégration continue (CI). Ainsi, une modification entraînant une rupture de compatibilité échouera à la validation avant sa mise en production, plutôt qu’après une panne de l’ tableau de bord .

Les produits et contrats de données Actian s'appuient sur la norme Open Data Contract Standard (ODCS) v3.1.0. Les équipes peuvent adopter une approche « contrat d'abord », en définissant les spécifications avant le transfert des données, ou une approche « données d'abord », en intégrant des « jeux de données s » existantes sans modifier les pipelines.

Renforcer les données gouvernance

  • Attribuez un responsable désigné à chaque « jeu de données » et pipeline critique, et ajoutez ce responsable à la chaîne d'alerte.
  • Répertorier et classer les données afin que les équipes sachent ce qui existe et qui en dépend.
  • Effectuez une analyse d'impact sur la traçabilité des données avant de déployer toute modification du schéma ou de la logique.
  • Conservez les définitions métier dans un glossaire partagé afin que la logique de transformation corresponde à la manière dont l'entreprise définit chaque terme.
  • Mettre en place des contrôles d'accès, des pistes d'audit et un système de gestion des versions afin que chaque modification puisse être retracée.

Le glossaire et le contrôle de la traçabilité comblent les lacunes liées à l’une des erreurs humaines les plus courantes : la mauvaise communication entre les équipes techniques et commerciales. Lorsque l’ gouvernance e est Embarqué dans la culture des données d’une organisation, les erreurs et les temps d'arrêt s deviennent moins fréquentes et plus faciles à résoudre.

Intégrer la redondance et la haute disponibilité dans les pipelines

  • Réessayer automatiquement en cas d'échecs temporaires et rendre les tâches idempotentes afin qu'une nouvelle exécution ne duplique jamais les données.
  • Envoyer les enregistrements ayant échoué vers une file d'attente de messages perdus au lieu de les supprimer ou de faire échouer le chargement complet.
  • Configurez un basculement pour les sources critiques, afin qu'un flux secondaire prenne le relais lorsque le flux principal est en retard ou indisponible.
  • Répliquez l'jeux de données s critiques dans toutes les régions ou tous les environnements où le coût d'une interruption justifie cette réplication.

Sauvegarder les données et tester la restauration

  • Définissez un objectif de délai de reprise (RTO) et un objectif de point de reprise (RPO) pour chaque service critique jeu de données, en fonction du délai d'attente acceptable pour l'entreprise et du niveau de perte de données qu'elle est prête à accepter.
  • Suivez la règle du 3-2-1 : trois copies de vos données, dont deux sur des appareils locaux différents et une hors site ou dans le cloud.
  • Testez les restaurations selon un calendrier défini. Une sauvegarde non testée n'est qu'une hypothèse.
  • Pour les tables « lakehouse », utilisez des instantanés ou la fonctionnalité « time travel » dans des formats tels qu’Apache Iceberg et Delta Lake afin de revenir en arrière en cas de chargement incorrect.

Surveiller et optimiser les performances du pipeline

Une tâche lente entraîne une « temps d'arrêt » des données, tout comme une tâche ayant échoué : les données arrivent en retard. Suivez ces étapes pour identifier et résoudre les problèmes de performances avant qu’ils n’entraînent des retards :

  • Suivre la durée des tâches et la latence de bout en bout en fonction du niveau d'actualité requis par chaque utilisateur des données.
  • Configurez des alertes pour les délais d'attente liés à l'API et à la source, qui se traduisent souvent par des chargements partiels plutôt que par des échecs complets.
  • Vérifiez régulièrement vos tâches les plus lentes et optimisez les requêtes, le partitionnement ou la planification avant qu'elles ne dépassent leurs délais.

Effectuer des contrôles de santé réguliers et réaliser des opérations de maintenance

  • Vérifiez régulièrement l'état des éléments d'jeux de données s critiques : tests ayant échoué, alertes en cours, objectifs de niveau de service (SLO) non atteints et éléments d'jeux de données sans responsable.
  • Validez les pipelines après chaque modification en amont.
  • Utilisez l'intégration continue et l'déploiement , afin que chaque modification apportée au pipeline soit soumise à des tests avant sa mise en production.
  • Prévoyez les mises à niveau et les correctifs pendant les heures creuses et informez à l'avance les utilisateurs des données des « temps d'arrêt s » prévues.

Tout comme l'infrastructure physique, l'infrastructure de données a besoin d'un entretien régulier pour rester fiable.

Mettre en place un processus d'intervention en cas d'incident lié aux données

Certains incidents continueront de se produire. Un processus clair, en quatre étapes, permet de les résoudre rapidement et d’éviter qu’ils ne se reproduisent :

  1. Évaluez l'incident. Confirmez son ampleur, identifiez les ressources en aval concernées à l'aide de la traçabilité et informez les utilisateurs.
  2. Transmettre l'information au responsable de l'jeu de données , en fixant un délai de réponse précis pour les actifs critiques.
  3. Procédez à une analyse des causes profondes après chaque incident majeur.
  4. Transformez chaque cause profonde en un nouveau test, en une nouvelle mesure de surveillance ou en une nouvelle règle contractuelle afin d'éviter que le même incident ne se reproduise.

Pour une approche étape par étape, découvrez comment procéder au triage des incidents liés aux données.

Plus d'informations sur l'observabilité données en tant que solution

L'observabilité des données s'impose progressivement comme une fonction essentielle dans les architectures de données modernes. Elle marque un tournant, passant d'une surveillance passive à une insight et une prévision actives.

observabilité plateformes provide :

  • Détection automatisée des anomalie .
  • Alertes en cas de dérive du schéma ou de données manquantes.
  • Suivi des données pour comprendre les impacts en aval.
  • Des diagnostics détaillés pour une résolution plus rapide.

En mettant en œuvre des outils d'observabilité , les entreprises obtiennent une insight en temps réel de leur écosystème de données, ce qui les aide à passer d'une lutte réactive contre les incendies à une gestion proactive de la fiabilité.

Mesure des progrès réalisés en matière de réduction de l'temps d'arrêt des données

Pour montrer que l'temps d'arrêt e des données diminue, il faut disposer d'un indicateur chiffré. Une formule couramment utilisée est la suivante :

temps d'arrêt s liées aux données = nombre d'incidents × (temps de détection + temps de résolution)

Avant d'apporter la moindre modification, établissez une base de référence à partir des incidents survenus au cours des 90 derniers jours. Suivez ensuite chaque mois ces indicateurs de l'observabilité :

KPI Ce que cela vous apprend
Nombre d'incidents par mois La prévention est-elle efficace ?
Temps moyen de détection (MTTD) Vérifier si la surveillance fonctionne
Temps moyen de résolution (MTTR) Vérifier si la lignée et les guides d'intervention fonctionnent correctement
Pourcentage d'incidents détectés en premier lieu par les parties prenantes Quelle part de votre « temps d'arrêt » reste encore inexprimée ?

Définissez des SLO pour chaque jeu de données critique. Un SLO définit le niveau de fiabilité sur lequel comptent les utilisateurs. Par exemple : « La table des commandes est mise à jour tous les jours avant 6 h du matin, le nombre de lignes ne devant pas s'écarter de plus de 5 % de la moyenne hebdomadaire glissante. » Suivez la fréquence à laquelle chaque SLO est respecté et examinez chaque manquement dans le cadre de votre processus de gestion des incidents.

Pour établir l'analyse de rentabilité de la résolution du problème, multipliez le nombre d'heures passées à l'temps d'arrêt par le coût pour votre entreprise d'une heure d'indisponibilité d'un tableau de bord, d'un rapport ou d'un modèle d'IA.

Quelle stratégie mettre en œuvre en premier ?

Si vous devez commencer dès demain à réduire l'temps d'arrêt des données, ne choisissez pas une stratégie dans une liste. Choisissez-la en vous appuyant sur votre propre historique d'incidents.

Étape 1 : Analysez les incidents survenus au cours des 90 derniers jours

Extrayez tous les incidents liés aux données survenus au cours des 90 derniers jours à partir des tickets, des fils de discussion Slack et des analyses rétrospectives. Pour chacun d'entre eux, enregistrement deux éléments : ce qui l'a provoqué et qui l'a détecté en premier.

Étape 2 : Alignez votre motif sur un point de départ

Si la plupart des incidents… Commencez par Indicateurs clés de performance à surveiller
ont été identifiés par les acteurs du monde des affaires Surveillance de vos 10 tables les plus critiques Pourcentage constaté par les parties prenantes, MTTD
Ils ont été trouvés rapidement, mais mis en place lentement Historique et guide d'intervention en cas d'incident MTTR
Provient des mêmes ruptures de schéma Contrats de données relatifs à ces sources Nombre d'incidents
Cela provenait d'une logique de transformation incorrecte Essais en cours de fabrication Nombre d'incidents
Dû à des coupures de courant ou à des défaillances de la source d'alimentation Redondance et sauvegardes MTTR

Étape 3 : Vérifiez que vous avez choisi la bonne stratégie

Vérifiez l’indicateur de performance clé (KPI) ciblé par votre stratégie initiale au bout de 30 jours. S’il s’est amélioré, étendez la stratégie à votre prochain niveau d’ jeux de données. Dans le cas contraire, réexaminez la manière dont vous avez classé vos incidents. Les causes peuvent différer de ce que vous aviez initialement supposé ; utilisez donc le tableau ci-dessus pour identifier une meilleure stratégie de départ.

Actian aide à organiser les données et à réduire leur volume temps d'arrêt

L'temps d'arrêt des données constitue une menace sérieuse pour l'efficacité opérationnelle, l'prise de décision, et la confiance au sein des organisations modernes. Si ses causes sont multiples, ses conséquences sont universellement néfastes. En adoptant des outils tels que l'observabilité des données et des solutions comme la plateforme Actian Data Intelligence, les entreprises peuvent détecter plus rapidement les problèmes, prévenir les défaillances et mettre en place des systèmes de données résilients.

Actian propose une gamme de produits et de solutions destinés à aider les entreprises à gérer leurs données et à réduire, voire prévenir, les temps d'arrêt s de données. Parmi les principales solutions et fonctionnalités, on peut citer :

  • Actian Data Intelligence Platform : Une plateforme cloud-native qui prend en charge les analyses des données en temps réel, l'intégration des données et la gestion des pipelines dans des environnements hybrides.
  • Visibilité de bout en bout : Contrôlez la fraîcheur des données, le volume, les modifications de schéma et les performances dans une interface unifiée.
  • Outils de récupération automatisés : Détectez et résolvez rapidement les problèmes grâce à des alertes intelligentes et des flux de travail de remédiation.
  • Accès sécurisé et réglementé aux données : Des fonctions de gouvernance intégrées permettent de garantir l'intégrité des données et la conformité aux réglementations.

Les entreprises qui utilisent Actian peuvent renforcer la fiabilité de leurs données, accélérer leurs analyses et éliminer les perturbations coûteuses causées par des données peu fiables. Réservez une démonstration de la plateforme Actian pour la découvrir par vous-même.

Réserver une démo