Exploitation de CMonChoix¶

Cette section explique comment faire fonctionner CMonChoix au quotidien sans casser la production. Elle est destinée à une personne qui reprend le site, même si elle n'a jamais administré la plateforme auparavant.

À quoi sert la couche Operations ?¶

La couche Operations regroupe toutes les procédures nécessaires pour exploiter, surveiller, maintenir, sauvegarder et dépanner CMonChoix en production.

Elle ne décide pas de la vérité métier. Elle ne détermine pas qu'un produit est un smartphone, ne résout pas son identité et ne calcule pas une projection.

Son rôle est différent : elle s'assure que les composants qui font ce travail fonctionnent correctement, restent observables et puissent être restaurés en cas de problème.

En pratique, Operations répond à des questions comme :

le site et les conteneurs sont-ils bien démarrés ?
les synchronisations marchands se terminent-elles correctement ?
les données produites sont-elles cohérentes ?
existe-t-il une sauvegarde restaurable ?
comment redémarrer un traitement interrompu ?
comment déployer un nouveau commit ?
comment revenir en arrière si un déploiement se passe mal ?
que vérifier avant d'exécuter une commande qui écrit en production ?

La règle la plus importante¶

Observer avant d'agir, sauvegarder avant une opération risquée, vérifier après toute modification.

Une intervention de production sûre suit autant que possible cette séquence :

Comprendre le problème
        ↓
Observer l'état actuel
        ↓
Identifier la couche responsable
        ↓
Sauvegarder si l'opération présente un risque
        ↓
Simuler / auditer lorsque c'est possible
        ↓
Exécuter l'action ciblée
        ↓
Vérifier le résultat
        ↓
Documenter l'incident ou le changement

Où se place Operations ?¶

                 Operations
                     │
        ┌────────────┼────────────┐
        │            │            │
     Pipeline      Runtime     Frontend
        │            │
        └────── Base de données ──┘

Operations observe et pilote ces composants, mais n'ajoute pas de règle métier.

Avant toute intervention sur le VPS¶

Avant de lancer une commande que vous ne connaissez pas :

vérifier dans quel dossier vous êtes ;
vérifier la branche Git et le commit ;
vérifier si le dépôt est propre ;
comprendre si la commande lit ou écrit ;
vérifier si elle agit sur l'hôte, un conteneur ou la base ;
si elle écrit ou supprime, vérifier qu'une sauvegarde adaptée existe ;
savoir comment contrôler le résultat.

Commandes de base utiles :

pwd
git status --short
git branch --show-current
git rev-parse HEAD
docker compose ps

Un git status --short sans sortie signifie que le dépôt ne contient pas de modification locale non commitée.

Comprendre les principaux objets d'exploitation¶

VPS¶

Le VPS est le serveur Linux qui héberge la plateforme et ses conteneurs Docker.

Docker Compose¶

docker compose décrit et pilote les services nécessaires à CMonChoix : WordPress, worker, MariaDB, documentation et autres services d'infrastructure.

Conteneur¶

Un conteneur est un environnement isolé dans lequel s'exécute un service. Modifier directement un fichier à l'intérieur d'un conteneur est généralement une mauvaise idée : le changement peut disparaître au prochain redémarrage et ne sera pas versionné dans Git.

Run¶

Un run représente une exécution identifiable, par exemple une synchronisation marchande. Il doit pouvoir être suivi, audité et repris lorsqu'il est conçu pour cela.

Worker¶

Le worker est le contexte chargé d'exécuter des traitements en arrière-plan. Il ne sert pas à afficher les pages du site.

Cron¶

Le cron déclenche des tâches planifiées. Une tâche automatique peut donc démarrer sans action manuelle d'un utilisateur.

Responsabilités d'Operations¶

1. Exploitation quotidienne¶

L'exploitation quotidienne consiste notamment à surveiller :

la disponibilité du site ;
l'état des conteneurs ;
les synchronisations ;
la qualité des données ;
les erreurs récentes ;
l'espace disque et les ressources lorsque nécessaire.

2. Supervision¶

La supervision cherche à répondre à la question : « Est-ce que le système fonctionne comme prévu ? »

Elle couvre notamment :

les runs du Pipeline ;
les traitements Runtime ;
la disponibilité des données ;
les erreurs applicatives ;
les ressources techniques.

3. Maintenance¶

La maintenance peut inclure :

reconstruction de projections ;
régénération de caches ;
maintenance de tables ou données temporaires ;
mise à jour contrôlée de composants ;
vérification des sauvegardes.

Une tâche de maintenance n'est pas automatiquement sans danger. Il faut toujours savoir si elle est en lecture seule ou si elle modifie l'état de production.

4. Déploiement¶

Un déploiement consiste à faire passer la production sur une version précise et validée du code.

La procédure canonique est décrite dans Déploiement.

Le principe est : on déploie un commit identifié, pas « ce qu'il y a actuellement dans le dossier ».

5. Sauvegarde et restauration¶

Une sauvegarde n'est utile que si elle peut être restaurée.

La procédure canonique est décrite dans Sauvegarde et restauration.

6. Gestion des incidents¶

Lorsqu'un problème apparaît, l'objectif n'est pas de modifier rapidement plusieurs choses jusqu'à ce que le symptôme disparaisse.

La bonne méthode est :

conserver les preuves ;
qualifier le symptôme ;
déterminer si le problème est technique, Runtime, Pipeline, données ou métier ;
limiter le périmètre ;
corriger la cause ;
vérifier le résultat ;
documenter ce qui s'est passé.

Lecture ou écriture : savoir faire la différence¶

Avant une commande importante, demandez-vous toujours si elle est read-only (lecture seule) ou si elle peut modifier les données.

Exemples généralement orientés lecture :

git status --short
docker compose ps
wp help

Exemples potentiellement mutatifs :

synchronisation marchande ;
rebuild d'une projection ;
migration de base ;
commande de réparation ;
UPDATE, DELETE ou INSERT SQL ;
restauration d'une sauvegarde.

Le fait qu'une commande s'appelle rebuild, fix, repair, sync, migrate ou restore doit immédiatement faire considérer qu'elle peut écrire jusqu'à preuve du contraire.

Procédure de diagnostic de premier niveau¶

Lorsqu'un problème est signalé et que vous ne savez pas encore d'où il vient :

Étape 1 — vérifier le serveur¶

cd /mnt/data/cmonchoix-platform
docker compose ps

Chercher un service arrêté, en redémarrage permanent ou marqué comme non sain.

Étape 2 — vérifier Git¶

git status --short
git branch --show-current
git rev-parse HEAD

Cela permet de savoir précisément quel code est présent sur le serveur.

Étape 3 — déterminer la famille du problème¶

le site ne répond pas → commencer par infrastructure / conteneurs / HTTP ;
une synchronisation ne démarre pas → Runtime / worker / queue ;
une synchronisation démarre mais produit de mauvaises données → Pipeline / normalisation / règles métier ;
une donnée correcte existe mais s'affiche mal → projection / frontend ;
la base semble incohérente → base de données / Write Service / incident de données.

Étape 4 — consulter le run ou les métriques¶

Ne concluez pas qu'un traitement a « fonctionné » uniquement parce qu'une commande a terminé sans message d'erreur. Vérifiez les compteurs et l'état final.

Étape 5 — ne pas improviser une écriture¶

Si la cause n'est pas comprise, n'exécutez pas une réparation SQL ad hoc simplement pour corriger le symptôme visible.

Les procédures essentielles à connaître¶

Pour reprendre l'exploitation de CMonChoix, commencer par lire dans cet ordre :

Ensuite, lire les playbooks spécifiques aux synchronisations et aux rebuilds.

Ce qu'il ne faut jamais faire sans procédure claire¶

Ne jamais :

modifier directement du code dans un conteneur ;
supprimer des données pour « voir si ça repart » ;
exécuter un DELETE, UPDATE, migration ou restauration sans comprendre le périmètre ;
déployer un dépôt sale ;
écraser un commit stable sans connaître le commit de retour arrière ;
considérer une sauvegarde comme bonne sans vérification de restauration ;
lancer plusieurs réparations en même temps pendant un incident ;
masquer une erreur avec || true dans une procédure censée être bloquante ;
confondre disparition du symptôme et résolution de la cause.

Comment savoir qu'une opération est terminée¶

Une opération importante n'est terminée que lorsque :

son résultat technique est connu ;
ses métriques sont cohérentes ;
les données attendues ont été vérifiées ;
aucun nouveau problème évident n'est apparu ;
une restauration ou un retour arrière est toujours possible si nécessaire ;
la documentation est mise à jour si le comportement a changé.