« Driiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiing » / « Knut (bruit de Teams) » / « Autre à définir », au bout de la ligne, un DA/DAA/Patron de BU/DP/Autre au bord de la crise de nerfs, une personne haut placé côté client vient d’appeler une personne haut placée côté chez nous et veut que son problème de prod soit réglé depuis hier et que bien évidemment après avoir fait le tour de toutes les personnes possibles vous êtes la Femme/L’Homme/L’Autre de la situation.
On pose le casque micro/le Téléphone/le TTY (prononcé TiTiOuialle – ou Teletype)/Autre et on part portable sous le bras affronter cette production récalcitrante.
Ces quelques lignes résument beaucoup d’appels que j’ai pu recevoir. À chaque fois, ce moment de stress où l'on se dit « suis-je à la hauteur ? »/ « de quelles compétences je vais avoir besoin ? » / « quel bout de doc réviser en chemin pour avoir un minimum de billes sur le sujet ? ». Bref, une tonne de questions vous traverse l’esprit sur la base des bribes d’informations collectées et vous vous demandez comment toutes ces pièces de puzzle s’assemblent.
Premier constat : le problème décrit est rarement le bon ;) Clairement, si c’était le réel problème il serait traité par la solution trouvée sur Google/StackOverflow/Le Gorafi/Autre et vous n’en seriez pas là. Souvent les pièces sont les bonnes mais leur interprétation a conduit à l’éloigner (pour faire plaisir aux qualiticiens) de la « root cause ». Donc à défaut de pouvoir rejeter les pièces, il faut reposer à plat l’interprétation et ensuite passer au tamis les pièces qui font partie du puzzle de celles qui ne sont que des conséquences ou du bruit. Vous ne me croyez pas ? Quelques exemples :
- Déséquilibre de charge sur un cluster de serveurs d’applications – Réalité : Problème de performance sur la base de données,
- Problème de base de données qui rame – Réalité : configuration du serveur d’impression (ok, il n’avait rien à faire sur le serveur de BDD, mais bon …) qui mangeait toute la RAM et pourrissait l’application,
- « Nouveau bug inconnu dans Sendmail » - Réalité : fichier de conf édité en mode « \r\n » (lol :p)
La liste est loin d’être exhaustive. Un premier conseil, la technique du canard, on reste calme en surface, on pédale à fond sous la ligne de flottaison :
Corollaire / complément, tout ce que l’on vous dit est vrai, c’est souvent les chaînes de causes / conséquences qui ne sont pas les bonnes.
Dernier constat, non, je ne connais pas la moitié ni le tiers et encore moins le quart de ce sur quoi j’interviens (oups, fallait pas le dire). Le seul point commun est la prise de recul par rapport à la problématique, la mise en cohérence (cause / conséquence entre les sujets) et la capacité à vérifier ce que l’on propose avec un plan d’action.
Ok jusque-là ? Oui, mais comment ?
Comme on se l’est dit, on ne part qu’avec son portable sur le dos et peu d’outillage à disposition. Si j’en crois la littérature et tout particulièrement Douglas Adams dans son prodigieux H2G2, le seul outil indispensable à sa propre survie dans l’espace intergalactique est : « La serviette ».
N’oubliez pas de célébrer le jour de la serviette le 25 mai en arborant votre outil de survie 😊 (effet assuré en toutes circonstances, je vous l’assure).
Ok pour la serviette, mais je me vois mal débloquer une production avec une serviette…
C’est juste, je voulais proposer un parallèle sympathique et poser la question : « quelle serait ma serviette pour réparer une production ? »
Si je ne devais retenir qu’un seul outil pour réparer un serveur (Linux) et accepter de me passer de tous les autres, ce serait… Tadam : « strace ».
Hein ? C’est quoi ce truc ?
Strace est un outil qui permet de tracer l’ensemble des appels entre l’espace utilisateur (nos programmes) et l’espace noyau (I/O, réseau, allocation mémoire, mutex, etc.). Il permet de voir (un peu à la Matrix) les différents appels ainsi que leurs paramètres défiler devant vous au fur et à mesure de l’exécution du logiciel.
Ok, mais j’en sors quoi ?
Déjà, il permet d’obtenir une sorte de vue d’ensemble du comportement en proposant de mesurer le temps cumulé par typologie d’appels (strace -c). La commande retourne la « pyramide » des temps et indique globalement ce qu’a beaucoup fait le logiciel.
- Service externe qui rame : beaucoup de temps passé en lecture réseau.
- Beaucoup d’I/O : sujet de lecture/écriture (les logs parfois…).
- Des futex dans tous les sens : c’est normal, c’est un processus Java qui ne fait que de la coordination de threads 😉
Oui, mais dans le détail, je peux voir la requête SQL qui rame ?
La réponse est oui (strace -e network pour tracer ce qui part sur le réseau et donc probablement la fameuse requête). En regardant la dernière écriture réseau suivie d’une lecture qui bloque (vous verrez, ça saccade vraiment à l’écran), vous avez potentiellement identifié une requête à problème. L’appel est à destination d’un service, je vous laisse conclure. On ne voit que du read et du write depuis une source, c’est peut-être un sujet de volume de données…
En substance, avec un seul outil (disponible la plupart du temps sur le serveur), vous pouvez détecter beaucoup de problèmes potentiels de manière rapide et efficace. Bien entendu, ce ne sera qu’un début d’analyse et d’autres outils de plus haut niveau vous permettront d’affiner… à moins que tout ne soit déjà visible dans « /proc », mais ça, c’est une autre histoire :)
https://www.commitstrip.com/fr/