Le taux d'erreur du service mesure le pourcentage de vos services APM qui rencontrent des erreurs côté serveur (réponses HTTP 5xx), ce qui peut empêcher l'utilisateur d'effectuer des tâches critiques telles que les achats, les inscriptions ou l'accès aux données. Cette règle de dashboard vous aide à identifier et à hiérarchiser la résolution des problèmes backend qui ont un impact direct sur l'expérience client.
À propos de cette règle de dashboard
Cette règle de taux d’erreur de service fait partie du niveau 1 (réactif) du modèle de maturité de l’expérience numérique. Il évalue si vos services backend présentent des erreurs de serveur non résolues qui pourraient affecter l'expérience utilisateur et les opérations commerciales.
Pourquoi cela est important : les erreurs de serveur (réponses 5xx) indiquent que votre backend ne peut pas répondre requests des utilisateurs, ce qui entraîne des échecs de transactions, des flux d'utilisateurs interrompus et des opportunités commerciales perdues. Les utilisateurs rencontrant des erreurs de serveur abandonnent souvent leurs tâches et peuvent ne pas revenir.
Comment fonctionne cette règle
Cette règle évalue le pourcentage de services APM qui signalent des erreurs de code d’état HTTP 5xx dans leurs réponses. Il identifie les services backend où des défaillances côté serveur peuvent empêcher l'utilisateur de mener à bien les actions prévues.
Comprendre votre score
- Pass (vert) : un faible pourcentage de services APM rencontrent des erreurs côté serveur
- Échec (rouge) : un pourcentage élevé de services APM présentent des erreurs 5xx non résolues
- Objectif : minimiser les erreurs de serveur sur tous les services, en particulier ceux qui prennent en charge les parcours utilisateurs critiques
Ce que cela signifie :
- Score de réussite : vos services backend répondent de manière fiable requests des utilisateurs et favorisent la réussite des tâches.
- Score d'échec : l'utilisateur peut rencontrer requests ayant échoué, un flux de travail interrompu ou une incapacité à effectuer des actions importantes
Comprendre les erreurs du serveur 5xx
Les erreurs de serveur indiquent des problèmes avec votre infrastructure backend ou votre code d'application :
Types d'erreurs 5xx courants
- Erreur interne du serveur 500 : Défaillance générale du serveur, souvent due à des bogues d'application ou à des exceptions non gérées
- 502 Bad Gateway : le serveur en amont a renvoyé une réponse non valide, fréquent avec les équilibreurs de charge ou les proxys
- 503 Service indisponible : serveur temporairement surchargé ou en maintenance
- 504 Gateway Timeout : délai d'expiration de la demande lors de la communication avec les serveurs en amont
Impact sur l'expérience utilisateur
- Transactions échouées : l'utilisateur ne peut pas effectuer d'achats, d'inscriptions ou de soumissions de données
- Flux de travail interrompu : les processus en plusieurs étapes échouent à mi-chemin, ce qui frustre l'utilisateur
- Données perdues : les soumissions de formulaires ou les saisies utilisateur peuvent être perdues en cas d'erreurs
- Dégradation de la confiance : les erreurs répétées réduisent la confiance des utilisateurs dans votre application
Comment réduire le taux d'erreur de service
Si votre score indique des taux d’erreur de service élevés, suivez ces étapes pour identifier et résoudre les problèmes de backend :
1. Identifier et hiérarchiser les services concernés
- Examiner la présentation du service APM : examiner les services qui signalent des erreurs 5xx
- Évaluer l'impact sur l'entreprise : prioriser les services qui prennent en charge les parcours utilisateurs critiques (paiements, authentification, fonctionnalités principales)
- Analyser les schémas d'erreur : rechercher des tendances dans le timing, la fréquence ou le point de terminaison affecté des erreurs
- Vérifier l'impact sur l'utilisateur : déterminer combien d'utilisateurs sont affectés par les erreurs de chaque service
2. Enquêter sur les causes profondes
Problèmes au niveau de l'application :
- Exceptions non gérées : erreurs de code qui ne sont pas correctement détectées et gérées
- Échecs de connexion à la base de données : épuisement du pool de connexions ou indisponibilité de la base de données
- Épuisement des ressources : fuites de mémoire, surcharge du processeur ou problèmes d'espace disque
- Erreurs de configuration : paramètres incorrects provoquant des échecs d'application
Problèmes au niveau de l’infrastructure :
- Problèmes de capacité du serveur : ressources insuffisantes pendant les pics de trafic
- Problèmes de connectivité réseau : échecs de communication entre les services
- Configuration de l'équilibreur de charge : routage incorrect ou échecs de vérification de l'état
- Pannes de dépendance : pannes de services tiers affectant votre application
3. Mettre en œuvre les correctifs cibles
Résolution immédiate :
- Correction de bugs critiques : résolution des problèmes de code d'application provoquant des erreurs 500
- Mettre à l'échelle les ressources : ajouter de la capacité pour les services surchargés rencontrant des erreurs 503
- Configurer les nouvelles tentatives : implémenter une logique de nouvelle tentative pour les échecs transitoires
- Mettre à jour les contrôles de santé : s'assurer que les équilibreurs de charge acheminent correctement le trafic
Améliorations systématiques :
- Gestion des erreurs : ajoutez des blocs try-catch complets et des réponses d'erreur élégantes
- Disjoncteurs (Circuit breakers) : implémenter des modèles pour gérer les échecs de dépendance avec élégance
- Améliorations du monitoring : ajoutez un logging et des mesures détaillées pour un diagnostic plus rapide
- Planification de la capacité : dimensionner l'infrastructure de manière adéquate pour gérer la charge prévue
4. Établir le suivi des erreurs et leur résolution
Utiliser la boîte de réception des erreurs New Relic :
- Suivi centralisé des erreurs : affichez toutes les erreurs 5xx sur tous les services en un seul endroit
- Regroupement des erreurs : regroupez automatiquement les erreurs similaires pour identifier les modèles
- Attribution des erreurs : relier les erreurs à un déploiement ou à des modifications spécifiques
- Suivi de la résolution : marquez les erreurs comme résolues et suivez la progression de la correction
Mettre en œuvre le suivi des défauts :
- Créer un ticket : consigner les erreurs dans votre système de suivi des problèmes (JIRA, GitHub Issues)
- Attribuer la responsabilité : s'assurer que chaque erreur est attribuée à une équipe ou à un individu responsable
- Suivi de la résolution : monitorer la progression des corrections d'erreurs jusqu'au déploiement
- Mesurer l'efficacité : vérifier que les correctifs réduisent réellement le taux d'erreur
Mesurer l'amélioration
Suivez ces mesures pour vérifier vos efforts de réduction des erreurs de service :
- Réduction du taux d'erreur : pourcentage décroissant de services subissant des erreurs 5xx
- Métriques d'impact utilisateur : amélioration des taux d'achèvement transaction , réduction des plaintes des utilisateurs
- Temps de résolution des erreurs : identification et résolution plus rapides des problèmes côté serveur
- Fiabilité du service : augmentation du temps de disponibilité et des taux de requêtes réussies
Scénarios d'erreur de service courants
Problèmes de connexion à la base de données :
- Problème : Épuisement du pool de connexions ou dépassement du délai d'attente de la base de données provoquant des erreurs 500
- Solution : optimiser le regroupement de connexions, mettre en œuvre une logique de nouvelle tentative de connexion, monitorer les performances de la base de données
Défaillances de tiers-dépendance :
- Problème : des API ou des services externes échouent, ce qui entraîne le renvoi d'erreurs 502/503 par votre application
- Solution : implémenter un disjoncteur, des mécanismes de secours et une gestion appropriée des délais d’attente
Erreurs liées au déploiement :
- Problème : nouvelle sortie introduisant des bugs provoquant des erreurs 5xx
- Solution : améliorer les procédures de test, implémenter le déploiement Canary, ajouter des fonctionnalités de restauration
Problèmes de capacité et d'évolutivité :
- Problème : les pics Traffic submergent les serveurs, ce qui entraîne des erreurs 503
- Solution : mettre en œuvre la mise à l’échelle automatique, les tests de charge et la planification de la capacité
Stratégies avancées de gestion des erreurs
Pratiques de prévention des erreurs
- Tests complets : tests unitaires, tests d'intégration et tests de charge pour détecter les problèmes avant la production
- Révision du code : se concentrer sur les modèles de gestion des erreurs et la couverture des cas limites
- Environnements de simulation : testez minutieusement dans des environnements de type production
- Déploiements progressifs : utilisez les indicateurs de fonctionnalité et le déploiement Canary pour minimiser l'impact des erreurs
Réponse d'erreur automatisée
- Mise à l'échelle automatique : ajoutez automatiquement de la capacité lorsque le taux d'erreur indique une surcharge
- Disjoncteur : isoler automatiquement les dépendances défaillantes pour éviter les pannes en cascade
- Contrôles de santé : suppression automatique des instances défectueuses de la rotation de l'équilibreur de charge
- Intégration d'alertes : notification immédiate lorsque le taux d'erreur dépasse le seuil
Suivi des changements intégration
- Corrélation déployée : connectez les pics d'erreurs à des changements de déploiement ou configuration spécifiques
- Procédures de restauration : capacités de restauration rapide lorsque des modifications introduisent des erreurs
- Analyse d'impact des changements : mesurer l'impact des changements de code sur le taux d'erreur au fil du temps
- Métriques de qualité de sortie : suivre le taux d'erreur comme indicateur clé de qualité pour la sortie
Validation des conditions d'erreur
Assurez-vous que votre suivi des erreurs se concentre sur les véritables problèmes ayant un impact sur l'utilisateur :
Filtrer les faux positifs
- Fin du point de contrôle de santé : exclure requests du système monitoring des calculs d'erreurs
- Appels de service internes : concentrez-vous sur les erreurs rencontrées par l'utilisateur plutôt que sur les communications internes du système
- Erreur attendue : Certaines réponses 5xx peuvent être intentionnelles (mode maintenance, limitation de débit)
- Trafic de robots : filtrez les erreurs du système automatisé qui ne représentent pas un impact réel sur l'utilisateur
Se concentrer sur les erreurs affectant l'utilisateur
- Services orientés clients : prioriser les erreurs dans les services qui servent directement l'utilisateur final
- Flux commerciaux critiques : se concentrer sur les erreurs qui ont un impact sur les activités génératrices de revenus
- Point de terminaison à fort trafic : erreurs d'adresse sur les points de terminaison d'API ou les pages très utilisés
- Entonnoirs de conversion : prioriser les erreurs qui affectent l'inscription des utilisateurs, les achats ou les actions clés
Considérations importantes
- Priorisation de l'impact sur l'entreprise : se concentrer d'abord sur les erreurs affectant les services critiques pour les revenus
- Contexte du parcours utilisateur : Considérez où dans le flux utilisateur les erreurs se produisent et leur impact sur l'achèvement des tâches
- Fréquence et gravité des erreurs : trouver un équilibre entre la correction des erreurs mineures fréquentes et les défaillances rares mais critiques
- Allocation des ressources : s'assurer que les efforts de résolution des erreurs s'alignent sur la capacité de développement disponible
Prochaines étapes
- Action immédiate : identifier et résoudre les erreurs 5xx ayant le plus d'impact sur l'utilisateur
- Amélioration des processus : Établir un flux de travail de tri des erreurs et des procédures de suivi des défauts
- Priorité à la prévention : mettre en œuvre de meilleures pratiques de test et de déploiement pour réduire les nouvelles erreurs
- Amélioration du monitoring : utiliser le suivi des changements pour corréler les erreurs avec la déploiement
- Progression vers le niveau 2 : une fois les erreurs de service sous contrôle, concentrez-vous sur l'optimisation des Core Web Vitals
Pour obtenir des conseils détaillés sur monitoring et la résolution des erreurs de service, consultez notre documentation APM suivi des erreurs et notre guide Boîte de réception des erreurs.