47 minutes d'indisponibilité à Reykjavik : le récit complet

Le vendredi 4 novembre 2022, entre 03 h 14 et 04 h 01 UTC, l'ensemble des services hébergés sur notre point de présence de Reykjavik a été injoignable. Durée totale : 47 minutes. Aucune donnée n'a été perdue, aucune machine n'a planté. Cet article reprend la chronologie complète, la cause — y compris notre propre erreur — et les changements déployés depuis. Il est publié cinq jours après l'incident, ce qui est notre engagement : récit complet, sous sept jours, à chaque fois.

Résumé exécutif

• Cause immédiate : section d'une gaine technique lors de travaux de voirie, gaine commune aux deux liaisons opérateurs du POP.
• Impact : 312 VPS injoignables, trafic entrant et sortant perdu, zéro perte de données.
• Erreur de conception : nos deux liaisons étaient redondantes sur le papier — deux opérateurs, deux contrats — mais partageaient le même chemin physique. Vérifié trop tard.
• Mesures : diversité physique vérifiée par OTDR sur les six POP, second opérateur à entrée de bâtiment distincte à Reykjavik, première mise à jour de statut engagée sous 5 minutes, crédits SLA automatisés.

Chronologie minute par minute

Tous les horaires sont en UTC, extraits de nos systèmes de supervision (alerting interne, journaux BGP, page de statut). Nous ne retouchons rien.

Impact réel

312 VPS ont été injoignables pendant 47 minutes. Précisons ce que cela signifie techniquement : les hyperviseurs ont continué de tourner sur leurs onduleurs, le stockage NVMe local n'a jamais été interrompu — seule la connectivité réseau a manqué. Aucune machine ne s'est arrêtée, aucune donnée n'a été perdue, aucun filesystem n'a nécessité de vérification.

Sur le plan commercial : 38 clients nous ont écrit pendant l'incident, 6 ont demandé un avoir. Nous avons crédité automatiquement les 312 services concernés — un jour de service chacun — sans qu'aucun ticket ne soit nécessaire. Les autres points de présence n'ont reçu aucun trafic de report significatif : la majorité des clients de Reykjavik y sont pour la juridiction islandaise, pas pour la latence.

La cause, sans maquillage

Le récit confortable serait : un tiers a coupé un câble, coup du sort. La vérité est plus ennuyeuse et beaucoup plus utile. Nous pensions avoir deux liaisons d'opérateurs distincts à Reykjavik — noms différents, contrats différents, équipements différents. Mais entre le bâtiment et le premier nœud de transport, les deux fibres empruntaient la même gaine technique enterrée. Une seule pelleteuse a donc suffi.

C'est l'erreur classique du double attachement « sur le papier », et elle est entièrement de notre fait. Nous avions vérifié les contrats et les SLA, pas le chemin physique. La vérification qui aurait révélé le problème en dix minutes — une trace OTDR et un constat terrain du génie civil — n'a été demandée qu'après la panne. Cette phrase, nous l'écrivons pour que n'importe quel opérateur qui nous lit puisse l'éviter chez lui : deux opérateurs ne garantissent rien si leurs câbles se tiennent la main.

Ce qui a changé depuis

• Diversité physique vérifiée : traces OTDR et constats de génie civil signés pour chaque liaison des six POP — Rotterdam, Bucarest, Reykjavik, Zurich, Panama City, Moscou. Un chemin non documenté est considéré comme partagé.
• Second opérateur à Reykjavik : entrée de bâtiment distincte, génie civil distinct, activation le 8 novembre 2022.
• Communication : engagement de première mise à jour publique en moins de 5 minutes après détection, testé par exercice trimestriel — pas seulement promis.
• Bascule réelle : exercice de cou physique (pas simulé) d'une liaison par trimestre, sur un POP tournant, à heure annoncée sur la page de statut.
• SLA automatisé : tout incident dépassant 15 minutes déclenche l'avoir correspondant sans ticket — la demande de remboursement devient inutile par construction.

Depuis le 8 novembre 2022, Reykjavik tourne en double attachement réellement diversifié. Ces 47 minutes restent, à ce jour, la totalité du temps d'arrêt du POP depuis son ouverture en avril 2021 — un point dont nous ne sommes pas particulièrement fiers : il aurait dû être zéro.

Nous publions ce post-mortem parce qu'un hébergeur qui ne montre que ses bons jours n'est pas un hébergeur fiable : c'est une brochure. La prochaine coupure viendra, d'où nous ne savons pas. Ce que nous pouvons garantir, c'est le récit complet, dans les sept jours, à chaque fois.