Incident du 30/10/2018
Date du post mortem : 31/10/2018
Participants du post mortem :
La couche de cache est devenue indisponible suite à une opération de maintenance visant à augmenter les capacités de notre moteur d’optimisation.
L’opération de maintenance visait à rajouter 15% de capacité supplémentaire au moteur d’optimisation. L’ajout de ces nouveaux noeuds a nécessité une mise à jour de plusieurs couches dialoguant avec ces noeuds. Ainsi, les couches de caches, des serveurs frontaux et de stockage ont été mises à jour pour accepter du trafic provenant des nouveaux noeuds.
Lors de la mise à jour de la couche de cache à partir de 15h36, une montée de version a eu lieu par erreur. En effet, cette version initialement prévue pour être déployée le mercredi 24 octobre 2018 avait été repoussée. Mais, le rollback n’avait été que partiellement effectué.
La nouvelle version a modifié le port d’écoute de certain processus de la couche cache et a entraîné un vidage non prévu des caches. Par ailleurs, ces processus sont devenus inaccessibles à cause d’un nombre trop élevée de connexions et le blocage de cette couche n’étant pas pris en compte par des mécanismes de fallback, les connexions se sont empilées et ont ralenti l’ensemble du trafic.
15h14 : lancement du déploiement sur la couche de cache
15h31 : premières erreurs 504 reportées par KeyCDN
15h58 : l’équipe CSE remonte via des tickets au support des problèmes de disponibilité de la plateforme, confirmés par notre outil de logs indiquant un nombre élevé d’erreurs 504 vues depuis notre couche de CDN.
A partir de 16h, de nombreux tickets clients informent de forts ralentissements ou d’indisponibilité sur leurs sites.
16h24 : L’ensemble de l’équipe technique est mobilisée sur le problème
16h32 : La nature du problème concernant les processus de la couche de cache est identifiée.
16h37 : L’incident est rendu public sur status.fasterize.com.
16h43 : Suite aux nombreuses alertes client, l’équipe technique suspend l’ajout des noeuds supplémentaires. Ele prend la décision de remettre à jour la couche de cache et de front avec la dernière version déployée en production.
16h50 : La version déployée n’est pas la bonne. Devant l’ampleur de l’incident impactant l’ensemble du trafic, l’équipe prend la décision de router l’ensemble du trafic vers les origines.
16h51 : Le trafic est rerouté vers les origines
17h03 : Modification de la version à déployer et nouvelle tentative.
17h20 : Problème d'accès au code à déployer suite à un changement du serveur hébergeant ce code depuis la dernière mise en production.
17h30 : Mise à jour des configurations pour accéder aux serveurs de code et relance du déploiement.
17h45 : Déploiement effectué avec succès, check de la plateforme.
18h14 : Réactivation de la plateforme sans nouveaux workers.
La mise à jour involontaire de la configuration des caches sans la mise à jour du moteur d’optimisation associée a autorisé celui-ci à accéder directement à ce service de cache sans pool de connexions. Les process ont alors saturé en terme de nombre de connexions simultanées.
Cela a provoqué des timeout au niveau de la couche de cache (configuré à 60 secondes).
Normalement, un mécanisme de fallback transfère la requête envoyée aux service de cache vers la couche de proxy, toutefois le timeout en place est trop long et les requêtes clientes ont été avortées avant la bascule.
Aucune bascule automatique n’a eu lieu car la requête utilisée par les sondes externes pour valider la disponibilité du système a une faiblesse : elle parcourt l’ensemble des couches via le même serveur de cache, du fait de notre mécanisme de consistent hashing. Or, ce serveur n’ayant pas été déployé, il n’a pas été impacté par le problème au niveau de la couche de cache.
La couche de cache ayant mis trop de temps à répondre, les requêtes ont été annulées par le CDN ou le navigateur. Ceci se traduit par l’augmentation des erreurs 499 au niveau de notre couche de front, ce qui correspond à une augmentation des erreurs 5xx au niveau de notre CDN.
Le mécanisme de fallback situé sur la couche de front se base sur la réponse de la couche de cache mais comme les requêtes n’ont pas été jusqu’au bout, la couche de cache n’a renvoyé aucune réponse et donc il n’a pas pu se déclencher.
* 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
* Time to detect : 28 minutes
* Time to resolve : 2h43
* Combien de client impactés nombre absolu ? tous
* Quelle proportion des clients impactés ? tous
* Quelle proportion des clients utilisant la feature problématiques impactés ? tous
Court terme
Moyen terme
Long terme