Cette traduction automatique est fournie pour votre commodité.
En cas d'incohérence entre la version anglaise et la version traduite, la version anglaise prévaudra. Veuillez visiter cette page pour plus d'informations.
La gestion des niveaux de service est la pratique de standardisation des données dans un langage universel. Au sein d’une organisation, la communication entre les parties prenantes peut souvent s’avérer plus difficile que nécessaire. Les services informatiques ne parlent généralement pas dans des termes que les parties axées sur l'entreprise d'une organisation peuvent comprendre et, à leur tour, ils ne communiquent généralement pas dans des termes que les équipes informatiques trouvent utiles. Pour améliorer la fiabilité, résoudre cette barrière linguistique permet d’éviter les problèmes. La gestion des niveaux de service, ou la pratique de normalisation des données dans un langage universel que toutes les parties peuvent comprendre, contribue à y parvenir.
La gestion des niveaux de service s'applique surtout à la pratique du temps de disponibilité, de la performance et de la fiabilité, mais elle s'applique également aux autres pratiques de l'expérience client, de l'innovation et de la croissance et de l'efficacité opérationnelle (apprenez-en plus sur ces pratiques). Quel que soit le domaine que vous souhaitez améliorer, l'utilisation du SLM a deux grands domaines d'impact : les résultats de l'entreprise et les résultats opérationnels.
Les résultats attendus de l'entreprise en termes de fiabilité portent sur la réduction du nombre d'incidents impactant l'entreprise, de leur durée et du nombre de personnes impliquées.
Réduisez le nombre d’incidents perturbant l’activité.
Réduire le Délai moyen de résolution (MTTR) (MTTR).
Réduire le nombre moyen de personnes impliquées (ETP) par incident grave.
Le résultat opérationnel requis en termes de fiabilité se concentre sur la santé de votre produit numérique.
Mesurez le succès opérationnel en fonction du pourcentage d’applications de produits critiques que vous couvrez avec votre niveau de service standard.
Examinez le pourcentage d’adoption des politiques par vos principales parties prenantes.
Concentrez-vous sur ce qui est important pour les parties prenantes, assurez la simplicité et prouvez l'efficacité de la Gestion des niveaux de service.
Pourquoi utiliser Gestion des niveaux de service ?
L’amélioration du niveau de service et de la fiabilité nécessite l’adoption de la pratique par toutes les parties prenantes du service. Cela comprend la gestion de l’ingénierie, la gestion des produits et la gestion exécutive pour montrer rapidement la puissance et la valeur du niveau de service et lancer des discussions sur ce qui compte pour chaque groupe. Les étapes décrites dans ce guide vous permettront d’engager très rapidement des discussions significatives.
Une méthode courante établit d’abord les niveaux de service de performance de sortie et de performance d’entrée pour un produit numérique et ses capacités critiques. Cela implique généralement un niveau de serviceglobal de sortie et d'entrée pour chaque application de point de terminaison (généralement un ou deux), puis environ 4 à 7 niveaux de service de performance de sortie pour les capacités critiques supposées mesurées au point de terminaison de la transaction.
Cette méthode n’interroge pas chaque partie prenante sur ce qui doit et ne doit pas être mesuré, car les enquêtes prennent souvent trop de temps et comportent trop de parties dans des scénarios comme celui-ci. L’important est de commencer avec la base de référence et la clé de transaction comme « capacités ».
Les implémentations réussies du niveau de service démontrent la capacité à mesurer et à communiquer facilement l’état de santé global du système. Cette démonstration initiale montrera l’intérêt d’investir plus de temps pour affiner ce que mesure votre niveau de service. Plus tôt vous fournirez cette démonstration complète, plus tôt vous pourrez parvenir à une adoption généralisée et commencer le processus d’amélioration de la fiabilité en collaboration avec toutes vos parties prenantes !
Jetons un œil à certains des termes courants et définissons nos KPI avant de continuer.
Terminologie
Un niveau de service mesure la performance d'un système. Vous mesurez le niveau de service en utilisant des indicateurs et en les comparant à un ensemble d’objectifs de performance et de résultats attendus.
Nous définissons la Gestion des niveaux de service comme la pratique consistant à rendre compte, à maintenir et à gérer la conformité du niveau de service.
Un SLI (SLI) mesure un niveau de service. Un SLI identifie quelque chose que vous souhaitez mesurer et mesure soit un point de données, soit un composite de points de données. Un SLI représente le plus souvent un pourcentage (%) de transactions ou d'événements réussis. Il mesure le nombre total de bons événements par rapport au nombre total d'événements valides calculés sur une période de temps spécifiée, par exemple 1 heure, 1 jour ou 1 semaine.
Exemples de SLI :
Pourcentage de transactions API de connexion qui se terminent dans les 500 millisecondes.
Pourcentage de transactions API de connexion qui se terminent sans erreur interne du serveur.
Pourcentage de transactions API de connexion qui se terminent dans les 500 millisecondes et sans erreur interne du serveur.
Pourcentage de pings de vérification Synthétique par rapport à l'API de connexion qui réussissent.
Pourcentage de connexions au navigateur qui mènent à la page de destination dans les 3 secondes.
Pourcentage de métriques ingérées qui sont disponibles pour la requête dans les 3 secondes.
Tout ou partie des éléments ci-dessus sont regroupés dans un seul SLI.
Un objectif de niveau de service (SLO) décrit le niveau de service attendu d'un système, d'une tâche ou d'une capacité. Il indique généralement le pourcentage de réussite requis d'un ou plusieurs SLI dans une période donnée.
Exemples de SLO :
L'API de connexion répondra dans les 500 millisecondes et sans erreur 99,99 % du temps chaque semaine.
La capacité de connexion mobile fera la transition vers la page de destination dans les 3 secondes 99,99 % du temps chaque semaine.
L'ingestion de données de métriques sera disponible pour requête dans les 3 secondes suivant la consommation à partir de l'API 99,99 % du temps chaque jour.
Une limite de service est souvent le point d'un système où le consommateur fait une demande via un client, également appelé API externe ou point de terminaison. Les limites de service peuvent également être internes entre deux systèmes distincts, où une collection d'applications répond aux requests d'une autre collection d'applications. Par exemple, un système de gestion des identités peut servir à la fois requests de connexion du client et à l'autorisation d'autorisations pour différentes fonctionnalités.
Types de limites :
Limite de service orientée clients: l'API GraphQL orientée clients. Cette limite vous donne la somme totale des temps de réponse et des métriques de réussite requises pour mesurer l'état des performances, sans qu'il soit nécessaire de mesurer chaque dépendance.
Limite de service interne: dépendance du middleware derrière l'API GraphQL orientée clients. Chaque API de dépendance qui répond au niveau GraphQL compte comme sa propre limite de service interne. Les limites des services internes ne représentent pas l’état global des performances de sortie dans un rapport 1:1. Par exemple, une requête client adressée à l'API GraphQL peut atteindre sept dépendances internes. Une dépendance lente n'affecte pas le temps de réponse total de la requête d'origine.
Un budget d’erreur mesure et communique la conformité de vos objectifs de niveau de service. Nous avons des informations plus détaillées sur cette méthode avancée dans notre documentation Gestion des niveaux de service.
Un budget d'erreur permet de suivre le niveau d'échec de votre service avant de devenir « non conforme ». Vous pouvez utiliser plusieurs méthodes différentes pour définir et mesurer les budgets d’erreur. Le mot « erreur » dans « budget d'erreur » ne désigne pas les erreurs de requête HTTP ou les erreurs d'application, mais fait plutôt référence à « toute requête ou événement incorrect » tel que défini dans vos objectifs de niveau de service.
Remarque: nous vous recommandons d’apprendre d’abord à définir, calculer et communiquer votre conformité au niveau de service avant de mettre en œuvre des budgets d’erreur. Il est très important que vous puissiez établir un objectif pour vos SLI afin de mesurer dans quelle mesure votre SLI répond à votre objectif. Par exemple, vous pouvez vérifier si vous êtes à 500 millisecondes près et sans erreur à 99,99 % sur chacune des requests connexion pendant une période de 24 heures. Si votre résultat de conformité SLI sur 24 heures atteint 99,99 %, vous pouvez alors considérer que votre objectif est atteint.
Références
Google définit un budget d'erreur comme :
« En un mot, un budget d’erreur est la quantité d’erreurs que votre service peut accumuler sur une certaine période de temps avant que votre utilisateur ne commence à être mécontent. Une fois que vous avez défini un objectif pour chaque (SLI) pour vos objectifs de niveau de service (SLO), le budget d'erreur est le reste, jusqu'à 100. » -- Google Cloud - Comment les fenêtres de maintenance affectent votre budget d'erreur — ConseilsSRE
Atlassian définit un budget d'erreur comme :
« Un budget d'erreur correspond à la durée maximale pendant laquelle un système technique peut tomber en panne sans conséquences contractuelles. Par exemple, si votre contrat de niveau de service (SLA) spécifie que le système fonctionnera 99,99 % du temps avant que l'entreprise ne doive indemniser les clients pour la panne, cela signifie que votre budget d'erreur (ou le temps pendant lequel votre système peut tomber en panne sans conséquences) est de 52 minutes et 35 secondes par an. -- Atlassian - Qu'est-ce qu'un budget d'erreur et pourquoi est-ce important ?
Prérequis
Disposez de données à monitorer et à établir des SLI, par exemple via l'instrumentation APM de votre application principale.
Vous pouvez également utiliser le test synthétique de votre application pour générer des données à monitorer sans dépendre des clients.
Bien que cela ne soit pas obligatoire, nous vous recommandons vivement d'acquérir des compétences de base avec les dashboards New Relic et NRQL.