Certaines personnes trouvent que les contenus sur LinuxFr.org sont de moins en moins techniques, et mon dernier journal parlait de motivation au travail, donc très peu technique. Pour compenser, je vais vous raconter une petite histoire sur du debug que j'ai fait la semaine dernière.
Jeudi dernier, dans l'après-midi, je venais de finir de coder une petite fonctionnalité et j'allais merger la pull request associée. Mais, au moment de faire ça, je me rends compte que l'intégration continue est au rouge : les tests d'intégration ont échoué. Ce sont une suite de tests écrits en Ruby qui lancent la partie serveur de Cozy (appelée cozy-stack), font des appels à l'API et vérifient que les réponses correspondent aux attentes. C'est surtout utilisé pour des parties où les tests unitaires ne sont pas suffisants, comme la mise en place de partage de fichiers entre deux instances Cozy.
Premier réflexe : copier les logs de l'échec et relancer le build. Ça arrive de temps à autres que les tests d'intégration échouent pour de mauvaises raisons (un problème réseau, la machine virtuelle a ramé et on a atteint un timeout, etc.), même si c'est de plus en plus rare. Bon, c'est toujours rouge. J'avais lancé les tests en local et ça passait, mais je vérifie une deuxième fois : chez moi, ça marche (c) !
Bon, va falloir réfléchir un peu et trouver de quoi ça vient. A priori, le test qui échoue a peu à voir avec le code modifié. Le dernier commit dans master date de mardi matin, c'était une mise à jour d'une dépendance et le build était vert à ce moment-là. Je veux savoir si le problème vient réellement de ma modification ou si c'est quelque chose d'externe, je crée alors une autre pull request avec juste un changement anodin par rapport à la branche principale pour lancer les tests d'intégration. C'est rouge aussi, le problème ne vient pas de mes modifications.
Ça se complique, il va falloir trouver ce qui a changé entre mardi matin et jeudi après-midi. Premier suspect : l'environnement d'intégration lui-même. Je passe pas mal de temps à chercher dans les documentations et blogs de GitHub, mais a priori, GitHub Actions n'a pas bougé significativement entre temps (j'ai d'ailleurs le même numéro de version du runner pour tous les builds récents, 2.267.1). J'en profite aussi pour demander à mes collègues si ce problème leur dit quelque chose.
Deuxième suspect : les dépendances. C'est un grand classique, on peut facilement se retrouver avec du code différent en local et sur la CI. Normalement, c'est le moins cas ces dernières années avec la généralisation des fichiers de lock pour les dépendances, mais j'ai encore eu le cas il y a quelque mois à cause d'un bug de bundler, l'outil de gestion de dépendances de Ruby. Bon, j'ai la même version de Ruby, Rubygems et bundler en local que sur la CI. Les fichiers de lock sont bien utilisés, aussi bien pour le code testé en Go que pour l'outillage de test en Ruby.
Il va falloir plonger plus profondément dans le code. J'hésite entre l'ajout de logs et chercher un moyen de me connecter en ssh sur la CI, mais je crains de passer beaucoup de temps sur la deuxième solution, donc je préfère commencer par simplement ajouter des logs, en me disant que si au bout d'une heure je suis toujours coincé, il sera sûrement temps de passer à l'autre méthode.
En ajoutant les logs, je trouve la source du problème : normalement, quand un utilisateur ajoute une image ou photo sur son instance Cozy, la stack génère des vignettes avec Image Magick et les applications peuvent être notifiées quand la génération a fini via une websocket, et ici, on reçoit 0 messages de notification, alors qu'on s'attend à en recevoir 3 (un par taille : large, medium et small). Je vérifie rapidement que Image Magick est bien installé sur la CI, avec une version à jour, mais je rajoute rapidement des informations de timing pour mieux comprendre ce qu'il se passe. Et là, je me rends compte qu'il se passe vraiment très peu de temps entre la fin de l'upload de l'image et le moment où on vérifie les vignettes générées. Je suspecte donc un problème liée à la websocket.
On utilise une bibliothèque Ruby appelée faye-websocket-ruby pour se connecter en websocket, et cette bibliothèque s'appuie sur EventMachine (une boucle événementielle en Ruby). Je vais lire la documentation et je trouve que l'on peut ajouter un callback pour avoir accès aux erreurs :
ws.on :error do |err|
puts err
endJe relance des tests sur GitHub Actions, et j'obtiens une jolie erreur ECONNREFUSED. Je continue d'essayer de trifouiller pour avoir plus d'informations, mais il faut se rendre à l'évidence, je tourne un peu en rond. Je décide de faire un petit résumé de ce que je sais :
- le code de test en Ruby n'arrive pas à se connecter en websocket à la stack
- pourtant la stack tourne bien et sur le port TCP attendu car les connexions HTTP classiques juste avant passent bien (et j'ai vérifié lors du debug que je pouvais aussi faire une connexion HTTP juste après)
- l'erreur est
ECONNREFUSEDet ça me laisse très fortement penser qu'on essaye d'ouvrir une connexion TCP vers le mauvais endroit - pour ouvrir la websocket, on passe deux informations : le nom de domaine et le port
- on passe
alice.test.cozy.toolscomme nom de domaine et8081comme port, et ça m'a l'air bon - une connexion TCP, c'est un quadruplet adresse IP source, port source, adresse IP destination, port destination
-
alice.test.cozy.toolsrésout en 127.0.0.1 (comme tous les sous-domaines decozy.tools).
Et là, j'ai une intuition (ou l'expérience qui parle) : la résolution de nom, pour passer du nom de domaine à une adresse IP ! Dans la très grande majorité des cas, cette résolution de nom se fait via la glibc. Mais les appels sont bloquants, et c'est problématique d'avoir des appels bloquants qui peuvent potentiellement durer jusqu'à quelques secondes dans une boucle événementielle comme Event Machine. De mémoire, il y a deux manières classiques de contourner le problème :
- avoir un pool de threads dédiés à la résolution de noms (il me semble que c'est l'approche retenue par Nodejs)
- ou réimplémenter la résolution de nom.
Je fouille le code de faye-websocket-ruby et d'Event Machine, et je trouve rapidement ce que je cherche : https://github.com/eventmachine/eventmachine/blob/master/lib/em/resolver.rb. EventMachine réimplémente la résolution de nom (sans chercher le détail, on voit qu'il lit les fichiers /etc/hosts et /etc/resolv.conf).
OK, j'ai une piste, il ne me reste plus qu'à l'exploiter. Je ne vois pas de moyen simple de monkey-patcher le code Ruby (il y a pas mal d'indirections), mais je peux jouer sur le fichier /etc/hosts pour forcer la résolution de nom sur 127.0.0.1. Ça confirme rapidement que la piste est bonne et me donne un moyen de réparer les tests d'intégration (au moins de manière provisoire) : https://github.com/cozy/cozy-stack/commit/15712ad12fb9b7a94f1089f5f08f959741c10c7c.
Au moment du commit, j'avais encore un peu de mal à comprendre pourquoi ça avait changé sur la CI, mais j'ai eu l'explication quelques minutes plus tard. Notre admin/sys avait rajouté la résolution DNS en IPv6 mardi en milieu de journée, mais il n'avait pas fait le rapprochement entre ça et le problème de vignettes sur les tests d'intégration. Je suppose donc que la résolution DNS d'EventMachine doit se faire d'une manière légèrement différente et retourner l'adresse en IPv6 alors que la stack écoute sur 127.0.0.1 (IPv4). Pour le moment, je vais rester sur ce correctif mais si je trouve un peu de temps cette semaine, j'aimerais bien faire un rapport de bug détaillé à EventMachine, voire proposer un correctif.
J'en profite pour rappeler trois astuces connues mais toujours aussi pertinentes pour débugger efficacement :
Résumer ce que l'on sait : idéalement, si on a un collègue disponible, on peut lui expliquer le problème, mais à défaut, on peut aussi utiliser un canard en plastique ou du papier et un crayon. Résumer ce que l'on sait et l'expliquer permet souvent de voir les trous et oublis.
Faire des pauses : quand on débug, il faut à la fois être attentif aux petits indices que l'on peut trouver et faire preuve d'imagination pour trouver de nouvelles pistes. Faire des pauses, que ce soit passer l'aspirateur, méditer, faire du sport, parler avec un collègue ou dormir, permet de laisser du temps au cerveau pour travailler en tâche de fond et revenir dans un état d'esprit plus disposé à voir ces petits indices.
Diviser pour mieux régner : enfin, il est facile de passer beaucoup de temps à chercher dans le vide, à suivre le déroulement complet de tout le processus dans un débugger sans trop savoir ce que l'on cherche. Il vaut mieux être capable d'émettre des hypothèses et formuler des moyens de vérifier si ces hypothèses sont vérifiées. Si l'hypothèse peut être vérifiée rapidement, autant le faire, même si ça vous paraît très peu probable que le problème vienne de là : au moins, vous serez fixé et vous pourrez plus facilement passer à la suite. Parfois, on peut faire des hypothèses assez précises, mais d'autres fois, on peut s'en remettre à une recherche dichotomique sur les différentes étapes. Si le processus pour reproduire un bug passe par un certain nombre d'étapes, on peut regarder si en gros à la moitié, on est dans l'état attendu ou non, puis en redivisant sur les étapes qui restent, on peut finir par isoler l'étape en question.
Voilà, j'espère que ça vous inspirera la prochaine fois que vous partirez à la chasse aux bugs !
# Et savoir comment on sait ce que l'on sait
Posté par Guillaum (site web personnel) . Évalué à 9.
Résumer ce que l'on sait: 99% du boulot ! J'y ajouterais qu'il faut vraiment faire très attention à comment sait on ce que l'on sait. Je ne compte plus le nombre d'heures de debug passées sur une supposition fausse.
Cette belle chanson résume le problème de partir de croyance et non de faits.
https://www.youtube.com/watch?v=YA3XKIAGRuE
[^] # Re: Et savoir comment on sait ce que l'on sait
Posté par Benoît Sibaud (site web personnel) . Évalué à 9. Dernière modification le 30 juillet 2020 à 10:23.
Parmi les cas les plus pénibles que j'ai rencontrés, liés à ce que l'on pense savoir à un moment :
[^] # Re: Et savoir comment on sait ce que l'on sait
Posté par ZeroHeure . Évalué à 4.
Ah oui ça énerve ce truc… je n'ai plus de cheveux depuis, toi aussi non ?
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
# Petite erreur de jugement ?
Posté par _kaos_ . Évalué à 10.
Salut,
Ton journal ici parle de technique informatique. Il a toute sa place, est complet et intéressant.
Ton précédent parlait de technique humaine ! Je l'ai trouvé bien plus intéressant.
Débugger un programme informatique, ok. C'est un peu ce que beaucoup de monde fait ici.
Juste au cas où, si quelqu'un a un débuggeur de cerveau, je serais très intéressé pour acheter une licence.
;)
Matricule 23415
[^] # Re: Petite erreur de jugement ?
Posté par martoni (site web personnel, Mastodon) . Évalué à 3.
Ça me fait penser à un bouquin – que je n'ai pas lu – qui est sorti il n'y a pas longtemps : Le bug humain
J'ai plus qu'une balle
[^] # Re: Petite erreur de jugement ?
Posté par barmic 🦦 . Évalué à 2.
La semaine dernière linuxfr est tout de même un peu devenu doléancefr. Ce sont des journeaux intéressants, mais leur accumulation en peu de temps donne effectivement une impression que les moules sont devenues des caliméros.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Petite erreur de jugement ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
Tu ne serais pas en train de te plaindre des derniers journaux quand même ? :)
[^] # Re: Petite erreur de jugement ?
Posté par barmic 🦦 . Évalué à 6.
On est pas sur râleurfr ici ? :p
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Petite erreur de jugement ?
Posté par freem . Évalué à 3.
Ma foi, nous attendons tes journaux tech avec grande impatience :) Sans blague, c'est sympa de temps en temps ces journaux, j'aimerai qu'ils soient la norme.
Et tant qu'a râler, autant râler sur des sujets un peu liés au thème du coin: linux et logiciels libres. Bon, ajoutons le troll vim vs emacs sur les journaux qui n'ont rien a voir avec les éditeurs de texte, ok (si quelqu'un peut retrouvé la n'image de référénce… j'ai perdu mon bookmark).
# ma petite technique
Posté par xulops (site web personnel) . Évalué à 7.
Si ça peut aider…
Quand je bossais en équipe, si un bug me bloquait plus de 5 ou 10 minutes, je demandais au collègue à côté de moi si je pouvais lui expliquer mon problème (et il faisait pareil quand il était bloqué).
Dans 90% des cas, le fait d'expliquer la situation permet de trouver le problème, car ça oblige à prendre un peu de recul, à reformuler les choses pour les rendre compréhensibles à l'interlocuteur.
Dans 9 autres % des cas, c'est le collègue qui trouve, car c'est bien connu qu'il y a toujours plus d'idées dans plusieurs cerveaux que dans un seul.
Dans les 1% restants, on galère à deux.
Un exemple de truc con sur lequel on a galéré : un éditeur (je ne me souviens plus lequel, peut-être gedit) qui faisait la différence entre un espace et la combinaison ALTGR + espace (tapé accidentellement car de mémoire sur le clavier français faut faire ALTGR 5 pour choper l'accolade, et la touche ALTGR a été relachée trop tardivement), et l'interpréteur aussi car il plantait avec erreur de syntaxe, sauf qu'à l'écran, rien ne permettait de faire la différence entre ces deux caractères. J'ai perdu deux heures là dessus pour trouver qu'un espace n'était pas un vrai espace.
Maintenant que je bosse seul, je continue un peu schizophréniquement à appliquer cette méthode : j'imagine un interlocuteur fictif auquel j'explique ce que je veux faire, … et ça marche (dans 90% des cas, ce qui est déjà pas mal).
[^] # Re: ma petite technique
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 8.
C’est une technique connue, et tu peux effectivement résoudre le problème tout seul dans 90 % des cas en utilisant un canard en plastique ou une peluche à la place du collègue.
L’avantage de la peluche étant qu’elle est toujours disponible et qu’elle ne râle jamais.
La connaissance libre : https://zestedesavoir.com
[^] # Re: ma petite technique
Posté par nico4nicolas . Évalué à 6.
Tout développeur respectable n'a pas un canard en plastique mais un manchot en plastique. De même que ce n'est pas un ours en peluche comme K&R qu'il faut avoir mais un gnou en peluche. Je reconnais quand même que le renard en peluche est sacrément mignon.
[^] # Re: ma petite technique
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6.
Moi j'ai un dévelopeur en peluche
[^] # Bien vu
Posté par Arthur Accroc . Évalué à 3.
Une solution plutôt bon marché pour tous les projets qui manquent de développeurs.
Et puis tu peux aussi leur acheter directement une fonctionnalité.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: ma petite technique
Posté par Tonton Th (Mastodon) . Évalué à 4.
Et pour moi, je pense m'équiper chez DoomyFlo :)
[^] # Re: ma petite technique
Posté par nico4nicolas . Évalué à 3.
Merci pour le lien ! Ca faisait un moment que je cherchais un Tux en peluche et celui proposé sur le site me parait très bien donc j'ai commandé.
[^] # Re: ma petite technique
Posté par claudex . Évalué à 5.
Personnellement, je trouve le collègue bien plus efficace, même s’il ne connaît pas le sujet, il peut valider ton raisonnement. Même si ça dépanne de parler à son bic quand on est seul.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: ma petite technique
Posté par Elfir3 . Évalué à 10.
J'ai aussi essayé la technique de se parler à soi-même.
Le problème c'est qu'avec la divergence d'opinion, on en arrive très rapidement à dévier et à se battre sur des sujets sensibles comme l'usage des espaces contre les tabulation.
[^] # Re: ma petite technique
Posté par xulops (site web personnel) . Évalué à 1.
Et il aide vraiment dans les 9 autres % (estimation pifométrique mais sûrement pas très loin de la réalité, en fait ça dépend du-dit collègue) alors que la peluche, elle te laisse dans la merde.
[^] # Re: ma petite technique
Posté par barmic 🦦 . Évalué à 6.
On voit que tu connais pas mon chonchon, toi ! Depuis 30 ans il ne m'a jamais fais faux bond lui
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: ma petite technique
Posté par xulops (site web personnel) . Évalué à 2.
Je n'ai malheureusement pas le plaisir de connaître Chonchon.
A mon prochain retour en France (si un jour ce satané virus le permet), on ira boire un pot ensemble et tu me présenteras ?
S'il est vraiment aussi efficace qu'un collègue faut penser au clonage ou à faire un élevage, il y a des sous à se faire là.
[^] # Re: ma petite technique
Posté par _kaos_ . Évalué à 4.
Salut,
Même méthode environ.
Si le problème n'est pas explicable, le problème est ailleurs. Une fois fini d'être expliqué, il y a de fortes chances que soit une bonne piste soit déjà trouvée :)
Sympa l'idée de la peluche ;)
Je l'utilisais sans trop savoir si ça pouvait marcher, dans une autre version.
Il m'arrive de faire de la modération (pas ici), même si j'avais un peu tout, parfois prendre une décision n'est pas facile.
C'est au cours d'un voyage en Grèce que j'ai trouvé cette solution similaire : une statuette de Thémis.
Elle me donne tout ce qu'il me faut : la balance pour évaluer, ou l'épée pour trancher.
Matricule 23415
# Corriger par paire
Posté par barmic 🦦 . Évalué à 5.
Tu semble y avoir passé du temps, avoir dû chercher pas mal de choses, qu'est-ce qui t'a manqué pour trouver la cause en quelques minutes ?
C'est le genre de questions que je me pose systématiquement en plus maintenant :
Ici tu explique que vous n'aviez pas la gestion d'erreur de votre event loop. C'est assez difficile de ne pas se concentrer sur l'happy path, ça vaut le coup de profiter de ce genre de cas pour se poser la question de comment améliorer la fiabilité. On reproduit rarement un bug 2 fois, mais ce genre d'amélioration sont généralement plus large. Par exemple logger les erreurs de l'event loop ça peut servir dans un certains nombre de cas.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Corriger par paire
Posté par _kaos_ . Évalué à 4.
Salut,
Tout le contraire de mon expérience.
Si je n'arrive pas à reproduire, c'est que j'ai mal écouté le use-case et qu'il me faut revenir vers l'utilisateur. Avant même de remonter les manches et attaquer le problème. Je ne me lance pas dans un fix au hasard.
Matricule 23415
[^] # Re: Corriger par paire
Posté par barmic 🦦 . Évalué à 5.
Hum je n'est pas était claire, je ne parle pas de ce genre de reproductibilité, mais qu'une fois que quelque chose est corriger il est pas sensé réexploser de la même façon même après plusieurs mois/années.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Corriger par paire
Posté par _kaos_ . Évalué à 2.
Salut,
Ah oui, je vois mieux.
Effectivement, quand on a fait une erreur une fois, on est un peu plus hésitant si on sens qu'elle traine encore dans le coin…
Matricule 23415
[^] # Re: Corriger par paire
Posté par freem . Évalué à 5.
Toi, tu bosses pas avec du hardware… parce que reproduire un bug causé par des interférences électromagnétiques fortes, causée, par exemple, par un navire qui passe ou par un putain de téléphone qui sonne juste à côté de la carte mère, c'est pas simple.
Le coup du tél on l'a trouvé par hasard (ps: kudos olivier, même si je doute que tu sois dans le coin), mais a permis de mettre en évidence le problème d'origine.
Hé oui, un bug, c'est pas toujours soft ni lié aux use-cases.
[^] # Re: Corriger par paire
Posté par windu.2b . Évalué à 3.
Tu peux pas nous laisser sur notre faim, comme ça !
La foule en délire réclame un journal racontant cette histoire de bug hardware et de téléphone qui parasite !
[^] # Re: Corriger par paire
Posté par freem . Évalué à 2.
Pas grand chose de plus a dire pour le coup, désolé.
C'est vraiment juste: une carte mère à la masse, reliée à un module usb qui lui ne l'étais pas.
Parfois le matos freezais, on ne savais pas du tout dans quelles circonstances, vu que c'était déployé en bord de cours d'eau pour être branché sur des péniches.
Le mettre à la masse "semble" avoir résolu le problème, que l'on n'était pas sûr d'avoir vraiment identifié, personne d'entre nous n'ayant de réelles compétences en radio/électronique et autres joyeusetés.
Il y a eu d'autres problèmes de hard/soft, si ça se trouve c'était juste une seule des causes. Je n'en saurais jamais plus :)
[^] # Re: Corriger par paire
Posté par _kaos_ . Évalué à 2. Dernière modification le 01 août 2020 à 09:59.
Salut,
Tu veux dire que ça, c'est pas du use-case ?
Effectivement, je fais plus du soft que du hard, mais je crois que ça reste pareil : si y'a une sorte de grain de sable, il faut le trouver avant de s'attaquer au reste. ;)
Matricule 23415
[^] # Re: Corriger par paire
Posté par freem . Évalué à 4. Dernière modification le 02 août 2020 à 22:49.
En vrai, j'ai dis le problème d'origine, mais c'est p'tet juste un d'eux. Pas comme si on avait des gens dont c’eut été le métier, en fait, alors on s'est démerdé à l'empirique.
Bon, et sinon, le "use case a écouter", c'était "Bonjour, je suis arrivé, la borne est freeze". Démerdes toi. Faut faire un poff/pon déjà pour remettre en service, parce que le client en a besoin pour alimenter son bateau, et donc ouai, t'as aucune info, sauf, ça freeze. Est-le soft? Est-le hard? Tu sais pas.
Et tu peux pas forcément aller voir sur place, non.
Dans ce cas on n'aurait jamais rien livré, parce qu'on ne peux pas reproduire aisément dans un petit atelier le passage a proximité d'une péniche mal blindée, l'usage d'un groupe électrogène foireux dans un système qui est connecté d'une manière ou d'une autre au système électrique, les problèmes de radio, etc.
C'est une des différences entre les problèmes liés au hard et ceux qui sont 100% logiciels.
Dans une solution purement logicielle, tu peux tout simuler a moindre frais, tu peux même fuzzer pour 3 fois rien, sans même instrumenter!
Quand c'est lié au hard (ou a des bugs de firmware qui seraient utilisés dans des composants hein)… pas vraiment. C'est pire que d'avoir un code proprio à intégrer.
Après, je manque clairement d'expérience sur le sujet, mais le peu que j'en ai me fait penser que c'est bien plus difficile a jauger quand il faut composer avec le matériel, ses défauts, les conditions météorologiques, les systèmes pourris qui passent à côté et t'envoient un max de parasites de partout (oui, le blindage aide, les mises à la masse aussi, mais difficile de toute tester amha), …
[^] # Re: Corriger par paire
Posté par ted (site web personnel) . Évalué à 2.
Une histoire dans le même genre:
(en) http://beza1e1.tuxen.de/lore/crash_cows.html
Un LUG en Lorraine : https://enunclic-cappel.fr
# Le debugging c'est la vie ! (ou pas)
Posté par Big Pete . Évalué à 10.
Je te préviens, j'ai zappé et en lue en diagonale la partie technique, ce n'est pas du tout mon domaine. Mais ta conclusion m'a donné envie de témoigné de mon cas.
Comme je suis ingé réseau, en exploitation, c'est très souvent qu'on viens me voir pour me demander pourquoi le réseau est pété alors que c'est "juste" un problème de résolution DNS et quelque fois, lié a un changement ou un problème qui n'est pas fondamentalement un problème réseau. Attention, par nature, le DNS est à cheval entre les deux monde (système/réseau). Techniquement, ce n'est pas dans mon périmètre là où je bosse, mais ça pourrait très bien l'être. (En réalité je pense même que ça devrait l'être, mais bon …)
En tout, cas c'est souvent que l'admin ne pense pas d'abord à vérifier la résolution DNS de sa machine avant de venir me voir. Mais attention, j'ai aussi conscience du biais que ceux qui y ont pensé d'abord ont immédiatement trouvé le problème et donc ne vienne pas me voir et fausse ma perception de la chose.
Et c'est aussi la raison pour laquelle je pose systématiquement cette question parmi d'autres d'ailleurs (comme vérifier les routes sur la machine, la conf de l'appli pour être sur qu'elle n'est pas en mode j'écoute uniquement sur 127.0.0.1). Les admins expérimentés me répondent qu'évidement ils ont déjà vérifié ça, qu'il faudrait quand même pas que je les prenne pour des jambons. Mais bon, je ne peux pas savoir, et comme ça permet de résoudre la majeure partie des problèmes, c'est un peu le passage obligé.
Sur le debugging des problèmes complexes, perso, j'adore çà. Alors c'est un sentiment bizarre, parce qu'on a pas envie d'avoir à le faire, mais en même temps, quand on en a un bien velu sur les bras, c'est là qu'on s'éclate le plus. Surtout le moment jouissif où on comprend enfin pourquoi ça déconne. Je compare souvent ça au travail d'enquêteur de police ou encore celui de médecin, toute proportions gardées, bien entendu. Mais on retrouve ce sentiment d’excitation malsain face a un truc qui ne marche pas, foireux, et dans leur cas, un malade bizarre ou encore un cadavre.
Et souvent la démarche intellectuelle est assez similaire. Les fausse pistes, le besoin de récapituler, la nécessité d'ouvrir le champ d'investigation quand on commence a tourner en rond, l'importance de ne négliger aucun indice, le rôle de l'intuition et de l'expérience et la capacité à gérer la situation en parallèle. Dans mon cas, quand on vient me voir c'est souvent parce que la prod est par terre ou assez mal en point et du coup j'ai un peu de monde sur le dos.
Malheureusement on est souvent aussi déçu par le coupable, les problèmes même complexe ont souvent pour origine des trucs à la con oublié dans les coins, qui par effet de bord et venu mettre le souk; le bug, le grain de sable dans l'engrenage. Même quand on a passé trois jours complet dessus limite à en perdre le sommeil, quand on finit par dire, ben c'est juste un petit truc qui déconne, on est déçu. on aurait aimé tenir le bug encore inconnu dans tel soft ou tel OS, et pouvoir remonté ça aux développeurs, mais même quand on pense en tenir un, on s’aperçoit qu'un rapport de bug est déjà ouvert depuis une plombe, que c'est corrigé, qu'il n'y a qu'à patcher et qu'on aurait déjà du patcher d’ailleurs et que c'est bien de notre faute si on s'est mis dans la merde.
Et comme le flic ou le toubib, on est le gars qu'on a pas forcément envie de voir mais qu'on est bien content de trouver quand ça va pas. On a souvent un caractère de merde (dans le boulot) lié au fait qu'on est conditionné à force à ne voir que ce qui ne marche pas et d'ailleurs, ça fait de nous des ingé pas forcément bon en conception pure, à force de voir que des problèmes partout, on ne voit pas forcément les solutions et on a une tendance a renâcler face aux changements. Par contre, dans un process de conception, je pense qu'on a notre rôle à jouer, dans le sens où ça permet de mettre en quelque sorte à l'épreuve un projet avant sa phase de réalisation et d'éviter pas mal d’écueils.
Et enfin, pour les gars dans dans mon cas, lisez des polards ! On s'y retrouve. Et puis j'ai pas mal de collègues qui finissent par bosser coté sécu. On se demande pourquoi … ;-)
Et quand les chefs me parle d'automatisation, de cloud, d'IA avec les yeux qui brillent en pensant que sa va résoudre tout ça et qu'il va pouvoir enfin se passer de mes services de vieux ronchon casse-couille, j'ai le sourire en coin et je me dit, toi t'es pas prêt de te débarrasser des gars comme moi. L'avenir est a la multiplication automatisé des emmerdements, à la connerie artificielle, aux tempêtes dans le cloud et jamais de la vie il vont pouvoir se passer de nous, bien au contraire !
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
[^] # Re: Le debugging c'est la vie ! (ou pas)
Posté par _kaos_ . Évalué à 5.
Salut,
Juste pour dire…
C'est tout à fait mon mode de fonctionnement. L'erreur, en général, elle n'est pas loin, et probablement pas du côté utilisateur.
Je trouve que se remettre soi-même en question en premier est le meilleur moyen d'avancer. L'utilisateur, lui, il veut juste utiliser et que ça marche.
Matricule 23415
[^] # Re: Le debugging c'est la vie ! (ou pas)
Posté par Big Pete . Évalué à 2. Dernière modification le 30 juillet 2020 à 10:58.
Moué, l'aphorisme est aussi applicable à l'utilisateur, c'est tout le problème. La comparaison avec le toubib n'est pas là par hasard, si on va voir un médecin en lui disant "je veux juste pouvoir faire n'importe quoi avec mon hygiène de vie et vous vous démerdez pour que ça n'ait pas de conséquence sur ma santé, c'est votre problème, c'est pour ça qu'on vous paye", je pense qu'on risque pas d'être très bien reçu. Et attention, le toubib qui nous dit, "pas de problème, signez ici, je vous garanti qu'avec mon traitement vous n'aurait jamais de souci", c'est pas forcément celui qui nous veux vraiment du bien.
Mais attention, je comprend aussi très bien ce que tu veux dire, toujours rejeté la faute sur l'utilisateur qui fait n'importe quoi (ou le patient dans le cas du toubib) est un biais assez dangereux dans le métier. En fait, c'est surtout que les deux doivent avoir la capacité de se remettre en question et c'est les deux qui ont souvent la solution. Dans le cas de l'informatique, c'est souvent là qu'intervienne les problématique d'interface homme/machine. On pense de façon assez binaire du style soit l'utilisateur ne sait pas se servir de la machine, soit la machine est mal foutue, mais en fait, c'est souvent que les deux sont pas adaptés l'un a l'autre.
C'est un problème hyper intéressant et absolument fondamental. L'adaptation à environnement, c'est le principe de base de la vie. Je connais par exemple une espèce vivante sur une planète que je connais assez bien qui a quelque souci avec ça en ce moment, si vous voyez ce que je veux dire.
Faut pas gonfler Gérard Lambert quand il répare sa mobylette.
[^] # Re: Le debugging c'est la vie ! (ou pas)
Posté par _kaos_ . Évalué à 3.
Salut,
Oui, bien sûr. Et si on remet tout ça à l'informatique, j'ai vu un petit jeu rigolo, même s'il doit dater, dernièrement. À propos d'hygniène :)
Des personnes en charge de la sécu info ont joué au plus malin. Donc tout était sous contrôle. Pas de risque vital.
Ils on acheté un nom de domaine, presque comme celui de la boite. Mis du SSL pour que voilà, ça semble réglo. Dupliqué le site vu qu'ils avaient les sources. Forgé un mail avec juste un petit gag. Le lien dans le message (officiel de la boite) ne pointait pas là où il fallait. Un bon gros honeypot, quoi. A peine masqué.
Je n'ai pas les chiffres, puisque j'y suis plus. Mais de ce que j'ai entendu, à tous les niveau, ça a cliqué, entré son login/password.
Bon, moi j'ai pris 30 secondes, et hop… ce mail, c'est poubelle !
Matricule 23415
[^] # Re: Le debugging c'est la vie ! (ou pas)
Posté par freem . Évalué à 3.
exercice de sécu «Red Team vs Blue Team»? J'adorerais être pris dans ce genre de trucs un jour, même à mon insu, voire, surtout à mon insu. Lire le résultat doit être super intéressant.
[^] # Re: Le debugging c'est la vie ! (ou pas)
Posté par _kaos_ . Évalué à 2.
Salut,
C'est plus de l'exercice genre "alarme incendie". Pour rappeler que non, même si ça a l'air vrai, on clique pas n'importe où ;)
Matricule 23415
[^] # Re: Le debugging c'est la vie ! (ou pas)
Posté par Christophe B. (site web personnel) . Évalué à 3.
+1
Oui mais beaucoup ne viennent te voir que quand cela les arrange … Pour éviter justement des remises en questions du projet qu'ils veulent caser chez le client.
[^] # Re: Le debugging c'est la vie ! (ou pas)
Posté par fearan . Évalué à 2.
j'aurais bien dit qu'il y a une différence majeur, c'est que le toubib on peut prendre rendez-vous; sauf que maintenant, le service info de la boite il faut prendre rendez vous; les consultations c'est plus possible :(
Ah oui et comme pour installer une vm (vmware) windows il faut leur laisser le PC 2H, c'est galère;
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Le debugging c'est la vie ! (ou pas)
Posté par windu.2b . Évalué à 2.
Ça dépend qui/pour quoi : si ton toubib, c'est Dr. House non seulement tu ne prends pas RDV, mais en plus ça veut dire que t'as un gros problème !
[^] # Re: Le debugging c'est la vie ! (ou pas)
Posté par oau . Évalué à 2.
J'ai adoré lire ce commentaire. Ce sont très exactement les raisons pour lesquelles j'adore mon métier. J'ai passé des années à debug les applicatifs de mes clients sans en avoir le code. Simplement en regardant l'impact de leur code sur la machine. J'ai donc fait du monitoring mon métier pendant de longues années.
Aujourd'hui je développe moi même une application et j'ai gardé cette maniaquerie de tout log, de tout monitorer, de récupérer toute les sortie d'erreur, d'avoir des scénarios de tests qui tournent en permanence et qui me remontent toutes sortes de métriques.
Au final il est rare que j'ai des bugs. Que des choses ne marchent pas et ça devient vraiment frustrant. Alors je ne sais pas si l'informatique (que j'utilise) est devenu vraiment stable, si c'est moi qui suis devenu pas trop mauvais avec le temps ou si ce que je fais reste finalement simple. Probablement un peu des trois. Alors je calme ma frustration en lisant la ml de ceph pour voir les problèmes des autres, ou bien linuxfr.
Mais moi des problèmes techniques en informatique j'en ai plus et ça me rend triste dans un sens.
[^] # Re: Le debugging c'est la vie ! (ou pas)
Posté par freem . Évalué à 2.
Ça serait possible de nous expliquer ce que tu monitores et comment, sur un système linux ou bsd?
J'ai passé ma journée a explorer le sujet, pour linux, j'ai lu pas mal de choses intéressantes, mais tout semble très… disons, expérimental, fragile. Mais sujet passionnant!
En plus, ça tombe bien, tu sembles t'ennuyer, et apprécier les discussions ici: je peux t'assurer que, quand on écrit un journal, on a des retours pas forcément positifs, mais très souvent instructifs et/ou divertissants.
# Externe
Posté par claudex . Évalué à 4.
Surtout si on se rend compte à postériori que le problème était externe, ça permet de mieux le diagnostiquer. Par exemple, un truc qui ne marche pas et puis qui remarche sans qu'on sache si un des changements qu'on a fait a résolu le problème. Cela peut être une API qu'on appelle qui ne répondait pas correctement. C'est difficile de revenir dans le passé pour vérifier si c'était bien ça.
Tous ces tests permettent aussi de tester de valider certains composants. Par exemple, si on arrive à appeler plusieurs API externes sans problème, c'est que le réseau fonctionne globallement bien (il peut y avoir un truc particulier pour un cas, mais c'est souvent assez rare).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Externe
Posté par guppy . Évalué à 3.
Souvent rare ? Ca veut dire quoi précisément ? :D
[^] # Re: Externe
Posté par claudex . Évalué à 5.
Ça veut dire que rarement, c'est très fréquent :)
Plus sérieusement, je voulais dire que dans la plupart des infras, si tu arrive à contacter des services externes, c'est que le réseau va bien, sauf cas exceptionnel. Par contre, j'ai connu des cas, où le réseau était tellement mal branlé que ce n'est pas parce qu'un truc marche que le truc à côté va marcher.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.