Introduction
Auto‑hébergé signifie contrôle — mais aussi responsabilité. Pour les installations Affilentra (PHP/MySQL), des sauvegardes fiables, des chemins de migration reproductibles et des processus de retour en arrière testés sont indispensables pour garantir le suivi, le calcul des commissions et les paiements sans interruption. Cet article fournit des recommandations pratiques que vous pouvez mettre en œuvre immédiatement pour minimiser les temps d'arrêt et rendre les durées de récupération prévisibles.
Principes de base d'une stratégie robuste
- Séparer les rôles : Les opérateurs logiciels exécutent les tâches d'infrastructure (sauvegardes, mises à jour), les commerçants coordonnent les campagnes et les partenaires vérifient l'intégrité du tracking.
- Séparation du code et des données : Sauvegarder le système de fichiers (webroot, médias, supports publicitaires) séparément de la base de données.
- Automatiser, documenter, tester : Chaque étape de sauvegarde et de migration doit être automatisable et reproductible dans un environnement de test.
- Migrations à impact minimal : Concevoir les modifications de schéma de manière à permettre la coexistence temporaire des anciens et des nouveaux chemins de code.
Stratégie de sauvegarde : intervalles et rétention
Une combinaison pragmatique de sauvegardes complètes, de sauvegardes incrémentales et d'enregistrement continu des transactions réduit la fenêtre de restauration.
- Base de données :
- Sauvegarde complète (physique ou logique) au moins une fois par jour pour les systèmes actifs.
- Pour des RTO/RPO faibles : activer et archiver régulièrement les logs binaires (MySQL binary logs) afin de permettre une restauration point‑dans‑le‑temps.
- Pour les grandes bases : utiliser des sauvegardes physiques (par ex. Percona XtraBackup) ou des snapshots cohérents via réplication pour éviter le verrouillage.
- Système de fichiers / fichiers applicatifs :
- Sauvegarde complète une fois par jour ; en cas de changements fréquents (supports publicitaires, uploads), ajouter des sauvegardes incrémentales horaires.
- Avant chaque mise à niveau, toujours créer immédiatement un snapshot de sauvegarde.
- Rétention : Minimum : sauvegardes quotidiennes des 7 derniers jours ; sauvegardes hebdomadaires pendant 8 semaines ; sauvegardes mensuelles pendant 12 mois. Adaptez la rétention aux obligations réglementaires et aux besoins commerciaux.
- Hors site et vérification : Conserver les sauvegardes chiffrées et au moins dans un emplacement externe. Tester régulièrement la restauration (par ex. mensuellement).
Snapshots de base de données et outils
Choisissez l'outil adapté à la taille et à la disponibilité de votre installation.
- petites installations : mysqldump convient pour des sauvegardes logiques et des restaurations simples.
- installations moyennes à grandes : Percona XtraBackup ou des snapshots physiques (LVM, ZFS) fournissent des sauvegardes cohérentes et plus rapides sans verrous prolongés.
- Réplication comme source de sauvegarde : Une réplique en lecture seule peut être utilisée pour les sauvegardes et pour des environnements de test afin de ne pas impacter la charge de production.
- Avant la mise à niveau : Toujours créer un snapshot cohérent incluant les binary logs actifs et consigner la position du binlog.
Trajets de migration entre versions
Planifiez les migrations de manière à préserver l'intégrité des données et à permettre des retours en arrière.
- Migrations versionnées : Utilisez un framework de migrations (par ex. Doctrine Migrations, Phinx ou un outil interne) avec des scripts Up et Down clairement définis.
- Privilégier les changements additifs : Ajouter les nouvelles colonnes en nullable, créer les index en étapes séparées, effectuer les backfills de migration de façon asynchrone.
- Compatibilité ascendante : Déployez d'abord du code qui fonctionne à la fois avec l'ancien et le nouveau schéma. Ce n'est qu'après un déploiement réussi et le backfill que vous basculez vers le nouveau schéma et supprimez ultérieurement les fonctions legacy.
- Éviter les freins de schéma : Les longues opérations ALTER TABLE doivent être préparées sur des réplicas puis exécutées via des procédures contrôlées (pt-online-schema-change, gh‑ost).
Environnements de test et CI/CD
Un environnement de test reflétant la production est obligatoire.
- Copie complète de staging : Générer régulièrement à partir de snapshots de production, incluant le système de fichiers et la BD (prévoir le masquage des données sensibles).
- Exécutions automatisées des migrations : Exécuter chaque migration dans la CI contre le staging et automatiser les tests d'intégration ainsi que les tests smoke (flux de tracking, conversion, calcul des commissions, historique des paiements).
- Canary / Blue‑Green : Pour les releases majeures, un déploiement Canary (petite part de trafic) ou Blue‑Green est recommandé pour pouvoir revenir rapidement à l'environnement stable en cas d'erreur.
Procédures de rollback : étape par étape
Un plan de retour testé minimise les risques opérationnels.
- Préparation : Avant la mise en production, effectuer une sauvegarde complète + position du binlog ; définir une check‑list de release et les responsabilités.
- Prioriser les options de rollback :
- Retour à la version précédente de l’application (option la plus rapide) — si les migrations sont réversibles et n’ont pas été destructives.
- Restauration de la base de données à partir d’un snapshot — nécessaire si les migrations ont inclus des modifications irréversibles ou en cas de corruption des données.
- Étapes en cas d’erreur :
- Verrouiller les écritures ou passer en mode maintenance.
- Revenir à la version précédente de l’application.
- Si nécessaire, restaurer la BD depuis un snapshot et rejouer le binlog jusqu’à juste avant la modification fautive.
- Exécuter des smoke‑tests et, après validation, réautoriser les écritures.
- Communication : Informer proactivement les marchands et partenaires des impacts possibles sur le tracking et les paiements.
Processus d’upgrade pratique (exemple)
Processus concret pour une fenêtre de release normale :
- 72–48 heures avant : notes de release, plan de test, nomination des responsables.
- 24 heures avant : sauvegarde complète de la BD, archivage des binlogs, snapshot des fichiers webroot.
- Avant le déploiement : restauration sur staging depuis le snapshot et exécution des tests automatisés.
- Déploiement en canary/blue‑green : augmenter le trafic progressivement, monitoring pendant 30–60 minutes.
- Après la validation : effectuer les backfills asynchrones et la reconstruction des index, supprimer les anciens champs seulement après une période d’observation.
Monitoring, validation et gouvernance
Après chaque upgrade, des vérifications systématiques sont nécessaires :
- Smoke‑tests : générer un lien de tracking, simuler une conversion, vérifier le calcul des commissions, contrôler les écritures de paiement.
- Logs et métriques : surveiller les taux d’erreur, les latences, les longueurs des files d’attente et les requêtes lentes de la BD.
- Audit et journal des changements : documenter chaque migration et chaque rollback, y compris la référence de la sauvegarde et la position du binlog.
Responsabilités basées sur les rôles
Une répartition claire des tâches réduit les frictions :
- Opérateur logiciel : Assure l’automatisation des sauvegardes, la gestion des snapshots, le déploiement des upgrades et des rollbacks.
- Marchands : Planifient les campagnes autour des fenêtres de maintenance ; vérifient après la release les métriques des campagnes et les supports publicitaires.
- Partenaires/éditeurs : Vérifient les liens de tracking et l’historique des paiements après une release et signalent immédiatement toute anomalie.
Conclusion et prochaines étapes
Pour les installations Affilentra, la planification paie : des sauvegardes cohérentes, une stratégie de migration par paliers et des procédures de restauration testées réduisent les risques d’interruption et protègent les revenus. Commencez par trois mesures simples : sauvegardes quotidiennes de la base de données + archivage des binlogs, restauration sur un environnement de staging avant chaque publication et une checklist de rollback écrite.
Prêt pour l’étape suivante ? Choisissez votre point d’entrée et faites-vous conseiller sur les options de licence appropriées et les forfaits de support : Choisir un point d’entrée.
Étape suivante
Tester Affilentra vous‑même
Plateforme unifiée qui regroupe de manière transparente la mise à disposition des produits, le tracking, la validation des conversions, le calcul des commissions et les paiements selon des rôles clairement séparés ; option d’installation auto‑hébergée avec licence perpétuelle sans participation au chiffre d’affaires ; les commerçants conservent le contrôle sur les produits, les conditions et les supports publicitaires ; les partenaires reçoivent des liens de suivi personnels et un historique de paiements consultable.