Incident nocturne : stabilisation du monolithe en prod

# Panne de prod en pleine nuit : Stabiliser le monolithe et coordonner l'équipe

L'alerte pager « PROD : tout est rouge » m'a sorti du lit en sursaut. Direction la salle d'incident : playbook SRE — stabiliser, analyser, post-mortem. L'équipe s'est réparti les rôles : coordination, communications, base de données, surveillance des métriques et logs. Objectif : débusquer la cause racine enfouie sous des couches de code legacy.

Les parties prenantes ont reçu la première mise à jour : « Service HS. L'équipe est dessus. Prochaine mise à jour dans 15 minutes. » La surveillance affichait toutes les métriques en rouge sauf un petit pic vert. Les logs débordaient d'erreurs de timeout cognant contre le monolithe, surnommé affectueusement « le dragon ».

Diagnostic : Des files de messages aux goulots d'étranglement en base

Les métriques des files de messages ont explosé de façon exponentielle, les consommateurs plantant à cause des timeouts. Coupable : des requêtes base de données trop lentes. Voici un exemple flagrant :

SELECT * FROM users WHERE some_condition ORDER BY created_at LIMIT 1000;
-- Pas d'index sur some_condition ou created_at, scan de plus de 10M de lignes — catastrophe totale.

Le DBA a repéré des index manquants et des problèmes de requêtes N+1 dans le nouveau service. L'architecte legacy a confirmé : le monolithe accumule l'état global, pas conçu pour scaler sans refactorisation.

Proposition urgente de migration Kubernetes ? Rejetée. Ça ajouterait de la complexité en pleine crise sans résoudre le vrai problème.

Contrôle de sécurité et compromis arrachés

Demande d'accès temporaire pour throttler le trafic et rollback la fonctionnalité ? La sécu a bloqué net. Le modèle de menaces exige une validation des risques. Compromis : accès d'une heure avec logging complet et rapport d'audit.

Actions :

• Throttler le trafic avec limitation de débit.
• Rollback de la nouvelle fonctionnalité via feature flag.
• Surveiller la récupération : rouge → rose → gris → vert stable.

Parties prenantes mises à jour : « Stabilisé. Analyse en cours. Prochaine mise à jour dans 30 minutes. »

Cause racine et leçons clés

Incident contenu : files engorgées, base de données malmenée par des requêtes non optimisées du nouveau service. Monolithe muselé et stable, mais il hurle pour une refonte systématique.

Le manager OKR intervient : doublement des releases, « tout réécrire », Kubernetes partout. Risque : courir après des projets big-bang au lieu de gains incrémentaux.

Leçons clés :

• La cause racine était des requêtes bâclées et des files saturées, pas le monolithe en soi.
• Des rôles d'incident clairs sont cruciaux : coordination, comms, expertise pointue.
• La sécu peut fléchir avec accès temporisé et audits.
• Éviter les migrations hâtives en crise ; prioriser la stabilisation.
• Le post-mortem façonnera la roadmap : index, feature flags, refactorisation graduelle.

L'équipe a bouclé la stabilisation en 2 heures. Prochaines étapes : post-mortem et plan d'actions.

— Editorial Team