Mesurer la performance applicative : Robot vs. Sonde
En pratique, vous voulez surtout savoir s’il est vrai que pour vos utilisateurs « ça rame », si oui, savoir pourquoi et au quotidien anticiper leur vécu, voire même prendre des objectifs de performance (SLA) vis-à-vis de vos utilisateurs préférés.
Pour cela, rien de tel que faire des mesures en continu sur ses applications. Comment ? Il y a 2 écoles qui s’opposent :
1. Les robots applicatifs : des logiciels automatiques simulent des utilisateurs et donnent leurs résultats
2. Les sondes ou agents : des outils d’écoute font la mesure directe du trafic réel des utilisateurs pour déduire le résultat par analyse
L’objet de cet article est de poser et peser le pour et le contre de ces 2 approches.
Chacune des 2 approches a ses avantages et inconvénients évidemment, mais elles ont aussi une complémentarité !
Ce que font les Robots
Les robots, par définition, sont bons pour reproduire des comportements fidèlement et toujours identiques. Voici donc leurs qualités pour le monitoring des Performance Applicative de vos utilisateurs :
- Factuel : Les robots vous garantissent que vous comparez de choux avec des choux et des topinambours et des topinambours. Donc si ça se dégrade, ce n’est pas une lubie, c’est factuel : il y a un problème !
- Permanent : Les robots sont infatigables, le jour, la nuit, toutes les 5 minutes sans faute, bref, votre mesure, vous l’avez tout le temps c’est certain.
- Référent : la combinaison des 2 atouts précédents vous fournit une donnée précieuse en monitoring de performance, une référence, une baseline, dans le jargon. Cette baseline vous permet de savoir si c’est « vert », « orange » ou « rouge » !
- Complet : Le robot se situant généralement près du siège de l’utilisateur, il teste toute la chaine IT d’une application, système, réseau, logiciels et datas inclus. C’est « End-to-end » ou de bout-en-bout, bref, un monitoring complet.
On peut dire qu’on part avec de bons atouts pour monitorer la Performance avec des robots. Mais… il y a un « mais », voire plusieurs.
Ce que les Robots ne font pas
Le café ! Oui, d’accord, mais c’est pas le propos. Le robot est donc fidèle, mais rigide aussi ! Ca a quelques inconvénients… quelques trous dans la raquette…
- Discontinu : Si on lui dit de tester chaque 5 ou 15 minutes, c’est régulier, permanent… mais pas continu ! En gros, c’est un échantillonnage, mais entre 2 tests, le robot ne dit rien de la performance. Il y a un trou dans la raquette, un vide béant même.
- Trop parfait : L’avantage de la constance du Robot se retourne contre lui. L’utilisateur ne fait pas toujours strictement la même chose, n’a pas toujours les mêmes données traitées et optimisées (nombre de mécanismes systèmes ou réseaux peuvent optimiser la donnée applicative rejouée par les utilisateurs), il ne suit pas toujours le manuel non plus (find *.* = 76 345 items, oups !), bref, le Robot ne répond pas vraiment sur le Real User Experience. C’est un sacré loupé pour parler de Performance « Utilisateur ».
- Rare : Un Robot a un coût et il n’y en a pas dans chaque siège utilisateur. Là aussi, si le VIP en déplacement dans un hotel à Singapour se plaint, vous ne pourrez pas parler de sa performance utilisateur à lui. Comme à tant d’autres utilisateurs.
- So what ? Le Robot dit « rouge », et alors ? C’est où ? Et bien, vu du siège utilisateur, il n’est pas forcément facile de dire si le temps de réponse vient du réseau ou du système (même si l’utilisateur dit toujours que « le réseau est lent », non, ce n’est pas toujours le réseau !). Comment diagnostiquer ? Avec plusieurs Robots, qui disent « vert » par-ci, « rouge » par-là ? Finalement, le robot vous parle surtout de ce qui va bien, à vous, humain, de trouver ce qui ne va pas !
On le voit, il y a tellement de trous dans la raquette du monitoring robotisé qu’il ne parle pas vraiment du vécu des utilisateurs dans le temps et l’espace.
Le Robot sait surtout ce qui marche, mais il ne sait pas grand chose sur ce qui ne marche pas ! Et c’est bien le principal problème : ce qu’on attend du monitoring, c’est qu’il nous parle surtout de ce qui ne marche pas. Quand ça marche, quelque part, on s’en fiche, ou au mieux on s’en sert comme parapluie… mais ça fait cher le parapluie.
Ce que vous devez faire pour les Robots
Et oui, le robot fait des choses pour vous, fidèlement, mais il faut aussi que vous fassiez des choses pour lui, ou plutôt pour eux.
- Les acheter ! Car 1 seul Robot, ce n’est plus des trous dans la raquette mais plutôt jouer au tennis avec juste un manche de raquette. Bref, le coût est indexé sur la finesse du monitoring que vous voulez.
- Les programmer ! C’est à vous de définir leur comportement et scripter leurs actions.
- Les mettre à jour : l’usage IT varie, le Robot doit varier aussi. Reprogrammer.
- Les maintenir. L’utilisateur va chez le médecin tout seul, pas vos robots…
- Les comprendre : c’est la conclusion du paragraphe précédent, ils vous parlent surtout de ce qui marche, a vous d’analyser ce qui ne marche pas, souvent par dichotomie entre les résultats de plusieurs Robots ou outils.
Vous commencez à me voir venir… nous avons un parti pris chez ISIS Performance. Il est clair, assumé car argumenté et pratiqué, nous penchons pour l’autre approche, celle des Sondes et des Agents, passifs. Bien que nous n’excluions nullement de bénéficier des qualités des Robots quand elles sont utiles, voir plus bas.
Ce que les font les Sondes passives
Les Sondes sont essentiellement des logiciels d’analyse des flux réseaux et les Agents sont essentiellement des logiciels d’analyse des évènements systèmes ou applicatifs dans les machines (serveurs voire clients). Dans les 2 cas, c’est une mesure passive de ce qu’il se passe, en principe à l’initiative des utilisateurs (et pourquoi pas des Robots aussi). En voici les atouts :
- Exhaustivité : La sonde observe tout ce qui passe tout le temps, elle ne manque rien ni personne, même le VIP dans son hotel de Singapore qui se connecte à SAP.
- Real User : La sonde observe le trafic des utilisateurs réels et effectifs, pas une simulation (qu’elle peut voir aussi d’ailleurs).
- Passive : donc non intrusive, elle ne génère pas de flux d’overlay ou de charge dans l’infrastructure et les applications
- Diagnostic : elle observe l’ensemble des transactions sur l’ensemble de l’infrastructure et peut donc détecter les concurrences, surcharges, domaines de responsabilités et métriques techniques d’infrastructure. Finalement, la Sonde ou l’Agent peut dire où et pourquoi quelque chose est « rouge ».
Elles ont aussi quelques atouts supplémentaires :
- Elles ne nécessitent pas de programmation mais d’une déclaration plus ou moins détaillées des applications
- Le coût est maitrisé avec une solution centrale unique et la maintenance est minimale (1 seule solution)
- Le déploiement est très rapide puisque non intrusif et centralisé
Comme les Robots, les sondes ont leurs petits défauts…
Ce que les Sondes ne font pas
Le café ? Toujours pas. Mais l’exhaustivité d’analyse des sondes à aussi ses inconvénients :
- Capacité : Qui dit exhaustivité dit grosse charge ! A tout analyser, il faut pouvoir digérer et stocker les métriques, les stats, voire les traces de tout. Le dimensionnement d’une Sonde est potentiellement conséquent, et le prix aussi.
- Impermanence : s’il n’y a pas de trafic, il n’y a pas d’analyse, la sonde est aveugle sur la performance possible !
- Sans référence : parce que le trafic analysé est réel, il n’est pas « standardisé » et la définition « vert » ou « rouge » reste sur une analyse moyenne ou de tendance mais pas une véritable baseline.
- Complexité : l’analyse est fine, riche en métriques techniques, donc potentiellement complexe à analyser.
Alors malgré ces défauts, nous préférons utiliser des sondes en Diagnostic et Monitoring par exhaustivité, pertinence et simplicité de mise en place (comprendre « coût »). Mais, la beauté de l’histoire de cet article, c’est que l’on peut marier le meilleur des 2 mondes !
Robots et Sondes ont une belle complémentarité !
L’impermanence et l’absence de référence de la mesure d’une sonde passive peut être complètement compensée par l’adjonction de Robots ! Et voici tout ce qu’on y gagne :
- Le « Morning Test » : votre agence ouvre à 9h, mais pouvez vous garantir que le service fonctionne avant d’ouvrir s’il n’y a pas d’utilisateur pour le valider ? Le Robot vous apporte la permanence du monitoring, la Sonde apporte le diagnostic rapide et précis en cas de besoin d’une réaction avant l’ouverture.
- Le Baselining : l’utilisateur se plaint, mais son problème fait-il partie de l’usage normal de l’application, le temps de réponse s’est-il écarté de la norme au point de rompre votre SLA (sur lequel la DSI s’engage) ou l’utilisateur est-il chatouilleux et son usage hors norme (find *.* = 76 345 items, oups !) ? Le Robot vous apporte la référence, la sonde vous indique où est la dérive pour l’utilisateur réel et pourquoi.
- La reproductibilité : un problème de performance épisodique et subtil se présente et vous garantit de diagnostic long et couteux (80% de la résolution d’un problème). Le Robot peut vous permettre d’assurer la reproductibilité du problème pour un diagnostic rapide avec une sonde par une méthodologie maitrisée et indépendante des aléas entre la chaise et le clavier…
- Le « Stress Test » : Le Robot charge, de manière contrôlée, l’infrastructure et l’application, la sonde mesure où et pourquoi la performance se dégrade, le mariage est parfait, les euros seront donc bien dépensés dans le dimensionnement de l’IT ! ROI garanti !
Nous sommes des experts dans la mesure de Performance Applicative perçue par l’utilisateur, notre parti est clairement pris en faveur de la Sonde et des Agents passifs dont la mesure nous semble particulièrement pertinente. Mais soyons clairs : nous travaillons aussi avec des Robots dont les atouts décuplent encore la pertinence du travail de mesure et monitoring passif.
