6 histoires de pannes terrifiantes

 (thenewstack.io)
7 points par before30 2020-12-28 | 6 commentaires | Partager sur WhatsApp

1. Charity Majors, CTO de Honeycomb

  • Les utilisateurs d’une région donnée (Europe de l’Est) ne recevaient pas les notifications push

  • Le problème est apparu juste après un changement de taille de l’ASG

  • Causé par un enregistrement DNS Round Robin qui dépassait la taille d’un paquet UDP

2. Matthew Fornaciari, CTO de Gremlin

  • Une panne s’est produite car le disque était plein et il était impossible d’écrire les logs

  • Développement d’une fonctionnalité de rotation des logs

  • Mise en place d’une alerte sur l’utilisation du disque

  • Ajout d’un test possible via Gremlin (chaos engineering)

3. Lirran Haimovitch, CTO de Rookout

"La légende urbaine d’un serveur qui tombe tous les jours à une heure précise,

après plusieurs semaines d’enquête, la cause a été trouvée dans la caméra de sécurité,

l’agent d’entretien débranchait le serveur pour brancher son aspirateur"

4. Daniel "Spoons" Spoonhower, CTO de Lightstep

  • L’application ne se chargeait pas

  • Il n’y avait eu ni déploiement ce jour-là, ni changement d’infrastructure

  • Il a été confirmé que seuls les utilisateurs internes étaient touchés

  • En vérifiant l’API de chargement de l’application, il a été constaté qu’un bloc de données supplémentaire était renvoyé pour les utilisateurs internes

  • Au fil des dernières semaines, la payload avait lentement grossi, jusqu’à dépasser cet après-midi-là la taille maximale autorisée, provoquant l’échec du chargement de l’application

5. Lee liu, CTO de LogDNA

6. Ting Huang, CTO de Transpoit

  • Impossible à lire sur Twitter mobile

  • Découverte d’un problème dans une nouvelle bibliothèque qui n’arrivait pas à parser le cookie de session

À lire aussi

6 commentaires

 
kunggom 2020-12-29

Dans le 5e cas, dont le contenu n’est pas résumé, il s’agit d’une expiration de certificat.

Ils pensaient qu’il n’y aurait pas de problème même si le certificat expirait comme prévu, mais cela ne valait que pour les systèmes nouvellement développés ; des problèmes sont quand même survenus sur les systèmes legacy encore en usage. Et, manque de chance, le même problème s’est aussi produit sur la solution CI/CD qu’ils utilisaient, ce qui a encore compliqué la situation.
 
kbumsik 2020-12-29

« Le personnel d’entretien a débranché le serveur pour brancher un aspirateur »

Ouh là...
 
kunggom 2020-12-29

En lisant le texte original, on comprend que ce passage servait d’introduction, et que la vraie panne venait du fait qu’une requête utilisée de temps en temps par l’administrateur côté client, notamment pendant des réunions, verrouillait toute la table, ce qui faisait exploser sans limite la latence du service backend à chaque fois. Ils ont optimisé la requête suspecte, mais c’était une fausse piste, si bien que le même phénomène se reproduisait chaque fois que le client rafraîchissait la page à répétition parce qu’elle était trop lente.
 
kunggom 2020-12-29

Une expérience personnelle assez similaire. C’était quand j’ai pris en urgence, en tant que freelance, un projet lié à une boutique en ligne.

Dans la nuit, une grosse opération a été menée sur la boutique en ligne — une mise à niveau majeure de la solution — puis, après avoir vérifié qu’il n’y avait pas de problème sur les fonctions essentielles comme le paiement des produits, le site a rouvert. Mais dans l’après-midi, le site de la boutique s’est soudainement mis à énormément ralentir, au point de presque se figer. Il s’est avéré que la cause venait d’une page distincte destinée aux vendeurs. La boutique fonctionnait avec une page d’administration pour vendeurs développée sur mesure et connectée à la solution e-commerce, et dès qu’on y entrait, une requête très lourde s’exécutait. Après la réouverture de la boutique, chaque fois que des vendeurs individuels s’y connectaient pour consulter l’état de leurs ventes, la charge sur MySQL augmentait, ce qui finissait par ralentir la boutique elle-même. En regardant, on a constaté que, pour une raison ou une autre, les index n’étaient pas correctement appliqués sur les tables concernées. Au final, le problème de ralentissement de la boutique a pu être résolu en corrigeant les index et en ajustant quelques paramètres.
 
kbumsik 2020-12-31

Oh, merci pour ce partage d’expérience.

C’est vrai que, pour les données destinées à l’admin ou à la prise de décision métier, comme on utilise des agrégations, la charge doit être assez importante. Je ne suis pas développeur web donc je ne m’y connais pas très bien, mais il paraît qu’aujourd’hui, dans ce genre de cas, on fait de la data engineering en rassemblant les données séparément.
 
kunggom 2021-01-02

Comme vous l’avez dit, la bonne pratique aurait été de séparer ces données pour les traiter à part, mais la boutique en ligne sur laquelle je travaillais était un système legacy avec pas mal d’éléments aberrants, donc ce type de considération architecturale n’avait absolument pas été pris en compte. Une version très ancienne de MySQL — datant de l’époque où le moteur par défaut était MyISAM et non InnoDB — tournait sur la même instance de VM qu’un serveur web Apache, lui aussi très ancien. La solution utilisée pour faire fonctionner la boutique en ligne était également déjà classée comme legacy et ne recevait plus que des correctifs. Les problèmes structurels de la solution que j’avais constatés pendant le travail semblaient avoir été résolus dans une nouvelle version redéveloppée depuis zéro, mais cela n’avait absolument aucun impact pour moi, qui devais intervenir sur la version legacy. C’était déjà l’an dernier.