Bonjour un petit sujet pour partager un peu nos mésaventures quotidiennes…
Et se défouler quand les choses vont mal.
La vm du jour, tout va bien… (note la vm host le node d’un cluster flink qui bizarrement est hs.)
Note 1: En bon noir, ça arrive forcement juste le Vendredi avant les vacances.
Note 2: J’ai pas la main sur cette infra, mais je crois que qq chose va pas bien.
Je saute sur ce sujet car j’ai depuis un moment une evie de faire une libre antene sur les histoires de problèmes qui nous on amener à amélioré les choses.
Parce que les REX de succès c’est bien mais les REX de problème c’est mieu pour aprendre je trouve.
J’aimerais bien faire une émission mensuell de 1h en Live Youtube avec des invités, comme une libre antène.
Bonne idée. Effectivement, les échecs et les erreurs c’est clairement plus formateur et réaliste.
qui nous on amener à améliorer les choses.
Alors dans le cas ci dessus, je suis pas certain que l’on va améliorer les choses. L’amélioration continue n’est pas forcement la norme partout… Mais c’est un autre sujet.
@nka, j’étais déjà tombé sur ton article, mais merci de l’avoir partagé ici . C’est courageux de partager ce type d’expérience, bravo ! C’est un bon retour d’expérience qui montre que sous la “pression” d’un client et avec le stress, cela peut conduire à déroger à certains principes et faire une grosse boulette.
Dans un radio DevOps, je disais “attention avec le cloud ça peut être assez rapide de se prendre une bonne pastille sur la facture”. Voici une illustration. (note: je détaille pas comment nous avons corrigé le pb car c’est pas le sujet, mais dites-le moi si ça vous intéresse)
Petit avertissement, rien n’était caché par le fournisseur de cloud et la faute est entièrement de notre faute. Une mise en place un peu trop hâtive sans être super attentif aux prix et …
Voici l’histoire, pour un de mes clients, nous avons dû mettre en place un service ftp. S’il vous plaît ne me juger pas ! Il se trouve que dans certain domaine, la norme pourtant récente impose du ftp. (La sécurité se fait sur le payload qui peut être signé et chiffré mais ce n’est pas imposé par la norme… Oui ça sux mais c’est comme ça).
On monte donc un service sur Azure, le service ftp (pas mal customisé) est redondant sur 3 serveurs, un dans chaque AZ. En frontal un LB qui dispatche la charge sur les 3 nodes et assure la HA si un serveur ne répond plus.
Pour que le service ftp fonctionne il faut faire des règles sur le LB, le port 21 pour les commandes et un certains nombres de port haut (mode ftp passif). Pour les ports hauts, on ouvre une centaine de ports car, le service devrait recevoir pas mal de connexions. Rien de vraiment fou et on ouvre les règles tranquillos sur le LB avec donc ~100 ports par environnements (dev, int, qualif, pprod, prod)… Cool après un peu de réglage de la configuration ça marche bien. La solution n’est pas en production, mais on va pouvoir le faire quand on en aura besoin.
Environ 6 semaines plus tard (la solution n’est pas tjr pas en prod) le client reçoit une alerte de seuil sur sa facture. Heureusement il a pris le temps de configurer cette alerte sinon ça allait faire très très mal. Il y en a quand même pour ~5k€ pour une solution qui n’a jamais réellement était utilisée !
On cherche la raison et là on regarde les règles de facturation du LB. (Tarification - Load Balancer | Microsoft Azure).
Le petit truc que l’on avait pas forcement imaginé ou vu c’est le prix des règles, 0,009 € pas cher, sauf que c’est par règle/heure.
Oui par heure ! Donc avec 100 règles ça fait quasiment 1€ par heure ! 100 règles * 0,009 * 5 envs * 24h = 108 € par jour * 45j = 4860€ juste pour les règles du LB. Aie ça pique…
Alors oui, mais j’ai volontairement omis certains détails ici. Notamment le fait qu’il faut 3 nodes, car il y a du Hazelcast qui tourne avec ce service pour faire une “distributed shared hashmap”.
Une minute fail de début de carrière pour ma part.
J’étais dans un grand groupe où les équipes passaient un outil un peu dégueulasse en ksh pour “analyser la sécurité de la machine” (c’était n’importe quoi mais c’est un autre histoire). L’outil sortait un rapport en HTML.
C’était mon premier job après l’école et je devais donc résoudre les soucis détectés par l’outil.
Une alerte concernait un paquet en lien avec x11 (je me rappelle plus du nom exact mais il y avait x11 sur le nom), avec une alerte du type “houlala il y a un paquet x11 sur un environnement server, problème critique …”.
Je demande un peu de précisions aux équipes et on me confirme qu’il faut absolument désinstaller le paquet. OK, je fais un playbook ansible qui désinstalle le paquet. Je passe ça sur nos environnements, ça marche, super.
Sauf que ces playbooks étaient aussi joués sur les environnements d’autres équipes. L’équipe gérant hadoop l’a lancé sur plusieurs environnements (heureusement c’est jamais passé en prod, que des envs de test/qualif…) et par une chaine de dépendance la suppression du paquet a aussi supprimé toute la stack hadoop/hbase/hive…
Morale de l’histoire: ne jamais forcer la désinstallation d’un paquet
de clients qui ne savent pas ce qu’est le mode passif
Parfois il faut se méfier, les clients évolués (genre filezilla) font des trucs pour pallier à certains défauts de configuration coté serveur et donc peuvent masquer des problèmes. J’ai pour habitude de toujours tester avec le client ftp le plus basique possible pour vérifier que ça fonctionne bien.
Après les clients(personnes), peuvent avoir du mal, ftp est un protocole super efficace pour faire ce pourquoi il a été conçu. Du transfert de fichiers. Par contre c’est “un peu ” daté (FTP is 50 years old) les contraintes réseaux et sécurité n’était pas les même à l’époque et la mise en place de ces solutions est un peu inhabituelle. Ce qui peut expliquer les difficultés aujourd’hui…
Bon courage avec les tickets, résister au coté obscur qui te donne envie de répondre sauvagement avec un bon vieux RTFM tu dois !
Un classique:
Sur Linux hostname -f → Display the FQDN (Fully Qualified Domain Name).
Sur HPUX l’option n’existait (n’existe ?) pas… hostname -f → Pas de réponse ($? == 0).
Et la souvent tu (ou l’admin) percutes pas, un peu vite, tu passes à un autre truc…
Mais 30mn plus tard il y a le feu ! C’est quoi le nom de la machine ? hostname → -f avec les conséquences que cela peut avoir coté applicatif.
Aujourd’hui un quiz minute fail.
Problème qui m’est arrivé ce Lundi et qui est un grand classique sur Ansible.
Le “playbook” fait le déploiement de keepalived sur 3 nodes et configure celui ci de manière adéquate.
Enfin normalement, car suite au bug, les 3 nodes ont reçu la même configuration. (aie !)
En conséquence l’utilisation de la vip marchait très mal, performance vraiment mauvaise, probablement à cause des requêtes ARP que devaient envoyer chaque node à cause de la mauvaise configuration. Mettant le bronx sur le réseau et le switch. Note: a noter que la difficulté a été de comprendre le soucis et trouver la mauvaise configuration, le bug et la correction sur Ansible par contre j’ai trouvé très vite.
Voila la conf (sans détails et possible choses confidentielles):
Inventory