Changer d’hébergement : planifier les données et la bascule
Planifiez ensemble base de données, fichiers et écritures. Un plan concret distingue préparation, bascule et retour arrière après de nouvelles modifications.
Pour votre équipe, un changement d’hébergement est terminé lorsque le parcours convenu fonctionne au nouvel emplacement avec le bon état des données. Définissez à l’avance quand les modifications seront acceptées, qui autorise la bascule et dans quelles conditions l’équipe peut revenir en arrière.
Recenser le parcours et ses voies d’écriture
Dans cet exemple fictif, une entreprise exploite le portail client P-65. Un client crée la demande A-65 avec la pièce jointe F-65. Base de données et stockage des fichiers vont ensemble. Une interface et un processus en arrière-plan peuvent aussi modifier les données, en plus du navigateur. Toutes ces voies d’écriture doivent entrer dans le plan de transition.
L’exemple prévoit une pause des écritures annoncée. C’est un choix délibéré, pas une obligation pour toute migration. L’équipe termine les modifications en cours de manière contrôlée et consigne les travaux ouverts qui pourront continuer à destination. Transférer continuellement les nouvelles modifications serait une autre méthode, avec ses propres contrôles de synchronisation et de conflits.
Convenir d’une séquence de bascule
AWS recommande de documenter et de répéter dépendances, ordre des tâches, responsables, contrôles et retour avant le changement. Le modèle détaillé ci-dessous décrit des étapes prévues, pas les résultats d’une migration exécutée.
Phase | Accord dans l’exemple | Rôle responsable | Condition pour l’étape suivante |
|---|---|---|---|
Préparation | Vérifier la cible avec une copie cohérente de la base et des fichiers. | Équipe applicative | L’authentification et l’accès autorisé fonctionnent, l’accès non autorisé est refusé et le fichier associé s’ouvre dans le test isolé. |
Pause des écritures | Arrêter l’acceptation et le traitement de nouvelles modifications sur toutes les anciennes voies ; transférer le dernier état cohérent. | Exploitation et équipe applicative | Les travaux ouverts sont consignés ; base et fichiers correspondent. |
Autorisation | Ouvrir l’accès cible vérifié et accepter les modifications uniquement sur la nouvelle cible d’écriture prévue. | Responsables métier et exploitation | État de référence des données, accès et décision d’arrêt sont clairs. |
Distinguer arrêt et retour à l’avance
Microsoft recommande d’adapter les critères d’arrêt et les étapes de retour éprouvées à la charge de travail. Dans l’exemple, une pièce jointe manquante empêche déjà l’autorisation. Tant qu’aucune nouvelle modification n’a été acceptée à destination, un retour préparé vers l’ancien état resté inchangé peut convenir.
Après de nouvelles modifications à destination, rétablir l’adresse DNS ne suffit pas. Ces modifications peuvent manquer dans l’ancien système. Le retour exige alors un état de référence défini et une méthode vérifiée pour les modifications intermédiaires. Aucune voie d’écriture parallèle non coordonnée n’est ouverte entre-temps. Si l’équipe ne peut pas traiter ce cas de façon sûre, elle doit revoir le plan avant l’autorisation.
Terminer ensemble DNS et transition
Le TTL DNS décrit la mise en cache normale d’une réponse. Certains clients peuvent donc encore utiliser l’ancien accès. Son comportement doit correspondre à la pause des écritures ou au nouveau système de référence ; deux copies modifiables indépendamment ne constituent pas un changement terminé.
Vérifiez le parcours complet dans un environnement de test adapté : nouvelle demande, pièce jointe, rôles et travail en arrière-plan. Les actions externes y restent limitées à des cibles de test. Prévoyez aussi surveillance et contact responsable après autorisation. L’ancien service n’est retiré qu’une fois les conditions de fin et le dispositif de sauvegarde clarifiés.
Sources
À lire aussi
Tous les articles
Cloud & exploitation avec ASES
Hébergement, déploiement, maintenance et suivi