Jaerdoster a écrit :Je venais en espérant une chute de baie, j'ai eu mieux.
Celle-là, elle se fera rapidement :}
Bon allez, voilà ce que tu attendais, Jaer :p
Fall of the machines (yes.) / Serveurs et Tremblements
Deux mois après le 11 mars 2011, et le grand tremblement de terre qui a détruit pas mal de choses, et endommagé notre bâtiment (lézardes, fissures, etc...).
Un chef nous demande de bourrer une armoire EMC de disques.
-"Euh, chef, le sol, il est prévu que pour 300kg max..."
-"Pas grave on s'en fout le business a besoin de storage, on bourre à 500kg"
-"Mais..."
-"On renforcera si il faut !"
-"..."
Les mecs d'EMC reposent la même question, et ont la même réponse. Le business a dit, donc l'IT fait.
Je vous signale la première leçon de vie dans ce genre de profession :
Cover
Your
Ass. Abrégé en CYA. Couvrez vos arrières. Trace écrite, mails, preuves liées entre elles. Ceci peut être bien sûr la différence entre "vous avez toujours votre job" et "vous êtes viré", ou entre "vous êtes viré" et "vous êtes viré pour faute grave".
Une armoire finit donc bourrée jusqu'à la gueule de disques, et des piquets sont vrillés dans la dalle de béton sous-jacente pour maintenir en place.
Le weekend qui suit l'installation ? Un tremblement de terre assez fort nous frappe, et je suis convoqué au taf pour une anlayse de l'étendue des dégâts.
Je vous la ferai en Pokemon :
"Oh, mais que se passe-t-il ? Rack est en train d'évoluer !"
"Rack vient d'évoluer en Ascenseur !"
"Ascenseur utilise Attaque Vrille sur Sol ! C'est très efficace !"
Du datacenter au 4ème étage, un rack venait de s'effondrer et transpercer la dalle de béton dans laquelle ils auraient tout aussi bien pu faire des pointillés, avec les piquets de renforcement. Elle était déjà fissurée, et les piquets ont aggravé la chose. D'une salle de réunion du 3ème étage, l'on voyait le séant de ladite armoire.
200 transceivers fibre (petits bitoniaux à 1000$ pièce) fracassés au passage.
33% des disques morts. Malgré ça, on félicitera EMC, car "l'array était toujours vivant" (une fois extraite du sol, et les disques rebranchés, pas de données perdues, un miracle).
Mais un million d'euros de réparations et de travaux.
Qu'un certain chef a été bien emmerdé pour expliquer. Surtout quand les ingénieurs et EMC ont sorti les mails prouvant qu'ils savaient pour le problème mais que les opinions n'ont pas été écoutées.
Régiment de poulets décapités / You can (not) think.
Dans la série EMC, on en a eu une magnifique avec une classe de produit nommée le CX, un type de storage EMC plus cheap que la normale car les disques sont du SATA.
Je vous passerai tout le détail technique, ce serait très amusant mais ça va larguer tout le monde :
- Le truc a deux processeurs, pour que ça reste accessible même si un des deux se viande. Ceci s'appelle de la redondance.
- Si un contrôleur prend un signal de dégâts disque pendant un redémarrage, c'est considéré comme une erreur critique et ça "tue" le second processeur pour éviter de la corruption de données. Ceci s'appelle un bug.
Une bonne centaine de serveurs étaient reliés à ce stockage, ce qui a planté plein de trucs et nous a fait voir masse de gens courir dans tous les sens comme des poulets décapités incapables de réfléchir et de juste hurler "c'est la merde". Chefs compris. Les seuls à ne pas paniquer étaient les ingénieurs de formation, et le mec responsable du storage.
Moralité : si c'est cheap, il y A une raison. si c'est cheap, vous n'avez pas de support 24H/24. si c'est pas fiable, c'est dangereux de dépendre de ça pour des activités critiques.
TU VIENS DE ME FAIRE PERDRE UNE VIE CONNARD / CHOIX 1 : LUI FAIRE MANGER LE DISQUE
Celle-là aussi j'ai du la raconter de vive voix un bon millier de fois.
C'était en 2010, juste avant un renouvellement de contrat.
Ceci concerne un serveur de fichiers Apple, un XServe, et son stockage, un XRAID.
Les deux sont de la merde propriétaire imbitable et pas parfaitement pensée. Enfin, le XRAID est chiant à configurer (depuis un Mac uniquement !) mais une fois tuné, il tourne du feu de Dieu, on lui donnera au moins ça.
Ces machins peuvent stocker une dizaine de disques pour en tout une dizaine de téra-octets.
Je vous fais la version allégée :
- Ces machins avaient six ans au moment de l'histoire. En gros, le troisième âge pour tous les disques ... qui étaient du même lot, de surcroît. Bref, ça ne demandait qu'à mourir et j'avais déjà signalé le risque. Encore une fois,
CYA.
- Le serveur de fichier de toute la banque (avec tous les documents, dossiers, rapports financiers(tm) etc... depuis dix ans) est mort. Quatre disques d'un coup.
- Les backups étaient sur le même stockage.

Oui, ça ne servait qu'à une chose : récupérer un fichier effacé par erreur, depuis le backup de la veille.
- Je suis appelé en urgence. Menacé d'être renvoyé et attaqué en justice si je ne répare pas ça dans la seconde : on me dit que c'est ma faute, ma responsabilité et mon obligation.
Non non non messieurs.
Ma faute ? Certainement pas, le matériel est mort de sa belle mort, et j'ai prévenu du risque.
Ma responsabilité ? Non plus, j'ai prévenu plusieurs fois et proposé des options mais à chaque fois on m'a dit que "c'était trop cher, et ça tourne très bien depuis six ans, pas de raison pour que ça continue pas comme ça."
Mon obligation ? Perdu, dans mon contrat rien n'est écrit sur la résurrection et les miracles. Contrat qui s'apprête à expirer et je n'avais pas encore eu de réponse alors qu'on dépassait largement le mois de préavis normalement requis.
-"Maintenant, si vous voulez que je vous aide, on peut voir, mais il y a des conditions."
-"Tu te crois en position de négocier ?!"
-"Oui."
-"..."
-"Je veux une reconduction de contrat, une prime de deux millions de yens, et une revue de performance extraordinaire."
-"Mais. MAIS ! C'est la limite qu'un manager peut approuver sans demander à la hiréarch-oh."
-"Oui."
Ma recommandation était d'envoyer ça dans un labo et payer le prix fort pour récupérer les données. Tout ce que je pouvais tenter n'était que du BIDOUILLAGE qui avait plus de chances de foirer que de réussir. Mais à ce stade, j'avais déjà prévu le pire, si ce serveur ne repart pas, je tire une croix sur mon contrat. Enfin, même sans ça, si ce serveur ne repart pas, la banque ne repart pas non plus et le problème reste entier. Beaucoup de trucs pas propres étaient ainsi faits que le mainframe avait besoin de ce serveur pour tel ou tel traitement critique.
Je sors donc oscilloscope, fer à souder, documentation de firwmare et de RAID arrachée à Apple après un coup de fil bouillant et un NDA.
Et je m'attelle à siphonner tout ce que je peux des disques encore chauds.
Il faut savoir une chose : la chaleur et les vibrations, ça n'en a pas l'air, mais ça peut vous pourrir un matos sur la durée. C'est la différence entre un matos qui survit trois ans et un qui survit vingt ans. Et notre datacenter n'était pas de première qualité. Poches d'air chaud, clim suboptimale, vibrations mal absorbées... Bref, une recette pour tuer des disques à petit feu.
A ce stade j'ai donc quatre vies, et j'ai codé des programmes :
- un défibrilateur qui va relancer les disques dès qu'ils montrent un signe de pétage de cable, et réajuster le débit
- un programme pour reconstituer le puzzle des données fait avec le manuel d'Apple sur comment le RAID est monté
Et dans les trois premières heures, je siphonne très vite les six disques survivants, reste les 4 problématiques.
Et les chefs me tournent autour comme des vautours à se donner l'air intelligent pour que les gens qui passent aient la sensation qu'ils sont dans le coup.
C'est déjà agaçant, mais le pire restait à venir.
L'un d'eux se prend les pieds dans le cable de l'oscilloscope et se casse la gueule en viandant un disque par terre.
Je vous jure que j'ai senti le temps s'arrêter.
Que j'ai vu un écran de choix :
1) Lui faire manger le disque.
2) Table flip "c'est pas mon problème, démerdez-vous, je trouverai un autre taf"
3) Retenant la rage de toutes mes forces "...Par pitié, vous servez à RIEN, BARREZ-VOUS !!"
J'ai été très tenté de prendre la première option. J'ai opté pour la troisième.
Pour visualiser mon sentiment, imaginez vous jouer à un shooter genre Touhou ou Ikaruga, où votre survie dépend du micro pixel entre vous et le danmaku.
Et là... LEEEEEEEEEEEEEEEEEEEEEROY JJJJJJJJJERKINS qui charge et vous bouscule. Vous faisant perdre une vie contre le dernier boss.
Au bout de trois jours sans dormir, j'ai réussi la réparation.
Les seuls fichiers perdus étaient de vieilles saloperies inutilisées depuis plus de cinq ans.
Le crétin qui a trébuché et pété mon oscillo a porté le chapeau pour toute l'affaire.
J'ai failli avoir une crise cardiaque avec le choc.
Et depuis je suis allergique au Redbull.
Et ... je ne peux pas dire que ça finit bien, parce que même si j'ai eu ma prime et mon contrat reconduit et tout...
-"Bon alors, on a un budget pour remplacer le serveur mort, là ?"
-"Non, toujours pas, mais bon... Si ça merde encore on refera appel à toi."
-"......................................NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOON"
Quant à "pourquoi il n'y a pas de budget" ? Ben... Beaucoup de corruption, et de trucs pas très honnêtes des managers vis-à-vis des directeurs et des actionnaires.
Le genre...
La transaction fantôme / L'attaque du mainframe / La revanche des ATM
Découvrir que la boîte a fait croire aux actionnaires que le mainframe était parti, mais comme ça arrange pas IBM et les copains qui font du backchiche, il a été maintenu et expliqué comme poste de dépense par "la solution de remplacement et les frais de migration" qui coûtent "exactement pareil" que le mainframe :
- "Oui, en fait pour ce tarif ça n'avait aucun intérêt de se débarasser du mainframe hein~ On ferait tout aussi bien d'y revenir. ^_^;"
- "Même pas en rêve."
- "Ah bon... ^_^;;"
Un bobard pareil à maintenir sur la durée, le grand écart devient de plus en plus intenable.
Surtout six ans après avoir promis qu'on s'en débarasserait.
Les actionnaires continuaient de couper le budget de l'IT et à chaque autre problème "Occupez-vous d'abord de réduire à zéro les coûts IBM, rien d'autre ne sera approuvé avant."
Et les chefs attendaient la retraite en priant que la supercherie ne se découvre pas.
Je vous la fais courte, ça a fini par se découvrir et les responsables ont payé cher.
Avant cela, je me suis retrouvé dans une réunion où les gars du mainframe voulaient en savoir plus sur comment une DB marche :
-"Ouais, votre joujou Oracle là, ou MySQL, je sais pas, ça gère comment les transactions simultanées ?"
-"Ben... Oui, c'est une des fonctions principales o_o"
-"Ah ouais ? Alors fais-moi la preuve au tableau, là, l'ingénieur, le savant, hop hop hop"
-"Euh... Pour Oracle, il faudrait demander à des consultants ou des experts Oracle, il faudrait voir le code pour en être sûr..."
-"Pff ouais toujours la même rengaine"
-"Mais d'abord pourquoi vous voulez savoir ça ??"
-"Mais t'es con ou quoi ? Tu sais pas que le mainframe est pas capable de gérer ça ?"
-"O_O"
Discussion échaudée en japonais, où le mec a cru que je faisais partie du cercle autorisé. Le reste de la salle se retourne, blanc comme un linge, à lui faire signe "TA GUEULE TA GUEULE TA GUEULE"

, et on me fait signe que la réunion est ajournée.
J'ai juste le temps d'entendre "Mais qu'est-ce que tu as été lui dire que le mainframe gérait pas ça ?! Ca fait SIX ANS qu'on le cache !!"
Deux semaines plus tard, le monsieur en question était au récurrage des chiottes. Je ne déconne pas.
Et on vient me demander :
-"Dis, pour les DB alors tu sais ? Le support des transactions il est au poil ou pas ?"
-"Euh...

Ben oui, enfin c'est comme j'ai dit l'autre jour, ça gère, enfin si vous me croyez pas vous avez qu'à faire un procès à Oracle si ça merde, mais vous avez pas écouté ou quoi ?"
-"Oh non pour rien, ça va, c'est tout ce que je voulais savoir..."
-"... o_o"
Bravo mec, pas discret du tout, que tu voulais vérifier si j'avais compris ou pas pour le mainframe...
La "transaction fantôme", c'est un truc que j'ai découvert sur ce mainframe et sa façon de gérer les accès.
Les accès simultanés courent le risque de corrompre les sommes sur les comptes des clients, et ... il y a un hack pour corriger ça avec l'historique, à la main, sans log ni audit.
Il était possible (au moins en théorie, et je suis presque sûr que ça a été mis en pratique vu les réactions) de changer le montant d'un compte donné pourvu qu'il y ait un complice en interne, et un retrait coordonné entre deux ATM.
Je suis du coup convaincu que c'est une des raisons pour lesquelles l'usage des téléphones est interdit à proximité d'ATM au Japon.
Encore un autre exemple où non, le preux chevalier n'a pas pu sauver le Royaume, il a pris la princesse et s'est barré aussi loin que possible parce que ce dragon là, nope nope NOPE.