Whaller experienced a minor incident on November 8, 2024 affecting Main application and API, lasting 48m. The incident has been resolved; the full update timeline is below.
Affected components
Update timeline
- investigating Nov 08, 2024, 07:16 AM UTC
Nous subissons des lenteurs sur la production mutualisée. Le site est cependant accessible, nous vous tenons informés. --- We are experiencing slowdowns in shared production. The site is still accessible, however, and we will keep you informed.
- identified Nov 08, 2024, 07:52 AM UTC
Nous avons identifié le problème, nous sommes en train de le corriger et redémarrer les services concernés. --- We have identified the problem and are in the process of correcting it and restarting the services concerned.
- resolved Nov 08, 2024, 08:04 AM UTC
Les services défaillants ont été redémarrés, la production a retrouvé une performance nominale.
- postmortem Nov 26, 2024, 10:40 AM UTC
### Postmortem Incident de Production - Lenteurs du 8 novembre 2024 #### Résumé Le 8 novembre 2024, des lenteurs importantes ont été constatées sur nos services de production, avec un temps de réponse moyen multiplié par deux et une hausse significative des erreurs. L’incident a été résolu après une série d’actions sur l’infrastructure, notamment la réactivation de services critiques. Ce document présente les événements, les causes et les mesures prises pour éviter toute récurrence. #### Chronologie des événements * **~00h00** : Début des anomalies \(suite à un remplacement de hosts sur l'infrastructure par OVHcloud\). * **07h08** : Les équipes techniques sont alertées suite aux notifications OVHcloud. * **08h11** : Confirmation de la dégradation de performance. Les équipes techniques identifient un taux d’erreur accru et un ralentissement général. * **08h16** : Une communication est publiée sur Statuspage pour informer les utilisateurs. * **08h26** : Redémarrage des processus ProxySQL sur les frontaux SaaS. * **08h45** : Inaccessibilité de certains services. * **08h57-09h01** : Réactivation des interfaces réseau et redémarrage des services. * **09h14** : Identification de VM avec des configurations réseau incorrectes \(non connectées au boot\). * **09h16** : Correction des configurations réseau sur les VM concernées. * **09h30** : Fin de l’incident #### Difficultés rencontrées 1. **Communication tardive des anomalies** : Les anomalies n’ont été identifiées qu’après plusieurs heures. 2. **Manque de redondance immédiate** : La dépendance à des configurations manuelles a retardé la résolution. 3. **Outils non opérationnels** : Certaines VM critiques n’étaient pas accessibles. #### Cause de l’incident L’incident a été causé par une mise à jour de l’infrastructure chez notre hébergeur \(remplacement de hosts physiques [\[RBX8\]\[Hosted Private Cloud\] - Racks R806L22/23/24](https://hosted-private-cloud.status-ovhcloud.com/incidents/fl439stlh482) \), qui a désactivé les interfaces réseau sur plusieurs machines virtuelles critiques. Cela a provoqué des dysfonctionnements dans des services essentiels. #### Perte de données Aucune perte de données n’a été constatée. Toutefois, certains traitements ont pu être retardés, entraînant des temps de réponse prolongés pour les utilisateurs. #### Mesures de remédiation 1. **Audit des configurations réseau** : Vérification de l’activation automatique des interfaces réseau sur toutes les VM. 2. **Automatisation des vérifications post-maintenance** : Déploiement d’outils pour détecter les anomalies après des opérations d’infrastructure. 3. **Amélioration de la supervision** : Renforcement des alertes sur les indicateurs de performance \(taux d’erreur et temps de réponse\). 4. **Plans de redondance** : Révision des mécanismes de basculement automatique pour limiter l’impact des incidents similaires.