Modèle de runbook Cutover

Un manuel de transition doit inclure toutes les activités qui seront effectuées pendant la transition. Cependant, il est tout aussi important de préparer un modèle ou une liste de contrôle préalable à la migration. Le modèle doit inclure les activités à réaliser avant la migration.

Les deux modèles (qui peuvent être fusionnés en un seul document) devraient fournir les réponses aux questions suivantes :

• Quelles sont les activités à effectuer ?

• Qui va exécuter les activités ?

• Quand les activités doivent-elles être effectuées ?

Cette section inclut un exemple de liste de contrôle préalable à la migration, un modèle de runbook de transition et un plan de restauration. La tâche IDs contribue à rendre la communication plus rapide et plus efficace.

Liste de contrôle préalable à la migration

ID de tâche	Tâche	Dépendance	Equipe	Propriétaire	Date d'achèvement	Statut	Remarques
P1	Document d'architecture cible approuvé.
P2	Le compte cible pour l'application existe.
P3	Le cloud privé virtuel (VPC) et les sous-réseaux de l'application existent.
P4	L'équipe de migration a accès au compte de l'application cible et dispose des autorisations AWS Identity and Access Management (IAM) requises.
P5	L'équipe chargée de l'application dispose de l'accès nécessaire au compte de l'application cible et à ses ressources.
P6	Demande de modification émise et approuvée.
P7	La connectivité entre l'environnement source et cible a été établie et testée.
P8	Liste des contacts de l'équipe chargée de l'application documentée.
P9	Le plan de transition a été examiné avec les principales parties prenantes.
P10	Les activités de sauvegarde préalables à la migration sont terminées.
P11	Confirmez si des contacts d'assistance supplémentaires doivent être mis en place.
P12	Confirmez les ressources pour chaque application : qui démarrera et arrêtera chaque application individuelle.
P13	Le plan de transition final a été communiqué à toutes les équipes participantes.
P14	Communication d'ouverture du passage à l'intention des principales parties prenantes.
P15	Une réunion rétrospective est prévue après la transition.

Il est également important de documenter les points précédents dans un journal des problèmes pour rester sur la bonne voie ou, en cas de problème, pour le remettre sur la bonne voie.

Runbook Cutover

ID de tâche	Tâche	Dépendance	Equipe	Propriétaire	Date/heure de début prévue	Date/heure de fin prévues	Date/heure de début réelles	Date et heure de fin réelles	Statut	Remarques
C1	Envoyez une note d'information à toutes les parties prenantes les informant que l'application sera interrompue comme indiqué dans le CR.
C2	Confirmez la sauvegarde des serveurs et des bases de données sources.
C3	Arrêtez les services d'application et de base de données sur les serveurs sources.
C4	Arrêtez les serveurs sources.
	Étape 1 Activités menées avant le transfert
C5	Effectuez la migration en fonction de votre approche de migration (par exemple AWS Application Migration Service pour lift-and-shift).
C6	Vérifiez l'infrastructure (serveurs cibles opérationnels).
	Étape 2 Migration terminée
C7	Mettez à jour les serveurs DNS pour qu'ils pointent vers les points de terminaison nouvellement créés.
C8	Vérifiez les modifications du DNS.
	Étape 3 Activités après la migration — Infrastructure achevée
C9	Démarrez les services d'application et de base de données sur les serveurs cibles.
C10	Appliquez des modifications de configuration spécifiques à l'application (par exemple, pointez vers de nouvelles adresses IP).
	Étape 3 Activités après la migration — Demandes terminées
C11	Effectuer des tests d'applications après la migration — Vérification technique.
C12	Effectuer des tests d'applications après la migration — Vérification de l'activité
C13	Communiquez à toutes les principales parties prenantes que la migration est terminée.
	Étape 4 Tests après migration terminés

Plan de rétrogradation

ID de tâche	Tâche	Dépendance	Equipe	Propriétaire	Statut	Remarques
R1	Arrêtez les services d'application et de base de données sur les serveurs cibles.
R2	Arrêtez les serveurs cibles.
R3	Annulez la mise à jour sur les serveurs DNS (pour rediriger vers les serveurs sources).
R4	Vérifiez les modifications du DNS.
R5	Démarrez les serveurs sources.
R6	Synchronisez à nouveau les données avec les serveurs sources (si nécessaire).
R7	Démarrez les services d'application et de base de données sur les serveurs sources.
R8	Effectuer des tests d'applications — Vérification technique.
R9	Effectuez des tests d'applications après la migration — Vérification opérationnelle.
R10	Communiquez à toutes les principales parties prenantes que la migration a été annulée.

Exemple de modèle pour la stratégie de réhébergement

L'une des stratégies de migration de type R les plus couramment utilisées sur le terrain est la stratégie de réhébergement, avec Application Migration Service comme outil de migration de choix. Vous pouvez utiliser l'exemple de modèle comme document de référence dans un scénario de réhébergement. Le modèle intègre les activités essentielles rencontrées lors des engagements réels avec les clients. Il inclut également un espace permettant aux équipes d'application d'ajouter leurs tâches et activités. Les étapes décrites dans la section précédente peuvent fournir des conseils initiaux pour créer votre propre runbook personnalisé selon les besoins.