P1 · Infrastructure
Une coupure de courant a fait tomber l'hyperviseur.
Une configuration fragile l'a gardé K.O. 5 heures de plus.
Une panne électrique datacenter a crashé l'hyperviseur en boucle pendant la nuit. Le courant est revenu à 04:02 — mais sans démarrage automatique ni routage persisté, les sites ne sont remontés qu'à 08:55.
L'écart 04:02 → 08:55 = ~4 h 53 d'indisponibilité évitable : le matériel était rétabli, mais rien ne s'est relancé tout seul.
Résumé
Durant la nuit, une panne électrique dans le datacenter de l'hébergeur a provoqué plusieurs coupures brutales successives de l'hyperviseur principal sur une fenêtre d'environ deux heures. À chaque redémarrage, l'infrastructure est remontée dans un état partiel et obsolète : aucun composant virtualisé (VM/conteneur) ni la configuration réseau n'était prévu pour se restaurer automatiquement.
La cause du redémarrage est externe et le matériel est sain. C'est le manque de résilience de la configuration qui a transformé une coupure de courant en panne applicative de plusieurs heures.
Chronologie
502 sur les pages temps-réel.Causes
Panne électrique datacenter
Plusieurs coupures d'alimentation brutales en ~2 h. Confirmé par la corrélation exacte entre l'heure du 1er crash (logs : arrêt net, sans kernel panic, sans erreur mémoire ECC, sans surchauffe) et la page de statut publique de l'hébergeur, qui signale deux incidents électriques successifs sur le rack concerné, sur la même fenêtre horaire. Le matériel du serveur est sain.
NAT figé sur un ancien reverse-proxy
Les règles 80/443 sont recréées au boot depuis un fichier réseau qui codait en dur l'adresse d'un reverse-proxy déclassé. Les règles correctes avaient été ajoutées à chaud, sans être persistées. Au reboot, seules les anciennes — vers un hôte mort — ont été rechargées : tout le trafic entrant tombait dans le vide.
MariaDB non redémarrée
Base non configurée en démarrage automatique : restée arrêtée plusieurs heures avant un démarrage manuel.
TimescaleDB non redémarrée
Également arrêtée et sans autostart. Les pages temps-réel l'interrogent : chaque requête bloquait jusqu'au timeout TCP (~18-31 s) → temps de réponse saturés et erreurs 502. Le serveur applicatif, lui, n'était pas en cause (charge faible, ressources disponibles).
Résolution
Trois correctifs appliqués en production : (1) suppression des règles NAT obsolètes, (2) démarrage de la base relationnelle, (3) démarrage de la base timeseries. Vérification de bout en bout : page temps-réel de référence à ~1 s (contre 18-31 s / 502 pendant l'incident), en accès direct à l'origine et via le CDN public.
Actions correctives
- Persister la configuration NAT sur le reverse-proxy actuel (supprimer toute référence à l'ancien) ; sauvegarder le fichier avant modification.
- Activer le démarrage automatique (
onboot) de tous les invités critiques : reverse-proxy, bases relationnelle & timeseries, DNS, services front-facing. - Définir un ordre de démarrage : bases de données avant les serveurs applicatifs et le reverse-proxy.
- Auditer l'écart entre l'état persisté et l'état de production (règles réseau, montages, services).
- Supervision : alerter si un invité critique est arrêté, si un port public ne répond plus, ou si une page de référence dépasse un seuil de latence.
- Dégradation propre côté applicatif : timeout court + message si une base est injoignable, plutôt qu'un blocage jusqu'au timeout TCP.
- Installer les utilitaires de lecture du journal matériel (BMC/IPMI) et des capteurs de température.
- Test de reprise après reboot planifié (hors heures de pointe).
- Runbook de reprise documenté (ordre de démarrage, vérifications, commandes de contrôle).
- S'abonner aux notifications de statut de l'hébergeur (électricité, réseau, refroidissement).
Enseignements
Ce qui a bien fonctionné — diagnostic méthodique (réseau → routage → bases → applicatif), isolation rapide de chaque cause, vérifications de bout en bout, et corrélation du crash avec l'incident datacenter.
Ce qui doit s'améliorer — la résilience au redémarrage. Une coupure d'alimentation est inévitable à terme ; un crash de l'hyperviseur ne devrait jamais entraîner une indisponibilité totale de plusieurs heures.
Risque résiduel — tant que la priorité haute n'est pas traitée, l'incident est intégralement reproductible au prochain redémarrage.