Operations Recovery¶
La reprise d'activité (Recovery) regroupe les procédures permettant de restaurer un fonctionnement normal de CMonChoix Platform après une interruption, une défaillance ou une corruption des données.
Contrairement à la gestion des incidents, qui vise à identifier et corriger la cause d'un problème, la reprise d'activité poursuit un objectif immédiat : remettre la Platform dans un état cohérent et exploitable.
La priorité est toujours de retrouver un fonctionnement stable avant d'engager les analyses approfondies.
Objectifs¶
Les procédures de reprise poursuivent plusieurs objectifs.
- restaurer un état cohérent de la Platform ;
- limiter l'interruption de service ;
- préserver les données métier ;
- garantir la continuité des traitements ;
- permettre une reprise progressive des opérations.
Une reprise réussie ne consiste pas uniquement à remettre les services en fonctionnement.
Elle garantit également que les données produites restent conformes aux principes de l'architecture.
Position dans l'architecture¶
La reprise peut concerner plusieurs couches de la Platform.
Recovery
│
┌──────────────┼──────────────┐
│ │ │
Database Runtime Pipeline
│ │
└────── Projections ──────────┘
La stratégie dépend toujours du composant concerné.
Principes¶
Les opérations de reprise reposent sur plusieurs principes fondamentaux.
Priorité à la stabilité¶
L'objectif est de retrouver un fonctionnement cohérent.
Les optimisations éventuelles interviennent après le rétablissement du service.
Reprise contrôlée¶
Chaque étape est réalisée de manière progressive.
Les validations intermédiaires permettent d'éviter une aggravation de la situation.
Traçabilité¶
Toutes les opérations de reprise doivent être documentées.
Il doit être possible de comprendre :
- pourquoi une reprise a été déclenchée ;
- quelles opérations ont été réalisées ;
- quel état a été restauré.
Reproductibilité¶
Une procédure de reprise doit pouvoir être exécutée plusieurs fois dans les mêmes conditions.
Cette propriété facilite les tests et améliore la fiabilité des opérations.
Situations de reprise¶
Plusieurs événements peuvent nécessiter une procédure de reprise.
Interruption d'un traitement¶
Une synchronisation ou une reconstruction peut être interrompue.
Une reprise permet de retrouver un état cohérent avant de poursuivre les traitements.
Dégradation des données¶
Une incohérence importante peut conduire à reconstruire certaines structures.
La reconstruction repose toujours sur les données de référence.
Régression¶
Une évolution peut produire un comportement inattendu.
Une reprise consiste alors à restaurer le dernier état validé avant de poursuivre l'analyse.
Incident technique¶
Une indisponibilité d'un composant peut nécessiter une remise en service progressive de la Platform.
Cycle de reprise¶
Toute opération suit un déroulement identique.
Détection
│
▼
Qualification
│
▼
Sécurisation
│
▼
Restauration
│
▼
Validation
│
▼
Reprise des traitements
Chaque étape réduit progressivement le niveau de risque.
Restauration¶
La restauration consiste à retrouver un état cohérent de la Platform.
Selon le contexte, elle peut s'appuyer sur :
- des sauvegardes ;
- des reconstructions ;
- des traitements officiels ;
- des projections régénérées.
La restauration ne doit jamais modifier arbitrairement les données métier.
Validation¶
Avant de reprendre l'exploitation normale, plusieurs contrôles sont réalisés.
Ils portent notamment sur :
- la cohérence des données ;
- le fonctionnement du Pipeline ;
- la disponibilité des projections ;
- le comportement du Runtime ;
- l'absence de régression visible.
La reprise n'est considérée comme terminée qu'après validation.
Documentation¶
Chaque reprise importante doit être documentée.
La documentation décrit notamment :
- l'événement déclencheur ;
- le périmètre concerné ;
- les opérations réalisées ;
- les validations effectuées ;
- les éventuelles actions préventives retenues.
Cette documentation contribue à l'amélioration continue des procédures d'exploitation.
Dépendances¶
Les procédures de reprise peuvent mobiliser plusieurs composants.
- Database
- Pipeline
- Runtime
- Read Services
- Write Services
- outils de supervision
- mécanismes de sauvegarde
La logique métier du Domain Core reste inchangée pendant toute la durée de la reprise.
Invariants¶
Les opérations de reprise respectent plusieurs propriétés fondamentales.
Les données restent cohérentes¶
La restauration ne doit jamais produire un état intermédiaire incohérent.
Les traitements restent reproductibles¶
Les opérations de reconstruction suivent les mêmes mécanismes que les traitements normaux.
Les responsabilités restent inchangées¶
La reprise n'introduit aucune logique supplémentaire dans les composants de la Platform.
Les consommateurs restent découplés¶
Le Frontend et le Runtime continuent de s'appuyer sur les projections officielles.
Garde-fous¶
Afin de préserver la stabilité de la Platform, plusieurs règles doivent toujours être respectées.
Ne jamais :
- restaurer partiellement des données sans validation de leur cohérence ;
- modifier directement des projections afin d'accélérer une reprise ;
- ignorer une anomalie détectée pendant la restauration ;
- reprendre les traitements avant la validation complète ;
- considérer une reprise comme terminée sans mise à jour de la documentation.
Vision long terme¶
Les mécanismes de reprise évolueront progressivement afin de :
- réduire le temps de restauration ;
- automatiser certaines procédures ;
- améliorer la détection des états incohérents ;
- renforcer les contrôles de validation ;
- accroître la résilience globale de la Platform.
L'objectif demeure identique : garantir qu'un incident puisse être surmonté sans compromettre l'intégrité des données ni les principes fondamentaux de l'architecture.
Voir aussi¶
- Operations Overview
- Operations Backups
- Operations Maintenance
- Operations Incidents
- Operations Monitoring
- Database Overview
- Pipeline Overview
- Runtime Overview
- Architecture Vision
Restore Check¶
La capacité de restauration est contrôlée par :
ccx-ops restore-check
Cette commande est non destructive.
Elle vérifie :
- présence des chemins critiques ;
- présence des commandes d'exploitation ;
- dernier backup SQL lisible ;
- dernier backup Docker présent ;
- runtime Docker opérationnel ;
- conteneurs critiques démarrés ;
- capacité disque suffisante ;
- documentation valide.
Un contrôle réussi retourne :
RESTORE_CHECK_STATUS=OK
Principe PRA¶
La restauration complète doit rester guidée et contrôlée.
Aucune commande destructive de restauration automatique ne doit être exécutée sans validation humaine.
La procédure de reprise doit suivre cet ordre :
- reconstruire le serveur Ubuntu ;
- installer Docker ;
- restaurer les volumes et configurations Docker ;
- restaurer WordPress ;
- restaurer MariaDB ;
- relancer les conteneurs ;
- exécuter
ccx-ops restore-check; - exécuter
ccx-ops audit; - valider le site et la documentation.