Ce guide est une introduction pour améliorer vos compétences en matière de diagnostic des problèmes ayant un impact sur les clients. Vous pourrez récupérer plus rapidement des problèmes de performances des applications en suivant les procédures décrites dans ce guide.
Ce guide fait partie de notre série sur la maturité de l'observabilité.
Prérequis
Voici quelques exigences et quelques recommandations pour l'utilisation de ce guide :
Couverture d'observabilité de New Relic :
- Required : APM avec tracing distribué, logs en contexte APM et agent infrastructure
- Recommandé : logs et monitoring réseau (NPM)
Required: Gestion des niveaux de service
Recommandé : une certaine expérience de l'utilisation de New Relic APM, du tracing distribué, des requêtes NRQL et de l'interface utilisateur
Recommandé : vous avez lu ces guides :
Présentation
Avant de commencer à utiliser ce guide, il vous aidera à comprendre ce que vous allez apprendre. Ce guide vous aidera à comprendre :
Comment votre entreprise est impactée par l’amélioration de vos compétences en diagnostic.
Les indicateurs de performances opérationnels clés utilisés pour mesurer le succès.
Comment votre utilisateur final perçoit les différents types de problèmes de fiabilité.
La différence entre la cause directe et la cause sous-jacente d’un problème.
Les étapes de diagnostic de base pour trouver et résoudre les problèmes, qui comprennent :
- Définition du problème – création d’un énoncé de problème
- Trouver la source du problème
- Trouver la cause directe de ce problème
Certaines catégories de problèmes de performances (performances de sortie, performances d'entrée et performances client) et la fonctionnalité New Relic utilisée pour diagnostiquer ces problèmes (APM, Syntheticset monitoring des applications mobiles).
Comment utiliser une matrice de problèmes, qui est une aide-mémoire pour comprendre les problèmes courants et leurs sources probables.
Vers la fin, nous passerons en revue quelques exemples de problèmes de performances, qui devraient vous aider à mieux comprendre ces concepts.
Résultats souhaités
Résumé
La valeur pour l'entreprise est :
- Réduire le nombre d'incidents perturbant l'activité
- Réduire le temps nécessaire à la résolution des problèmes (MTTR)
- Réduire le coût opérationnel de l'incident
La valeur pour les opérations informatiques et SRE est :
- Améliorer le temps de compréhension et de résolution
résultats de l'entreprise
En 2014, Gartner a estimé que le coût moyen des temps d’arrêt informatiques était de 5 600 $ par minute. Le coût cumulé d'un incident ayant un impact sur l'entreprise est déterminé par des facteurs tels que le temps de détection, la fréquence, le temps de réparation, l'impact sur les revenus et le nombre d'ingénieurs chargés de trier et de résoudre l'incident. En termes simples, vous souhaitez moins d’incidents ayant un impact sur l’entreprise, une durée incident plus courte et des diagnostics plus rapides, avec moins de personnes nécessaires pour résoudre les impacts sur les performances.
En fin de compte, l’objectif commercial est de maximiser le temps de disponibilité et de minimiser les temps d’arrêt, le coût des temps d’arrêt étant le suivant :
Downtime minutes x Cost per minute = Downtime cost
Le temps d'arrêt est déterminé par le nombre d'incidents perturbant l'activité et leur durée. Le coût des temps d’arrêt comprend de nombreux facteurs, mais les plus directement mesurables sont les coûts opérationnels et les pertes de revenus.
L'entreprise doit réduire les éléments suivants :
- nombre d'incidents perturbant l'activité
- coût opérationnel de l'incident
Résultat opérationnel
Le résultat opérationnel requis est de maintenir la conformité aux objectifs de niveau de service au niveau du produit. Pour ce faire, vous devez diagnostiquer le niveau de service dégradé, communiquer votre diagnostic et effectuer une résolution rapide. Mais des dégradations et incidents inattendus surviennent toujours et vous devez réagir rapidement et efficacement.
Dans d’autres guides de cette série, nous nous concentrons sur l’amélioration time to know. Dans notre guide de gestion de la qualité des alertes, nous nous concentrons sur reactive les moyens d'améliorer le temps de connaissance, et dans notre guide Gestion des niveaux de service, nous nous concentrons sur proactive les méthodes.
Dans le guide que vous lisez actuellement, nous nous concentrons sur l'amélioration time to understand et time to resolve.
indicateurs de performances clés - opérationnels
De nombreuses mesures sont discutées et débattues dans le monde de la « gestion incident » et de la théorie SRE ; cependant, la plupart s'accordent à dire qu'il est important de se concentrer sur un petit ensemble d'indicateurs de performances clés.
Les KPI ci-dessous sont les indicateurs les plus courants utilisés par les pratiques réussies SRE et de gestion incident .
Perception de la fiabilité par l'utilisateur final
La façon dont les clients perçoivent les performances de votre produit est essentielle pour comprendre comment mesurer l’urgence et la priorité. De plus, comprendre le point de vue des clients permet de comprendre comment l’entreprise perçoit le problème, ainsi que de comprendre le workflow requis pour prendre en charge les capacités impactées. Une fois que vous comprenez la perception des clients et de l’entreprise, vous pouvez mieux comprendre ce qui pourrait avoir un impact sur la fiabilité de ces capacités.
En fin de compte, l’observabilité du point de vue du client est la première étape pour devenir proactif et compétent en ingénierie de fiabilité.
Il existe deux expériences principales qui ont un impact sur la perception qu'a l'utilisateur final des performances de votre produit numérique et de ses capacités. Les termes ci-dessous sont issus du point de vue des clients et utilisent le langage courant des clients.
Cause profonde vs cause directe
La cause profonde d’un problème n’est pas la même que la cause directe de ce problème. De même, corriger la cause directe (à court terme) ne signifie généralement pas que vous avez corrigé la cause profonde (à long terme) du problème. It's very important to make this distinction.
Lorsque vous recherchez un problème de performances, vous devez d'abord tenter de trouver la cause directe du problème en posant la question « Qu'est-ce qui a changé ? ». Le composant ou le comportement qui a changé n’est généralement pas la cause première, mais est en fait la cause directe que vous devez résoudre en premier. Résoudre la cause profonde est important, mais nécessite généralement une discussion rétroactive après l’incident et une gestion du problème à long terme.
Par exemple : le niveau de service de votre capacité de connexion chute soudainement. On constate immédiatement que le trafic est beaucoup plus important que d’habitude. Vous trace le problème de performances à une configuration de limite de connexion TCP ouverte qui entraîne une file d'attente de connexion TCP beaucoup plus grande. Vous résolvez immédiatement le problème en déclenchant une augmentation de la limite TCP et une instance de serveur supplémentaire. Vous avez résolu la cause directe du problème à court terme, mais la cause profonde pourrait être une mauvaise planification de la capacité, une communication manquée du marketing ou un déploiement associé avec des conséquences imprévues sur les charges en amont.
Cette distinction est également faite dans ITIL/ITSM Incident management versus Problem management. Les causes profondes sont discutées lors des discussions post-incident, puis résolues dans des processus de gestion des problèmes à plus long terme.
Étapes de diagnostic (aperçu)
Étape 1 : Définir le problème
La première règle est d’établir rapidement l’énoncé du problème. Il existe de nombreux guides sur la création d'énoncés de problèmes, mais le meilleur est celui qui est simple et efficace. Un énoncé de problème bien formulé fera ce qui suit :
- Décrivez ce que ressent l’utilisateur final. Quel est le problème rencontré par l’utilisateur final ?
- Décrivez le comportement attendu de la capacité du produit. Quelle est l’expérience que l’utilisateur final devrait ressentir ?
- Décrivez le comportement actuel de la capacité du produit. Quelle est l’évaluation technique de ce que vit l’utilisateur ?
Évitez toute hypothèse dans votre énoncé de problème. Restez fidèle aux faits.
Étape 2 : Trouver la source
La « source » est le composant ou le code le plus proche de la cause directe du problème.
Pensez à de nombreuses conduites d’eau reliées par de nombreuses jonctions, séparateurs et vannes. Vous êtes alerté que votre niveau de service de production d'eau est dégradé. Vous trace le problème depuis la sortie d’eau à travers les tuyaux jusqu’à ce que vous déterminiez quelle jonction, quelle division, quelle vanne ou quel tuyau est à l’origine du problème. Vous découvrez qu’une des vannes électriques est en court-circuit. Cette valve est la source de votre problème. Le court-circuit est la cause directe de votre problème. Vous résolvez facilement la cause directe en remplaçant la valeur. Gardez à l’esprit que la cause profonde peut être quelque chose de plus complexe, comme les conditions météorologiques, les produits chimiques dans l’eau ou la fabrication.
Il s’agit du même concept pour diagnostiquer une pile technologique complexe. Si votre capacité de connexion est limitée (sortie), vous devez trace au composant (source) à l'origine de cette limite et le résoudre. Il peut s'agir du logiciel API (limite de service), des services middleware, de la base de données, des contraintes de ressources, d'un service tiers ou d'autre chose.
En informatique, il existe trois catégories principales de points d’arrêt pour améliorer vos temps de réponse :
Output
Input
Client
Définir vos mesures de performance au sein de ces catégories, également appelées niveau de service, améliorera considérablement votre temps de réponse pour déterminer la source du problème. La mesure de ces catégories est abordée dans notre guide Gestion des niveaux de service. Pour comprendre comment les utiliser dans le diagnostic, continuez à lire.
Étape 3 : Trouver la cause directe
Une fois que vous êtes proche de la source du problème, déterminez ce qui a changé. Cela vous aidera à déterminer rapidement comment résoudre immédiatement le problème à court terme. Dans l’exemple de l’étape 2, le changement était que la vanne ne fonctionnait plus en raison d’un matériel dégradé provoquant un court-circuit.
Voici quelques exemples de changements courants dans le domaine informatique :
- débit (trafic)
- Code (déploiement)
- Ressources (allocation de matériel)
- Changements de dépendance en amont ou en aval
- Volume de données
Pour d’autres exemples courants de problèmes ayant un impact sur les performances, consultez la matrice des problèmes ci-dessous.
Utiliser les points de données de santé
Comme mentionné précédemment, il existe trois catégories de performances principales qui lancent votre parcours de diagnostic. La compréhension de ces points de données sur la santé réduira considérablement le temps nécessaire pour comprendre la source du problème.
Matrice des problèmes
La matrice des problèmes est une aide-mémoire des problèmes courants classés selon les trois points de données de santé.
Les sources de problèmes sont classées par ordre de fréquence, les plus courantes étant situées dans la rangée supérieure et à gauche. Une ventilation plus détaillée est présentée ci-dessous. Une gestion des niveaux de service bien effectuée vous aidera à éliminer rapidement deux de ces trois points de données.
Ce tableau est une matrice de problèmes triée par point de données de santé :
Point de données | Fonctionalité de New Relic | Sources de problèmes courants |
|---|---|---|
Sortir | APM, infrastructure, logs, NPM | Application, sources de données, modification de la configuration matérielle, infrastructure, réseau interne, fournisseur tiers (AWS, GCP) |
Saisir | Synthétique, logs | Routage externe (CDN, passerelles, etc.), routage interne, éléments sur Internet (FAI, etc.) |
Client | Browser, mobile | Code Browser ou mobile |
Les problèmes ont tendance à s'aggraver, mais l'objectif est de « trouver la source » et de déterminer « ce qui a changé » afin de rétablir rapidement le niveau de service.
Exemples de problèmes
Regardons un exemple de problème. Disons que votre entreprise lance un nouveau produit et que l'augmentation significative des requests entraîne des temps de réponse inacceptables. La source est découverte dans le service middleware de connexion. Le problème est un saut dans les temps d’attente TCP.
Voici un aperçu de cette situation :
- Category: performances de sortie
- Source: middleware de connexion
- Direct cause:Temps de file d'attente TCP en raison d'une charge de requête supplémentaire
- Solution: augmentation de la limite de connexion TCP et mise à l'échelle des ressources
- Root-cause: planification insuffisante des capacités et tests d'assurance qualité sur le service en aval, ce qui a un impact sur le middleware de connexion
Un autre exemple de problème
Voici un autre exemple de problème :
- Il y a eu une augmentation soudaine des erreurs de passerelle 500 lors de la connexion...
- Les temps de réponse de l'API de connexion ont augmenté au point où les délais d'attente ont commencé...
- Les délais d'attente ont été tracés jusqu'aux connexions de base de données dans la couche middleware...
- trace de transaction a révélé une augmentation significative du nombre de requêtes de base de données par demande de connexion...
- Un marqueur de déploiement a été trouvé pour un déploiement qui s'est produit juste avant le problème.
Voici un aperçu de cette situation :
- Category:dégradation des performances de sortie entraînant une défaillance des performances d'entrée
- Source: service middleware appelant la base de données
- Direct cause: 10x augmentation des requêtes de base de données après déploiement du code
- Solution: restauration du déploiement
- Root-cause:tests d'assurance qualité insuffisants
Matrice des problèmes par source
Voici un tableau avec la matrice des problèmes triée par sources.
Source | Common direct causes |
|---|---|
Application |
|
Source des données |
|
Réseaux internes et routage |
|
Identification des anomalies du modèle de performance
Conseil
Avoir un niveau de service bien défini sur vos limites de service relatives à la clé de transaction (capacités) vous aidera à identifier plus rapidement dans quel workflow de bout en bout réside le problème.
L’identification des anomalies de modèle améliorera votre capacité à identifier quelle est la cause directe des problèmes et où elle se situe.
Il existe de nombreuses informations utiles et des cours en ligne gratuits sur l'identification des modèles, mais le concept général est plutôt simple et peut débloquer de puissantes capacités de diagnostic.
La clé pour identifier les modèles et les anomalies dans les données de performances est que vous n'avez pas besoin de savoir comment le service devrait fonctionner : vous devez uniquement déterminer si le comportement récent a changé.
Les exemples fournis dans cette section utilisent le temps de réponse ou la latence comme métrique, mais vous pouvez appliquer la même analyse à presque tous les ensembles de données, tels que les erreurs, le débit, les métriques des ressources matérielles, les profondeurs de file d'attente, etc.
Normale
Vous trouverez ci-dessous un exemple de graphique de temps de réponse apparemment volatil (7 jours) dans APM. En y regardant de plus près, vous pouvez voir que le comportement du temps de réponse est répétitif. En d’autres termes, il n’y a pas de changement radical dans le comportement sur une période de 7 jours. Les pics sont répétitifs et pas inhabituels par rapport au reste de la chronologie.
En fait, si vous changez la vue des données de average over time à percentiles over time, il devient encore plus clair à quel point les changements dans le temps de réponse sont « réguliers ».
Anormal
Ce graphique montre un temps de réponse d'application qui semble avoir augmenté de manière inhabituelle par rapport au comportement récent.
Cela peut être confirmé en utilisant la comparaison d’une semaine à l’autre.
Nous constatons que la tendance a changé et qu’elle semble s’aggraver par rapport à la comparaison de la semaine dernière.
Trouver la source
Ensuite, nous verrons comment trouver la source dans New Relic. Notez que ce workflow repose sur le tracing distribué.
Tout d’abord, vous trouverez une application liée à la latence ou aux erreurs rencontrées par l’utilisateur final. Cela ne signifie pas que l'application ou le code est le problème, mais trouver une application dans le flux (en premier) vous rapproche plus rapidement de la source. Une fois cette application trouvée, vous pouvez rapidement exclure des composants tels que le code, l'hôte, la base de données, la configuration et le réseau.
Une fois l’application identifiée, la question est de savoir quelles transactions au sein de cette application font partie du problème. Utilisez l’application que vous avez identifiée comme rencontrant un problème de performances et identifiez la ou les transactions concernées. Ici, vous pouvez répéter la compétence d'anomalie du modèle de performance décrite ci-dessus dans Identifier les anomalies du modèle de performance, mais cette fois sur les transactions elles-mêmes.
Les documents suivants vous aideront à utiliser New Relic pour identifier les transactions problématiques :
- Page Transactions : Rechercher des problèmes de performances spécifiques
- Transactions lentes sur la page de résumé du service
Une fois les transactions problématiques identifiées, vous pouvez utiliser le tracing distribué pour examiner les composants de bout en bout prenant en charge cette transaction. Le tracing distribué vous aide à identifier rapidement où se trouve la latence et/ou où se produisent les erreurs sur l'ensemble de votre stack, le tout dans une seule vue.
Les ressources suivantes vous aideront à apprendre à utiliser le tracing distribué pour identifier le composant source du problème :
- Introduction au tracing distribué
- Comment utiliser l'interface utilisateur de tracing distribué
- Webinaires en ligne gratuits sur le tracing distribués
- Une vidéo sur l'utilisation du tracing distribué pour l'analyse des causes directes
Voici un bref résumé des étapes de recherche de la source :
- Examiner une application liée aux performances impactées.
- Identifiez les transactions qui contribuent au problème.
- Utilisez le tracing distribué pour identifier le composant problématique dans le flux de bout en bout.
Nous pouvons maintenant passer à l’étape finale, identifier la cause directe.
Trouver la cause directe
Une fois le composant source trouvé, vous pouvez commencer à déterminer la cause directe.
En utilisant les connaissances acquises lors des étapes précédentes, vous saurez si le problème est lié à la latence, au succès ou aux deux.
les problèmes de latence peuvent être détectés à l'aide de trace de transaction et/ou "span en cours de processus" au sein des traces distribuées.
Les messages d'erreur de problèmes de réussite peuvent également être vus dans la trace, mais les meilleurs détails sur les problèmes de réussite se trouvent généralement dans les logs d'application.
Quoi qu'il en soit, si vous êtes l'intervenant de premier niveau incident ou un SRE, la recherche de la cause directe incombe aux experts en la matière (SME), qui sont généralement les développeurs et les ingénieurs responsables du composant source trouvé.
L’étape suivante la plus efficace après avoir découvert le composant source est de contacter les experts en la matière pour ledit composant. Montrez-leur les données découvertes lors du triage et des diagnostics que vous avez effectués pour avoir une longueur d'avance sur le dépannage.
Conseil
Notez que les logs en contexte et le tracing distribué sont activés par défaut avec nos nouveaux agents . (Si vous n'avez pas mis à jour vos agents depuis un certain temps, nous vous recommandons de mettre à jour régulièrement vos agents.)
Les logs en contexte et le tracing distribués sont des fonctionnalités essentielles nécessaires pour réduire votre temps de triage, de diagnostic et de résolution des problèmes à long terme.
Maintenant, allez-y et devenez un excellent ingénieur fiabilité des sites avec New Relic !
Prochaines étapes
Si vous ne l'avez pas déjà fait, vous souhaiterez peut-être lire certains de nos guides de maturité d'observabilité connexes, notamment :