Ce guide vous montre comment optimiser vos erreurs afin d'améliorer le taux d'erreur, la détection des erreurs et l'expérience client. Cela fait partie de notre série sur la maturité de l'observabilité.
Présentation
Le suivi des erreurs est la pratique consistant à capturer les erreurs d'application et le taux d'erreur afin que vous puissiez résoudre les problèmes affectant votre expérience client de votre logiciel.
Le suivi de l'IA de ce guide a pour but de permettre à un client ou à une équipe New Relic de :
- Calibrez la façon dont les erreurs sont comprises par New Relic, de sorte que les mesures liées aux erreurs reflètent uniquement les erreurs qui sont significatives pour vous
- Réduire l'incidence des erreurs au fil du temps
Résultat souhaité
Améliorez l'expérience client et la fiabilité en réduisant le taux d'erreur d'application et le délai moyen de résolution (MTTR).
indicateurs de performances clés
Indicateurs clés de performance de l'entreprise
Réduire les erreurs rencontrées par le client améliore la fiabilité. les organisations qui améliorent la fiabilité bénéficient d’un taux de conversion plus élevé (taux d’achèvement du parcours utilisateur) et d’un engagement utilisateur plus élevé. Cela permet à l'organisation de se rapprocher de ses objectifs de revenus (commerciaux) ou d'impact social (à but non lucratif).
Les KPI commerciaux ci-dessus fonctionnent sur l’hypothèse que vous soutenez votre utilisateur en lui fournissant une application frontale. Si vous assistez vos clients via l'API, il peut être possible d'adapter les KPI ci-dessus au type d'entité Transaction. Certaines organisations qui fournissent des API en tant que service utilisent des KPI opérationnels comme ceux ci-dessous pour promouvoir la qualité de leur offre.
Indicateurs de performance opérationnels
Prérequis
Installation et configuration requises
- Assurez-vous que nos solutions monitoring des applications mobiles , , monitoring sans serveur ou OpenTelemetry reçoivent vos erreurs.
- Cartes sources à jour pour les applications Web
- Symbolisation à jour pour les applications mobiles
Établir l'état actuel
Créez une workload pour vos applications
Définissez la liste des applications et des services pour lesquels vous essayez d’optimiser les erreurs. L’équipe qui mène le processus d’optimisation des erreurs doit avoir l’entière responsabilité et le contrôle de ces applications et services. Une fois que vous avez décidé, définissez une workload pour ces entités.
la charge de travail est un groupe d'entités (applications, instances, etc.) dont une équipe spécifique est responsable. Ils vous permettent de consulter les données uniquement pour l’entité sur laquelle vous pouvez faire quelque chose. Nous baserons la majeure partie de notre travail à l'avenir sur la workload que vous avez définie ici.
Il ne faut que quelques minutes pour configurer une workload. Voir les instructions workload .
Si vous êtes déjà familiarisé avec la charge de travail et préférez diviser vos applications et services en plusieurs charges de travail, vous le pouvez. Suivez simplement les étapes ci-dessous pour chaque workload.
Créez un niveau de service pour votre workload
niveau de service vous permet de configurer et de visualiser facilement les objectifs de niveau de service (SLO) pour un groupe d'entités donné. L'utilisation du niveau de service est une façon de monitorer et de communiquer le succès de votre projet de gestion des erreurs.
Depuis votre workload, accédez à l’onglet Service levels. Créer un niveau de service qui mesure le taux d'erreur pour chaque entité de la workload. Ceci est configuré à l’étape 2 dans l’interface utilisateur du niveau de service. Pour chaque niveau de service, utilisez les clauses WHERE pour filtrer les bonnes requests ou les erreurs qui ne doivent pas être prises en compte.

Utilisez le niveau de service pour suivre vos progrès par rapport au taux d'erreur actuel
En utilisant le processus documenté ci-dessus, vous avez créé un niveau de service basé sur votre taux d'erreur actuel.
- La colonne SLO vous montre le taux d'erreur cible que vous avez sélectionné à l'aide d'une base de référence.
- Le mode d'affichage opérationnel vous montre les performances récentes par rapport à votre objectif.
- Le mode d'affichage Période par période vous montre les performances par rapport à votre objectif sur une période plus longue.
- Vous pouvez mettre à jour le taux d'erreur cible au fur et à mesure que des améliorations sont apportées.

Processus d'amélioration
- Identifier les erreurs sans conséquence
- Supprimez les erreurs sans conséquence de votre taux d'erreur
- Configurer des alertes de taux d'erreur
- Établir une liste de héros en erreur
- Trier les erreurs à l'aide de la boîte de réception des erreurs
- Erreurs de lien vers JIRA
- Erreurs de lien vers Slack
- Utiliser CodeStream
Identifier les erreurs sans conséquence
Explorez vos erreurs de la manière qui vous convient le mieux. Vous pouvez le faire en utilisant :
- Vues prêtes à l'emploi pour APM, monitoring des applications mobiles, erreurs JavaScript, monitoring sans serveur et OpenTelemetry
- Erreurs Boîte de réception filtrée en fonction de votre workload
- Types de données NRQL tels que
TransactionError
,JavaScriptError
,MobileRequestError
,AwsLambdaInvocationError
,Span
Supprimez les erreurs sans conséquence de votre taux d'erreur
Vous pouvez supprimer les erreurs qui n'ont pas d'importance de deux manières :
- Empêchez leur ingestion à l'aide de la configuration (APM uniquement) ou à l'aide de règles de suppression. Cette approche ne fonctionne que pour les erreurs dont vous êtes certain qu'elles n'ont pas besoin d'être capturées. L’avantage supplémentaire de cette approche est la réduction de l’ingestion d’erreurs bruyantes.
- Utilisez NRQL pour filtrer les erreurs des calculs de niveau de service. Faites-le en ajoutant un filtre de mauvaises réponses à la clause WHERE. Assurez-vous de redéfinir le niveau de service si cela améliore considérablement le taux d’erreur. Cela améliorera la précision des alertes d’erreur.
Configurer des alertes de taux d'erreur
Passez en revue chacun des niveaux de service configurés dans Créer un niveau de service pour votre workload et créez une alerte pour avertir l'équipe lorsque le taux d'erreur augmente au-delà d'un taux acceptable.
Établir une liste de héros en erreur
Les alertes vous permettront de savoir si vous respectez les niveaux actuels de performances en matière d'erreur, mais ne vous aideront pas à les améliorer. Pour améliorer le sentiment des clients, créez un processus où les erreurs sont examinées quotidiennement par un membre de votre équipe. Le héros de l'erreur devrait :
- Concentrez-vous d’abord sur les erreurs qui se produisent au-dessus de la ligne de flottaison. Pour un processus de révision quotidien, cela signifie se concentrer sur les erreurs qui se sont produites uniquement au cours des dernières 24 heures.
- Trier les erreurs à l'aide de la boîte de réception des erreurs
Trier les erreurs à l'aide de la boîte de réception des erreurs
La boîte de réception des erreurs est un endroit unique pour détecter, trier et agir de manière proactive sur toutes les erreurs avant qu'elles n'affectent les clients. Les erreurs similaires seront regroupées pour éviter la duplication du travail et vous permettre de hiérarchiser les erreurs par nombre d'occurrences.
Lorsque vous accédez à la boîte de réception des erreurs, assurez-vous de sélectionner votre workload afin de ne voir que les erreurs pertinentes pour votre équipe.
Prévoyez un moment régulier pour parcourir la boîte de réception des erreurs en équipe. Pour commencer, une fréquence quotidienne ou plusieurs fois par semaine est logique, car vous aurez de nombreux groupes d'erreurs à parcourir. Plus tard, une fréquence hebdomadaire ou bimensuelle peut être plus appropriée.
Parcourez les erreurs une par une en cliquant sur l'écran des détails des erreurs lorsque cela est nécessaire pour obtenir plus d'informations telles que la trace, les logs, etc. Cela indiquera soit la cause de l’erreur, soit un point de départ pour une enquête plus approfondie.
Après une brève discussion, vous pourrez peut-être marquer le groupe d’erreurs comme l’un des suivants :
- Ignorer : à utiliser lorsque l’erreur n’est pas problématique. Cela masquera le groupe d’erreurs de la vue de la boîte de réception à partir de ce moment.
- Résolu : à utiliser lorsque l’erreur était le résultat d’un problème connu qui a maintenant été résolu. Cela supprimera le groupe d’erreurs de la liste, sauf si cela se reproduit. Si cela se reproduit, il faudra repenser le correctif mis en place précédemment.
Remarque : ignorer et/ou résoudre les erreurs via la boîte de réception des erreurs ne les empêchera pas d'être comptabilisées dans le taux d'erreur métrique.
Si aucun des statuts ci-dessus ne convient, attribuez l’erreur au membre de l’équipe approprié pour une enquête plus approfondie et une résolution. Ce membre de l’équipe peut mener une enquête plus approfondie à son rythme, en mettant à jour les notes du groupe d’erreurs avec sa progression et/ou en demandant de l’aide aux autres membres de l’équipe via la section notes.
Lors de la prochaine réunion de tri, vous pourrez revoir ces groupes d'erreurs pour voir s'ils peuvent désormais être marqués comme résolus. Au fil du temps, vous devriez commencer à voir apparaître moins de nouveaux groupes d’erreurs et une évolution positive de vos KPI.
Erreurs de lien vers JIRA
À mesure que vous rencontrez des erreurs plus spécifiques ou plus complexes, vous pourriez avoir besoin de demander de l’aide à d’autres équipes. Lier la boîte de réception des erreurs à Jira peut aider à résoudre ce problème. Connectez votre boîte de réception d'erreurs à Jira pour vous permettre de créer facilement des tickets connectés à des groupes d'erreurs. Vous pouvez contrôler les informations envoyées à Jira via les modèles Jira.
Erreurs de lien vers Slack
À mesure que la vitesse des erreurs arrivant dans la boîte de réception des erreurs diminue, une session d'équipe régulière peut ne plus être une bonne utilisation du temps. Une alternative consiste à lier la boîte de réception des erreurs à Slack et soit a) désigner une personne tournante pour monitorer le canal et résoudre/ignorer/attribuer des groupes d'erreurs au fur et à mesure qu'ils arrivent, soit b) permettre à l'équipe de répondre de manière proactive aux groupes d'erreurs.
Utiliser CodeStream
Bon nombre de vos groupes d’erreurs nécessiteront des modifications de code pour être résolus. Connectez CodeStream à votre compte New Relic pour ouvrir le code incriminé directement dans votre IDE afin d'enquêter directement sur le code. Vous pouvez également laisser des notes et des commentaires sur des lignes de code spécifiques pour que les développeurs puissent les examiner et vice versa.
New Relic avec CodeStream vous offre plus de contexte sur vos groupes d'erreurs, comme la possibilité de voir les numéros de version ou de valider les SHA. De plus, l'utilisation de la boîte de réception des erreurs comme emplacement centralisé pour identifier, discuter et rectifier les problèmes de code vous permet de répondre efficacement aux problèmes de code et d'éviter de dupliquer le travail.
Réalisation de la valeur
Révisez les taux d’erreur chaque semaine à mesure que vous progressez dans la pratique. À mesure que le taux d'erreur diminue, vous devriez constater un délai moyen de résolution (MTTR) plus rapide et une satisfaction accrue des clients.