Comment réussir une migration d’infrastructures sans (l)armes, ni haine, ni violence ?

TL;DR Avant de rentrer dans le vif du sujet, nous allons donner quelques éléments de contexte autour de la migration, notamment les cas les plus fréquents et quelques risques courants. Pour aller directement à la partie “guide” avec nos conseils, rendez-vous à la section “Oxeva : Méthode du Peuple Migrateur”. Avec plaisir ! 

La migration d’infrastructures est un exercice assez périlleux pour les entreprises où la moindre erreur ou le moindre oubli peuvent rapidement devenir très chronophages, coûteux et stressants. Autrement dit, le tiercé gagnant des projets à hauts risques. Même si la réalisation d’une migration reste assez peu fréquente à l’échelle d’une entreprise, les raisons qui nécessitent d’y avoir recours sont assez nombreuses :

• Une plateforme sous-dimensionnée ou surdimensionnée pour le niveau d’activité
• Une mise à jour de logiciels critiques ou stratégiques pour l’entreprise, nous pensons notamment à une montée de version de Magento ou Prestashop pour les sites e-commerce
• Un changement d’OS serveur arrivé en fin de vie
• Un changement d’hébergeur ou de prestataire informatique

Et ici nous n’évoquons que les cas les plus fréquents, il en existe pléthore. Tant et si bien qu’une entreprise devrait vivre au moins une fois dans sa vie une migration d’infrastructures et de données. Voici donc notre modeste contribution pour vous aider à aborder la migration un peu plus sereinement.

Connaître les risques pour mieux les éviter

Avoir conscience des risques liés à la migration de vos infrastructures ou de vos données constitue un premier pas vers l’identification d’erreurs à ne pas commettre pendant l’opération. Au fil des années, nous avons observé et identifié des erreurs récurrentes aux conséquences assez fâcheuses pour les entreprises. 

L’ancien site apparaît toujours 

Il s’agit d’un risque principalement pour les entreprises qui utilisent leur site internet pour réaliser des transactions financières, notamment les sites e-commerce ou les éditeurs de solutions SaaS.

Une situation généralement provoquée par une bascule des DNS mal anticipée. En conséquence, certains utilisateurs verront toujours l’ancienne version du site, même après la migration, et passeront commande dessus sans savoir qu’elles n’aboutiront jamais.

Pertes de données

Un cas assez classique de mauvaise surprise suite à une migration. Ici, l’erreur vient généralement d’une mauvaise préparation des données à migrer. Autrement dit, un oubli bête et méchant. 

Il existe un autre cas qui peut conduire non pas à une perte des données mais à une altération des données, notamment si vous passez d’un encodage ISO-8859-1 vers l’unicode UTF-8. Si le recensement des fichiers à convertir n’est pas méticuleusement réalisé vous aurez probablement des jolis “é” à la place de vos “é”. 

Indisponibilité totale

Le scénario catastrophe par excellence. S’il ne s’agit pas du cas le plus répandu, il est généralement dû à une erreur récurrente : celle de vouloir effectuer une migration en même temps qu’une montée de version. Les deux actions sont trop périlleuses individuellement pour envisager de les mener simultanément. 

Si, pour une raison X ou Y, vous devez mener les deux de front, passez du temps sur votre environnement de test pour sécuriser au maximum la démarche le jour J. Nous recommandons néanmoins d’effectuer la migration dans un premier temps et de gérer les évolutions ensuite.

Ralentissements

Il s’agit d’une variante du point précédent donc nous ne nous étendrons pas dessus. Les ralentissements sont généralement liés à des oublis, notamment de configurations précises comme des mises en cache. 

Oxeva : Méthode du peuple migrateur

Nous réalisons quasi-systématiquement les migrations de nos clients lorsqu’ils basculent leurs infrastructures chez nous. Une habitude que nous avons prise car, ayant un engagement de résultat sur la disponibilité des plateformes que nous hébergeons, nous préférons nous assurer que tout est fait dans les règles de l’art. Et comme l’expertise vient avec la pratique, nous avons développé une belle aisance sur le sujet. 

Pour nous faciliter la tâche nous avons mis au point, testé et éprouvé une méthode dont nous respectons scrupuleusement chaque étape. Rien d’extraordinaire en soi mais elle nous permet de sécuriser au maximum la démarche et de prévenir les oublis. La voici.

1. Découverte

À cette étape, l’enjeu est de recenser l’intégralité des éléments qui constituent la plateforme actuelle : les applications, les serveurs, les différentes versions des OS, les bases de données, la présence ou non de technologies “exotiques”, les configurations web ou encore la liste des sites hébergés.

Recommandation

Pour récupérer les configurations dites “usuelles” et gagner du temps à cette étape, nous utilisons des scripts maison réalisés avec Bash.

2. Vérification

Une fois ce recensement effectué, nous définissons les éléments qui doivent être migrés. Pour nous, l’un des maîtres-mots de la migration est la frugalité, tout n’a pas vocation à être migré. Plus vous réduisez le périmètre de la migration, mieux vous vous porterez. Pour parler plus directement, débarrassez-vous de ce qui ne sert à rien et qui n’a pas d’impact financier ou sur les performances. 

Recommandation  

Si vous souhaitez quand même conserver des éléments qui ne seront pas utiles pour la prochaine plateforme, ne les migrez pas, sauvegardez-les sur un support dédié, vous pourrez y accéder de nouveau plus tard si nécessaire.

3. Plan d’organisation

Le plan d’organisation permet de lister les étapes de la migration, y associer les responsabilités de chacun et le planning. Il ne s’agit pas d’une lubie procédurière mais plutôt d’un outil de transparence pour partager une vision d’ensemble du projet avec toutes les parties prenantes. Quelques étapes récurrentes : 

• Commande des serveurs
• Installation en datacenter
• Création de l’environnement :
  • Virtualisation
  • Stockage
  • Sauvegarde
  • Environnement applicatif (OS et autres composants logiciels)
• Migration des données
• Tests unitaires
• Dernière synchronisation des données avant bascule
• Bascule des DNS

Recommandation

Cette planification est indispensable pour nous. Elle peut aussi se révéler utile côté client pour organiser l’opérationnel, planifier la disponibilité de son personnel, désigner un responsable de la migration et anticiper sa charge de travail. 

4. Répétition 

Nous effectuons le dépôt de code et des bases de données sur l’environnement de test pour nous assurer qu’il n’y a pas d’erreur de conception dans la nouvelle plateforme, de compatibilité entre les différents éléments applicatifs et observer le comportement de l’environnement en effectuant une série de test dessus, par exemple :

• Test de l’interface administrateur
• Test des scripts horaires (Crontab)
• Test de montée en charge

Cette étape est cruciale puisqu’elle permet d’identifier ou de découvrir les problèmes sur un environnement de test et non sur la plateforme définitive. 

Recommandation

Le jour de la migration vous ne devez pas vous poser de question mais exécuter purement et simplement les opérations effectuées pendant l’étape de répétition.

5. Migration

La même chose qu’en répétition, sauf que ce n’est plus sur un environnement de test. Pour la migration nous utilisons des scripts Bash qui s’avèrent particulièrement utiles pour ce genre d’opération.

Recommandation

Pour que la bascule des DNS s’effectue correctement et éviter que l’ancienne version de votre site ou application ne s’affiche pour certains clients/utilisateurs, veillez à baisser les TTL du domaine au maximum. Les plus avertis d’entre vous pourront mettre en place un proxy redirigeant de l’ancienne plateforme à la nouvelle.

6. Optimisations

Même si l’opération a été globalement sécurisée sur l’environnement de test, il se peut qu’en “conditions réelles” la plateforme ne réagisse pas de la même manière. Même si le plus dur est fait, ne négligez pas les optimisations des infrastructures et des applicatifs pour améliorer les performances de votre site ou application.

Comme vous avez pu le constater, nous utilisons des solutions pour nous simplifier la vie comme Ansible ou des fonctions Bash. Nous utilisons également quelques outils développés en interne mais la vraie valeur ajoutée lors d’une migration, ce sont les êtres humains qui en ont la charge. Plus vous maîtrisez déjà le sujet, plus vos chances de succès seront grandes.

S’il peut paraître évident, ce protocole nous évite systématiquement les imprévus usuels des migrations et nous a permis de réduire drastiquement le temps passé sur l’opération. Aujourd’hui, une migration peut nous prendre au minimum 4H et au maximum plusieurs semaines, tout dépend évidemment du périmètre de la migration, de la complexité des sites, infrastructures et applications ou encore de la réactivité de nos interlocuteurs.