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.
# Runbook Cutover
Comme indiqué précédemment, les migrations peuvent être complexes et comporter de nombreux éléments mobiles qui concernent le matériel, les logiciels, les personnes, les processus et l'organisation. Pour garantir le succès, la cohérence et l'accélération éventuelle, un plan bien conçu, documenté et approuvé par toutes les parties prenantes est essentiel à toutes les étapes de la migration. Un tel plan peut être documenté à l'aide d'un runbook intégré.
Un runbook de transition couvre toutes les activités qui doivent être effectuées pour une migration donnée. Il s'agit d'un guide complet et détaillé sur les sujets suivants :
+ Activités
+ Chronologie planifiée
+ Horodatages des activités réelles
+ Critères de réussite pour chaque étape
+ Appropriation à chaque étape
Lorsque vous préparez le runbook de transition, posez-vous les questions suivantes et fournissez les réponses dans votre plan.
| Question | Pourquoi c'est important |
| --- | --- |
| La transition nécessite-t-elle un temps d'arrêt ? | Les interruptions de service prolongées auront un impact sur l'expérience de vos utilisateurs. Lorsque vous préparez votre plan de transition, essayez de minimiser le temps d'arrêt de votre application ou de votre système. |
| Devez-vous synchroniser les données avant le passage ? | Si vous migrez la couche de stockage, telle que les volumes Amazon Elastic Block Store (Amazon EBS) ou les compartiments Amazon Simple Storage Service (Amazon S3) avant le passage à un système de réplication continue, la couche de stockage risque de se désynchroniser. Dans ce cas, assurez-vous d'effectuer une dernière synchronisation après avoir arrêté les services sources, mais avant de commencer le transfert. |
| Qui doit être au courant du transfert prévu ? | Informez toutes les parties prenantes et les utilisateurs du temps d'arrêt prévu. |
| Voulez-vous diviser la migration en plusieurs parties ou tout migrer en une seule fois ? | Si vous migrez un système complexe, il est judicieux de scinder la migration en plusieurs phases et d'effectuer plusieurs transferts. Par exemple, vous pouvez d'abord migrer la couche de données. |
| Avez-vous besoin de l'assistance d'un fournisseur externe ? | Il se peut que vous deviez contacter les fournisseurs externes plusieurs semaines avant votre transition prévue pour vous assurer de leur disponibilité. Renseignez-vous auprès du fournisseur pour connaître les éventuels points à prendre en compte en matière de licence. |
| Avez-vous besoin d'une approbation spéciale pour une partie quelconque du processus ? | Obtenez toutes les approbations requises quelques semaines avant le passage prévu. |
# 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 Gestion des identités et des accès AWS (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](samples/cutover-runbook_template.zip) 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.