Liste de contrôle en 11 points pour définir et respecter les SLA (avec un modèle)

Nous oserions dire qu’aucune équipe n’est trop petite pour élaborer et s’engager à conclure un accord de niveau de service de données, ou un SLA en matière de données. Qu’est-ce qu’un SLA en matière de données ? Il s’agit d’une promesse publique de fournir un niveau de service quantifiable. Tout comme vos fournisseurs d’infrastructure en tant que service (IaaS) s’engagent à garantir un temps de fonctionnement de 99,99 %, vous vous engagez à fournir des données d’une certaine qualité, selon certains paramètres.

Il est important que l’engagement soit public. (Du moins, au sein de l’entreprise). La publicité favorise la responsabilisation, vous aide à aligner toutes les équipes sur ce qui est le plus important et vous permet de mettre en place une structure qui soutient la qualité.

Dans ce guide, nous allons découvrir comment établir votre propre SLA en matière de données.

Des accords de niveau de service formels et écrits rendent vos engagements informels concrets et mutuellement acceptables. Chaque relation de données implique des engagements informels, que vous les exposiez ou non, et très souvent, deux parties peuvent s’accorder sur quelque chose sans se rendre compte qu’elles parlent de différentes choses.

Qu’est-ce qu’un SLA sur les données ? Il s’agit d’un simple document écrit (généralement de 250 à 500 mots) publié dans un espace partagé comme un wiki d’entreprise ou Google Doc. Il doit comporter 6 éléments :

• Objectif : Pourquoi ce SLA de données existe-t-il ? Quels sont les problèmes que vous attendez qu’il résolve et comment espérez-vous qu’il soit utilisé ?

• Promesse : que promettez-vous aux autres équipes ?

• Mesure : Comment allez-vous mesurer le SLA des données, qui le mesurera et quel est le calendrier du SLA ?

• Ramifications : Que se passe-t-il lorsque vous ne respectez pas votre SLA de données ? Qui est responsable et quels types de résolutions sont disponibles, le cas échéant ?

• Exigences : qu’attendez-vous en retour ? Quelles sont les conditions de vos promesses ?

• Signatures : Qui s’engage à respecter le SLA de données ?

Lorsque vous rédigez vos SLA de données, faites-les en aussi peu de mots que possible sans en changer le sens. Cela nécessite beaucoup de modifications, mais nous vous recommandons d’écrire tout-en-un et de revenir les modifier plus tard. En effet, si vous regardez la page trop longtemps, vous risquez de développer ce que les écrivains appellent « l’anxiété de la page blanche » et de la continuer à la repousser. Éliminez tout de suite un projet de mauvaise qualité, n’attendez pas.

Voici un exemple d’accord de niveau de service en matière de données :

L’objectif de ce document est d’établir une promesse publique de la part de notre équipe envers les autres de maintenir une haute qualité des données dans le cadre de paramètres précis. Nous espérons qu’il favorisera la compréhension, qu’il nous aidera à travailler ensemble et qu’il permettra à nos équipes de se responsabiliser mutuellement.

Notre promesse : nous fournirons des données de vente avec un score de qualité des données d’au moins 95 % d’ici 5 h (heure de l’Est) tous les jours afin que l’équipe puisse répondre à des questions du type : « Quelles étaient les ventes d’hier ? » Nous accusons réception de toutes les demandes dans un délai d’un jour ouvrable et les trions par tickets simples et complexes. Nous répondrons aux demandes simples en 3 jours ouvrables et aux demandes complexes en 2 semaines.

Nous mesurerons la qualité des données en comparant les KPI de livraison des données tels que l’heure de début et la fin de l’exécution, le nombre d’enregistrements et le ratio entre de valeurs nulles et le nombre d’enregistrements, ainsi que les scores de distribution et de dérive avec les normes prédéfinies en matière de fraîcheur, d’exhaustivité et de fidélité des données.

Si nous ne respectons pas un SLA de données, dans les trois jours ouvrables, notre équipe publiera une excuse publique, expliquant pourquoi cela s’est produit et sur les mesures précises que nous mettons en place pour le corriger en mettant en place des correctifs.

Pour tenir cette promesse, nous avons besoin de votre aide. Notre équipe a besoin de directives, d’entrée et de commentaires clairs sur la manière dont les données sont utilisées, ainsi que d’un préavis d’au moins quatre semaines pour toute modification complexe demandée.

Veuillez adresser vos questions, commentaires et préoccupations à data-eng@team.com.

Avec détermination,

- Votre équipe d’ingénierie des données

Une fois votre SLA en place (ou peut-être pendant que vous le modifiez), commencez à réfléchir à tout ce que vous devez mettre en place avant de pouvoir vous y tenir.

En voici quelques exemples :

Essayez d’éliminer autant d’ambiguïté que possible de cette phrase. Définissez-le en termes concrets et clairs. Comme nous le voyons, il y a quatre caractéristiques que vous pouvez utiliser pour définir des données de haute qualité. Une fois définies, obtenez l’accord des autres équipes sur cette définition.

Posez-vous la question suivante :

• Quel est l’impact des données de qualité sur l’entreprise ?
• Quelles sont les caractéristiques uniques qui définissent la qualité des données ?
• Quelles sont les caractéristiques des données de mauvaise qualité ?

Pour le suivi, vous aurez besoin d’un outil d’observabilité afin de savoir si certaines parties de votre pipeline sont en panne. Sans contrat, il est assez difficile de mesurer si vous n’avez pas de SLA, et encore moins de diagnostiquer l’origine du problème. Il vous aide également à identifier les erreurs et à apporter des correctifs beaucoup plus rapidement.

Vous pouvez traiter vos SLA de données comme un indicateur de référence : un point central pour guider tout le monde. Mais au sein de ce système, il existe bien sûr une grande complexité cachée, et vous devrez suivre un ensemble de KPI pour vous aider à savoir ce qui se passe en amont et en aval.

Voici quelques recommandations à ce sujet :

1. Mettre en place des tests automatiques pour contrôler la qualité des données dans ses quatre dimensions
   • Pré-production des données de test
   • Tester à chaque étape : exhaustivité, anomalies
2. Mesurez votre capacité à découvrir les problèmes, à y répondre et à les traiter
   • Délai de découverte
   • Délai de résolution
   • Incidents par actif
3. Documenter les causes immédiates et les causes racines de chaque problème
   • Le partenaire données a raté une livraison
   • Temps d’arrêt
   • Tâche bloquée dans une file d’attente
   • Transformation inattendue
   • Problème d’autorisation
   • Erreur d’exécution
   • Programmer les changements

Soyez prudent dans vos engagements. Vous ne pouvez pas être partout et tout préparer, et un SLA de temps de fonctionnement de 99,999 % signifie que vous ne pouvez avoir que 5 minutes de temps d’arrêt par an. Pour y parvenir, vous auriez probablement besoin de plus de effectifs, de plus de visibilité, de plus de redondances et de personnes travaillant 24 heures sur 24.

Vous aurez probablement besoin d’un outil de gestion de tickets comme Jira ou ServiceNow. Cela permet aux utilisateurs de données de créer des tickets, à votre équipe de les suivre et à vous de comprendre la nature de ces tickets afin que vous puissiez trouver des correctifs à long terme et identifier les points problématiques.

Il se peut que vous ne souhaitiez pas le spécifier dans votre document SLA sur les données publiques, mais définissez les propriétaires de la source de données et du pipeline. Ce sont les responsables en dernier ressort en cas de problème. Précisez également ce qui se passe s’ils partent en vacances ou quittent l’entreprise.

Configurez des alertes à afficher dans l’application de messagerie de votre équipe, telle que Slack, ou dans un système de gestion des incidents tel que PagerDuty. Plus vous pouvez fournir de détails sur les incidents dans cette alerte, plus le diagnostique est rapide. Ces alertes vous indiquent rapidement qui d’autre vous devrez faire appel, ou par où commencer votre analyse. (IBM® Databand peut envoyer ces alertes et ajoute des informations et un contexte utiles.)

Supposons qu’un consommateur de données vous dise qu’un tableau est cassé dans son tableau de bord. Comment confirmer et répondre ? Mettez-le par écrit afin d’éviter, en cas d’incident, le problème du spectateur, où tout le monde suppose que quelqu’un d’autre s’occupera de l’incident, et où personne n’agit.

En fonction de la taille de votre équipe et de sa répartition dans le monde, vous pouvez prendre cette question très au sérieux et nommer ce que les services d’urgence appellent un commandant de l’incident. Cette personne devient le PDG de l’incident et dirige toutes les autres. (Cela garantit une réponse coordonnée et évite que plusieurs personnes ne s’attaquent au même problème.)

Le cas échéant, créez des panneaux d’alerte sur les tableaux de bord des utilisateurs afin de pouvoir communiquer l’état du système. En cas de panne, vous pouvez écrire : « Nous subissons une panne. Voici notre délai estimé de résolution. » Cela diffusera des alertes répétées de la part de tous vos consommateurs de données et vous permettra de répondre réellement.

Si vous ne pouvez pas créer de panneaux d’alerte, au moins, désignez une personne clé dans chaque équipe à qui vous pouvez l’indiquer, qui le dira ensuite à toutes les autres.

Surveillez la façon dont vos consommateurs de données utilisent les données (et s’ils les utilisent). Menez des enquêtes occasionnelles, formelles ou informelles, pour évaluer leur confiance dans ces données, et les inviter à faire des suggestions. Pour les consommateurs intéressés, communiquez le contenu de votre feuille de route.

Définissez des périodes de maintenance périodiques au cours desquelles votre équipe examine les raisons des dysfonctionnements et réfléchit à des correctifs. Demandez pourquoi ces problèmes ont pu se produire, effectuez une analyse rétrospective sans faute, documentez vos conclusions, attribuez les correctifs et contrôlez leur efficacité.

Maintenant que tout cela a été calculé, vous êtes prêt à modifier et à réviser vos SLA de données. Publiez-le publiquement sur le wiki de votre entreprise ou dans un endroit partagé, obtenez l’engagement de tout le monde et respectez-le.

Les SLA de données vous aident à rester honnête, vous et votre équipe. Bien qu’il s’agisse d’une promesse publique à d’autres, il s’agit en fait d’un accord bilatéral. Vous acceptez de fournir des données dans des paramètres spécifiques, mais en retour, vous avez besoin de la participation et de la compréhension des gens.

Beaucoup de choses peuvent mal tourner dans l’ingénierie des données, et une grande partie de cela est liée à une mauvaise communication. Documenter votre SLA permet de tout clarifier et de vous permettre d’atteindre votre objectif ultime : instaurer une plus grande confiance dans les données au sein de votre entreprise.

Commencez à détecter les problèmes de santé des données à un stade précoce et cessez de perdre de l’argent à cause des accords de niveau de service (SLA) manqués. Découvrez comment vous pouvez doter vos ingénieurs d’alertes avancées et de systèmes de détection des anomalies afin de résoudre les problèmes de qualité dans l’œuf. Si vous êtes prêt à aller plus loin, réservez une démo dès aujourd’hui.