Attribuer des erreurs aux équipes et mettre à jour le statut des erreurs

Affecter l'erreur à la bonne équipe

À partir de la page Error group summary , vous pouvez affecter le groupe d’erreurs à l’équipe appropriée.

Attribuer une erreur à une personne ou à une équipe élimine les éventuelles erreurs de communication. Les informations qui vous ont aidé à résoudre l'erreur sont transmises directement au propriétaire du code, lui permettant de reprendre là où vous vous êtes arrêté.

La mission est ensuite remise à l'équipe par courrier électronique :

Marquer le statut de l'erreur

Une fois attribuée, vous pouvez mettre à jour le statut d'une erreur.

Cette fonctionnalité présente quelques avantages différents :

• Si un groupe d’erreurs est attendu, vous pouvez marquer l’erreur comme Ignored. Les erreurs attendues sont connues de vous et de l'équipe : il peut s'agir de bogues non critiques ou d'erreurs associées à l'utilisateur final (comme quelqu'un utilisant un mot de passe incorrect).
• Nous vous recommandons cependant de résoudre erreurattendue autant que possible. Ignorer un groupe d’erreurs n’empêche pas New Relic de signaler l’erreur à l’avenir, ce qui contribue à votre ingestion de données.
• New Relic suit l’état d’une erreur au fil du temps. Par exemple, si vous marquez un groupe d’erreurs comme Resolved mais qu’il apparaît ultérieurement avec un nouveau déploiement, New Relic marquera cette erreur comme Regression.

Enquêter sur la cause profonde

Que vous réduisiez les erreurs courantes ou que vous réagissiez à une panne critique, vous suivez des données qui vous mènent à la cause directe d'une erreur. Vous avez peut-être réparé la fuite du tuyau qui a inondé votre jardin, mais vous n'avez pas encore découvert la cause de la fissure.

Lorsque vous attribuez des groupes d’erreurs à des équipes, il est plus facile d’organiser des rétrospectives où chacun identifie les processus qui ont conduit à une panne. Pour en revenir à votre tuyau fissuré : vous rencontrez un plombier et il vous dit que les arbres de votre jardin poussent dans tous vos tuyaux. Les rétrospectives où tout le monde peut consulter les mêmes données conduisent naturellement à des améliorations du workflow global de votre équipe.

Voici quelques causes courantes des pannes de service :

• Tests d’assurance inappropriés en pré-environnement de production.

• Ne pas tester chaque fonction ou méthode d’une base de code pour garantir que les résultats sont ceux attendus.

• Incompréhension des exigences de dépendance en amont, de la capacité ou de ses limites. Par exemple, si une requête de base de données fonctionne parfaitement en préproduction avec des charges plus petites, mais qu'elle commence à ralentir sous l'effet du stress.

• Manque de planification des capacités. Peut-être que votre code réussit tous ses tests habituels sous des charges ordinaires, mais lorsque la demande atteint un pic, il n'est pas performant.

  La cause profonde peut être aussi variable que le nombre d’équipes existantes. Mais ce qu’il faut retenir, c’est qu’il faut suivre les données, communiquer et creuser plus profondément au-delà de la cause directe.