Amélioration d’un Système d’Informations existant : analyser (1)

 

Nous continuons notre série sur la reprise d’un système d’informations existant. Une introduction de la méthode est disponible dans un précédent article. La première étape est de mesurer, de collecter des informations. La seconde étape est d’analyser les données. Nous allons voir quelques éléments à prendre en compte. Quelques exemples pratiques seront utilisés pour illustrer le propos.

Des outils complexes d’analyse de données

Il existe des outils dédiés à l’analyse de données. Comme toute famille d’outils, certains sont simples : le marteau permettant de planter un clou. D’autres sont plus complexes : une perforeuse burineuse SDS -MAX à mandrin interchangeable et vitesse de rotation variable. Cependant, vous n’utiliserez pas la perforeuse burineuse SDS -MAX à mandrin interchangeable et vitesse de rotation variable pour planter un clou dans une cloison. Il n’est pas nécessaire de disposer du meilleur outil existant, le plus cher, le plus complexe à utiliser pour faire du très bon travail.

Utiliser un outil complexe impose de disposer d’une compétence technique adaptée. Ce qui coûte cher. L’outil vous a déjà coûté cher (il est le meilleur, le plus efficace, le plus performant, le plus …, le plus cher). Un outil de ce type a souvent des pré-requis élevés. Il requiert probablement plusieurs serveurs physiques, des CPUs performants, une mémoire conséquente, des disques SSD très rapides, un espace disque conséquent, un serveur d’application sous licence, une base de données propriétaire dédiée, … En plus de cela, il va vous falloir comprendre l’outil, commencer à l’utiliser, comprendre les réponses, comprendre l’écart entre la réponse fournie et la réponse attendue, comprendre la lenteur de fourniture des résultats, comprendre la documentation conséquente, comprendre les termes utilisés dans la documentation, … Il va vous falloir installer l’outil, le paramétrer, le maintenir, être formé à son utilisation, être formé à son administration. Tout cela a un coût. Élevé. Très élevé. Dont vous n’avez peut être pas idée. Avez-vous réellement besoin de tant de fonctionnalités? Avez-vous réellement besoin de tant de performances? Avez vous réellement besoin de perdre autant d’argent et de temps?

L’analyse de données nécessite des notions de statistiques, de mathématiques. Il est faux de croire qu’il suffit de brancher la perforatrice, de la mettre contre le mur et qu’elle réalisera le trou elle-même. Il est nécessaire de savoir choisir son burin en fonction du mur, le diamètre du burin, la fréquence de rotation, l’utilisation ou non de la percussion, … Ces connaissances sont indispensables pour maîtriser l’outil. Dans mon passé d’intégrateur, j’ai remarqué quelles sont souvent mises de côté. Les utilisateurs veulent comprendre rapidement comment fonctionne un outil, mais ne veulent pas passer de temps sur l’apprentissage théorique nécessaire pour arriver au but recherché. Le problème que je constate est que les jeunes étudiants veulent exactement la même chose. Tout le monde souhaite faire un joli graphique en 3D mais sans vouloir comprendre ce qu’est un axe, une unité, une légende, un repère orthonormé, … Pourtant, c’est sur ce point que les conseils sont les plus importants et que toute l’expérience du formateur est cruciale.

Dans la majorité des cas, quelques outils simples, bien utilisés suffisent. Il n’est pas nécessaire d’investir dans des outils coûteux si l’on n’a pas encore ressenti les manques des outils traditionnels. Attention à ne pas prendre cela au pied de la lettre : parfois, il est bien de remettre en cause ses habitudes pour s’améliorer. Mais dans notre monde informatique technophiles, j’ai souvent remarqué qu’il fallait utiliser la dernière-techno-à-la-mode-d’ailleurs-cest-genial-regarde-cest-encore-en-beta! si on ne voulait pas se faire taxer de « vieux con » ou « dépassé ». Les modes que j’ai observées :

  • JAVA-J2EE mis à toutes les sauces. Annoncé comme le PHP-Killer, je crois que le PHP-Killer sera tout simplement PHP lui-même
  • les bases de données objet : je me souviens encore du commentaire de notre prof de SQL: « bon, on nous force à vous apprendre les bases de données relationnelles mais c’est fini, c’est le passé ». Je me souviens aussi de la question-réponse de mon pote : « c’est qui ce on ? Pourquoi vous n’avez pas réussi à les convaincre? On va encore perdre notre temps inutilement? Quelles sont les autres cours de cette année qui ne nous servirons à rien? »
  • Ruby-Ruby-on-Rails : il m’a été présenté (la bonne blague!) par certains développeurs comme « le VRAI PHP-Killer (oublie JAVA-J2EE, c’était une arnaque) »
  • les bases de données XML/XSL/XQuery. C’était le truc génial car « indépendant des moteurs de base de données ». Quelqu’un en a déjà vue une de « base de données XML »? Non, mais en vrai?
  • Git et GiHub. J’ai déjà entendu « si on avait GitHub plutôt que SVN, il y aurait moins de bug » ou « avec GitHub, on aurait beaucoup plus de contributeurs ».
  • Les pare-feux: qui n’a jamais entendu « je peux pas avoir de virus, j’ai un parefeu! ». Je me souviens d’un article absolument magnifique sur ce genre de débilités dans un LinuxMag.
  • La virtualisation. « Grâce à la virtualisation, plus besoin de se soucier des serveurs physiques! ». Sauf pour le stockage des données, qu’il faut mettre sur un espace…. heu… physique… heu… dédié… (« virtualisation du stockage »).
  • Le cloud. Je n’ai pas besoin de détailler, c’est encore très frais dans les mémoires collectives.

Aujourd’hui, je vois poindre des « nouvelles » technologies qui, lorsqu’elles vous sont présentées, vont lutter contre le réchauffement climatique, contre la faim dans le monde, contre les guerres, contre la violence, contre la haine, … Bref, tout informaticien étant une Miss France qui s’ignore, la dernière techno va sauver la planète. Celles d’aujourd’hui sont :

  • NoSQL. Il parait que celle-ci est super performante, super simple, super géniale. Si vous avez un problème de performance sur une base de données, faites du NoSQL et tous vos problèmes disparaîtront. En tout cas, je l’entends souvent ce discours.
  • Docker. Vous avez des difficultés à installer votre application ou à faire installer votre application par des tiers? Docker est, parait-il, LA solution qui résout tous les problèmes de dépendances.
  • JSON. On fait tout en JSON. Avant, c’était le XML qui faisait tout. Mais plus aujourd’hui. Aujourd’hui, c’est le JSON. Oui, parce que c’était compliqué à lire le XML alors que le JSON… Faire des fichiers de configuration en JSON, c’est bien. Stocker des données sur disque en JSON, c’est bien aussi. #ohWait!
  • BigData. On en mange à toutes les sauces. « Grâce aux BigData, vous allez trouver des données que vous n’auriez jamais pensé rechercher ». Ça donne envie. T’as combien dans ton BigData toi? 18cm?!? Ho le nul… Je suis à 23cm… dans l’eau froide en plus. Et toi? …. COMBIEN? … COMBIEN??? Non, tu déconnes?!? Ha… Sinon… vous avez regardé le Grand Prix de F1 dimanche?

Des outils d’analyse simples et efficaces

Les outils les plus simples sont souvent les meilleurs. Le fameux KISS : Kepp It Simple Stupid plaide en ma faveur. Voyons ce que nous pouvons tirer des outils que vous devez déjà avoir sur votre Système d’Information. Une petite anecdote: pour planter un clou, mon père frappait 4 fois avec son marteau:

  1. le premier coup a pour but de bien placer le clou, de le planter au bon endroit
  2. le second coup a pour but qu’il tienne tout seul
  3. le troisième coup a pour but de le faire entrer dans le mur dans sa grand majorité
  4. le dernier coup a pour but de rentrer définitivement le clou, pour qu’il soit parfait.

Parfois, il loupait un coup et devait taper une fois de plus. C’était du temps de perdu et un juron qui s’échappait de sa bouche. Moi, pour rentrer un clou, il me faut 4 coups pour qu’il soit bien placé, 4 coups pour qu’il tienne tout seul, 3 coups pour qu’il rentre correctement et enfin, deux coups pour qu’il soit parfaitement rentré. Généralement, je loupe les 4 premiers coups et je dois prendre un autre clou (la flegme de chercher et de ramasser le clou qui est tombé) et recommencer. Conclusion: bien que le marteau soit un outil simple, il faut savoir l’utiliser correctement pour le maîtriser et ce n’est pas donné à tout le monde sans un minimum de pratique (message personnel : « oui papa, je te jure que je me suis entraîné, regarde mes doigts »).

Des outils courants (et non simples) doivent être maîtrisés en informatique. Ses outils sont:

  • les formats de données et l’export/import de données
  • les graphiques
  • le tableur (LibreOffice)

En maîtrisant ses outils de base, vous pouvez déjà aller très loin dans l’analyse de vos données.

Du regard humain sur des graphiques

Un informaticien lambda dispose d’une faculté naturelle d’analyse et de déduction. Nous, scientifique dans l’âme, pourfendeur de littéraires et d’artistes débauchés, avons appris cela naturellement mais aussi grâce à nos études de mathématiques, de logique et d’informatique. Nous nous sommes forgés un esprit cartésien, analytique, déductif. Lorsque nous regardons quelque chose, nous essayons d’y trouver un sens logique. Nous imaginons (c’est notre côté créatif) un passé et un futur, lorsqu’il y a un axe des temps. Avec un peu d’entraînement, ce type d’analyse devient un réflexe acquis. Vous réalisez les actions sans même en avoir conscience. Si votre cerveau n’est pas encore entraîné à cela, il va vous falloir l’entraîner. Pour cela, c’est relativement simple: face à une situation, essayer de comprendre ce qui ont pu être les causes de celle-ci dans un premier temps puis dans un second temps, quelles peuvent être les conséquences. Faites cela à tout moment de la journée, dans votre métier, à votre maison (« pourquoi ma femme râle? », « pourquoi mon enfant pleure? », « pourquoi mon voisin ne me parle plus? »), dans les transports (« pourquoi ce couple se dispute? », « [pendant l’arrêt du train/métro dans un tunnel] qui a peur? », …), pendant que vous regardez la télé/écouter la radio/lisez (« pourquoi réagit-il de cette façon? », « est-il énervé? », « qu’est ce qui l’a énervé? », « est ce un point particulier ou une succession de questions? », « pourquoi à cette question? », « la colère est elle feinte, simulée ou réelle? », « tiens ma bière est chaude »), … Je développe énormément mon esprit critique en regardant des films (même des films peu « intellectuels »), en suivant l’équipe de France de foot (« pourquoi un tel changement de comportement des joueurs en si peu de temps? », « où ont-ils retrouvé leur envie de jouer collectivement? », « qu’est ce qu’un bon capitaine? » , « qu’est ce qu’un bon manager? », « suis-je un bon manager? »), en regardant les news (même BFMTV/ITélé), en lisant une BD, … Il est rare de ne pas tirer d’enseignement de situation que vous vivez ou de situation que vous vivez par procuration (films/romans/…).

La difficulté la plus importante est de s’assurer que ce que l’on imagine n’est pas le pur fruit de notre imagination mais se rapproche de la réalité. Cela est très complexe et il faut beaucoup s’informer sur le sujet pour qu’éventuellement, une idée que l’on s’était faite soit confirmée ou infirmée.

Après tout cet entraînement, en regardant un graphique, vous développerez alors naturellement des idées sur le passé et sur le futur.

La supervision : identifier les pannes

Lors de l’utilisation d’un outil de supervision/monitoring, il est courant d’avoir des graphiques. Ceux-ci peuvent nous donner des informations pertinentes si on les analyse correctement. Le cas le plus simple est la « panne »: un élément génère une alerte de supervision et il faut identifier la raison. Les graphiques peuvent aider. Beaucoup. Énormément. Mais pas grand monde ne les regarde. Il est tellement mieux de se connecter sur le serveur n’est ce pas? Voici deux graphiques sur une panne :

Panne subite graphiques_panne_previsible

Le premier graphique démontre une panne subite : il n’était pas possible a priori de prévoir la panne. Celle-ci s’est produite dans un temps trop court pour être anticipée. Il s’agit probablement d’un processus qui s’est emballé, qui tourne en boucle. Le second graphique montre que la panne s’est produite sur un temps plus long. Peut-être que le serveur a été de plus en plus chargé par un nombre de requêtes plus important.

La supervision : anticiper les consommations d’espace disque

Les graphiques peuvent aussi permettre de visualiser ce qui se passera probablement dans le futur. Il est nécessaire de faire appel à son imagination. Il faut alors laisser s’exprimer son côté créatif, artistique. Cela demande un peu de gymnastique mais ceci est très simple, presque enfantin. Voici un exemple de graphique:

graphiques Panne disque prévisible affichage standard
La valeur n’est pas dépassée. Rien d’alarmant à première vue. Cependant, en regardant un peu plus en détail, on imagine clairement que le graphique va continuer de monter. Il est rare que les utilisateurs d’outil de supervision utilisent les graphiques pour tirer une analyse comme celle-ci. Beaucoup préfèrent se reposer sur les alertes. « Tant que je ne dépasse pas la valeur seuil, tout va bien » s’imaginent-ils.

Avec un peu plus d’imagination, on peut obtenir une image mentale du futur, qui donnerait cela :

graphiques panne disque prévisible reflexion

Autrement dit : « que va-t’il se passer dans les prochaines semaines? » Là est l’analyse humaine, son intelligence, votre valeur ajoutée. Il faut réaliser ce travail si aucun outil n’est disponible. Pour ce graphique, le travail est très loin d’être complexe. Il est évident que « ça va dépasser dans les prochaines semaines ». Le « quand » n’est pas le plus important. L’important est :

  1. êtes vous capable de faire cette analyse mentalement?
  2. êtes vous capable de faire cette analyse régulièrement?
  3. êtes vous capable de prendre la décision qui s’impose (donner plus d’espace disque)?
  4. êtes vous capable de faire prendre la décision (faire un achat permettant de disposer de plus d’espace disque)?
  5. êtes vous capable de prouver vos dires?

En fait, la date aussi est importante. Vous en aurez besoin pour planifier l’augmentation de l’espace disque, pour prioriser un achat par rapport à un autre. Notamment, les cas imposant une procédure complexe lorsqu’un problème d’espace indisponible se pose. C’est le cas d’un SAN totalement rempli, auquel il est impossible d’ajouter de l’espace libre (nouveaux disques, disques plus gros) sans passer par une procédure complexe ou une procédure nécessitant un arrêt de production ou une procédure d’une durée très importante ou une procédure ayant un impact fort sur les performances. Dans le cas où la date prévisionnelle de dépassement, il est toujours possible (ou alors… changer d’outil!) de récupérer un export des données et de faire ce genre de graphique :

graphiques panne disque prévisible reflexion mentale

Ce n’est pas compliqué, il suffit d’utiliser LibreOffice et la fonction « tendance ». Si vous voulez vous amuser, vous pouvez aussi calculer et colorer la date à partir de laquelle une valeur seuil sera probablement dépassée. Vous présentez cela en réunion, si possible devant tous les grands chefs, dans un joli LibreOffice Impress (ou Powerpoint si vous êtes du mauvais côté de La Force), en remerciant votre chef de vous avoir aider. Penser à préciser que « ce sera vraiment critique le 18 septembre, vers.. heu… oui c’est ça… 04h22… Chef, je ne me souviens plus… je vous ai parlé de mes congés du mois de septembre? ». Succès garanti.

La supervision : analyser les récurrences

Les graphiques permettent aussi de détecter les problèmes récurrents. Grâce à un graphique, il est possible de voir immédiatement qu’un événement se produire de manière récurrente : tous les jours à la même heure. Voici un exemple que j’ai déjà vécu :

graphiques panne reccurenceGrâce à ce graphique, j’ai pu constaté que l’on avait un pic d’activité sur le serveur tous les jours à la même heure et pour une durée identique. Dès lors, il faut corréler avec les autres indicateurs. Car visualiser un point sur un seul graphique n’est pas suffisant, il est nécessaire de vérifier que ce comportement est confirmé par les autres indicateurs. Dans ce cas précis, il l’était : tous les indicateurs démontraient un pic d’activité tous les jours à la même heure. C’est la grande force des graphiques: en empilant sur une même page tous les graphiques d’un équipement, on peut voir l’impact global sur tous les indicateurs : est ce que seul le CPU est impacté? est ce que d’autres indicateurs sont impactés? Si oui lesquels?

Dans notre cas, tous les indicateurs montraient un pic d’activité. La décision a été alors d’optimiser les performances du serveur. Nous avons travaillé à différents niveaux:

  1. optimisation de la base de données : ajout d’index, optimisation des paramètres pour que les index soient conservés en mémoire, …
  2. optimisation du serveur d’application : mise en place d’un moteur de cache de code
  3. augmentation du nombre de processus permettant de servir les pages

Dès lors, les pics se sont réduits, en intensité mais surtout en durée:

graphiques panne reccurence optimisationCe qui est surtout visible lorsque l’on met les graphiques l’un au dessus de l’autre (avant/après). Cependant, ça ne répond pas à la question : pourquoi? Oui, pourquoi? Pourquoi ce pic d’activité? Pourquoi tous les jours? Pourquoi exactement à la même heure? Ce ne peut être un facteur humain : le site étant consulté sur toute la France, tous les utilisateurs se synchronisent pour consulter les pages en même temps? Non, ce serait très étonnant. Impossible même.

L’analyse des logs

L’analyse des logs permet d’apprendre des quantités d’éléments. Dans le cas précédent, nous avons développé un script (en perl évidemment!) qui nous a fourni des statistiques sur :

  • le nombre de requêtes HTTP par heure
  • le nombre de requêtes HTTP par IP Source

Ce n’était pas suffisant. Nous avions une corrélation : le nombre de requêtes par heure connaissait un pic d’activité similaire au pic d’activité des autres indicateurs. Le nombre de requêtes HTTP par IP source ne montre rien d’étonnant : les organismes les plus importants font le plus de requêtes. Mais… et le nombre de requêtes par IP Source et par heure? Là, ce fut intéressant… très intéressant… très très intéressant. Nous avions la source de notre problème : un organisme ne faisait aucune requête HTTP (vraiment aucune) sauf pendant le pic d’activités. Durant ce pic, le nombre de requêtes explosait complètement. Pourquoi? Est ce que les administrateurs n’autorisent l’accès au web externe que durant ce moment précis de la journée? Le proxy web n’est ouvert que durant cette période? Ce pouvait être possible à cette époque où la connexion internet était fortement limitée en bande passante et coutait très chère. En fait, en regardant la signature du « navigateur », nous nous sommes rendus compte que ce n’était pas un navigateur standard qui utilisait notre site mais un aspirateur de site web. Ce qui était contraire au conditions générales d’utilisation de notre site, accessible uniquement aux utilisateurs authentifiés. Des règles simples et efficaces ont permis de bloquer l’aspirateur. Une fois ceci fait, nous avons attendu que le responsable appel pour se plaindre et… je vous laisse deviner.

Il n’est plus nécessaire de faire de script Perl aujourd’hui. Grâce à ELK (ElasticSearch, Logstash et Kibana), on obtient le même résultat en plus performant et plus flexible. À l’époque, cet outil n’existait pas. Cependant, les scripts ont fait le boulot. Des scripts simples, efficaces, performants. Pensez-y dans d’autres cas.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *