Votre plus belle boulette? Le truc à pas faire que vous avez fait au cours de votre carrière?

Bonsoir!

Ça doit faire vingt ans que je turbine dans le métier. Et quelque-fois, quand je me retourne en arrière et que j'examine le travail accompli, il m'arrive de me retourner de nouveau vers l'avant effrayé de ce que j'ai pu commettre.

Si... Si...

On a tous une gaufre, une catastrophe à confesser. La manipulation vraiment pas avisée. Le truc qu'il ne fallait pas surtout pas faire et que l'on a fait.
On ira peut être pas en parler au prochain recruteur! Mais entre-nous...

Laissez-moi débuter:

J'avais 22 ans, un et demi d'expérience au mieux, et j'étais encore féru d'informatique système. Je travaillais pourtant sur IBM AS/400.

Un jour, j'étais seul au travail (à cet âge-là, les employeurs n'ont aucun scrupule à vous faire ressentir la nécessité de faire des heures supplémentaires, et vous, tout jeune, n'avez aucun doute sur le bien fondé de leur demande. Et que rien ne soit rémunéré, bien-sûr. Puisque "Vous êtes en retard sur ce qu'il y a à faire."), j'avais quelques sources à modifier d'un logiciel que ma société avait douteusement repris d'une autre qui avait fait faillite. Et ces sources ne pouvaient pas fonctionner avec l'OS de l'IBM AS/400 que j'employais.
Alors moi, voyant les cartouches de la version suivante de l'OS accessible, je les pris et je débutais nuitamment la migration de l'OS vers sa nouvelle version.

Tout s'est bien passé. L'AS/400 redémarra avec le nouveau système et tout fut en ordre.
Mais quel savon je pris le lendemain!
Changer de ma propre initiative le système d'exploitation de l'ordinateur central de la boite n'était effectivement pas, avec le recul, la chose la plus avisée à faire.

Grunt.

La pire qui m'est arrivée, en stage à 15-16 ans.
Ordre de sortir la vieille imprimante du patron. Je débranche la prise, oups c'etait la prise de son PC (il bossait dessus a ce moment) :aie:

Bonjour,
1 semaine par mois, les utilisateurs (contrôleur de gestion) saisissaient l'ensemble de données.
Au milieu de la semaine, comme chaque semaine, des évolutions à faire de toute urgence et non demandée durant les 3 autres semaines. L'une d'elles pour être sûr qu'elle fonctionne demandait à ce que je vide le cube pour le réalimenter avec des données récentes.
Je vide le cube. Oups, je suis sur le mauvais serveur, celui-ci est celui de prod.
Il était 9h45, j'ai dû remettre les données de la veille au soir avec 2h de perte de données.
Vu que les alimentations s'effectuaient via des classeurs que je leur fournissais, ça n'a pas trop mouché surtout qu'encore une fois, c'était une fleur qu'on leur faisait en effectuant une modif de dernière minute.
Petit hic ... Mon collègua avait fais la même le mois précédent mais vers 17h :aie:
Il nous a été demandé de séparer les accès aux cubes (prod, recette, dév, ...) afin de ne plus reproduire cette erreur.
Nous avons supprimé toutes les données du cube 2 fois en 4ans. Pas de chance, c'était 2 fois d'affilée.

La solution de la séparation a été abandonné car cela nous imposait des procesus de mise à jour bien plus longue car par batch, rules, ... et nous imposait des fermetures d'accès aux utilisateurs et ce n'était pas souhaité.

Ah les serveurs ... je pense que c'est super casse gu**le ces petites bêtes.

il y a 2 ou 3 ans j'étais la préposée à la maintenance d'un petit logiciel pour faire de l'import initial de données de fichiers excel vers une base Oracle.

Je fais une modif dans l'import, donc pour testé mon import initial je clic joyeusement sur vider la base. Sauf que dans la ligne adresse IP bah c'était pas ma base de test .... Oups .... :aie:

Bon dans mon malheur c'était la base d'un de mes collègues qui n'a juste pas compris pourquoi tout a coup son test c'est lamentablement planté ... (j'ai quand même rechercher quel base j'avais bien pu vidé et me suis confondue d'excuses....):oops:

Celle là je pense que je ne la referais plus. Toujours , toujours vérifier !! (toujours .... toujours .... *obsession*)

Je crois que nous avons tous ce genre d'expériences ....
Le jour où j'ai vidé par erreur l'une des principales tables de la base de données de Developpez.com, je ne faisais pas le fier. Le site n'affichait plus rien, toutes les pages d'index étaient vides et manque de bol nous n'avions pas de sauvegarde récente.
Il a fallu recréer toutes les données manquantes à partir d'historiques divers. J'ai passé une soirée horrible et depuis je fais vraiment plus attention quand je vide une table, je vérifie toujours à deux fois de quelle table et de quelle base il s'agit.

Humm avoir mal remis une barrette mémoire sur un serveur et le rallumer... Tiens de la fumer :oops:, Chef ? Le pc il va plus. Euh non je ne sais pas pourquoi :whistle2:

Sinon avoir supprimer un répertoire d'un serveur à la place de mon répertoire locale. Heureusement il y avait un système de backup :hola: mais je me suis fait une grosse frayeur

Faire une présentation client de son logiciel avec un jeu de test de mon cru. Les utilisateurs étaient Marcel Pagnol, Jean Valjean, René Cotti, et le chaperon rouge, le loup débile :?
Une chance, j'étais de bonne humeur; cela aurait put être pire.

Ecraser une version avec sa précédente dans subversion.

Pour l'instant, ma plus belle boulette est celle-ci:
J'ajoute un trigger sur une table, pour mettre à jour la date de modification de l'enregistrement. Donc dans le trigger, je mets une requête update... sans la clause where...:aie:
Résultat, au premier update, le moteur a tenté de mettre à jour en cascade tous les enregistrements... et pan la base ! Heureusement c'était la base de test.

Une autre, mais d'un collègue: c'est un grand classique. Pour vider des logs, au lieu de taper rm -rf ./*, il a tapé... rm -rf . /*, et ce sur le serveur Web de production, et en tant que root ! Adieu veau, vache, site web et serveur...

Tatayo.

En administration système, on dit qu'il y a deux types dadministrateurs : Ceux qui ont déjà rebooté le mauvais serveur et ceux qui vont le faire....

Je suis vite passé à la première catégorie.


Une autre :
Mise à jour système (Sun Recommended) d'un serveur pour mon projet ....à 3 jours de mes vacances. Mis à jour Failed, serveur crashé..

Bon, j'ai 3 jours pour refaire 1 mois de travail.

Le pire pour moi sur un serveur de fichiers Linux en production.

Code:

---

rm -rf /etc

---

:aie::aie:

Dans la série de rm -rf j'ai fait assez fort aussi.

J'avais un script de dézippage d'une archive. Je devais faire quelques contrôles sur le contenu du zip avant de le mettre en place.
Donc je dézippé dans un répertoire nommé ${TMP}, je faisais mon bouzin avant de le copier vers un répertoire ${DATA} et bien sur de vider soigneusement mon répertoire par un rm -rf ${TMP}/*

C'est beaucoup moins fun quand ${TMP} n'est pas renseigné...

Heureusement j'étais pas root, mais j'avais quand même les droits sur tous les répertoires de travail de mes collègues.... Et toutes leurs instances de serveurs de tests qui sont tombées une à une... :aie:

Depuis j'ai appris à vérifier le contenu de mes variables avant de les utiliser :oops:

Dans un système d'impression de courrier de l'administration, on me demande de rajouter un type de courrier, je code tout, pour les tests je désactive l'enregistrement dans la BD afin de pouvoir ré-imprimer toujours le même jeux de test, dans la précipitation j'oublie de le réactiver et le fait passer en production comme ca, ou bout d'une semaine on me demande si c'est normal que l'on aie autant de courrier par jour...
Le programme n'enregistrant pas qu'il imprimait le courrier, il le ré-imprimait donc chaque jour avec les nouveaux courriers du jours, certain client on reçus 5 fois le même courrier :calim2:

// Mode recruteur : ON
ToDo : tenir une liste actualisée des pseudos sur ce sujet, et toujours s'y référer avant un recrutement
// Mode recruteur : OFF

:mrgreen:

Citation:

---

Envoyé par javamine

// Mode recruteur : ON
ToDo : tenir une liste actualisée des pseudos sur ce sujet, et toujours s'y référer avant un recrutement
// Mode recruteur : OFF

:mrgreen:

---

Prend plutot la liste des personnes qui n'ont pas écrit de boulettes... Une boulette faite est une boulette qu'on ne refait pas.

(sauf pour mon collegue qui a 1 an d'intervalle a fait la même ... l'adresse IP de la gateway attribuée à un serveur... :D)

Citation:

---

Envoyé par tatayo

Pour l'instant, ma plus belle boulette est celle-ci:
J'ajoute un trigger sur une table, pour mettre à jour la date de modification de l'enregistrement. Donc dans le trigger, je mets une requête update... sans la clause where...:aie:
Résultat, au premier update, le moteur a tenté de mettre à jour en cascade tous les enregistrements... et pan la base ! Heureusement c'était la base de test.

Une autre, mais d'un collègue: c'est un grand classique. Pour vider des logs, au lieu de taper rm -rf ./*, il a tapé... rm -rf . /*, et ce sur le serveur Web de production, et en tant que root ! Adieu veau, vache, site web et serveur...

Tatayo.

---

Idem pour le Update sans Where sauf que moi c'était sur la base en prod :aie:
Mais bon j'ai tout récup en 2h , Maniac des logs en tout genre j'ai juste eu besoin de faire un prog qui les lisaient et qui remettait tout en place :oops:

Une boulette sur un Outlook express. Le responsable commercial de la boite, et aussi DG :aie:, me demande de mettre ses mails dans un dossier facilement accessible pour réaliser des copies. Je lui dit ok, récupère son pc portable, je créé le nouveau dossier, et déplace tous les fichiers de OE vers le nouveau dossier (pour quoi un déplacement ? Par manque de place sur le DD). Le déplacement terminé, j'ouvre OE (vide) et lui indique le nouveau dossier de stockage :ccool: !
Sauf que ce *@$&@* de OE détruit le contenu du nouveau dossier et recrée sa base vide ! :aie:
Comme demandé, je quitte OE et le relance, et là ... dossier vide ! 8O

On est reparti sur la dernière sauvegarde... de la semaine précédente !:calim2:

Préparation d'une chaine à passage unique exceptionellement monstrueuse(dossier suivi par le ministre en personne, avec plein de commentaires dans les médias, j'en dis pas plus pour ne pas me griller). On doit passer avant 18h00 dernier délai, sinon, un jour de retard(impact média et ministre). On est les derniers de la chaine, et notre chaine passe en 1 heure.

A 16h00, on reçoit le fichier. A 16h01, on plante. A 16h15, je me rends compte que mon composant est "livré", mais pas "installé". On a frôlé la catastrophe. Ce qui nous a sauvé, c'est que le directeur de projet connaissait par leur prénom les gens de l'exploitation. Mais ça aurait, vraiment, pu faire de gros dégats. Jamais rebossé sur des sujets aussi sensibles(mais c'est marrant, ça fait des souvenirs.....quand ça se termine bien).

En général, les erreurs de livraison, c'est ma hantise.

Un jour on m'a demandé une extraction de table sous excel avec une mise en forme bien gonflante à faire.
Ca me gonfle d'avance, je fais ma requête, j'extrais le résultat en csv dans un fichier mescouilles.csv (manie récurrente que j'ai d'appeler les fichiers d'un truc qui me gonfle)
Je l'ouvre dans excel, je remets en forme, c'est beau et ça a l'air bon, j'enregistre dans mescouilles.xls
Je renomme le fichier avant de l'envoyer par mail (quand même), avec en copie ma responsable de service et sa responsable de service.
15 minutes après, coup de téléphone, "super boulot c'est exactement ce que je voulais, par contre tu as vu ce qui est marqué dans ton onglet ?".......... Apparement (je dois pas assez utiliser excel pour le savoir) quand on enregistre un csv en xls, l'onglet du classeur prend le nom du fichier csv........ :ave:
Les responsables en copie ont pas dû ouvrir le fichier...

Citation:

---

Envoyé par Alvaten

La pire qui m'est arrivée, en stage à 15-16 ans.
Ordre de sortir la vieille imprimante du patron. Je débranche la prise, oups c'etait la prise de son PC (il bossait dessus a ce moment) :aie:

---

J'ai eu une boulette similaire durant mon stage, j'avais 19 ans et c'était encore pire.

Dans une salle avec 15 employés, un informaticien de la boîte m'a demandé de débrancher la grosse prise noire or il y en avait 2: oops, j'ai débranché la prise principale, les machines de toute la salle se sont éteintes, tout le monde râle et moi je me tape la honte!!

Citation:

---

Envoyé par leminipouce

Dans la série de rm -rf j'ai fait assez fort aussi.

J'avais un script de dézippage d'une archive. Je devais faire quelques contrôles sur le contenu du zip avant de le mettre en place.
Donc je dézippé dans un répertoire nommé ${TMP}, je faisais mon bouzin avant de le copier vers un répertoire ${DATA} et bien sur de vider soigneusement mon répertoire par un rm -rf ${TMP}/*

C'est beaucoup moins fun quand ${TMP} n'est pas renseigné...

Heureusement j'étais pas root, mais j'avais quand même les droits sur tous les répertoires de travail de mes collègues.... Et toutes leurs instances de serveurs de tests qui sont tombées une à une... :aie:

Depuis j'ai appris à vérifier le contenu de mes variables avant de les utiliser :oops:

---

Presque pareil : en root, sur un serveur de prod : chown mouser:mongroupe $mavariable/
ben après plus rien dans les bases de données (MySQL ne retrouvait plus ses fichiers) et pleins d'autres programmes avaient des comportements bizarres....
Du coup on reste au boulot jusqu'à minuit (heureusement c'est arrivé en fin de journée les clients ne l'ont pas vu) et on migre tout vers un autre serveur pour pouvoir réinstaller celui-ci...