Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Planification des vagues
Un plan de vague est essentiellement un calendrier de migration, similaire aux autres activités de planification de projet. Nous vous recommandons d'utiliser les vagues de migration pour créer des groupes gérables, réduire les risques et organiser des activités autour de ces groupes.
Pour créer des plans de vague de migration efficaces et fiables, vous devez obtenir une vue complète du portefeuille d'applications, de l'infrastructure associée (calcul, stockage, réseaux), du mappage des dépendances et de la stratégie de migration.
Outre les applications métier, qui constituent une forme de regroupement d'un ensemble de composants logiciels et d'infrastructure, vous pouvez utiliser d'autres niveaux de groupe. Une vague est le niveau de groupe le plus élevé. Au sein d'une vague, vous pouvez créer des groupes de dépendances. Ce type de sous-groupe peut contenir plusieurs applications. Par exemple, deux applications ou plus doivent être migrées en même temps en raison de dépendances techniques, telles qu'une faible latence, ou d'autres facteurs. Ce groupe de dépendances est ensuite géré dans son ensemble. Plusieurs groupes de dépendance peuvent être affectés à une vague. Vous pouvez ensuite attribuer une date de migration à l'ensemble de la vague ou à des groupes de dépendances individuels au sein d'une vague. La date de migration est la date et l'heure auxquelles ce groupe sera arrêté à l'emplacement actuel et deviendra actif dans AWS.
Les vagues migratoires ont de multiples activités. Nous vous recommandons d'organiser la vague en phases et de définir une durée prévue pour chaque phase. Les phases ci-dessous servent d'exemple :
-
Conception : Dans cette phase de vague, la conception cible pour chaque application de la vague est confirmée et approuvée.
-
Planification de la transition : cette phase inclut la création ou l'itération de runbooks de transition et la planification de toutes les étapes nécessaires pour passer à l'application (y compris les scénarios de AWS restauration).
-
Pre-migration: Cette phase inclut les activités de déploiement dans la zone d'atterrissage, telles que le provisionnement des comptes, la configuration, les tests de prémigration, la configuration des outils de migration et la réplication des données.
-
Transition : cette phase correspond au moment où la migration proprement dite a lieu. Pendant ce temps, les applications sont arrêtées à leur emplacement actuel, les données sont synchronisées pour la dernière fois, des tests commerciaux sont effectués et la migration est finalisée. Cette phase inclut le transfert opérationnel.
-
Hypercare ou Post-migration: Cette phase est une période pendant laquelle les équipes de migration sont disponibles pour soutenir les opérations en cas de problème. Des optimisations peuvent également être appliquées selon les besoins.
-
Clôture de la vague : Au cours de cette phase, vous passez en revue les indicateurs et les leçons apprises et vous clôturez officiellement la vague.
Il n'y a pas de durée prédéfinie pour une vague de migration, et cela dépendra du niveau d'effort et de complexité. Nous recommandons de limiter les vagues de migration dans un délai de 6 à 10 semaines. Les cas où plus de temps est nécessaire, par exemple lors de la réécriture complète d'un composant d'application, sont généralement mieux gérés en dehors des vagues de migration.
Pour mesurer le succès et suivre les progrès, les vagues doivent être alignées sur les résultats et les moteurs commerciaux. Cela influencera également la durée des vagues et les groupes de dépendance qu'elles contiennent. L'achèvement d'une vague doit refléter un résultat mesurable.
Il existe plusieurs manières d'organiser les vagues migratoires. Le tableau suivant décrit les options d'organisation des vagues les plus courantes. Elles sont généralement combinées.
Type d'organisation Wave |
Description |
Avantages |
Inconvénients |
|---|---|---|---|
Par stratégie de migration ou par pile technologique |
Affectez à une vague des applications ayant une stratégie ou un modèle de migration commun. Par exemple, une vague contenant uniquement des applications de réhébergement. |
Des équipes dédiées par modèle ou par pile peuvent se voir attribuer des vagues entières. Durée homogène des activités. |
Nécessite une analyse plus approfondie des dépendances, en particulier pour les applications qui suivent des modèles différents. |
Par domaine d'activité |
Créez des vagues par domaine d'activité. Par exemple, une vague de gestion des commandes ou une vague de paiements. |
Données partagées généralement au sein d'un domaine donné. Implication constante de l'équipe. |
Risque accru en raison de l'impact sur l'ensemble du domaine d'activité. |
Par capacité technique |
Regroupez les applications qui utilisent une ou plusieurs fonctionnalités. Par exemple, une vague de calcul uniquement ou une onde d'équilibrage de charge basée sur le calcul et l'équilibrage de charge. |
Les migrations démarrent plus rapidement car les fonctionnalités techniques sont activées au fil du temps. Supprime la dépendance pour une zone d'atterrissage pleinement opérationnelle. |
Crée des poches de complexité lors des vagues ultérieures. |
Par environnement |
Une vague contient un environnement spécifique pour un ensemble d'applications. Par exemple, une vague de développement ou une vague de production. |
Non-production les vagues bénéficient de flexibilité lors de l'exécution. Réduction des risques liés à la migration de production. |
Nécessite de se concentrer sur l'analyse des dépendances afin d'éviter de perdre des dépendances absentes des environnements hors production. |
Par priorité commerciale |
Crée des groupes uniquement en fonction d'un critère de priorisation donné. |
Répond aux résultats commerciaux. |
Généralement, de nombreuses équipes sont impliquées ; difficile à coordonner. |
La section consacrée à l'établissement d'une base de référence pour le portefeuille d'applications décrit quatre catégories de dépendances techniques. Ces dépendances contribuent à la création de vagues de migration et à la définition de groupes de dépendance. Les groupes de dépendance seront déterminés en fonction de l'importance de la dépendance. En outre, les dépendances non techniques doivent être prises en compte. Par exemple, les calendriers de lancement des applications, les fenêtres de maintenance et les dates commerciales clés (telles que le traitement de fin de mois ou de fin de trimestre) peuvent influencer le plan de vague.
Déterminez si la dépendance est souple ou dure. Une dépendance souple est une relation entre deux actifs ou plus, ou entre un actif et une contrainte, qui ne dépend pas de l'emplacement des composants. Par exemple, deux systèmes fonctionnant sur le même réseau local (ou la même infrastructure) peuvent être séparés en déplaçant l'un de ces systèmes vers le cloud tandis que l'autre reste sur site. Une dépendance stricte est une relation entre deux actifs ou plus, ou entre un actif et une contrainte, qui dépend de l'emplacement. Par exemple, deux systèmes qui fonctionnent sur le même réseau local et qui sont fortement tributaires d'une faible latence pour la communication entre le serveur d'applications et le serveur de base de données ont une forte dépendance. Le transfert d'un seul de ces systèmes vers le cloud entraînerait des problèmes de fonctionnalité ou de performance impossibles à résoudre. De même, des raisons non techniques, telles que la disponibilité des ressources (telle que l'équipe chargée de la migration) ou des contraintes opérationnelles (telles que les fenêtres de maintenance où deux systèmes ne peuvent être migrés que dans un intervalle de temps donné), peuvent créer une forte dépendance pour ces actifs.
Pour créer un plan de vague de migration, déterminez vos groupes de dépendances en analysant les dépendances, idéalement à partir d'une source de données hautement fiable telle que des outils de découverte spécialisés. Combinez ces informations avec les critères de priorisation de vos applications et les circonstances opérationnelles.
Il est difficile de déterminer les dépendances techniques. Plusieurs points de données sont nécessaires, et aucune source de données ne les contient tous. Par exemple, bien que vous puissiez obtenir des informations de communication entre processus à l'aide d'outils de découverte, il est difficile de les classer en dépendances souples et strictes. La tolérance de latence est également difficile à déterminer à partir des seules données du réseau.
Les techniques suivantes peuvent vous aider à surmonter l'ambiguïté liée à la détermination des dépendances réelles :
-
Collectez toutes les données comme décrit dans la section sur les exigences en matière de données et tout autre point de données que vous avez jugé nécessaire.
-
Filtrez les informations de dépendance (ou les données de communication) et excluez les services partagés, tels qu'Active Directory, la sauvegarde et le suivi du trafic. Les services techniques partagés ont tendance à englober l'ensemble du champ d'application.
-
Classez toutes les informations. Le cas échéant, utilisez la fréquence du réseau et les volumes de transfert de données entre les composants.
-
Rencontrez les propriétaires d'applications, les architectes et les équipes de support. Discutez du type de connexion. Sont-ils synchrones ou asynchrones ? Connaissent-ils les exigences de latence minimale ? Quelles sont les connexions critiques et que se passe-t-il si elles ne sont pas disponibles ? Il vous manque des connexions importantes ? Tenez compte du fait que les traitements par lots peuvent se produire de façon sporadique et ne pas figurer dans l'ensemble de données.
-
Si votre outil de découverte fournit un graphique de données, recherchez des applications uniques qui relient de grands clusters d'applications. Ces points de connexion uniques peuvent aider à diviser les données en petits groupes.
AWS Transform peut vous aider à analyser les dépendances et à planifier les vagues.
Création d'un plan de vagues
Les données du portefeuille d'applications et l'évaluation détaillée du groupe d'applications qui seront migrées au cours de la vague sont des conditions préalables à la migration d'une vague d'applications. L'évaluation détaillée doit inclure la liste des applications incluses dans la vague, les détails de l'infrastructure associée, une conception cible et une stratégie de migration pour chaque application.
L'établissement de la propriété et de la gouvernance des vagues est essentiel pour gérer et suivre le travail des vagues, les dépendances entre les programmes, la gestion du changement, les problèmes et les risques. Assurez-vous qu'un cadre de gouvernance est en place pour gérer le plan.
Pour définir le plan de vagues, commencez par une construction de vague par défaut. Que se passe-t-il au sein d'une vague ? Une fois l'entrée initiale définie, la vague peut commencer. En règle générale, les activités seront les suivantes :
-
Affinez le plan de transition. Cette activité doit décrire les runbooks et les étapes à suivre au moment de la migration, y compris la coordination avec d'autres équipes internes et externes.
-
Affinez le plan de restauration. Que faut-il faire pour annuler les demandes en cas de problème ?
-
Préparez l'infrastructure cible. Par exemple, vous pouvez créer ou étendre la zone AWS d'atterrissage (sécuritéCompte AWS, mise en réseau, services d'infrastructure, autres infrastructures de support).
-
Testez l'infrastructure cible.
-
Utiliser les outils de migration. Par exemple, installez des agents de réplication et lancez le transfert de données.
-
Procédez à un plan de découpage et enregistrez des cycles de séchage. Regroupez tous les membres de l'équipe participants et passez en revue toutes les étapes à l'avance.
-
Surveillez la réplication des données et les déploiements d'infrastructures.
-
Confirmer l'état de préparation à l'exploitation de l'infrastructure et des applications dans AWS.
-
Vérifiez l'état de préparation en matière de sécurité
-
Confirmez les exigences réglementaires et de conformité (par exemple, validation de la charge de travail avant et après la migration), le cas échéant.
-
Migrez les applications vers AWS et effectuez des tests préalables à la mise en service.
-
Fournissez une assistance après la migration pendant une période, par exemple 3 jours, lorsque les équipes opérationnelles et les équipes de migration sont entièrement disponibles pour résoudre les problèmes et appliquer les optimisations.
-
Procéder à un examen après la migration. Documentez les leçons apprises et intégrez-les dans les futures vagues.
-
Clôturez la vague en confirmant le transfert opérationnel et en obtenant des indicateurs pour les rapports.
La durée de chacune de ces activités dépendra de la complexité de la portée, de la capacité des vagues, des personnes impliquées et de votre situation particulière. Dans la mesure du possible, des vagues plus petites sont préférables, car cela réduira l'impact des retards ou des blocages de migration. Déterminez, avec vos équipes, la durée par défaut d'une vague.
Procédez ensuite à l'analyse des dates pour créer une structure initiale de haut niveau composée de vagues vides (aucune application n'ayant encore été assignée). Posez-vous les questions suivantes :
-
Quelle est la durée totale du programme de migration ?
-
Quels sont les délais ?
-
Existe-t-il des dates de sortie fixes pour les centres de données ?
-
Existe-t-il des dates de fin de contrat de collocation ?
-
Quels sont les cycles d'actualisation des applications et de l'infrastructure ?
-
Quels sont les cycles de maintenance et de publication des applications ?
-
Y a-t-il des dates auxquelles les migrations devraient être évitées (par exemple, cycles de publication et de maintenance, fin d'année, vacances, traitement de fin de mois) ?
En tenant compte de ces considérations, tracez les vagues dans un plan. Pour accélérer le processus de migration, nous recommandons de superposer les vagues dans la mesure du possible. La clé du chevauchement des vagues est de définir et de prendre en compte ce qui se passe au sein d'une vague. Généralement, les activités de déploiement, la validation de l'infrastructure cible et la synchronisation des données ont lieu au cours de la première moitié d'une vague. Le second semestre se concentrera sur la migration proprement dite, les tests et le transfert opérationnel. Cela signifie que différentes équipes sont impliquées dans chaque moitié du processus et que vous pouvez gagner en efficacité. Par exemple, dès que l'équipe impliquée dans la préparation de l'infrastructure cible aura terminé son travail, elle pourra commencer à travailler sur les exigences de la prochaine vague. En général, il est préférable que la plupart des vagues aient une longueur et une structure similaires afin de faciliter une approche des migrations similaire à celle d'une usine. Cependant, au cours du processus de planification des vagues, la taille d'une vague donnée peut être étendue pour répondre aux dépendances ou aux exigences opérationnelles.
Ensuite, en fonction des groupes de dépendance identifiés, déterminez la taille maximale d'une vague en termes de nombre de groupes de dépendance qu'elle peut contenir. La taille des vagues est généralement dictée par l'appétit pour le risque (par exemple, dans quelle mesure les changements parallèles peuvent être tolérés) et par la disponibilité des ressources (par exemple, dans quelle mesure les changements parallèles peuvent être effectués avec les ressources, les compétences et le budget disponibles). Toutefois, lors de la planification initiale, ne vous limitez pas aux besoins en ressources et à la disponibilité. Les ondes contenant plusieurs groupes de dépendance peuvent être décomposées en vagues plus petites lors des prochaines itérations.
Une fois que les groupes de dépendance pour une vague donnée ont été confirmés, passez en revue les ressources nécessaires à la migration de la vague. Envisagez d'ajuster la taille de la vague (le nombre de groupes de dépendance qu'elle contient) en fonction des besoins en ressources. Cela peut entraîner des vagues plus ou moins grandes. Répétez le plan de vagues selon les besoins jusqu'à ce que toutes les vagues aient été définies. Envisagez de travailler avec des services AWS professionnels ou des partenaires de compétences en matière de AWS migration, qui peuvent fournir des spécialistes pour vous aider tout au long du processus.
Gérer le changement
Le portefeuille d'applications et l'infrastructure associée évolueront au cours du cycle de vie des programmes de migration. Long-running les programmes de migration coexistent avec l'évolution et le changement normaux des entreprises. Les applications continuent d'évoluer en attendant d'être migrées. Des serveurs sont ajoutés ou supprimés, une nouvelle infrastructure est déployée sur site. On s'attend à ce que la portée d'une vague ou d'un groupe de dépendance doive être modifiée. Des modifications sont nécessaires, en particulier lorsque, à l'approche de la date de migration, une dépendance précédemment inconnue est identifiée ou qu'un nouveau serveur est inclus dans l'inventaire. Cela peut parfois se produire pendant la migration elle-même.
Les modifications du champ d'application affectent les groupes de dépendance et les vagues. Pour gérer le changement et minimiser son impact, il est important de mettre en place un mécanisme de contrôle de la portée. Un mécanisme de contrôle des modifications du champ d'application nécessite la définition d'une source fiable unique pour le champ d'application. Il peut s'agir d'un outil de gestion du périmètre, d'un fichier .csv, d'une feuille de calcul ou d'une base de données, tel que défini par la gouvernance du programme de migration. Vous devez identifier les changements, analyser leur impact et communiquer les changements aux parties prenantes concernées afin qu'elles puissent prendre des mesures. Le plan de vagues sera donc itéré.
