Reprise après incident¶

Cette page explique comment remettre CMonChoix dans un état stable après une panne, une corruption de données ou une régression. Elle ne remplace pas le diagnostic : son objectif est de retrouver un fonctionnement cohérent sans aggraver la situation.

Qu'est-ce que la reprise d'activité ?¶

La reprise d'activité (recovery) regroupe les actions qui permettent de restaurer un fonctionnement normal après un incident.

Il faut distinguer deux sujets :

dépannage / troubleshooting : comprendre pourquoi le problème est arrivé ;
reprise : remettre le système dans un état exploitable et sûr.

En situation critique, la priorité est généralement de stabiliser la plateforme, puis d'approfondir l'analyse.

Les situations typiques¶

Une procédure de reprise peut être nécessaire après :

une synchronisation interrompue ;
une reconstruction incomplète ;
une régression après déploiement ;
une corruption ou suppression de données ;
l'indisponibilité d'un service Docker ;
une panne du VPS ;
une restauration de sauvegarde.

Règle fondamentale¶

Ne pas multiplier les changements pendant une reprise.

Le cycle recommandé est :

Détecter
   ↓
Qualifier
   ↓
Sécuriser
   ↓
Restaurer ou reconstruire
   ↓
Valider
   ↓
Reprendre progressivement les traitements

Chaque étape doit réduire le risque au lieu d'ajouter de nouvelles inconnues.

Étape 1 — qualifier ce qui est réellement cassé¶

Avant une action destructive, répondre à quelques questions simples :

le site public répond-il ?
les conteneurs critiques sont-ils démarrés ?
MariaDB répond-elle ?
le problème concerne-t-il le code ou les données ?
tous les marchands sont-ils concernés ou un seul ?
un déploiement récent précède-t-il l'incident ?
existe-t-il une sauvegarde vérifiée et restaurable ?

Commencer par les contrôles documentés dans Monitoring et Dépannage.

Étape 2 — préserver les preuves¶

Avant de restaurer ou d'écraser un état dégradé, conserver ce qui peut aider à comprendre ou récupérer l'incident :

logs ;
métriques ;
commit Git courant ;
état des conteneurs ;
dernier run concerné ;
sauvegarde de la base actuelle si elle reste accessible.

Une base dégradée peut contenir des données plus récentes que la dernière sauvegarde saine. La remplacer immédiatement peut faire perdre ces informations.

Étape 3 — choisir la bonne stratégie¶

Le code est en cause¶

Si une régression provient d'un déploiement, un retour au commit stable précédent peut être approprié.

Voir Déploiement pour la procédure de rollback du code.

Un rollback Git ne restaure pas automatiquement les données si une migration ou une écriture destructive les a déjà modifiées.

Les données dérivées sont en cause¶

Une projection ou un cache reconstructible doit de préférence être régénéré depuis sa source de vérité plutôt que corrigé ligne par ligne.

Cela permet de conserver le fonctionnement normal et reproductible de la plateforme.

Les données persistantes sont perdues ou corrompues¶

Utiliser une sauvegarde uniquement après avoir vérifié son intégrité et sa restaurabilité.

Voir Sauvegarde et contrôle de restauration.

Un traitement a été interrompu¶

Ne pas supposer qu'il faut recommencer depuis zéro.

Les traitements reprenables doivent utiliser l'état persistant du run, les batches ou les mécanismes officiels de reprise documentés par le Runtime.

Étape 4 — valider avant de rouvrir complètement¶

La remise en route d'un conteneur n'est pas une validation suffisante.

Après une reprise, contrôler notamment :

état Docker ;
disponibilité WordPress ;
connexion MariaDB ;
état du Runtime ;
cohérence des données critiques ;
disponibilité des projections ;
dernier run concerné ;
logs et métriques ;
fonctionnement du site public.

Lorsque cela s'applique :

make doctor

Un résultat PASS apporte une validation technique globale, mais il faut aussi vérifier le comportement métier touché par l'incident.

Reprendre progressivement les traitements¶

Après une interruption importante, éviter de relancer simultanément toutes les opérations lourdes.

Préférer :

vérifier les services fondamentaux ;
vérifier les données ;
lancer un traitement contrôlé ;
examiner son résultat ;
seulement ensuite revenir au fonctionnement normal.

Cette progression permet de détecter une anomalie avant qu'elle ne touche un périmètre plus large.

Cas d'un VPS à reconstruire¶

Une perte complète du serveur demande une procédure plus large qu'un simple redémarrage.

Le principe de PRA — Plan de reprise d'activité — consiste à reconstruire l'environnement puis restaurer les données validées.

Le chemin conceptuel est :

Nouveau serveur Ubuntu
        ↓
Docker et dépendances
        ↓
Code CMonChoix depuis Git
        ↓
Configuration et secrets
        ↓
Volumes / uploads nécessaires
        ↓
MariaDB depuis sauvegarde validée
        ↓
Démarrage des services
        ↓
Contrôles techniques
        ↓
Contrôles fonctionnels

La restauration complète reste guidée et contrôlée. Elle ne doit pas être déclenchée automatiquement sans validation humaine.

Attention aux anciennes commandes documentées¶

Des documents historiques peuvent mentionner d'anciens outils ou commandes de reprise.

Pour l'état actuel, privilégier les commandes versionnées et effectivement présentes dans le dépôt, notamment :

make doctor ;
make backup ;
make backup-verify ;
make restore-check.

Une commande historique ne doit pas être utilisée simplement parce qu'elle apparaît dans une ancienne note. Vérifier qu'elle existe encore réellement avant exécution.

Ce qu'il ne faut jamais faire¶

Ne jamais :

modifier directement une projection pour accélérer la reprise ;
restaurer partiellement des données sans comprendre leurs dépendances ;
écraser une base dégradée sans conserver les preuves utiles ;
relancer tous les traitements avant validation ;
considérer un conteneur Up comme preuve que les données sont cohérentes ;
mélanger plusieurs corrections indépendantes pendant le même diagnostic ;
exécuter une ancienne commande de restauration sans vérifier qu'elle correspond encore au Runtime actuel.

Checklist après reprise¶

[ ] la cause ou au minimum le périmètre de l'incident est identifié
[ ] les preuves utiles ont été conservées
[ ] le code déployé est connu
[ ] les données restaurées ou reconstruites sont identifiées
[ ] make doctor passe lorsque applicable
[ ] les projections concernées sont cohérentes
[ ] un traitement contrôlé fonctionne normalement
[ ] le site public est validé
[ ] les logs ne montrent pas de nouvelle anomalie
[ ] l'incident et la reprise sont documentés

Après le retour à la normale¶

Une reprise réussie n'est pas la fin du travail.

Il faut ensuite documenter :

le symptôme initial ;
la cause si elle est connue ;
les données ou services touchés ;
la stratégie de reprise utilisée ;
les contrôles réalisés ;
les actions permettant d'éviter une répétition.

Cela transforme un incident ponctuel en connaissance transmissible.