Chez Fasterize, la transparence est une valeur essentielle et donc, comme d’habitude en cas d’incident sur notre plateforme, nous partageons avec nos clients, partenaires et futurs clients notre post mortem suite à l’indisponibilité de notre plateforme jeudi dernier.
Nous pensons que c’est un gage de confiance que de mettre à disposition de chacun ce que nous avons vécu, comment nous l’avons traité et présenter nos axes d’amélioration.

Description de l’incident

Les sites des clients branchés sur Fasterize ont été partiellement ralentis suite à un déploiement de la plateforme Fasterize jeudi 17 septembre vers 15h.
Tout les utilisateurs des sites clients ont été impactés.
Nos machines échangent entre elles des messages 0mq afin de distribuer les tâches d’optimisation aux workers et ce via des brokers.
A mesure que le déploiement de notre moteur a avancé, les machines ont été de moins en moins accessibles car le nombre de connexions entre les brokers et les workers a explosé (x100) et a entrainé un dépassement du nombre de connexions trackées par iptables. Les connexions supplémentaires ont été purement et simplement droppées.
Aujourd’hui, deux pistes sont étudiées pour identifier l’origine de cette explosion de connexions.

Faits et timeline

Les premiers ralentissements sont apparus un peu avant 14h, nous avions reçu une alerte pour notre site indisponible à 13h53, via Pingdom et nous avons pensé que le problème était ponctuel et limité à notre site.
Ensuite, le problème a commencé à apparaître vers 14h45, vers la fin du déploiement. Les premiers serveurs avaient été déployés et testés (nous faisons du Canary Release sur un certain nombre de serveurs et validons nos tests sur cet ensemble restreint de machines avant de déployer le reste).
Les optimisations ont été débranchées plusieurs fois automatiquement entre 14h45 et 15h50, via les sondes Cedexis et Route 53. Pendant cette période, les sites de nos clients étaient soit non-optimisés, soit ralentis en passant par Fasterize.
Une bonne partie de nos métriques étaient en forte augmentation (nombre de requêtes DNS internes notamment).
A 15h50, nous avons décidé de débrancher complètement pour étudier le problème plus sereinement.
Après investigation et rechargement des processus de notre moteur d’optimisation, nous avons vérifié que tout était ok et avons rebranché progressivement le trafic à partir de 18h40 ; le service était de nouveau fonctionnel et les sites sont de nouveau optimisés.

Quelques métriques

  • Niveaux de sévérité de l’incident : Sévérité 1, arrêt du site non planifié qui affecte un nombre significatif d’utilisateurs
  • Temps de détection : 15min
  • Temps de résolution : 4h50min

Impacts

Tous les clients ont été impactés mais à des degrés divers, la majeure partie ayant bénéficié du reroutage automatique à l’origine.
Tous les clients qui se sont adressés au support ont vu leur ticket traité dans les 15 minutes.
Au niveau de l’équipe, l’impact est conséquent sur le moral mais cet incident a permis d’identifier un problème déjà apparu une fois et qui n’avait pas été résolu.
La communication sur cet incident a été pauvre, seulement à travers les demandes des clients et non pas en utilisant nos outils habituels (status.fasterize.io).

Contre-mesures

  • plus de visibilité sur le déploiement (annonces automatiques du début et de la fin en plus des mails aux clients)
  • améliorer le processus de communication en cas d’alertes
  • ajout d’alertes via Route53
  • mettre en place le monitoring des connexions ouvertes et l’alerting associé ainsi que pour les connexions brokers/workers
  • revoir la façon dont sont faites les résolutions DNS du moteur
  • amélioration du Canary Release : isolement des machines encore plus poussé et mode live

Conclusion

Nous sommes sincèrement désolés pour l’indisponibilité relative à cet incident.
Cette panne nous a montré que notre système de déploiement pouvait encore être amélioré et que nous pouvions toucher des limites inattendues de nos machines en cas de problème réseau.
Cela nous prouve aussi qu’il ne faut pas relâcher nos efforts pour améliorer encore la résilience de la plateforme, notamment par l’optimisation continue de nos ressources. Nous y travaillons et vous remercions encore une fois pour votre confiance.
Pour rappel, et même si cette fois elle n’a pas été très utile, la page status.fasterize.com permet de relayer toutes les informations concernant l’état de santé de la plateforme. Sur cette page, vous avez par ailleurs la possibilité de recevoir des notifications quand nous y publions des événements.

Hello SMX Paris !