Thread by @jbuget

#JDB Aujourd’hui, c’était Point Tech. Il s’agit d’une après-midi toutes les 2 semaines,au cours de laquelle tous les développeurs qui le souhaitent peuvent travailler sur des tâches hors sprint, pr améliorer nos outils,creuser des sujets,se former,tester ou nettoyer des trucs,…

📝Par exemple, nous avons publié un nouvel article sur notre blog technique, qui explique les différents types d'environnements que nous gérons ~ engineering.pix.fr/infrastructure…

🕵️‍♂️Autre sujet. Nous avons constitué un petit groupe cross-team de 4-6 personnes pour explorer une micro-instabilité rencontrée hier soir qui a provoquée le crash de 4 conteneurs (sur les 8 en trafic minimal), l'un après l'autre, à 10mn d'intervalle.

Préambule : grâce au scaling horizontal et à l'auto-restart des conteneurs applicatifs (entre autres) – 🙏merci @ScalingoHQ – la plateforme a continué de tourner comme si de rien n'était et aucune donnée utilisateur n'a été maltraitée ou perdue durant l'incident.

👩‍✈️/👨‍✈️ Nous avons pu nous en rendre compte très rapidement grâce à notre alerting entre Scalingo (notre hébergeur de type PaaS) et Slack. Au passage, merci les Captains du passé pour avoir mis tout ça en place ~ engineering.pix.fr/organisation/2….

Les conteneurs ont planté à cause d'un problème mémoire. Nous avons commencé par regarder les métriques & courbes techniques. Nous nous appuyons sur un de nos mécanismes qui balance, toutes les 15mn et pour chaque conteneur, des mesures (heap, rss, CPU, RAM) à Datadog.

Puis nous avons exploré les logs. C'est un art qui demande une minutie, une logique et une sérénité à toute épreuve.

Nous avons constaté, pour les 4 crash de conteneurs, 1 même requête, à chaque fois avec un temps d'exécution long.

Nous avons alors plongé dans le code. C'était pratique et efficace d'avoir des personnes des différentes équipes, pour bien appréhender les choix d'implem, modélisation métier et autres éléments contextuels. Nous avons fini par identifier un bout de code bien suspect.

Notre attention s'est portée sur une fonctionnalité ajoutée récemment pour laquelle on en vient à faire un gros `Promise.all` sur une collec. d'objets pouvant être gros, auxquels on applique un traitement avec une dose non négligeable d'intelligence ou de sous-traitements lourds.

Dans une archi de style classique "plutôt synchrone", il vaut mieux éviter de faire des `Promise.all` sur des collections d'objets de même nature, surtout quand ceux-ci sont gros ou subissent des traitements lourds. À la rigueur, on peut utiliser `Bluebirds.Promise.mapSeries`.

Contre-exemple : il peut être pertinent tout de même d'utiliser `Promise.all` pour effectuer des traitements bien distincts.

Ex: (a) qui appelle une API ; (b) qui fetch des données de la DB ; et (c) qui fetch d'autres données de la DB qui n'ont rien à voir.

La suite : l'équipe produit concernée par le bout de code va s'occuper du sujet dans les jours qui viennent. Ce n'était pas prévu, mais la prod avant tout 🤷‍♂️