Quoi sauvegarder avant un déploiement
Le snapshot pré-déploiement inclut : l’ensemble des fichiers HTML générés (synchronisé vers le bucket de sauvegarde via rsync --checksum), le fichier de manifeste de build (qui liste toutes les URLs, leurs hashes et leurs dates), les fichiers de configuration du serveur (nginx, workers edge), et le dump de la base de données si des métadonnées de pages y sont stockées.
Les assets statiques (images, CSS, JS) ne sont pas inclus dans le snapshot car ils sont versionnés par leur hash dans le nom de fichier. Un rollback n’a pas besoin de restaurer les assets : les anciens assets restent accessibles sous leurs URLs historiques. Seuls les fichiers HTML et la configuration sont restaurés.
Procédure de rollback en moins de 5 minutes
La procédure de rollback est scriptée et ne nécessite pas d’accès manuel au serveur. Elle consiste à : (1) récupérer le snapshot du build précédent depuis le bucket, (2) synchroniser les fichiers HTML vers le serveur de production via rsync, (3) purger le cache CDN pour les URLs modifiées, (4) vérifier que la page d’accueil répond correctement. Ces quatre étapes prennent en moyenne 3 minutes 20 secondes sur notre infrastructure.
Un rollback déclenche automatiquement une alerte dans le canal de monitoring avec le timestamp, l’identité du déclencheur (humain ou automatique), et le build vers lequel on revient. Cette traçabilité est essentielle pour l’analyse post-incident : comprendre pourquoi un rollback a été nécessaire est aussi important que de l’exécuter rapidement.
Test mensuel du rollback en staging
La procédure de rollback est testée le premier lundi de chaque mois sur l’environnement de staging. Le test consiste à déployer un build de test, puis à exécuter la procédure de rollback vers le build précédent, et à vérifier que le résultat est identique à l’état initial. Ce test prend 15 minutes et son résultat est enregistré.
Un échec du test mensuel est traité comme une urgence : il signifie que la procédure de rollback est cassée et qu’un futur incident de production ne pourrait pas être résolu rapidement. La cause est identifiée et corrigée dans les 48 heures suivant le test échoué, indépendamment d’autres priorités.
Questions fréquentes
Les sauvegardes sont-elles chiffrées ?
Oui. Les snapshots sont chiffrés au repos avec AES-256 via la fonctionnalité de chiffrement côté serveur du bucket de stockage. Les clés de chiffrement sont gérées par le service de gestion de clés du fournisseur cloud, avec rotation annuelle automatique.
Combien de snapshots sont conservés ?
Les 10 derniers snapshots de déploiement sont conservés. Au-delà, les anciens snapshots sont supprimés automatiquement par une politique de rétention. En dehors des snapshots de déploiement, une sauvegarde hebdomadaire complète est conservée pendant 90 jours.