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 à la recherche de problèmes susceptibles de nuire à l'expérience d'un visiteur.

Nous savons tous à quel point la surveillance est importante pour garantir que nos sites Web et nos applications restent exempts d'erreurs, mais ce n'est qu'une partie de l'équation. Que faites-vous une fois qu'une erreur a été détectée ? Comment décidez-vous des mesures à prendre ensuite ?

L'évaluation de la gravité d'un problème et la notification de la bonne personne jouent un rôle important dans la rapidité et l'efficacité avec lesquelles les problèmes sont résolus. Nous avons élaboré un guide rapide 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 niveaux de gravité et pourquoi sont-ils importants

En termes simples, le gravité d'une erreur indique la gravité d'un problème en fonction de l'impact négatif qu'il aura sur les utilisateurs et la qualité globale d'une application ou d'un site Web.

Par exemple, une erreur provoquant le blocage d’un site Web serait considérée comme ayant une gravité élevée, tandis qu’une erreur d’orthographe pourrait (dans certains cas) être considérée comme faible.

La gravité est importante car elle :

• Vous aide à réduire et à contrôler la quantité de bruit d'alerte.
• Facilite le processus de gestion des erreurs.
• Améliore l’efficacité et l’efficience avec lesquelles vous résolvez les problèmes.

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

À plus grande échelle, cela rend les décisions sur ce qu’il faut réparer plus faciles pour tout le monde.

Comment créer des règles d'escalade adaptées à votre équipe

Il est facile de comprendre les avantages de l'évaluation de la gravité d'un incident, mais il peut être difficile de créer un processus de gravité adapté à votre équipe. Il n'existe pas de solution miracle pour ce processus. Ce qui fonctionne pour vous peut ne pas fonctionner pour une autre équipe, même si elle est de la même taille ou du même secteur.

La manière dont vous choisissez de configurer vos niveaux de gravité peut varier en fonction de votre équipe, du projet et de son infrastructure, de l'organisation de votre équipe et des outils que vous utilisez. Alors, par où commencer ?

D'après notre expérience, il y a trois éléments principaux auxquels vous devez penser lors de la création d'un processus d'escalade :

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

Les erreurs plus graves nécessiteront naturellement un canal de notification plus fiable. Par exemple, vous pouvez choisir d'envoyer un SMS à l'aide de PagerDuty pour une erreur de gravité élevée, tandis qu'une erreur considérée comme mineure peut ne pas déclencher d'alerte pour aider à réduire le bruit. Au lieu de cela, vous pouvez choisir de le laisser sous forme de notification de Testomato, qui peut être consultée par quelqu'un ultérieurement.

1) Structure de gravité

L’un des moyens les plus simples de configurer 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 système de paiement. Ce sont ces fonctionnalités qui pourraient gravement affecter l'activité d'une boutique en ligne si elles cessaient de fonctionner. Ces problèmes doivent être prioritaires avant tous les autres.

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

1. Créez une liste des fonctionnalités clés ou des objets de contenu de votre site Web ou de votre application Web (par exemple, catalogue, paiement, page d'accueil, inscription, etc.). Il est judicieux de garder votre liste simple pour faciliter la hiérarchisation des problèmes.
2. Analysez votre historique d'alertes et identifiez les problèmes courants qui peuvent nécessiter un niveau de gravité différent de celui que vous attribueriez normalement (c'est-à-dire que les faux délais d'attente peuvent devoir être marqués comme étant de faible gravité, même si un délai d'attente serait classé quelque part plus haut 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 toutes les erreurs récurrentes que vous avez trouvées dans votre historique.

Il n'existe pas de bonne ou de mauvaise façon de procéder. La chose la plus importante à savoir est la manière dont votre équipe va classer les incidents spécifiques et s'assurer que tout le monde est sur la même longueur d'onde.

2) Structure de l'organisation

La prochaine chose que vous voudrez faire est de jeter un œil à la structure de votre équipe.

Une compréhension claire de la structure de votre équipe et l'automatisation de la communication des problèmes vous aideront à définir un flux de communication plus efficace par la suite. Par exemple, les membres de l'équipe responsables de votre environnement doivent être informés immédiatement des problèmes, tandis qu'un chef de projet peut uniquement vouloir être tenu au courant des problèmes critiques afin d'être informé des problèmes potentiels.

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

*Une petite équipe se trouve généralement dans une agence de conception Web ou dans une startup en phase de démarrage.

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

• Qui doit participer au processus d’alerte ?
• Quelles sont les responsabilités de chacun lorsqu’il s’agit de résoudre un problème ?
• À quel moment une alerte nécessite-t-elle que ce rôle soit intégré dans la boucle de communication ?

3) Structure de communication

L’une des parties les plus difficiles des alertes de gravité peut être de mettre en place une structure de communication, surtout si vous n’avez pas une idée précise de la manière dont les alertes doivent circuler dans la structure de votre équipe.

Pense-y de cette façon:

• Structure de gravité : Quelle est la gravité de ce problème ?
• Structure d'organisation: À qui incombe la responsabilité ?
• Structure de communication : Si 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 s'assurer que les bonnes personnes sont informées des problèmes et aident à les hiérarchiser. La définition d'une structure de communication vous permet de connecter différents niveaux de votre structure de gravité aux rôles de votre organisation et d'ajouter des actions plus définies en fonction de la sensibilité temporelle ou de la fréquence des erreurs. De cette façon, vous pouvez garantir que les bonnes personnes sont contactées en utilisant le canal approprié requis pour la situation. Si aucun intervenant n'est disponible, il existe un chemin d'escalade pour garantir qu'une autre personne de l'équipe soit avertie.

L'attribution de canaux de notification et la définition de seuils correspondant à l'organisation de votre équipe signifie que les problèmes sont traités efficacement et n'impliquent que les personnes nécessaires pour les résoudre.

Par exemple, si un incident critique survient sur votre site Web, un administrateur reçoit immédiatement un appel téléphonique et un SMS est envoyé au développeur responsable de cette fonctionnalité en même temps. Si le problème n'est pas résolu après 10 minutes, le responsable de l'équipe recevra également un appel téléphonique.

D'un autre côté, un avertissement peut uniquement justifier l'envoi d'un e-mail à l'administrateur de l'équipe et aux développeurs concernés.

Dans PagerDuty, vous pouvez créer 2 services Testomato – un général et un autre critique – et faire correspondre ces services à la politique d'escalade nécessaire. Si vous avez des SLA de 15 minutes pour les incidents critiques, ce chemin d'escalade sera plus serré que pour les incidents généraux.

Voici un aperçu de base de la façon 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: manager, 2 administrateurs (responsables de la production) et 2-3 développeurs.

Lorsque des erreurs surviennent sur votre projet, utilisez le processus suivant :

PagerDuty – SMS et appel téléphonique

• Toutes les erreurs sont envoyées à PagerDuty.
• PagerDuty a envoyé des SMS immédiatement aux deux administrateurs.
• Après 5 minutes, un administrateur est appelé selon l'horaire d'astreinte.
• Après 15 heures, un chef d'équipe est également appelé.
• Les développeurs ne sont pas contactés par PagerDuty.

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 courrier électronique.
• Les développeurs reçoivent des e-mails concernant les erreurs et les avertissements pour rester informés des problèmes de production.

Nous espérons que vous avez trouvé cet article utile ! Quel processus d'alerte de gravité fonctionne le mieux pour votre équipe ?