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à. # Pianificazione delle ondate In sostanza, un piano d'ondata è un programma di migrazione ed è simile ad altre attività di pianificazione dei progetti. Ti consigliamo di utilizzare *le ondate di migrazione* come mezzo per creare gruppi gestibili, ridurre i rischi e organizzare attività attorno a tali gruppi. Per creare piani di migrazione efficaci e altamente affidabili, è necessario ottenere una visione completa del portafoglio di applicazioni, dell'infrastruttura associata (elaborazione, archiviazione, reti), della mappatura delle dipendenze e della strategia di migrazione. Oltre alle *applicazioni aziendali*, che sono una forma di raggruppamento di una raccolta di componenti software e infrastrutturali, è possibile utilizzare altri livelli di gruppo. Un'*onda* è il livello di gruppo più alto. All'interno di un'ondata, è possibile creare *gruppi di dipendenze*. Questo tipo di sottogruppo può contenere più di un'applicazione. Ad esempio, due o più applicazioni che devono essere migrate contemporaneamente a causa di dipendenze tecniche, come la bassa latenza o altri fattori. Quindi quel gruppo di dipendenze viene gestito nel suo insieme. È possibile assegnare più gruppi di dipendenze a un'ondata. Successivamente, è possibile assegnare una data di migrazione all'intera ondata o ai singoli gruppi di dipendenze all'interno di un'ondata. La data di migrazione è la data e l'ora in cui il gruppo verrà fermato nella posizione corrente e reso attivo in. AWS Le ondate migratorie hanno molteplici attività. Ti consigliamo di organizzare l'ondata in fasi e di impostare una durata prevista per ogni fase. Le fasi seguenti servono da esempio: + **Progettazione**: in questa fase d'onda, viene confermato e approvato il progetto target per ogni applicazione inclusa nell'ondata. + **Pianificazione** del **cutover**: questa fase ondata include la creazione o l'iterazione di runbook cutover e la pianificazione di tutte le fasi necessarie per passare all'applicazione AWS (compresi gli scenari di rollback). + **Pre-migration**: Questa fase include le attività di implementazione delle landing zone, come il provisioning degli account, la configurazione, i test di premigrazione, la configurazione degli strumenti di migrazione e la replica dei dati. + **Cutover**: questa fase è quella in cui avviene la migrazione effettiva. Durante questo periodo, le applicazioni vengono interrotte nella posizione corrente, i dati vengono sincronizzati per l'ultima volta, vengono eseguiti test aziendali e la migrazione è completata. Questa fase include il trasferimento operativo. + **Hypercare** o **Post-migration**: questa fase è un periodo di tempo in cui i team di migrazione sono disponibili per supportare le operazioni in caso di problemi. Inoltre, le ottimizzazioni possono essere applicate secondo necessità. + **Chiusura dell'ondata**: in questa fase, si esaminano le metriche e le lezioni apprese e si chiude formalmente l'ondata. Non esiste una durata predefinita per un'ondata di migrazione e dipenderà dal livello di impegno e complessità. Consigliamo di mantenere le ondate di migrazione entro 6-10 settimane. I casi in cui è necessario più tempo, ad esempio quando si riscrive completamente un componente dell'applicazione, in genere vengono gestiti meglio al di fuori delle ondate di migrazione. Per misurare il successo e tenere traccia dei progressi, le ondate devono essere allineate ai risultati e ai fattori di business. Ciò influirà anche sulla durata dell'onda e sui gruppi di dipendenza contenuti in un'onda. Il completamento di un'ondata dovrebbe riflettere un risultato misurabile. Esistono diversi modi per organizzare le ondate migratorie. La tabella seguente descrive le opzioni di organizzazione delle ondate più comuni. Di solito sono combinate. | | | Tipo di organizzazione dell'onda | Description | Pro | Contro | | --- |--- |--- |--- | | Per strategia di migrazione o stack tecnologico | Assegna applicazioni con una strategia o un modello di migrazione comune a un'ondata. Ad esempio, un'ondata contenente solo applicazioni di rehosting. | A team dedicati per pattern o stack possono essere assegnate intere ondate.
Durata omogenea delle attività. | Richiede una maggiore analisi delle dipendenze, in particolare per le applicazioni che seguono modelli diversi. | | Per dominio aziendale | Crea ondate per dominio aziendale. Ad esempio, un'ondata di gestione degli ordini o un'ondata di pagamenti. | Dati condivisi in genere all'interno di un determinato dominio.
Coinvolgimento costante del team. | Aumento del rischio dovuto all'impatto sull'intero dominio aziendale. | | Per capacità tecnica | Raggruppa le applicazioni che utilizzano una o più funzionalità. Ad esempio, un'onda di sola elaborazione o un'onda di bilanciamento del carico di calcolo \+. | Le migrazioni iniziano più rapidamente man mano che le funzionalità tecniche vengono abilitate nel tempo. Elimina la dipendenza per una landing zone completamente operativa. | Crea sacche di complessità nelle ondate successive. | | Per ambiente | Un'onda contiene un ambiente specifico per un insieme di applicazioni. Ad esempio, un'ondata di sviluppo o un'ondata di produzione. | Non-production le onde traggono vantaggio dalla flessibilità durante l'esecuzione.
Riduzione del rischio di migrazione della produzione. | Richiede un'attenzione particolare all'analisi delle dipendenze per evitare la mancanza di dipendenze non presenti negli ambienti non di produzione. | | Per priorità aziendale | Crea gruppi esclusivamente in base a determinati criteri di prioritizzazione. | Risolve i risultati aziendali. | In genere sono coinvolti molti team; difficile da coordinare. | La sezione sulla [definizione di una linea di base per il portafoglio di applicazioni](baseline-application-portfolio.md) descriveva quattro categorie di dipendenze tecniche. Queste dipendenze contribuiscono alla creazione di ondate migratorie e alla definizione dei gruppi di dipendenza. I gruppi di dipendenza saranno determinati dalla criticità della dipendenza. Inoltre, devono essere prese in considerazione le dipendenze non tecniche. Ad esempio, le pianificazioni dei rilasci delle applicazioni, le finestre di manutenzione e le date aziendali chiave (ad esempio l'elaborazione di fine mese o di fine trimestre) potrebbero influenzare il piano d'ondata. Determina se la dipendenza è *morbida* o *rigida*. Una dipendenza morbida è una relazione tra due o più asset, o tra una risorsa e un vincolo, che non dipende dalla posizione dei componenti. Ad esempio, due sistemi che operano nella stessa rete locale (o nella stessa infrastruttura) possono essere separati spostando uno di questi sistemi nel cloud mentre l'altro rimane in sede. Una forte dipendenza è una relazione tra due o più risorse, o da una risorsa a un vincolo, che dipende dalla posizione. Ad esempio, due sistemi che operano nella stessa rete locale e che dipendono fortemente dalla bassa latenza per la comunicazione tra il server delle applicazioni e il server del database hanno una forte dipendenza. Lo spostamento di uno solo di questi sistemi nel cloud causerebbe problemi di funzionalità o prestazioni che non possono essere risolti. Allo stesso modo, ragioni non tecniche, come la disponibilità delle risorse (ad esempio il team che esegue la migrazione) o vincoli operativi (come le finestre di manutenzione in cui è possibile migrare due sistemi solo in una determinata finestra temporale), potrebbero creare una forte dipendenza per queste risorse. Per creare un piano basato sulle ondate di migrazione, stabilite i gruppi di dipendenze analizzando le dipendenze, preferibilmente da una fonte di dati altamente affidabile come strumenti di scoperta specializzati. Combinate queste informazioni con i criteri di prioritizzazione delle applicazioni e le circostanze operative. Determinare le dipendenze tecniche è difficile. Sono necessari diversi punti dati e nessuna fonte di dati li contiene tutti. Ad esempio, sebbene sia possibile ottenere informazioni sulla comunicazione da processo a processo utilizzando Discovery Tooling, è difficile classificarle in dipendenze morbide e rigide. La tolleranza alla latenza è inoltre difficile da determinare sulla base dei soli dati di rete. Le seguenti tecniche possono aiutarvi a gestire l'ambiguità legata alla determinazione delle dipendenze reali: + Raccogli tutti i dati come descritto nella [sezione sui requisiti dei dati](understanding-complete-assessment-data-requirements.md) e tutti gli altri punti dati che ritieni necessari. + Filtra le informazioni sulle dipendenze (o i dati di comunicazione) ed escludi i servizi condivisi, come Active Directory, il backup e il monitoraggio del traffico. I servizi tecnici condivisi tendono a integrare l'intero ambito. + Classificate tutte le informazioni. Se disponibili, utilizzate la frequenza di rete e i volumi di trasferimento dati tra i componenti. + Incontra i proprietari delle applicazioni, gli architetti e i team di supporto. Discutete il tipo di connessioni. Sono sincrone o asincrone? Sono a conoscenza dei requisiti minimi di latenza? Quali sono le connessioni critiche e cosa succede se non sono disponibili? Ti mancano connessioni importanti? Considerate che i processi in batch potrebbero verificarsi sporadicamente e mancare nel set di dati. + Se il tuo strumento di scoperta fornisce un grafico di dati, cerca app singole che collegano grandi cluster di applicazioni. Questi punti di connessione singoli possono aiutare a suddividere i dati in gruppi più piccoli. [AWS Transform](https://docs.aws.amazon.com/transform/latest/userguide/what-is-service.html) può aiutarti ad analizzare le dipendenze ed eseguire la pianificazione delle ondate. ## Creazione di un piano ondulatorio Un prerequisito per la migrazione di un'ondata di applicazioni è costituito dai dati del portafoglio di applicazioni e dalla valutazione dettagliata delle applicazioni del gruppo di applicazioni che verranno migrate nell'ambito di tale ondata. La valutazione dettagliata dovrebbe includere l'elenco delle applicazioni incluse nell'ondata, i dettagli dell'infrastruttura associata, una progettazione degli obiettivi e una strategia di migrazione per ciascuna applicazione.  Stabilire la titolarità e la governance di Wave è fondamentale per gestire e monitorare l'ondata di lavoro, le dipendenze tra i programmi, la gestione delle modifiche, i problemi e i rischi. Assicurati che sia in atto un quadro di governance per gestire il piano. Per delineare il piano ondulatorio, inizia con un costrutto d'onda predefinito. Cosa succede all'interno di un'onda? Dopo aver definito l'ingresso iniziale, l'onda può iniziare. In genere, le attività saranno:  1. Perfeziona il piano di cutover. Questa attività dovrebbe delineare i manuali e le misure da adottare al momento della migrazione, compreso il coordinamento con altri team interni ed esterni. 1. Perfeziona il piano di rollback. Cosa si deve fare per ripristinare le applicazioni se le cose vanno male? 1. Prepara l'infrastruttura di destinazione. Ad esempio, è possibile creare o estendere la AWS landing zone (sicurezza Account AWS, rete, servizi di infrastruttura, altre infrastrutture di supporto). 1. Esegui il test dell'infrastruttura di destinazione. 1. Utilizza gli strumenti di migrazione. Ad esempio, installa gli agenti di replica e avvia il trasferimento dei dati. 1. Esegui un piano Cutover ed esegui le esecuzioni a secco. Raggruppa tutti i membri del team partecipanti e rivedi tutti i passaggi in anticipo. 1. Monitora la replica dei dati e le implementazioni dell'infrastruttura. 1. Conferma la disponibilità per il funzionamento dell'infrastruttura e delle applicazioni in. AWS 1. Conferma la disponibilità alla sicurezza. 1. Conferma la conformità e i requisiti normativi (ad esempio, la convalida del carico di lavoro prima e dopo la migrazione), se applicabile. 1. Migra le applicazioni AWS ed esegui i test prima del lancio. 1. Fornisci supporto post-migrazione per un periodo di tempo, ad esempio 3 giorni, in cui i team operativi e i team di migrazione sono completamente disponibili per risolvere i problemi e applicare le ottimizzazioni. 1. Effettua una revisione successiva alla migrazione. Documenta le lezioni apprese e incorporale nelle ondate future. 1. Esegui la chiusura dell'ondata confermando il passaggio di consegne operative e ottenendo le metriche per la reportistica. La durata di ciascuna di queste attività dipenderà dalla complessità dell'ambito, dalla capacità delle onde, dalle persone coinvolte e dalle circostanze specifiche. Ove possibile, sono preferibili onde più piccole perché ciò ridurrà l'impatto di eventuali ritardi o ostacoli alla migrazione. Stabilite, insieme ai vostri team, quale sarà la durata predefinita di un'ondata. Successivamente, procedi con l'analisi delle date per creare una struttura iniziale di alto livello di onde vuote (senza ancora assegnare alcuna applicazione). Considerate le seguenti domande: + Qual è la durata totale del programma di migrazione?  + Quali sono le scadenze? + Esistono date di uscita fisse per i data di uscita dal data center?  + Esistono date di scadenza del contratto di collocazione?  + Quali sono i cicli di aggiornamento delle applicazioni e dell'infrastruttura?  + Quali sono i cicli di manutenzione e rilascio delle applicazioni?  + Esistono date in cui è necessario evitare le migrazioni (ad esempio, cicli di rilascio e manutenzione, fine anno, festività, elaborazione di fine mese)? Con queste considerazioni, traccia le onde in un piano. Per accelerare il processo di migrazione, consigliamo di sovrapporre le onde ove possibile. La chiave per la sovrapposizione delle onde è definire e considerare cosa succede all'interno di un'onda. In genere, le attività di implementazione, la convalida dell'infrastruttura di destinazione e la sincronizzazione dei dati avverranno durante la prima metà di un'ondata. La seconda metà si concentrerà sulla migrazione effettiva, sui test e sul passaggio di consegne operative. Ciò significa che team diversi sono coinvolti in ciascuna metà del processo e che è possibile aumentare l'efficienza. Ad esempio, non appena il team coinvolto nella preparazione dell'infrastruttura target ha completato il proprio lavoro, può iniziare a lavorare sui requisiti della fase successiva. In generale, è preferibile che la maggior parte delle onde abbia una lunghezza e una struttura simili per facilitare un approccio di fabbrica alle migrazioni. Tuttavia, durante il processo di pianificazione delle onde, la dimensione di una determinata onda può essere estesa per soddisfare dipendenze o requisiti operativi.  Successivamente, in base ai gruppi di dipendenza che sono stati identificati, determina la dimensione massima di un'onda in termini di numero di gruppi di dipendenza che può contenere. La dimensione delle onde è in genere dettata dalla propensione al rischio (ad esempio, quanto cambiamento parallelo può essere tollerato) e dalla disponibilità delle risorse (ad esempio, quante modifiche parallele possono essere eseguite con le risorse, le competenze e il budget disponibili). Tuttavia, durante la pianificazione precoce, non lasciatevi limitare dai requisiti e dalla disponibilità delle risorse. Le onde che contengono più di un gruppo di dipendenze possono essere scomposte in onde più piccole nelle iterazioni future. Dopo la conferma dei gruppi di dipendenza per una determinata ondata, esamina i requisiti di risorse per la migrazione dell'ondata. Valuta la possibilità di modificare la dimensione dell'onda (il numero di gruppi di dipendenze che contiene) in base ai requisiti di risorse. Ciò potrebbe portare a onde più piccole o più grandi. Iterate il piano d'onda secondo necessità fino a definire tutte le onde. Prendi in considerazione la possibilità di collaborare con AWS Professional Services o AWS Migration Competency Partners, che possono fornire specialisti in grado di assisterti durante tutto il processo. ## Gestire il cambiamento Il portafoglio di applicazioni e l'infrastruttura associata cambieranno durante il ciclo di vita dei programmi di migrazione. Long-running i programmi di migrazione coesistono con la normale evoluzione e cambiamento aziendale. Le applicazioni continuano a evolversi in attesa di essere migrate. I server vengono aggiunti o rimossi, la nuova infrastruttura viene implementata in locale. Si prevede che l'ambito di un'ondata o di un gruppo di dipendenza richieda modifiche. Le modifiche sono necessarie soprattutto quando, in prossimità della data di migrazione, viene identificata una dipendenza precedentemente sconosciuta o viene incluso un nuovo server nell'inventario. A volte ciò può accadere durante la migrazione stessa. Le modifiche all'ambito influiscono sui gruppi e sulle ondate di dipendenza. Per gestire il cambiamento e ridurre al minimo l'impatto, è importante stabilire un meccanismo di controllo dell'ambito. Un meccanismo di controllo della modifica dell'ambito richiede la definizione di un'unica fonte di verità per l'ambito. Potrebbe trattarsi di uno strumento per la gestione dell'ambito o di un file.csv, foglio di calcolo o database, come definito dalla governance del programma di migrazione. È necessario identificare le modifiche, analizzare l'impatto e comunicare le modifiche alle parti interessate in modo che possano agire. Di conseguenza, il piano d'ondata verrà iterato.