Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Runbook Cutover
Come notato in precedenza, le migrazioni possono essere complesse, con molte parti mobili che comprendono hardware, software, persone, processi e organizzazione. Per garantire il successo, la coerenza e l'eventuale accelerazione, è essenziale un piano ben strutturato, documentato e concordato da tutte le parti interessate in tutte le fasi della migrazione. Tale piano può essere documentato utilizzando un runbook cutover.
Un cutover runbook copre tutte le attività che devono essere completate per una determinata migrazione. È una guida completa e dettagliata su quanto segue:
+ Attività
+ Cronologia pianificata
+ Timestamp delle attività effettive
+ Criteri di successo per ogni fase
+ Titolarità per ogni fase
Quando prepari il cutover runbook, poniti le seguenti domande e fornisci le risposte nel tuo piano.
| Domanda | Perché è importante |
| --- | --- |
| Il cutover necessita di un periodo di inattività? | I tempi di inattività prolungati influiranno sull'esperienza degli utenti. Quando preparate il vostro piano di cutover, cercate di ridurre al minimo i tempi di inattività dell'applicazione o del sistema. |
| È necessario sincronizzare i dati prima del cutover? | Se esegui la migrazione del livello di storage, ad esempio i volumi Amazon Elastic Block Store (Amazon EBS) o i bucket Amazon Simple Storage Service (Amazon S3) prima del cutover senza utilizzare un meccanismo di replica continua, il livello di storage potrebbe non essere sincronizzato. In questi casi, assicurati di eseguire una sincronizzazione finale dopo aver chiuso i servizi di origine ma prima di iniziare il cutover. |
| Chi deve essere a conoscenza del cutover pianificato? | Informa tutte le parti interessate e gli utenti sui tempi di inattività pianificati. |
| Vuoi suddividere la migrazione in parti più piccole o migrare tutto in una volta? | Se si esegue la migrazione di un sistema complicato, è opportuno suddividere la migrazione in fasi ed eseguire diversi passaggi. Ad esempio, è possibile migrare prima il livello di dati. |
| Avete bisogno del supporto di un fornitore esterno? | Potrebbe essere necessario contattare i fornitori esterni diverse settimane prima del termine previsto per assicurarne la disponibilità. Rivolgiti al fornitore per eventuali considerazioni relative alle licenze di cui sei a conoscenza. |
| Hai bisogno di un'approvazione speciale per qualsiasi parte del processo? | Ottenete le approvazioni necessarie qualche settimana prima del completamento previsto. |
# Modello di runbook Cutover
Un cutover runbook dovrebbe includere tutte le attività che verranno eseguite durante il cutover. Tuttavia, è altrettanto importante preparare un modello o una lista di controllo preliminare alla migrazione. Il modello deve includere le attività da completare prima della migrazione.
Entrambi i modelli (che possono essere uniti in un unico documento) dovrebbero fornire le risposte alle seguenti domande:
+ Quali attività devono essere svolte?
+ Chi svolgerà le attività?
+ Quando devono essere svolte le attività?
Questa sezione include un esempio di checklist di pre-migrazione, un modello di runbook cutover e un piano di rollback. Questo compito IDs aiuta a rendere la comunicazione più veloce ed efficace.
## Lista di controllo prima della migrazione
| ID attività | Attività | Dipendenza | Team | Owner | Data di completamento | Stato | Note |
| --- | --- | --- | --- | --- | --- | --- | --- |
| P1 | Documento sull'architettura di destinazione approvato. | | | | | | |
| P2 | Esiste un account Target per l'applicazione. | | | | | | |
| P3 | Esistono cloud privato virtuale (VPC) e sottoreti per l'applicazione. | | | | | | |
| P4 | Il team di migrazione ha accesso all'account dell'applicazione di destinazione e dispone delle autorizzazioni richieste AWS Identity and Access Management (IAM). | | | | | | |
| P5 | Il team dell'applicazione ha l'accesso necessario all'account dell'applicazione di destinazione e alle relative risorse. | | | | | | |
| P6 | Richiesta di modifica inviata e approvata. | | | | | | |
| P7 | La connettività tra l'ambiente di origine e quello di destinazione è stata stabilita e testata. | | | | | | |
| P8 | Elenco dei contatti del team di applicazione documentato. | | | | | | |
| P9 | Piano Cutover esaminato con le principali parti interessate. | | | | | | |
| P10 | Attività di backup precedenti alla migrazione completate. | | | | | | |
| P11 | Conferma se è necessario stabilire contatti di supporto aggiuntivi. | | | | | | |
| P12 | Conferma le risorse per ogni applicazione: chi avvierà e chiuderà ogni singola applicazione. | | | | | | |
| P13 | Piano finale rilasciato a tutte le squadre partecipanti. | | | | | | |
| P14 | Comunicazione di inizio Cutover rilasciata alle principali parti interessate. | | | | | | |
| P15 | È prevista una riunione retrospettiva post-Cutover. | | | | | | |
Altrettanto importante è documentare gli elementi precedenti in un registro delle emissioni per rimanere aggiornati o, se qualcosa va storto, riportare la situazione in ordine.
## Runbook Cutover
| ID dell'attività | Attività | Dipendenza | Team | Owner | Data/ora di inizio pianificata | Data/ora di fine pianificata | Data/ora di inizio effettiva | Data e ora di fine effettiva | Stato | Note |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| C1 | Invia una nota informativa a tutte le parti interessate informando che l'applicazione non sarà disponibile come specificato nel CR. | | | | | | | | | |
| C2 | Conferma il backup dei server e dei database di origine. | | | | | | | | | |
| C3 | Arresta l'applicazione e i servizi DB sui server di origine. | | | | | | | | | |
| C4 | Arresta i server di origine. | | | | | | | | | |
| | **Pietra miliare 1** **Attività pre-cutover completate** | | | | | | | | | |
| C5 | Esegui la migrazione in base al tuo approccio di migrazione (ad esempio AWS Application Migration Service per lift-and-shift). | | | | | | | | | |
| C6 | Verifica l'infrastruttura (server di destinazione attivi e funzionanti). | | | | | | | | | |
| | **Milestone 2** **Migrazione completata** | | | | | | | | | |
| C7 | Aggiorna i server DNS in modo che puntino agli endpoint appena creati. | | | | | | | | | |
| C8 | Verifica le modifiche al DNS. | | | | | | | | | |
| | **Milestone 3** **Attività successive alla migrazione: infrastruttura completata** | | | | | | | | | |
| C9 | Avvia l'applicazione e i servizi DB sui server di destinazione. | | | | | | | | | |
| C10 | Applica modifiche alla configurazione specifiche dell'applicazione (ad esempio, punta a nuovi indirizzi IP). | | | | | | | | | |
| | **Pietra miliare 3** **Attività successive alla migrazione: domande completate** | | | | | | | | | |
| C11 | Eseguire test delle applicazioni dopo la migrazione: verifica tecnica. | | | | | | | | | |
| C12 | Esegui test delle applicazioni dopo la migrazione: verifica aziendale | | | | | | | | | |
| C13 | Comunica a tutte le principali parti interessate che la migrazione è stata completata. | | | | | | | | | |
| | **Pietra miliare 4** **I test post-migrazione sono stati completati** | | | | | | | | | |
## Piano di rollback
| ID dell'attività | Attività | Dipendenza | Team | Owner | Stato | Note |
| --- | --- | --- | --- | --- | --- | --- |
| R1 | Arresta l'applicazione e i servizi DB sui server di destinazione. | | | | | |
| R2 | Arresta i server di destinazione. | | | | | |
| R3 | Ripristina l'aggiornamento sui server DNS (in modo che punti nuovamente ai server di origine). | | | | | |
| R4 | Verifica le modifiche al DNS. | | | | | |
| R5 | Avvia i server di origine. | | | | | |
| R6 | Sincronizza i dati con i server di origine (se necessario). | | | | | |
| R7 | Avvia l'applicazione e i servizi DB sui server di origine. | | | | | |
| R8 | Eseguire test delle applicazioni: verifica tecnica. | | | | | |
| R9 | Esegui test delle applicazioni dopo la migrazione: verifica aziendale. | | | | | |
| R10 | Comunica a tutte le principali parti interessate che la migrazione è stata annullata. | | | | | |
## Modello di esempio per la strategia di rehosting
Una delle strategie di migrazione di tipo R più comuni utilizzate sul campo è la strategia di rehosting, con Application Migration Service come strumento di migrazione preferito. È possibile utilizzare il [modello di esempio](samples/cutover-runbook_template.zip) come documento di base in uno scenario di rehosting. Il modello include le attività essenziali che sono state riscontrate durante le interazioni effettive con i clienti. Include anche spazio per consentire ai team applicativi di aggiungere i propri compiti e attività. I passaggi della sezione precedente possono fornire una guida iniziale per creare il proprio runbook cutover personalizzato, se necessario.