\o/ … c’est bien elle a pensé aux années bissextile.
Allez, autre anecdote, toujours dans la même société.
Une assistante de direction en train de rédiger une propal vient poser des questions au chef de projet, dans notre open-space.
Elle : “Le client veut savoir si on utilise UML dans nos projets”
Lui : “Oui, bien sûr”
Moi : (sous cape parce qu’il est susceptible) “Mouahahahahaha. C’est faux”.
Elle : “Mais c’est quoi UML ?”
Lui : “C’est un langage de programmation”
Moi : “Oh. Pu. Taiiiiiiiin”
Elle (elle avait un petit bagage technique) : “Et par rapport à Merise, c’est quoi UML ?”
Lui : “UML, c’est une des composantes de Merise”
C’est ce jour là que j’ai réalisé que ce mec était vraiment nul (et nuisible, mais c’est une autre histoire) et qu’il devenait urgent que je change d’employeur.
2 « J'aime »
Allez, je me lance.
Dans mon premier stage j’étais dev JavaEE, bref le classico.
À midi tout le monde était parti mangé, j’ai voulu faire preuve d’initiative (ça part mal). Du coup sur les environnements d’intégrations (qui était en faite utilisés par environ 150 personnes pour tester des règles bancaires), je me suis dit que je pouvais clean la base de données, et là arrive le drame, j’ai fait un where un peut trop généreux dans mon PL/SQL. Le truc c’est que je ne m’en suis pas rendu compte et je suis parti manger.
Donc 15 minutes plus tard je reçois un appel pendant la pause dej pour demander ce que j’ai fait, car tout le plateau de test est bloqué. Au final, heureusement les backups étaient bien faits et les datas ont été restaurées en moins d’une heure. Mais bref, quand tu commences en entreprise tu flippes quand ça t’arrive.
5 « J'aime »
Ce fil va être dérivé en émission Live !
Avec @Uggla on vous prépare un truc démentiel !
Vous pourrez nous raconter en live vos plus grosses foirades !
Des REX ou tous se passent mal ! 
Mais ça va aider la communauté.
RDV tous les 2 mois le premier vendredi à 17h !
Ça commence le 04/02
3 « J'aime »
Hello,
pour celles et ceux qui sont friands de certifications, j’ai partagé mon expérience sur les certifs kubernetes, avec un peu de fail dedans: How to fail your CK{A,S} Kubernetes Certifications | by Rémi Verchère | LINKBYNET | Jan, 2022 | Medium
Auréli Vache avait aussi partagé son fail sur GCP : How I fail the GCP Professional Cloud Architect certification exam - DEV Community
1 « J'aime »
Aller un m’est venu en tête, le jour où j’ai fait exposé des données clients qui on mi a mal une grosse avant-vente.
J’étais spécialiste de la télémétrie d’Office, ce qui permet à l’organisation de préparer les migrations. Pour faire les démo au client on a une base de données avec des données de tests.
J’avais donc bien préparer ma base en local, fait plusieurs tests, tous est était ok. Pour lancer le Dashboard j’utilise la recherche Windows (car sinon le Dashboard est super compliqué à trouver sur Windows)
D’habitude ça marche super bien. Sauf que ce jour-là. Ma recherche n’a pas renvoyé le bon fichier, et au lieu du Template j’ai ouvert un autre Dashboard qui contenais les données d’un autre client.
J’ai bien sur le coup que mon Dashboard ne répondait pas comme d’habitude, certain truc semblait casser, mais avec le stress d’une présentation qui était très importante et compliqué à préparer et présenter (Car on leur vendait un truc qui ne voulais pas) J’ai juste continué à dérouler.
On finit la présentation et là un des clients me demande pourquoi j’utilise des données d’un autre client (car certain des plugins remonté par mon Dashboard avait des acronymes qui pouvais faire référence a une autre entreprise) Moi je ne me démonte pas et je dis que non, ce sont des données de test, j’ai monté la bdd moi-même, elle est la et elle tourne.
Fin de la présentation, on debrief mon architecte qui était aussi dans le meeting avec moi.
Il me dit en gros, que j’ai fait une connerie, j’ai montré des données d’un autre client lors de la présentation, qu’il doit immédiatement reporter cette divulgation de données plus haut, qu’on a surement perdu le deal à cause de ça.
En sortant j’appelle mon mentor de l’époque, lui explique la situation, il me rassure disant que bon ce n’est pas très grave a soit, ça fait chier c’est sûr mais ça arrive, et que de toute façon le deal était déjà très compliqué. Je rendre au bureau et vais directement voir mon manager pour lui parler de ça. Il était déjà au courant de tout (l’architecte lui a dit). Au final ils m’ont sortie du projet, je n’ai jamais vu le client (qui de toute façon étaient des con) Je n’ai jamais rebosser avec cette architecte qui malgré ça présence lors du meeting m’a laissé dérouler sans m’arrêter alors qu’il aurai pu avec une habille pirouette dont il a le secret dire " Oh oui, attend tu t’es tromper, c’est pas grave attend, on va ressortir le bon Dashboard"
Le processus d’exposition de donnée a finalement conclu que les données ne présentaient aucun risque et qu’i n’avait pas lieu d’aller plus loin.
Voilà j’ai été très en colère suite à ça, surtout à cause des équipe sales et architecte en fait qui on trouver dans mon erreur la raison parfaite pour dire pourquoi leur deal de merde était compliqué
2 « J'aime »
Ca compte les fails quand on n’était pas encore un professionnel de l’informatique, même pas encore étudiant d’ailleurs, et qu’on se prenait pour Matthew Broderick dans WarGames ?
1 « J'aime »
si c’est un fail … ça compte
1 « J'aime »
Quand la chaîne Linus Tech Tips perds toutes les archives vidéo, ~ 750 TB de données
Un joli post-mortem détaillé qui empile l’une après l’autre les erreurs qui ont menées a l’incident…
2 « J'aime »
Il y a aussi plein de témoignages sur ce thread Twitter :
2 « J'aime »
Là où je bossais j’étais dans l’équipe qui s’occupait d’envoyer du reporting client (les clients étant des banques). On envoyait dans les 30 000 rapports par jour, avec un bon 10 000 de nuit.
Un jour je devais faire des tests d’envois de flag en qual pour vérifier la bonne génération des rapports. Vers midi, j’avais faim, j’étais un peu trop rapide sur mon copy/paste d’url, et j’ai relancé la génration de tous les rapports… en prod 
sans compter la charge en plus il y a aussi tous les envois FTP avec chargement automatique chez certains clients qui posaient pb 
2 « J'aime »
Petit quiz avec le petit fail de hier, qui m’a quand même coûté 1h / 1h30 pour trouver l’erreur… 
Ce n’est pas le code original, j’ai reproduit l’idée du code pour simplifier, raccourcir et mettre en évidence l’erreur.
L’idée est simplement de mapper certains champs d’un dict vers un objet.
L’erreur est classique en python.
from datetime import datetime, timezone
import unittest
class Share():
instance_uuid = None
share_id = None
status = None
tag = None
export_location = None
share_proto = None
def map_to_share_object(share, fields, db_share):
for field in fields:
setattr(share, field, db_share[field])
def main():
NOW = datetime.now(timezone.utc)
share = Share()
fake_db_share = {
'created_at': NOW,
'updated_at': None,
'deleted_at': None,
'deleted': False,
"id": 1,
"instance_uuid": "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa",
"share_id": "e8debdc0-447a-4376-a10a-4cd9122d7986",
"status": "attaching",
"tag": "e8debdc0-447a-4376-a10a-4cd9122d7986",
"export_location": "10.0.0.50:/mnt/foo",
"share_proto": "NFS",
},
fake_instance = {
"instance_uuid": "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa",
"instance_flavor": "tiny"
}
map_to_share_object(share,
[
"instance_uuid",
"share_id",
"status",
"tag",
"export_location",
"share_proto"
],
fake_db_share)
test = unittest.TestCase()
test.assertEqual(share.instance_uuid,
'aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa')
test.assertEqual(share.share_id,
'e8debdc0-447a-4376-a10a-4cd9122d7986')
test.assertEqual(share.status,
'attaching')
test.assertEqual(share.tag,
'e8debdc0-447a-4376-a10a-4cd9122d7986')
test.assertEqual(share.export_location,
'10.0.0.50:/mnt/foo')
test.assertEqual(share.share_proto,
'NFS')
if __name__ == '__main__':
main()
Stacktrace
Traceback (most recent call last):
File "/home/rribaud/workspace/bug/bug.py", line 67, in <module>
main()
File "/home/rribaud/workspace/bug/bug.py", line 40, in main
map_to_share_object(share,
File "/home/rribaud/workspace/bug/bug.py", line 15, in map_to_share_object
setattr(share, field, db_share[field])
TypeError: tuple indices must be integers or slices, not str
Vous l’avez ce p… de 
?
Yes, grand classique… on a parfois le même comportement dans les playbooks Ansible, ou l’erreur n’est pas forcément là où on croit ! 
1 « J'aime »
On est d’accord que c’est quand même un p… de piège qui rend fou ! 
Je suis content de ne pas avoir mis 1h a trouver 
TypeError: tuple indice m’avait mis la puce a l’oreille quand à la nature coupable à chercher: j’ai déjà entendu parler de ce cas 
Tu ne te fera plus avoir maintenant 
Cool si tu as trouvé rapidement. Le pire, je connaissais le comportement. Mais j’avoue que c’est le genre de truc que j’ai énormément de mal à détecter. Dans le même style les valeurs avec un _ au lieu d’un -, genre instance_uuid vs instance-uuid, ou une permutation de caractère intsance_uuid. Je peux lire le truc 100 fois et pas le voir. Quand je finis par comprendre, j’ai envie de me mettre des claques. 
Et aussi ici, si j’avais mieux lu le message d’erreur, j’aurais probablement trouvé plus vite… Ce qui me donne envie de faire x 10 sur le nombre de claques. 
Un lanage compilé et fortement typé, ça évite pas mal d’emmerdes quand même 
Hello,
allez, un petit pour la route, tout frais d’hier soir.
Je dois upgrader Harbor en dernière version, via chart Helm.
Après un helm diff upgrade, je remarque qu’il y a beaucoup de changements… modification des values pour corriger cela (cf harbor-helm/Upgrade.md at master · goharbor/harbor-helm · GitHub)
Maintenant tout semble OK, j’ai bien mes backups au cas où, l’upgrade s’est bien passée en environnement de pré-prod.
Vient le moment de l’upgrade:
- Tout se passe “presque” bien…
- Les pods redémarrent, la BDD migre, postgres démarre OK
- Bizarrement les applis n’arrivent pas à contacter la BDD, les bases “registry” and co sont inexistantes !!
A priori, le volume persistant qui héberge la BDD est trop juste, mais pas suffisamment pour remonter un alerte avant l’upgrade. Donc harbor/pg a tenter l’upgrade de la BDD, s’est foiré, a perdu les data. Youpi \m/
Obligé alors de sortir la restauration velero (sur un autre cluster “juste” pour avoir le dump de la bdd).
Manque de bol, coupure réseau lors de la restauration, je suis un peu fatigué, je refais, entrées en double dans la BDD, au redémarrage les applis se foirent de partout !
Biensur, un kubectl copy ne fonctionne pas pour faire le dump en local car les conteneurs postgres n’ont pas tar. Obligé de monter le volume via un autre pod pour la copy/restauration.
Les alertes commencent à tomber, sur les cronjobs qui pull régulièrement les images docker, oh joie…
On se calme, il est tard, je fais qq manips, au bout du compte la restauration est OK, les pods redémarrent, je vais pouvoir me coucher, et les utilisateurs le lendemain n’auront vu que du feu !
Bilan de l’intervention:
- toujours faire un backup de la BDD, mais ça tout le monde le sait (sauf ceux qui ont un peu trop confiance en eux)
- vérifier l’état des volumes persistants, qu’ils soient pas “juste” en taille pour éventuellement permettre un dump.
Allez, on se décourage pas, ce soir j’enchaine avec GitLab 
Edit: upgrade GitLab est passée sans encombres !
2 « J'aime »
que la force soit avec toi !