Plan de migration cloud : inventaire, ordre, test, retour
Un plan de migration cloud comprend quatre parties : inventaire, ordre de déménagement, environnement de test et retour arrière. Ce qui cause les pannes.
Équipe rabbitclipPublié: 7 min de lecture
En bref
Un plan de migration cloud consiste à faire l'inventaire du système actuel, à ordonner les éléments selon ce qui dépend de quoi, à tester chaque étape sans toucher au site en ligne, et à laisser une voie de retour vers l'ancienne organisation au cas où quelque chose tournerait mal. Si un plan manque de ces quatre étapes, le déménagement n'est pas une migration mais un pari. Le signe d'une migration réussie n'est pas la rapidité, mais le fait que les utilisateurs ne remarquent rien du tout.
La plupart des ennuis de migration ne viennent pas de la difficulté technique, mais d'un élément oublié : une tâche planifiée qui tourne sur l'ancien serveur, une règle de messagerie, ou un réglage que seule une personne connaissait. C'est pourquoi la partie la plus précieuse d'un plan n'est pas la liste des tâches à accomplir, mais un état des lieux honnête de ce qui existe.
Par où commencer : comment dresser un inventaire ?
Un inventaire est une liste écrite de tout ce qui sera déplacé : sites, applications, bases de données, stockage de fichiers, tâches planifiées, noms de domaine, certificats SSL, comptes de messagerie et connexions avec des services tiers. Pour chaque élément, vous notez à qui il appartient, son degré de criticité et ce dont il dépend.
La question qui fait le plus de travail à ce stade est : que se passe-t-il si cet élément s'arrête ? Si un formulaire de réservation s'arrête, du chiffre d'affaires est perdu ; si un outil interne de rapports s'arrête, un rapport arrive avec un jour de retard. Cette distinction décide de l'ordre du déménagement et de la durée d'interruption que vous pouvez accepter.
- Les sites, les applications et les bases de données qu'ils utilisent.
- Les tâches planifiées et les scripts qui tournent en arrière-plan.
- Les enregistrements de domaine, les réglages DNS et les certificats.
- Les comptes de messagerie et les redirections qui y sont attachées.
- Les connexions avec des services tiers comme les paiements, les cartes et les statistiques.
Dans quel ordre faut-il déplacer les éléments ?
La règle générale est de déplacer d'abord ce qui a peu de dépendances et peu de risque. Un environnement de test ou un outil interne convient à un premier essai, car une erreur coûte peu et l'équipe apprend le processus. Les systèmes qui touchent directement les clients viennent une fois la routine installée.
Les éléments qui dépendent les uns des autres doivent être pensés ensemble. Si une application et sa base de données tournent à des endroits différents, le délai entre les deux peut causer des problèmes de vitesse. C'est pourquoi déplacer un système en une seule étape, avec ses éléments associés, est souvent la voie la plus sûre.
Comment tester sans toucher au site en ligne ?
Un environnement de test est une copie construite sur la nouvelle infrastructure et pas encore ouverte aux utilisateurs. On prend une copie à jour de la base de données, on fait tourner l'application dans le nouvel environnement et on essaie à la main chaque parcours important : connexion, envoi de formulaire, paiement, notification par e-mail, téléversement de fichier.
Ensuite, on observe le comportement sous charge. Si le catalogue produits d'un fabricant de revêtements de sol reçoit beaucoup de visites le matin, cette charge doit aussi être simulée dans l'environnement de test. Les mesures de vitesse n'ont de sens pour comparer que si elles sont prises de la même façon avant et après le déménagement.
Enfin, on choisit l'heure de la bascule. Un déménagement fait dans la tranche la plus calme du trafic réduit l'effet de tout accroc. Comme les changements DNS mettent du temps à se propager, abaisser la valeur du TTL avant le déménagement est une étape préparatoire à part.
- Construire le nouvel environnement avec une copie à jour des données.
- Essayer à la main les parcours de connexion, de formulaire, de paiement et d'e-mail.
- Simuler le comportement à une heure de forte affluence.
- Mesurer la vitesse de la même façon avant et après le déménagement.
Pourquoi écrit-on d'abord le retour arrière ?
Un plan de retour arrière est l'exposé écrit des étapes qui vous ramènent à l'ancienne organisation, et du temps que cela prend, si quelque chose tourne mal pendant le déménagement. Il est préparé avant le déménagement, car il est difficile de réfléchir calmement une fois le problème arrivé. Maintenir l'ancien système en marche, inchangé, pendant un temps après le déménagement est le fondement de ce plan.
Une décision importante pour le retour arrière concerne l'endroit où les données sont écrites. Les commandes ou formulaires créés sur le nouveau système après le déménagement peuvent être perdus si vous revenez à l'ancien. On règle donc au préalable comment les données seront maintenues en phase pendant la fenêtre de migration, ou quand l'écriture sera gelée.
Quand passer au cloud est-il le mauvais choix ?
Si le système est petit, si le trafic est régulier et si l'hébergement actuel fonctionne sans problème, un déménagement n'apporte souvent aucun gain. L'effort du déménagement, la charge de gestion de la nouvelle organisation et le risque d'erreur demeurent, tandis que le bénéfice est incertain. Un déménagement a besoin d'une raison : une limite de capacité, un besoin de continuité ou un prestataire actuel insuffisant.
Déménager juste avant une grosse campagne ou une saison chargée est aussi un mauvais moment. Pour un groupe de spas, les semaines qui précèdent la ruée des réservations d'été sont une période où l'équipe n'aura pas le temps de corriger les problèmes. Placer le déménagement dans une période calme compte autant que le plan.
Quelles erreurs sont fréquentes lors d'une migration ?
L'erreur la plus courante est de sauter l'inventaire et de passer directement au déménagement. Un élément oublié se manifeste des jours après, à un moment que personne n'attendait. La deuxième erreur est de tester sur le site en ligne au lieu d'un environnement de test, ce qui fait de vos utilisateurs l'équipe de test.
La troisième erreur est d'éteindre l'ancien système juste après le déménagement. Un ancien système qui n'est pas maintenu en parallèle pendant un temps supprime la possibilité de revenir en arrière. La quatrième est de laisser le déménagement dans la connaissance d'une seule personne ; si le processus n'est pas écrit, personne ne peut prendre le relais quand cette personne est absente.
- Commencer à déménager sans inventaire.
- Tester sur le site en ligne plutôt que dans un environnement de test.
- Éteindre l'ancien système juste après le déménagement.
- Laisser le processus dans la mémoire d'une seule personne.
Un plan de migration cloud commence par un inventaire, s'ordonne selon les dépendances, se teste dans un environnement séparé et se sécurise par un retour arrière. Quand ces quatre étapes sont sautées, le risque de panne devient plus grand que le déménagement lui-même. Si vous souhaitez discuter de la question de savoir si votre système actuel mérite le cloud et de la manière de planifier le déménagement, vous pouvez prévoir un entretien de découverte avec rabbitclip.
Questions fréquentes
Combien de temps dure une migration cloud ?
Cela dépend de la taille du système, du nombre de dépendances et de l'étendue des tests. Un petit site peut déménager en un jour ou deux ; un système composé de nombreux éléments liés peut demander des semaines.
Le site sera-t-il en panne pendant le déménagement ?
Dans un déménagement bien planifié, les utilisateurs ne remarquent aucune panne. Le nouvel environnement est construit et testé à l'avance, et le changement DNS est fait à un moment où le trafic est faible.
Un plan de retour arrière est-il vraiment nécessaire ?
Oui. Il est difficile de décider calmement une fois le problème arrivé. Garder l'ancien système en marche pendant un temps et écrire les étapes du retour évite qu'un accroc ne devienne une crise.
Dois-je tout déplacer d'un coup ?
En général non. Commencer par les éléments à faible risque permet d'apprendre le processus et de repérer les erreurs à petite échelle. Les éléments étroitement liés doivent toutefois être déplacés ensemble.
