Un jour j'ai fait un UPDATE users SET password sur la base de prod de linuxfr.org et j'ai oublié le WHERE user_id.
Un jour, j'ai fait quasiment la même chose dans une CMDB qui servait de source à un DNS. J'ai attribué la même IP à des milliers de noms de serveurs.
La requête contenait un where 2012 (ce qui donne un Vrai) au lieu de where id_serveur=2012.
Ma procédure, écrite 15 jours avant l'opération de maintenance, et testée sur une base de test, a été revue par mes collègues, et par un comité de contrôle (revue de changement). Personne n'a détecté le problème avant que je voie mysql répondre qu'il avait modifié plusieurs milliers de lignes au lieu d'une seule. Bien sûr, je n'avais pas fait de transaction. On a rollback avant que le cron d'update du DNS de prod ne passe, mais j'ai mis des heures à m'en remettre.
Bref, ça arrive, c'est très désagréable, mais ça fait clairement partie du métier.
Les seuls qui ne font pas de conneries sont ceux qui ne font rien !
[^] # Re: Expérience et postmortem
Posté par cg . En réponse au journal Comment j'ai foutu en l'air une partie de notre prod (et comment on l'a remise sur pieds). Évalué à 10.
Un jour, j'ai fait quasiment la même chose dans une CMDB qui servait de source à un DNS. J'ai attribué la même IP à des milliers de noms de serveurs.
La requête contenait un
where 2012(ce qui donne unVrai) au lieu dewhere id_serveur=2012.Ma procédure, écrite 15 jours avant l'opération de maintenance, et testée sur une base de test, a été revue par mes collègues, et par un comité de contrôle (revue de changement). Personne n'a détecté le problème avant que je voie mysql répondre qu'il avait modifié plusieurs milliers de lignes au lieu d'une seule. Bien sûr, je n'avais pas fait de transaction. On a rollback avant que le cron d'update du DNS de prod ne passe, mais j'ai mis des heures à m'en remettre.
Bref, ça arrive, c'est très désagréable, mais ça fait clairement partie du métier.
Les seuls qui ne font pas de conneries sont ceux qui ne font rien !