Industrie Mag - Le journal de l'industrie.

Une (banale) histoire de temps de réponse...

C’est l’histoire d’un consultant, appelé par un client qui ne parvient pas à résoudre un problème de temps de réponse sur sa plateforme e-commerce.

Le consultant demande au client s’il a une solution d’APM. Celui-ci répond qu’ils ont en effet un outil d’APM..

Quand le consultant demande s’il peut jeter un œil au problème sur son environnement de pré-production, le client répond que seul leur environnement de production est monitoré.

Le consultant se connecte donc à l’outil de monitoring, qui inclue tableaux de bord, alertes et mise en évidence des temps de réponse anormaux. Il a une vision globale de l’environnement et peut même identifier une transaction spécifique particulièrement lente. Mais il a besoin de plus de détails : en analysant les requêtes en bases de données, il constate que tous les indicateurs sont au vert... Qu’est ce qui peut donc ralentir la transaction de la sorte ? Une recherche approfondie dans l’exécution de la transaction s’avère nécessaire...

Il demande alors au client d’exporter les données de production pour les étudier plus en détails en offline, ce qui s’avère malheureusement impossible avec leur outil de monitoring.

Le consultant finit par découvrir que des faits manquants altèrent les analyses, ce que leur outil d’APM n’avait ni identifié, ni rapporté.

Puisque l’outil de monitoring en place ne lui permet pas d’avoir la vision approfondie dont il a besoin pour identifier la cause du problème, il décide alors d’installer une solution d’APM équipée d’un outil de diagnostic prêt-à-l’emploi. Résultat : il lui faut moins d’une heure pour identifier le problème, et à peine plus pour le corriger.

C’est un cas assez classique.

Une solution d’APM à la rescousse

Comment une solution d’APM avait-elle permis de régler le problème en quelques heures, quand l’outil installé n’y était pas parvenu en plusieurs semaines ? Plusieurs facteurs y contribuent :

1. Une visibilité exhaustive de bout-en-bout : autrement dit, un niveau de détail élevé de chaque transaction. La solution d’APM permet de bénéficier d’une vision exacte de la façon dont le code s’exécute, grâce à la mesure fine - et non agrégée - des temps (CPU, exécution, temps total, I/O, Sync et Wait). Il est nécessaire d’accéder aux arguments de méthode et aux valeurs de retour, en ce qu’ils peuvent être critiques pendant l’analyse. Les appels externes, les exécutions de bases de données, les contenus tiers, les erreurs et les exceptions, sont autant de détails supplémentaires indispensables à connaître. 2. Une couverture totale, sans d’échantillonnage, de chaque transaction : qu’il s’agisse de rejouer un problème ou d’étudier les données de production, tout repose sur les détails, pour chaque transaction, qu’elle soit exécutée une seule ou plusieurs fois. Les agrégats et les échantillons ne suffisent pas !

3. Une capacité à partager et à analyser des données offline : le comportement observé doit être partagé avec les architectes et les développeurs. Mais pas sous la forme d’un résumé, de captures d’écran et de fichiers de logs. Les équipes ont besoin de partager l’ensemble des détails de l’exécution des transactions problématiques, pour s’assurer de n’avoir rien oublié.

4. Une seule solution, un seul savoir : Les chances de malentendus et d’incompréhensions se réduisent drastiquement si toutes les équipes sont impliquées dans la recherche d’un problème, avec les mêmes outils et la même vision des choses. Si l’équipe de production voit les mêmes données que les testeurs et les développeurs, représentées et analysées avec les mêmes outils, ils peuvent parler le même langage. Plus de « ... mais mon outil mesure ceci et le tien montre cela... ». Ce qui permet de réduire de manière significative les cycles de communication.

Choisir une solution d’APM, c’est choisir celle qui non seulement assure le monitoring, mais qui répond également aux besoins des testeurs, des développeurs, des équipes d’exploitation, des intégrateurs, des partenaires et des fournisseurs. Une solution qui vous dit qu’une transaction est lente, mais sans vous préciser pourquoi, où, et qui doit la corriger, est pour ainsi dire inutile.

Choisissez bien - parce qu’un jour, vous aussi, vous rencontrerez un problème ...

Choisissez une solution qui adresse l’ensemble du cycle de vie de l’application. Votre application passe par du développement, de la personnalisation et des tests avant d’être mise en production. Un problème de production suivra à peu de chose près le même chemin à l’envers : de la production, aux testeurs qui le rejoueront, pour finir chez les développeurs qui le corrigeront. Puis la solution repartira dans l’autre sens jusqu’à la production. Comme les problèmes, les solutions pour les résoudre doivent pouvoir suivre le cycle de vie d’une application et notamment s’intégrer avec vos outils de test.

Choisissez une solution que les parties prenantes à ce cycle de vie adopteront. Impliquez votre organisation et ceux avec qui elle travaille : partenaires et fournisseurs. Faites confiance à leurs conseils et recommandations, parce que c’est sans doute vers eux que vous vous tournerez le jour où vous aurez un problème critique. Suivez également leurs best practices.

Enfin, acceptez le fait que vous aurez des problèmes, petits et gros. Il serait utopique de penser qu’une plateforme en proie à des changements constants soit épargnée par les difficultés. Si ce n’est pas vous, un autre fera des erreurs qui vous affecteront d’une manière ou d’une autre...

Outil vs. Solution

Il y a une différence entre outil d’APM et solution d’APM. Assurez-vous de tenir compte des besoins non seulement de l’équipe de production, mais aussi de tous ceux avec qui vous travaillez, ainsi que des données dont ils sont susceptibles d’avoir besoin. Ne vous contentez pas de comparer une liste de fonctionnalités ou de mots clés, testez les solutions.

Des informations complémentaires ici http://www.dynatrace.com/fr/project...