Incident du 07/11/2019

Date du post mortem : 07/11/2019

Participants du post mortem :

• David Rousselie
• Mikael Robert
• Nicolas Alabrune
• Grégoire Lejeune
• Anthony Barré
• Jerome Lachaud
• Stephane rios

Description de l'incident

Le 07/11/2019, à partir de 05:40, des alertes sont reçues par l’astreinte avec pour objet un fort taux d’erreur sur les optimisations.

Ces erreurs sont rapidement identifiées comme étant liées à la maintenance réseau effectuée plus tôt dans la nuit.

L’objectif de ce déploiement était de basculer sur le réseau privé d’un de nos hébergeurs au lieu de notre VPN. Nous espérions une amélioration notable de la stabilité et des performances du réseau, il s’est avéré que ce réseau et notamment la communication entre les différentes version de ce réseau sont trop instables et trop peu performant quand le trafic est important, et l’effet obtenu fut inverse.

Timeline

22:00 : départ du déplacement / de la maintenance de réseau

03:15 : Fin du déplacement / de la maintenance réseau. Supervision et tests automatisés tous ok. La bascule a été longue à cause de la procédure mise en œuvre pour ne pas couper le service / la plateforme.

05h40 : Alerte “High optimization error rate detected”

05h50 : L'équipe identifie les problèmes de latence sur le réseau privé de notre hébergeur et décide d’effectuer un rollback vers l’ancien réseau privé virtuel avec un focus sur l’ensemble des composants du moteur (workers/broker/proxys)

07h30 : Les machines impactées par ce problème sont revenues sur notre ancien VPN. Plusieurs membres de l’équipe restent en supervision de la plateforme.

11h50 : Un premier ticket est reçu au support relatant des temps de latence plus élevée sur la page d’accueil d'un de nos clients. Suivent d’autres messages sur le support de trois autres clients. Nous avions déjà identifié un certain nombre de soucis réseaux restant et commencer à re-basculer les machines sur l’ancien réseau progressivement. La hausse progressive du trafic dans la matinée a amplifié les problèmes réseaux déjà détectés.

12h00 : L'équipe complète se mobilise afin d’effectuer un rollback complet et rapide de la configuration précédent la mise en production de la veille au soir.

Certains sites clients sont débranchés afin de limiter l’impact de l'opération en cours.

14h20 : L’infrastructure et la configuration réseau est à nouveau dans l'état précédent la mise en production survenue la veille.

Analyse des causes de l’incident

Suite à la maintenance programmée portant sur la migration de notre réseau privé virtuel vers le réseau privé d’un de nos hébergeurs, des instabilités réseaux et des latences sont apparues dans la communication entre les machines de l’infrastructure.

Ces instabilités se sont manifestées par une augmentation des timeouts d’optimisation vus par les proxys.

L’impact est également visible en comparant le speed index médian par rapport à la semaine précédente.

Après analyse il s’avère que le réseau privé d’un de nos hébergeur est bien plus lent que notre ancien réseau virtuel privé, et qu’il y a des erreurs de connexion et routage assez régulièrement entre plusieurs machines.

Les temps d’optimisation de ressource ont énormément augmenté et ne sont revenus à des seuils normaux qu’une fois l’infrastructure re-basculée sur l’ancien réseau.

Processus de rollback

Lors du passage sur le nouveau réseau privé, les adresses IP du réseau virtuel sécurisé avaient été supprimées de nos firewalls. Et lors du rollback, les services se sont remis à échanger sur le réseau virtuel sécurisé mais bloqués par les firewalls.

Le process de rollback a été long car nous n’avions pas prévu la cohabitation des deux réseaux en parallèle. Il a fallu mettre à jour l’ensemble de la plateforme.

Métriques

* Niveaux de sévérité de l'incident :

Sévérité 2 : dégradation du site, problème de performance et/ou feature cassée avec difficulté de contourner impactant un nombre significatif d'utilisateur.

* Time to detect : 10 minutes

* Time to resolve :

• mitigation : 1 heure 40 minutes
• patch: 2 heures 20 minutes

Impacts

• Des erreurs 502 se sont produits sur les frontaux, et vu par les clients (la majorité est due aux moments où les machines ont basculé d’un réseau à l’autre pendant le rollback).
• La fonctionnalité de flush ne fonctionnait plus
• Les métriques utilisateurs (boomerang) se sont dégradées.

Plan d'actions

Court terme

• Nous avons remis le réseau dans le même état qu’avant la mise en production prévue et en premier lieu sur les workers qui étaient les plus impactés.
• Nous avons re-basculé le reste de l’infrastructure progressivement ensuite.

Moyen terme

• Abandon du projet d’utiliser le réseau privé de notre hébergeur (migration en cours vers le nouvel hébergeur)
• Préparation d’un plan de rollback testé sur les environnements de staging pour éviter le flottement pendant rollback et surtout mise en place d’un déploiement progressif pour les opérations impactantes.
• Retirer les adresses IP privées dans nos configurations pour les remplacer par des variables pour éviter une mise à jour forcée de l’ensemble des configurations.

Long terme

• Utiliser un DNS uniquement et plus d’adresses IP dans les configuration de services.
• Trouver un moyen de pouvoir reproduire un trafic réel sur la plateforme, sans impacts sur les sites réels afin de valider ce type de migration potentiellement impactantes.
• Mettre en place une métrique permettant de détecter les pertes et latence du réseau privé.
• Mettre en place du blue-green déploiement et passage progressif du trafic d’un réseau à l’autre.
• Meilleure formation de l’ensemble de l’équipe au premier secours sur la plateforme. Dans le cas des MEP, prévoir si possible une meilleure couverture des compétences.