Bonjour, Depuis ce matin 9h50 nous avons des crashs récurrent du cluster de base de données,

Un problème hardware sous-jacent a été identifié et une intervention est en cours de planification avec l'hébergeur,

Nous essayons de planifier l'intervention, qui peut entrainer un downtime conséquent, dans la nuit, mais nous pouvons la déclencher plus tôt dans la journée si jamais le cluster est trop instable pour limiter la dégradation des services,

Nos équipes sont mobilisés, nos excuses pour le dérangement occasionnés,

Nous lançons le remplacement du hardware concerné dès maintenant malheureusement la situation s'est dégradé plus rapidement que prévu,

L'intervention matérielle est terminée, le serveur est de nouveau disponible, les services sont en train revenir, nous procédons aux vérifications et communiqueront bien sûr de manière plus détaillée dans les prochaines heures,

Encore toutes nos excuses pour ce long dérangement,

Vous trouverez ci-dessous le déroulé complet de l'incident.

Ce downtime n'est pas à la hauteur du service que nous souhaitons proposer, nous allons revoir en profondeur les différentes étapes et mettre au point un plan d'action pour améliorer la résilience du service concerné ici.

Toutes nos excuses pour le dérangement, nous restons à disposition si vous avez besoin de plus d'informations.

1. Résumé Exécutif

Le 19 janvier, le serveur node-data01 (un membre de notre cluster de données) a subi une série de défaillances matérielles critiques. Ce qui a débuté comme une alerte mémoire (RAM) s'est avéré être une panne systémique incluant la carte mère et l'alimentation électrique.

Le service a été maintenu en mode dégradé jusqu'à 14h30, heure à laquelle le serveur s'est arrêté définitivement. Face à un retard de réplication important sur le serveur de secours (Slave) pour le service MariaDB, nous avons pris la décision stratégique de ne pas forcer le basculement pour préserver l'intégrité des données, tablant initialement sur une intervention rapide du datacenter. La complexité de la panne matérielle a prolongé l'interruption jusqu'à 19h50.

Aucune donnée n'a été perdue, il ne s'agissait pas d'un incident de cyber-sécurité mais de disponibilité sur la plupart de nos services ayant un dépendance le service MariaDB qui n'a pas été dans les conditions requises pour effectuer une bascule sur le serveur de Slave (contrairement à tous les autres services qui ont pu l'être).

2. Chronologie Détaillée

09h50 - Premier incident : Redémarrage spontané du serveur. Vérifications d'usage immédiates.

10h50 - Diagnostic RAM & Délestage : Second redémarrage. Les logs (EDAC) confirment des erreurs matérielles sur la RAM.

Action : Déclenchement du plan de délestage. Arrêt des services non-critiques pour réduire la charge mémoire.

11h27 - Perte de capacité : Troisième redémarrage. L'OS ne "voit" plus une partie de la RAM. Nous continuons le délestage, espérant que l'isolation automatique des barrettes défectueuses stabilisera le système.

12h00 - Planification : Intervention de remplacement de RAM programmée avec OVH pour la nuit (02h00), afin de minimiser l'impact.

13h00 : Poursuite du délestage pour maintenir le service actif jusqu'à la nuit.

14h30 - Arrêt critique et Prise de Décision : Le serveur s'arrête et ne redémarre plus.

Analyse : Le serveur esclave MariaDB présente un retard de réplication (lag) trop important pour garantir la cohérence des données en cas de bascule.

Contexte : L'estimation standard pour un remplacement de RAM par l'hébergeur est de 1 à 2 heures.

Décision : Refus du basculement (Failover). Nous jugeons préférable de subir 2h d'arrêt de service plutôt que de risquer une corruption de données irréversible liée au lag. L'intervention d'urgence est déclenchée.

15h45 : Début de l'intervention physique par le technicien.

17h00 - Complication (Carte Mère) : Le remplacement de la RAM ne suffit pas. Diagnostic étendu : la carte mère est HS. Changement planifié immédiatement.

18h30 - Complication (Alimentation) : Après changement de la carte mère, le serveur reste instable. L'alimentation électrique (PSU) est identifiée comme la cause racine probable. Remplacement effectué.

19h30 : Tests de validation matériel (Burn-in) en cours sur l'ensemble des composants neufs.

19h50 - Rétablissement du service : Le matériel est validé stable. Redémarrage de l'OS, vérification de l'intégrité des bases de données (aucune corruption détectée) et relance de tous les services, y compris le Primary du service MariaDB.

Nous avons maintenant résolu l'incident. Merci pour votre patience.