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.
# Le debugging c'est la vie ! (ou pas)
Posté par Big Pete . En réponse au journal Petite histoire de debug. É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.