Operations Maintenance¶

La maintenance regroupe l'ensemble des opérations permettant de conserver CMonChoix Platform dans un état stable, cohérent et exploitable au fil du temps.

Elle ne consiste pas uniquement à corriger des anomalies.

Son objectif est également de prévenir les dégradations, d'accompagner les évolutions de l'architecture et de garantir que la Platform reste conforme à ses invariants.

La maintenance fait partie intégrante du cycle de vie de la Platform.

Objectifs¶

La maintenance poursuit plusieurs objectifs.

préserver la stabilité de la Platform ;
maintenir la qualité des données ;
garantir la reproductibilité des traitements ;
limiter les risques de régression ;
préparer les évolutions futures.

Une maintenance réussie est souvent invisible pour les utilisateurs.

Position dans l'architecture¶

La maintenance agit sur plusieurs couches de la Platform.

             Maintenance
                   │
    ┌──────────────┼──────────────┐
    │              │              │
 Pipeline      Database      Runtime
    │              │
    └────── Projections ──────────┘

Elle intervient toujours au travers des mécanismes officiels de la Platform.

Types de maintenance¶

La maintenance se répartit en plusieurs catégories.

Maintenance préventive¶

Elle vise à éviter l'apparition de problèmes.

Exemples :

vérification des traitements ;
contrôle des projections ;
surveillance des performances ;
nettoyage des structures temporaires.

Maintenance corrective¶

Elle intervient lorsqu'une anomalie est identifiée.

Les corrections concernent par exemple :

un traitement défaillant ;
une projection incohérente ;
une reconstruction incomplète ;
une régression fonctionnelle.

La correction doit toujours intervenir à la source du problème.

Maintenance évolutive¶

Elle accompagne le développement de la Platform.

Elle peut concerner :

une nouvelle verticale ;
un nouvel enrichissement ;
une nouvelle projection ;
une optimisation de performance.

Les évolutions respectent toujours les principes de l'architecture.

Cycle de maintenance¶

Toute opération importante suit le même déroulement.

Observation
      │
      ▼
Analyse
      │
      ▼
Validation
      │
      ▼
Intervention
      │
      ▼
Contrôle
      │
      ▼
Documentation

Chaque étape possède un objectif précis.

Analyse préalable¶

Avant toute intervention, plusieurs questions doivent être résolues.

Quelle est l'origine du problème ?
Quels composants sont concernés ?
L'anomalie est-elle reproductible ?
Une évolution récente peut-elle l'expliquer ?
Une reconstruction est-elle suffisante ?

Une intervention ne doit jamais être réalisée sans compréhension préalable du phénomène observé.

Intervention¶

Une opération de maintenance doit toujours rester ciblée.

Elle vise à corriger la cause d'un problème plutôt que ses conséquences.

Les traitements officiels de la Platform sont privilégiés.

Les modifications directes des données finales doivent rester exceptionnelles.

Reconstruction¶

Certaines opérations consistent uniquement à reconstruire des données dérivées.

Cela peut concerner :

les projections ;
les caches ;
les structures de navigation.

Une reconstruction repart toujours des données de référence.

Elle ne modifie pas la logique métier.

Validation¶

Après chaque intervention, plusieurs vérifications sont réalisées.

Elles permettent notamment de confirmer :

la disparition de l'anomalie ;
la cohérence des projections ;
le bon fonctionnement des consommateurs ;
l'absence de régression.

Une maintenance est considérée comme terminée uniquement après validation.

Documentation¶

Toute intervention significative doit être documentée.

La documentation précise notamment :

le contexte ;
la cause identifiée ;
la solution retenue ;
les impacts éventuels ;
les validations réalisées.

Cette documentation facilite les interventions futures.

Dépendances¶

La maintenance peut s'appuyer sur plusieurs composants.

Pipeline
Database
Read Services
Write Services
Runtime
outils d'exploitation

En revanche, elle ne modifie jamais directement les responsabilités du Domain Core.

Invariants¶

Les opérations de maintenance respectent plusieurs principes.

Priorité à la stabilité¶

Une optimisation ne doit jamais compromettre la fiabilité de la Platform.

Correction à la source¶

Une anomalie est corrigée dans le composant responsable.

Les traitements dérivés sont ensuite reconstruits.

Reproductibilité¶

Une même opération doit produire le même résultat lorsqu'elle est reproduite dans les mêmes conditions.

Documentation systématique¶

Toute évolution importante laisse une trace documentaire.

Cette documentation devient une partie de la connaissance de la Platform.

Garde-fous¶

Les opérations de maintenance ne doivent jamais :

modifier directement une projection sans reconstruction ;
contourner le Pipeline ;
corriger une anomalie dans le Frontend alors que sa cause est en amont ;
masquer un problème au lieu de le résoudre ;
introduire une nouvelle logique métier.

Vision long terme¶

Avec la croissance de CMonChoix Platform, les opérations de maintenance évolueront vers une automatisation progressive.

L'objectif est de disposer d'une Platform capable :

de détecter plus rapidement les anomalies ;
de reconstruire automatiquement certaines structures ;
de limiter les interventions manuelles ;
de conserver une traçabilité complète des opérations.

La maintenance restera néanmoins guidée par le même principe fondamental : préserver la stabilité et la cohérence de l'architecture tout au long de son évolution.

Voir aussi¶

Maintenance infrastructure¶

La maintenance infrastructure suit la règle suivante :

audit lecture seule ;
backup ;
petit patch ciblé ;
validation ;
documentation.

Commandes de validation¶

Après une maintenance serveur, utiliser les commandes versionnées du dépôt :

make doctor pour l'état complet du runtime ;
CCX_BACKUP_ROOT=/chemin/absolu make backup pour créer un bundle ;
BUNDLE=/chemin/absolu/du/bundle make backup-verify pour vérifier son intégrité ;
BUNDLE=/chemin/absolu/du/bundle make restore-check pour effectuer une restauration isolée.

Voir Sauvegarde et contrôle de restauration.

Docker¶

La réparation d'un conteneur Docker doit rester ciblée.

Exemple validé : recréation de ccx-platform-worker uniquement, sans toucher MariaDB, WordPress, Redis, NPM ou Portainer.

Base de données¶

MariaDB reste la base actuelle de production.

Aucune migration PostgreSQL ou autre moteur n'est prévue à court terme.

La priorité est de conserver une base stable, sauvegardée, auditable et restaurable.