Blog

Importance des niveaux de gravité pour réduire le MTTR

par Vivian Au 29 septembre 2014 | 7 min de lecture

Article de blog invité par Elle Sidell, Lukas Burkoň et Jan Prachař Testomato Testomato propose des tests automatisés simples pour vérifier les pages et les formulaires des sites web et détecter les problèmes susceptibles de nuire à l'expérience des visiteurs.

Nous savons tous combien la surveillance est importante pour garantir le bon fonctionnement de nos sites web et applications, mais ce n'est qu'une partie du problème. Que faire une fois une erreur détectée ? Comment décider des prochaines étapes ?

Évaluer la gravité d'un problème et s'assurer que la bonne personne est informée sont essentiels pour une résolution rapide et efficace. Nous avons préparé un guide pratique sur l'importance de la gravité des erreurs et sur la manière de définir des niveaux de gravité adaptés à la politique d'escalade de votre équipe.

Que sont les degrés de gravité et pourquoi sont-ils importants ?

En termes simples, le gravité Le niveau d'erreur indique la gravité du problème en fonction de son impact négatif sur les utilisateurs et sur la qualité globale de l'application ou du site web.

Par exemple, une erreur provoquant le plantage d'un site web serait considérée comme très grave, tandis qu'une faute d'orthographe pourrait (dans certains cas) être considérée comme mineure.

La gravité est importante car elle :

  • Vous aide à réduire et à contrôler le niveau des signaux d'alerte.
  • Facilite le processus de gestion des erreurs.
  • Améliore la manière dont vous résolvez les problèmes, et ce, de façon plus efficace.

La mise en place d'un processus d'alerte de gravité peut vous aider à prioriser les problèmes les plus critiques et à éviter de déranger les mauvaises personnes avec des problèmes qui ne relèvent pas de leur domaine de responsabilité habituel.

À plus grande échelle, cela facilite les décisions pour tous quant aux problèmes à résoudre.

Comment créer des règles d'escalade efficaces pour votre équipe

Comprendre l'intérêt d'évaluer la gravité d'un incident est simple, mais mettre en place un processus d'évaluation adapté à votre équipe peut s'avérer complexe. Il n'existe pas de solution miracle : ce qui fonctionne pour vous ne fonctionnera pas forcément pour une autre équipe, même de taille similaire ou appartenant au même secteur d'activité.

Le choix des niveaux de gravité dépend de votre équipe, du projet et de son infrastructure, de l'organisation de votre équipe et des outils utilisés. Par où commencer ?

D’après notre expérience, il y a 3 points principaux à prendre en compte lors de la création d’une procédure d’escalade :

  1. Structure de gravité
  2. structure organisationnelle de l'équipe
  3. Seuils et leur canal de notification correspondant

Les erreurs plus graves nécessitent naturellement un canal de notification plus fiable. Par exemple, vous pouvez choisir d'envoyer un SMS via PagerDuty pour une erreur critique, tandis qu'une erreur mineure peut ne pas déclencher d'alerte afin de limiter les notifications superflues. Dans ce cas, vous pouvez opter pour une notification Testomato, consultable ultérieurement.

1) Structure de gravité

L'un des moyens les plus simples de mettre en place une structure de gravité consiste à identifier les parties les plus critiques de votre site web ou de votre application en fonction de leur valeur commerciale.

Par exemple, les éléments les plus critiques d'une boutique en ligne sont son catalogue de produits et son processus de paiement. Leur dysfonctionnement aurait des conséquences désastreuses pour l'activité de la boutique. Il est donc impératif de traiter ces points en priorité absolue.

Voici une méthode que nous avons trouvée utile pour créer une structure de gravité :

  1. Dressez la liste des fonctionnalités ou éléments de contenu clés de votre site web ou application web (par exemple : catalogue, page de paiement, page d’accueil, inscription, etc.). Il est conseillé de simplifier votre liste afin de faciliter la priorisation des problèmes.
  2. Analysez votre historique d'alertes et identifiez les problèmes courants qui pourraient nécessiter un niveau de gravité différent de celui que vous attribuez habituellement (par exemple, les faux délais d'attente peuvent devoir être considérés comme de faible gravité, même si un délai d'attente serait classé à un niveau supérieur sur votre échelle).
  3. Déterminez les niveaux que vous souhaitez utiliser pour votre échelle (par exemple, faible, moyen, élevé). Vous pouvez ajouter d'autres niveaux en fonction de la taille de votre projet et de votre équipe.
  4. Une fois votre liste et votre analyse terminées, estimez le niveau de gravité de chaque fonctionnalité ou objet de contenu, ainsi que des erreurs récurrentes que vous avez trouvées dans votre historique.

Il n'y a pas de bonne ou de mauvaise façon de procéder. L'essentiel est de savoir comment votre équipe classera les incidents spécifiques et de s'assurer que tout le monde partage la même compréhension.

2) Structure organisationnelle

L'étape suivante consiste à examiner la structure de votre équipe.

Bien comprendre la structure de votre équipe et automatiser la communication des problèmes vous permettra de définir ultérieurement un flux de communication plus efficace. Par exemple, les membres de l'équipe responsables de votre environnement doivent être immédiatement informés des problèmes, tandis qu'un chef de projet souhaitera peut-être être tenu au courant uniquement des problèmes critiques afin d'être informé des difficultés potentielles.

D’après ce que nous avons constaté avec les équipes de projet chez Testomato, les équipes de développement sont généralement structurées selon le tableau suivant :

Taille de l'entreprise/de l'équipe Gestion d'équipe Développement de projet Surveillance
travailleur indépendant client équipe d'une seule personne aucun / manuellement
client
utilisateurs
petite équipe* PDG quelques développeurs aucun
personne célibataire
développeur / administrateur
utilisateurs
grande équipe PDG
CTO
VP Ing
Chefs d'équipe
une équipe de développeurs aucun
utilisateurs
une équipe de testeurs
une équipe d'administrateurs

*On trouverait généralement une petite équipe dans une agence de conception web ou une jeune entreprise.

Pour une structure plus détaillée, voici quelques questions supplémentaires à garder à l'esprit :

  • Qui doit faire partie du processus d'alerte ?
  • Quelles sont les responsabilités de chacun en matière de résolution d'un problème ?
  • À quel moment une alerte exige-t-elle que ce rôle soit intégré au circuit de communication ?

3) Structure de communication

L'une des difficultés majeures liées à la gravité des incidents peut être la mise en place d'une structure de communication, surtout si l'on n'a pas une idée précise de la manière dont les alertes doivent circuler au sein de son équipe.

Voyez les choses ainsi :

  • Structure de gravité : Quelle est la gravité de ce problème ?
  • Structure organisationnelle : À qui incombe cette responsabilité ?
  • Structure de communication : Si l'événement X se produit, comment et quand les membres de l'équipe doivent-ils être contactés ?

L'objectif principal des niveaux de gravité est de garantir que les personnes concernées soient informées des problèmes et puissent contribuer à leur priorisation. La mise en place d'une structure de communication permet d'associer les différents niveaux de gravité aux rôles au sein de l'organisation et d'ajouter des actions plus précises en fonction de l'urgence ou de la fréquence des erreurs. Ainsi, vous vous assurez que les bonnes personnes sont contactées par le canal approprié. Si un intervenant n'est pas disponible, une procédure d'escalade permet d'informer un autre membre de l'équipe.

L'attribution de canaux de notification et la définition de seuils adaptés à l'organisation de votre équipe permettent de traiter les problèmes efficacement et de n'impliquer que les personnes nécessaires à leur résolution.

Par exemple, en cas d'incident critique sur votre site web, un administrateur est immédiatement contacté par téléphone et un SMS est simultanément envoyé au développeur responsable de la fonctionnalité concernée. Si le problème n'est pas résolu au bout de 10 minutes, le responsable d'équipe est également contacté par téléphone.

En revanche, un avertissement pourrait se limiter à l'envoi d'un courriel à l'administrateur de l'équipe et aux développeurs concernés.

Dans PagerDuty, vous pouvez créer deux services Testomato : un service général et un service critique, et les associer à la politique d'escalade requise. Si votre SLA est de 15 minutes pour les incidents critiques, la procédure d'escalade sera plus rapide que pour les incidents généraux.

Voici un aperçu de la manière dont nous utilisons les niveaux de gravité chez Testomato, en utilisant à la fois les notifications PagerDuty et nos propres alertes par e-mail :

Membres de l'équipe : un responsable, 2 administrateurs (en charge de la production) et 2 à 3 développeurs.

En cas d'erreurs sur leur projet, la procédure suivante est utilisée :

PagerDuty – SMS et appels téléphoniques

  • Toutes les erreurs sont envoyées à PagerDuty.
  • PagerDuty a immédiatement envoyé un SMS aux deux administrateurs.
  • Au bout de 5 minutes, un administrateur est appelé selon le planning d'astreinte.
  • Au bout de 15 minutes, un chef d'équipe est également appelé.
  • PagerDuty ne contacte pas les développeurs.

Testomato – Courriel

  • Les erreurs et les avertissements sont envoyés sous forme de notifications par e-mail Testomato aux administrateurs et aux développeurs.
  • Les avertissements sont envoyés uniquement par courriel.
  • Les développeurs reçoivent des courriels concernant les erreurs et les avertissements afin de rester informés des problèmes de production.

Nous espérons que cet article vous a été utile ! Quel processus d'alerte de gravité convient le mieux à votre équipe ?