Le dimanche 2025-03-09, Gandi a enregistré un incident majeur sur sa plateforme causé par une panne du système de stockage du filer et affectant de nombreux services dont les boîtes mails.
| En bref : – De nombreux services ont été gravement perturbés du dimanche 9 mars de 0:31:10 à 16:49:15, impactant notamment 39% de toutes les boîtes mails. – Certaines boîtes mails (environ 15%) sont restées indisponibles jusqu’au lundi 10 mars 10:29. Toutefois, tous les utilisateurs ont récupéré tous leurs courriels le mercredi 12 mars à 17:00:00. – Il est important de noter que cet incident n’a pas entraîné la perte ou la corruption de données. |
Quelle est la cause initiale de l’incident ?
La première cause de cet incident est la défaillance d’un filer de stockage SSD. Cependant, plusieurs autres facteurs ont contribué à aggraver l’impact de cette défaillance :
- Certains systèmes, y compris le contrôle interne, ne disposaient pas de mesures de redondance efficaces pour faire face à l’interruption du stockage.
- Certains systèmes qui disposaient d’une redondance au niveau des machines virtuelles étaient mal conçus, de sorte que toutes les machines virtuelles dépendaient d’un seul et même filer impacté.
- Certains systèmes redondants au niveau des machines virtuelles et du stockage n’étaient pas dotés d’une capacité suffisante pour faire face à l’augmentation de la charge en cas de défaillance de l’une des instances.
Le déroulement des faits :
| Date et heure (UTC) | Événement |
|---|---|
| 2025-03-09 00:31:10 | Déclenchement de l’incident, les intervenants de garde enquêtent sur plus de 1500 alertes ; difficile de déterminer quelle est la cause initiale, et le bot de surveillance est indisponible |
| 2025-03-09 01:11:19 | Les équipes prennent la mesure de la gravité de l’incident, le CTO est averti |
| 2025-03-09 01:21:51 | Statut public publié sur status.gandi.net avec les premiers services impactés identifiés |
| 2025-03-09 01:23:31 | Tentative de déclaration d’incident via l’outil ChatOps |
| 2025-03-09 01:25:15 | Panne de VPN identifiée pour les employés non Ops |
| 2025-03-09 01:33:03 | Problème identifié : un filer a planté |
| 2025-03-09 01:34:46 | Redémarrage du filer tenté |
| 2025-03-09 01:47:09 | Échec du redémarrage du filer |
| 2025-03-09 02:16:21 | Un intervenant est dépêché au data center |
| 2025-03-09 03:31:11 | Premier rapport du data center – filer redémarré manuellement après déconnexion de l’alimentation |
| 2025-03-09 04:03:05 | Le redémarrage ne permet pas de résoudre le problème |
| 2025-03-09 04:15:51 | Début du basculement du stockage de service vers un autre filer |
| 2025-03-09 05:37:27 | Tous les systèmes impactés sont désormais identifiés ; nous avons identifié que tous les e-mails sont correctement en file d’attente et qu’il n’y a aucune perte de données possible |
| 2025-03-09 06:40:04 | Arrivée d’intervenants supplémentaires sur site |
| 2025-03-09 07:01:41 | Mise à jour du firmware commencée |
| 2025-03-09 07:15:07 | Premier service critique à redémarrer identifié |
| 2025-03-09 07:20:55 | Échec de la mise à jour du firmware |
| 2025-03-09 07:30:40 | Mise à jour du firmware réussie, mais le problème persiste |
| 2025-03-09 07:41:11 | Nous avons identifié que le problème du firmware peut être lié à un dispositif PCI, donc nous avons dû démonter le fichier et retirer tous les dispositifs PCI |
| 2025-03-09 09:15:57 | Nous avons réussi à remettre notre bot de surveillance en ligne |
| 2025-03-09 10:25:00 | Nous avons réussi à récupérer le VPN afin que l’équipe de support puisse travailler correctement |
| 2025-03-09 16:49:15 | Nous avons réussi à récupérer tous les services sauf les boites mails |
| 2025-03-09 16:50:10 | Nous commençons à récupérer les boîtes mails |
| 2025-03-10 10:29:06 | Le fichier était de nouveau en ligne après plusieurs changements matériels, et les VM sont également de nouveau en ligne |
| 2025-03-10 11:30:15 | Nous avons identifié que dans certains cas, certains serveurs de messagerie n’ont pas monté le système NFS de la boîte mails et stockaient les e-mails localement. Ce montage incorrect a entraîné la disparition de tous les anciens e-mails des boîtes mails |
| 2025-03-10 13:30:00 | Nous avons commencé à restaurer la partition appropriée sur les boîtes mails impactées. En conséquence, les clients pouvaient voir les anciens e-mails mais pas ceux reçus pendant l’incident ; nous avons commencé une procédure pour récupérer correctement les e-mails qui étaient stockés sur la mauvaise partition ; aucun courrier n’a été divulgué, et chaque boîte mails avait ses e-mails correctement segmentés |
| 2025-03-12 17:00:00 | Nous avons réussi à restaurer tous les e-mails dans chaque boîte mails dans un dossier dédié |
| 2025-03-13 09:00:15 | Problèmes de réplication identifiés sur la base de données de quota : cette base de données stocke l’espace utilisé pour chaque boîte mails. Nous devions recréer la base de données car l’erreur était insoluble. La décision a été prise de saisir cette occasion pour créer une nouvelle base de données qui répond à nos nouveaux standards. |
| 2025-03-14 14:30:00 | Nous avons recréé la base de données. La création de la base de données nécessitait l’injection de tous les quotas à partir de zéro, ce qui signifiait recalculer à nouveau l’espace utilisé sur toutes les boîtes mails. Avec un index manquant, la mise à jour des quotas causait un problème de verrouillage, ce qui faisait planter Postfix et impactait à nouveau le service de messagerie. |
| 2025-03-14 16:30:00 | Toutes les boîtes mails sont à nouveau opérationnelles, et nous avons décidé de reporter toutes les opérations sur le quota et de le migrer après le week-end. |
Analyse
Plusieurs facteurs ont compliqué l’identification de la cause première des perturbations :
- Le système d’authentification interne a été touché, de sorte que plusieurs services internes et bots n’ont pas pu fonctionner correctement. Ce service est redondant avec un keepalive qui bascule automatiquement les services sur la machine appropriée. Cependant, étant donné que seul le stockage du filer était indisponible, le keepalive n’a pas fonctionné car les services étaient toujours accessibles via le réseau et seulement dans un état dégradé sans accès à leurs disques.
- Pour ajouter à la complexité de la situation, l’équipe d’assistance à la clientèle n’était pas non plus en mesure de fonctionner car tous ses outils utilisaient soit une authentification interne, soit des restrictions d’IP nécessitant une connexion au VPN.
Quelles mesures ont été prises ?
Après cet incident, plusieurs décisions ont été prises afin d’éviter que cette situation ne se réitère :
- Tout d’abord, améliorer la redondance pour tous nos bots de surveillance, car sans surveillance, nous sommes limités dans notre capacité à voir ce qui se passe, ce qui a clairement retardé notre temps de réaction et rendu nos décisions plus difficiles.
- S’assurer d’arrêter toutes les machines virtuelles sur le filer affecté si nous avons un problème avec le filer, afin de s’assurer que les mécanismes de redondance peuvent fonctionner correctement.
- S’assurer que tous les services redondants sont répartis sur plusieurs filers.
- Améliorer la documentation et mettre en place des procédures de contournement pour les pannes des systèmes d’infrastructure critiques tels que l’authentification et la mise en réseau.
- Augmenter le nombre de machines virtuelles de certains services afin de pouvoir absorber les fluctuations du trafic si un sous-ensemble d’instances n’est pas disponible.
- Augmenter la redondance des VMs servant à exposer les boites emails aux clients.
- Nous travaillons à passer d’un système zfs à un système ceph, ce qui nous rendra moins exposés aux problèmes matériels.
Cet incident a pris une ampleur exceptionnelle en raison notamment de sa durée. Nous tenons à souligner le professionnalisme de nos équipes, dont beaucoup n’étaient pas d’astreinte et se sont portées volontaires pour aider un dimanche.
