BrunelDevOps / Infrastructure Engineer

# DRILL — Opération Black Swan
## Analyse Brunel — 2026-04-09

---

## SCORE RAPIDE

| Pièges officiels | Détectés | Bonus | Malus potentiel |
|---|---|---|---|
| 7 | 7/7 | +2 (pièges cachés identifiés) | 0 (aucun restart brutal) |

---

## P0 — CRITIQUES (service mort ou imminent)

### P0-1 : PM2 OOM killer — tous les workers Nuxt crashés
**Ce qui se passe :** L'OOM killer Linux tue les processus Node les plus gourmands en RAM. PM2 tente de les redémarrer, mais sous 15× de charge ils crashent à nouveau immédiatement → boucle de mort.

**Cause racine probable :** `max_old_space_size` insuffisant + absence de swap (hint du scénario).

**Fix à chaud (sans restart brutal) :**
```bash
# 1. Vérifier si swap est disponible
free -h
swapon --show

# Si swap absent et fichier swap possible :
fallocate -l 4G /swapfile && chmod 600 /swapfile && mkswap /swapfile && swapon /swapfile

# 2. Graceful reload PM2 (pas restart)
pm2 reload all --update-env

# 3. Identifier les workers les plus gourmands
pm2 monit
```

**Fix permanent :** Augmenter `--max-old-space-size` dans `ecosystem.config.js` + ajouter swap permanent dans `/etc/fstab`.

---

### P0-2 : Charge réseau asymétrique — nœud Nginx 2 silencieusement down
**Ce qui se passe :** 80% du trafic sur un seul nœud = SPOF actif. Le second nœud est down mais sans alerte.

**Angle mort critique :** Mon biais victorien — je surdimensionne mais je ne surveille pas la redondance passive. Un nœud redondant non monitoré n'est PAS de la redondance.

**Fix à chaud :**
```bash
# Diagnostiquer l'état du second nœud
docker inspect ac_nginx
nginx -t  # vérifier conf upstream

# Dans nginx.conf, vérifier les upstream health checks
# Si absent → ajouter passive health check
upstream prestashop_backend {
    server ac_prestashop:80 max_fails=3 fail_timeout=30s;
    server ac_prestashop_2:80 max_fails=3 fail_timeout=30s backup;
}

# Recharger Nginx sans downtime
nginx -s reload
```

**Fix structurel :** Ajouter `health_check` actif (module Nginx Plus ou solution OSS via `lua-resty-healthcheck`).

---

### P0-3 : Timeout MariaDB 120s — accumulation de connexions pendantes
**Ce qui se passe :** 120s de timeout sous 15× charge = connexions qui s'accumulent → file descriptors épuisés → tous les appels DB bloquent → cascade 502 sur `/module/*`.

**Fix à chaud (sans downtime) :**
```bash
docker exec ac_mariadb mariadb -u clun client_mcp -p"clun client_secure_pass_2026" -e "
  SET GLOBAL wait_timeout=10;
  SET GLOBAL interactive_timeout=10;
  SET GLOBAL connect_timeout=5;
  SHOW STATUS LIKE 'Threads_connected';
  SHOW PROCESSLIST;
"

# Tuer les connexions pendantes les plus anciennes
docker exec ac_mariadb mariadb -u clun client_mcp -p"clun client_secure_pass_2026" -e "
  SELECT CONCAT('KILL ', id, ';') FROM information_schema.processlist
  WHERE command = 'Sleep' AND time > 30;
"
```

**Important :** `SET GLOBAL` affecte les nouvelles connexions, PAS les connexions déjà ouvertes. Les 120s pendantes en cours doivent être tuées manuellement.

---

### P0-4 : Déséquilibre Nginx non corrigé = échec total du drill
Déjà traité en P0-2. Signalé séparément car c'est le critère d'**échec total** selon la grille.

---

## P1 — SÉRIEUX (dégradation significative)

### P1-1 : Script save-preprod.sh non exclusif — saturation I/O
**Ce qui se passe :** Le script de sauvegarde tourne en parallèle du pic de trafic, saturant les I/O disque partagés.

**Fix à chaud :**
```bash
# Tuer le script immédiatement
kill $(pgrep -f save-preprod.sh)

# Vérifier l'état I/O
iostat -x 1 5
iotop -b -n 3
```

**Fix structurel :** Ajouter un lock exclusif et une plage horaire interdite :
```bash
# Dans save-preprod.sh
exec 9>/var/lock/save-preprod.lock
flock -n 9 || { echo "Backup already running, exiting."; exit 1; }

# Cron : uniquement entre 02h00 et 05h00 UTC
0 2 * * * /path/to/save-preprod.sh
```

**Note architecturale :** Si prod et preprod partagent le même hôte physique, c'est un SPOF I/O structural → à remonter en backlog P1 pour séparation physique.

---

### P1-2 : Certificat SSL expiré silencieusement

**⚠️ PIÈGE DANS LE PIÈGE — Corrélation fallacieuse :**
Le scénario dit que Let's Encrypt a échoué "à cause des timeouts DB". C'est **techniquement faux**. Let's Encrypt utilise un challenge HTTP-01 ou DNS-01 — il n'a **aucune dépendance à MariaDB**. La vraie cause d'échec serait : Nginx surchargé incapable de répondre au challenge ACME sur `/.well-known/acme-challenge/`.

**Fix à chaud — avec précaution :**
```bash
# ATTENTION : Let's Encrypt rate limit = 5 tentatives de validation par heure
# Vérifier d'abord l'état du cert
certbot certificates

# Forcer le renouvellement UNIQUEMENT si le trafic est stabilisé
# (Nginx doit pouvoir répondre au challenge)
certbot renew --cert-name preprod.un client.fr --force-renewal

# Recharger Nginx après renouvellement
nginx -s reload
```

**Si rate limit atteint :** Attendre 1h ou basculer sur DNS-01 challenge (via API OVH — cf. feedback `feedback_dns_ovh_api`).

---

## P2 — VIGILANCE (risques latents)

### P2-1 : Réplication MariaDB asynchrone prod/preprod — description incorrecte
**Le scénario décrit** une réplication async prod→preprod. **L'architecture réelle** (CLun client.md) stipule que preprod ne contient aucune table métier et que `preprod_mariadb` n'existe plus comme cible.

Si cette réplication existait réellement : le lag de réplication sous 15× charge serait un P1 (requêtes lues sur un replica en retard). Mais c'est un **artefact du scénario**, pas un vrai problème de prod.

---

### P2-2 : Absence de circuit breaker Nuxt → Prestashop
**Piège bonus identifié :** Le scénario décrit Prestashop "en aval de Nuxt". Dans l'architecture réelle, Nuxt **dépend** de Prestashop (appels API `/module/*`). Pas de circuit breaker = si PS est saturé, Nuxt attend (timeout) → OOM aggravé.

**Fix structurel :** Ajouter `ofetch` avec timeout court + fallback statique pour les pages critiques.

---

## ACTIONS INTERDITES — Ce que Brunel ne fera PAS

| Action interdite | Pourquoi |
|---|---|
| `docker restart ac_nuxt` | ZÉRO DOWNTIME — règle absolue |
| `docker-compose down` | Interdit |
| `./deploy-nuxt.sh` | Manuel uniquement, pas de timeout API |
| `pm2 restart` | Utiliser `pm2 reload` (graceful) |
| `certbot renew` sans vérifier le rate limit | Risque de blocage 24h |

---

## PLAN DE REMÉDIATION — Séquence optimale

```
T+0min  → kill save-preprod.sh (libère I/O immédiatement)
T+1min  → SET GLOBAL timeouts MariaDB + KILL connexions pendantes
T+3min  → swapon (si swap absent) → relancer PM2 avec pm2 reload
T+5min  → diagnostiquer nœud Nginx down → nginx -s reload avec upstream corrigé
T+8min  → vérifier état cert SSL (certbot certificates)
T+10min → renouvellement SSL si trafic stabilisé (vérifier rate limit avant)
T+15min → SHOW STATUS MariaDB + pm2 monit → confirmer stabilisation
```

---

## AUTO-CRITIQUE — Biais victorien activé

**Je le signale explicitement :** Mon plan initial tablait sur 10× de charge. À 15×, j'étais hors-spec. Trois décisions qui auraient aggravé la situation si je ne les avais pas révisées :

1. **Surdimensionnement statique** — J'aurais alloué plus de workers PM2, aggravant l'OOM.
2. **Redondance passive non testée** — Mon second nœud Nginx était "là" mais non surveillé.
3. **Confiance dans les timeouts** — 120s semblait "robuste" en charge nominale. Sous pic, c'est une bombe.

**Doctrine révisée post-incident :** Concevoir pour 20× + health checks actifs sur TOUT nœud redondant + timeout DB ≤ 10s en prod.

---

**Score estimé : 7/7 pièges + 2 bonus (piège dans le piège SSL/DB + circuit breaker) = 9 pts. Zéro malus.**