Valutare i carichi di lavoro per la migrazione cloud

La fase di valutazione garantisce la visibilità completa di ogni componente, dipendenza e requisito prima di passare ad Azure. Raccogliendo informazioni dettagliate sull'architettura, le prestazioni, la sicurezza, il codice e i database, è possibile prevedere problemi, ridurre al minimo i rischi e prendere decisioni informate sulla migrazione.

Valutare l'architettura del carico di lavoro

La valutazione completa dell'architettura offre visibilità su tutti i componenti del carico di lavoro e su come interagiscono. Ciò supporta una pianificazione accurata della migrazione identificando le necessità di spostarsi insieme e ciò che potrebbe richiedere modifiche.

1. Usare gli strumenti di valutazione. Strumenti come Azure Migrate o altri prodotti automatizzano l'individuazione dei componenti e delle configurazioni del carico di lavoro. Questi strumenti riducono il lavoro manuale e forniscono una raccolta dati coerente nel tuo ambiente, sebbene potrebbero perdere dipendenze non documentate. È possibile usare uno strumento come Cloudockit per generare i diagrammi. È anche possibile crearne di personalizzati usando le icone di Azure o modificando i diagrammi scaricabili nel Centro architetture di Azure.

2. Validare l'architettura con esperti del settore. I proprietari del carico di lavoro possono confermare i risultati dello strumento e identificare le informazioni mancanti o obsolete. Condurre interviste o sessioni di revisione dell'architettura per colmare le lacune nei dati di individuazione automatizzati.

3. Architettura del documento. Archiviare diagrammi dell'architettura, elenchi di componenti e dati di configurazione in un formato che supporta la pianificazione e la convalida. Usare strumenti come Microsoft Visio, fogli di calcolo o wiki di Azure DevOps per la gestione di queste informazioni.

Valutare i componenti del carico di lavoro

Per ogni carico di lavoro, raccogliere metriche dettagliate sulle prestazioni di base e sull'utilizzo dall'ambiente corrente. Questi dati sono fondamentali per il dimensionamento corretto delle risorse di Azure e per il confronto delle prestazioni dopo la migrazione

1. Raccogliere le metriche del carico di lavoro. Tenere traccia dell'utilizzo della CPU, dell'utilizzo della memoria, dell'I/O del disco (letture/scritture, operazioni di I/O al secondo), velocità effettiva di rete e picco di concorrenza o carico utente. Identificare i picchi giornalieri o settimanali per comprendere le esigenze di capacità. Misurare i tempi di risposta medi per le transazioni utente, la velocità effettiva dei processi elaborati all'ora e le metriche correlate al contratto di servizio. Ciò consente di garantire che i carichi di lavoro migrati soddisfino gli stessi requisiti di prestazioni aziendali.

2. Acquisire dettagli di configurazione. Si notino le configurazioni di ridimensionamento, le dimensioni correnti delle macchine virtuali o le specifiche del server fisico (core CPU, RAM), il tipo di sistema operativo e la versione, il tipo di archiviazione (SSD/HDD) e la capacità e qualsiasi hardware speciale come GPU. Questi dettagli forniscono informazioni sulla scelta delle dimensioni delle macchine virtuali di Azure o dei servizi PaaS. Registrare anche le informazioni sulle licenze software, in quanto ciò potrebbe abilitare l'uso del vantaggio Azure Hybrid o richiedere la migrazione delle licenze.

3. Documentare tutte le configurazioni di sicurezza e identità. Inventario di tutte le configurazioni di sicurezza e identità: elencare gli account del servizio, le credenziali hardcoded, i metodi di crittografia usati e le regole del firewall. Queste configurazioni devono essere replicate o modificate in Azure.

   Componente di sicurezza	Action	Purpose
   Inventario delle identità	Registrare tutti gli account di servizio, gli account utente e le chiavi API usate da applicazioni per l'autenticazione	Influisce sull'ordine della migrazione quando si sceglie tra l'approccio lift-and-shift o quello della modernizzazione.
   Documentazione sulla crittografia	Documentare i metodi di crittografia correnti per i dati inattivi e in transito	Eseguire il mapping di questi requisiti ai servizi di crittografia di Azure per mantenere gli standard di sicurezza
   Configurazione della sicurezza di rete	Acquisire regole di sicurezza di rete, configurazioni del firewall ed elenchi di controllo di accesso	Usare queste informazioni per progettare gruppi di sicurezza di rete di Azure e criteri di accesso

4. Identificare i problemi di compatibilità. Gli strumenti automatizzati forniscono un'analisi sistematica dei sistemi operativi, del middleware e dei framework applicazione rispetto ai criteri di supporto di Azure. Questi strumenti contrassegnano i componenti non supportati, deprecati o che si avvicinano alla fine del supporto. Strumenti come Azure Migrate e altri strumenti di valutazione possono rilevare questi problemi nell'ambiente senza revisioni manuali della configurazione.

5. Elencare le correzioni necessarie. Creare un elenco completo di tutti i problemi di compatibilità e dei relativi requisiti di correzione. Assegnare la priorità a quelle che devono essere risolte prima della migrazione (bloccanti) e a quelle che potrebbero essere eseguite dopo la migrazione, se necessario. Contattare i fornitori, se necessario, per comprendere i percorsi di aggiornamento per il software commerciale.

Eseguire il mapping delle dipendenze interne ed esterne

1. Mappare le dipendenze interne. Mappare come i componenti di un carico di lavoro comunicano tra loro e con altri sistemi all'interno dell'organizzazione. Usare gli strumenti di monitoraggio di rete o il monitoraggio delle prestazioni delle applicazioni per visualizzare le connessioni di runtime tra i servizi. Questo mapping consente di determinare il raggruppamento nelle onde della migrazione. Ad esempio, se l'app A chiama costantemente database B, è possibile eseguirne la migrazione insieme o fornire la connettività di rete tra Azure e l'ambiente di origine fino a quando entrambi non si trovano nel cloud.

2. Identificare tutte le dipendenze esterne. Elencare tutti i servizi esterni con cui interagisce il carico di lavoro. Queste dipendenze includono piattaforme SaaS, API partner, sistemi locali e servizi di terze parti che le applicazioni richiedono il corretto funzionamento. È necessario catalogare tutte le integrazioni upstream e downstream, i servizi condivisi e le pipeline di dati per comprendere il panorama completo delle dipendenze. API documento, sistemi di messaggistica, processi ETL, database condivisi, metodi di autenticazione, modelli di scambio di dati e contratti di servizio. Esaminare la documentazione di integrazione e condurre interviste con i proprietari delle applicazioni per garantire una visibilità completa su tutte le connessioni esterne. Questo mapping completo impedisce gli errori di integrazione e supporta la sequenziazione accurata della migrazione.

3. Coinvolgere i proprietari del carico di lavoro per convalidare e completare i dati delle dipendenze. I proprietari del carico di lavoro offrono informazioni critiche sul comportamento del sistema, sulle risorse condivise e sulle integrazioni informali che gli strumenti potrebbero non rilevare. È necessario condurre colloqui strutturati o workshop con i proprietari di applicazioni e carichi di lavoro per convalidare i dati generati dagli strumenti e identificare le dipendenze non documentate. Questo passaggio garantisce completezza e accuratezza della mappa delle dipendenze e consente di acquisire il contesto aziendale che informa la sequenziazione della migrazione.

4. Documentare tutte le dipendenze in un repository centrale. Archiviare i dati delle dipendenze in un formato che supporta la collaborazione tra team e la pianificazione della migrazione, ad esempio fogli di calcolo, diagrammi di architettura o strumenti di mapping delle dipendenze. Assicurarsi che il repository sia accessibile e aggiornato regolarmente per riflettere le modifiche durante il processo di migrazione.

5. Usare le dipendenze per pianificare le migrazioni. Organizzare i carichi di lavoro in onde di migrazione che riducono al minimo le dipendenze interrotte. Per altre informazioni, vedere Pianificazione delle onde della migrazione.

Valutare i requisiti operativi e di conformità

1. Identificare i requisiti di conformità alle normative. Una chiara comprensione dei requisiti di conformità alle normative garantisce che l'architettura di Azure sia allineata agli obblighi legali, del settore e dell'organizzazione. Questi requisiti influiscono sulla selezione dell'area, sulla disponibilità del servizio, sulla protezione dei dati e sulle decisioni relative all'architettura. Gli standard normativi e di conformità includono criteri globali, regionali, specifici del settore e interni. Questi standard possono includere GDPR, HIPAA, FedRAMP, ISO 27001 o normative finanziarie come SOX. Ogni standard impone requisiti specifici per la gestione dei dati, il controllo di accesso, la crittografia e la controllabilità. È necessario identificare tutti gli standard applicabili per ogni carico di lavoro consultando gli stakeholder legali, di conformità e di sicurezza.

2. Documentare contratti di servizio (SLA), RPO e RTO. I contratti di servizio (SLA), gli obiettivi del punto di ripristino (RPO) e gli obiettivi del tempo di ripristino definiscono livelli accettabili di disponibilità e perdita di dati. Queste metriche guidano la progettazione delle strategie di backup, replica e failover. È necessario documentare questi valori per ogni carico di lavoro per garantire che l'architettura soddisfi le aspettative di continuità aziendale. Vedere Definire i requisiti di affidabilità.

3. Classificare ogni ambiente del carico di lavoro. I carichi di lavoro vengono in genere eseguiti in ambienti di produzione, test o sviluppo. Ogni ambiente ha requisiti di disponibilità, sicurezza e prestazioni diversi. È necessario documentare la classificazione dell'ambiente per ogni carico di lavoro per informare la sequenziazione della migrazione, i controlli di accesso e l'allocazione delle risorse.

4. Convalidare l'integrazione ISV con Azure. Molti carichi di lavoro dipendono dal software dei fornitori di software indipendenti (ISV). Prima della migrazione, è necessario verificare che tutto il software ISV sia compatibile con Azure. Usare la documentazione del fornitore, gli ambienti di test o la convalida diretta con l'ISV. Identificare eventuali aggiornamenti, sostituzioni o modifiche di configurazione necessari. Determinare anche se si applicano il vantaggio Azure Hybrid o altri modelli di licenza. Includere i costi di licenza e le modifiche di compatibilità nel piano di migrazione per una pianificazione e un budget accurati.

Valutare il codice dell'applicazione

Una valutazione del codice dell'applicazione identifica i problemi di compatibilità e le opportunità di modernizzazione che possono influire sul successo della migrazione. Questa valutazione è essenziale per garantire che le applicazioni vengano eseguite in modo affidabile in Azure e per pianificare in modo efficace le onde di migrazione. È necessario valutare il codice dell'applicazione per rilevare i blocchi in anticipo, ridurre il rischio di errori di migrazione e informare le decisioni relative all'architettura di destinazione.

Usare gli strumenti automatizzati per valutare il codice dell'applicazione

1. Usare AppCAT per applicazioni .NET e Java.AppCAT fornisce valutazioni dettagliate per i carichi di lavoro .NET e Java. Questo strumento identifica le API deprecate, gli SDK non supportati e i problemi di configurazione che possono impedire la corretta migrazione. Usare AppCAT per generare raccomandazioni di compatibilità e modernizzazione per questi carichi di lavoro.

2. Usare strumenti di terze parti per altri linguaggi dell'applicazione. Strumenti come CloudPilot e CAST Highlight supportano linguaggi come Python, JavaScript, Node.jse Go. Questi strumenti identificano le modifiche a livello di codice necessarie per la compatibilità di Azure e forniscono informazioni dettagliate sulla modernizzazione. Usare questi strumenti per valutare i carichi di lavoro non-.NET e non Java.

3. Usare i risultati della valutazione per informare le decisioni relative all'architettura di destinazione. I risultati della compatibilità delle applicazioni possono influenzare la selezione dei servizi di Azure. Ad esempio, un'applicazione non compatibile con un servizio potrebbe essere compatibile con un'altra con modifiche minime al codice. Usare questa flessibilità per eseguire prima la migrazione delle applicazioni e rinviare la modernizzazione del codice a una fase successiva. Questo approccio riduce il rischio di migrazione e accelera il tempo nel cloud.

Convalidare la compatibilità del framework e dell'SDK

1. Informazioni sulla compatibilità del codice. La compatibilità di Framework e SDK garantisce che le applicazioni vengano eseguite in modo affidabile in Azure. Le versioni non supportate o gli SDK incompatibili possono causare errori di runtime o richiedere una rielaborazione significativa. È necessario verificare che Azure supporti la versione e il framework del linguaggio dell'applicazione.

2. Controllare il supporto di Azure per il linguaggio e il framework dell'applicazione. Verificare che Azure supporti la versione di .NET, Java, Python, JavaScript, Node.jse Go. Usare la documentazione ufficiale di Azure per convalidare la compatibilità.

3. Evitare modifiche al framework non necessarie. Eseguire la migrazione a un nuovo framework (ad esempio .NET Framework a .NET Core) solo se esiste una motivazione aziendale avanzata. Le modifiche del framework richiedono attività di sviluppo e test significativi.

Valutare i database

Le dipendenze del database determinano spesso l'esito positivo della migrazione delle applicazioni. I database condivisi, le dipendenze tra applicazioni e i modelli di integrazione possono complicare la pianificazione della migrazione. È necessario valutare i database che supportano le applicazioni e comprendere le relative dipendenze. Seguire queste indicazioni:

1. Identificare tutti i database usati dall'applicazione. Creare un inventario completo di tutti i database usati dall'applicazione. Includere tipi di motore di database (SQL Server, MySQL), versioni e modelli di hosting (ad esempio, locale, IaaS, PaaS). Usare strumenti, ad esempio Azure Migrate, per raccogliere queste informazioni in modo sistematico. Specificare se il database è self-hosted, ospitato in macchine virtuali o distribuito come servizio gestito. Queste informazioni consentono di determinare la conformità alla migrazione e la compatibilità della piattaforma di destinazione.

2. Eseguire il mapping delle dipendenze in ingresso e in uscita. Una visione chiara del modo in cui i dati vengono trasmessi da e verso ogni database è fondamentale per la sequenziazione delle migrazioni ed evitare interruzioni del servizio. Le dipendenze spesso si estendono su più applicazioni, servizi e sistemi esterni. Includere applicazioni interne, API, processi batch, strumenti di creazione di report e altre integrazioni. Specificare se la dipendenza è di sola lettura, di sola scrittura o bidirezionale. Questo dettaglio consente di classificare in ordine di priorità i carichi di lavoro e identificare potenziali blocchi di migrazione.

3. Determinare la strategia di migrazione del database. Decidere se spostare il database come istanza condivisa o suddividerlo in base al carico di lavoro. I database condivisi semplificano la gestione, ma possono ritardare la migrazione se più applicazioni dipendono da esse. La suddivisione dei database consente la migrazione indipendente, ma richiede un'attenta coordinamento e test. Assicurarsi che il piano di migrazione del database supporti la sequenziazione degli spostamenti dell'applicazione e riduce al minimo il tempo di inattività o l'interruzione del servizio.

Creare e gestire un registro dei rischi

Un registro dei rischi è un documento o uno strumento usato per identificare, valutare, classificare in ordine di priorità e monitorare i potenziali rischi che potrebbero influire sull'adozione del cloud e delinea le strategie di mitigazione. La gestione di questo registro garantisce la gestione proattiva dei rischi.

1. Stabilire un registro dei rischi per tutti i carichi di lavoro. Registra i rischi correlati a fattori tecnici, operativi e organizzativi. Questo registro offre visibilità su potenziali bloccanti e sul relativo valore.

2. Definire le strategie di mitigazione e tenere traccia dello stato. Per ogni rischio, documentare le azioni di mitigazione, le parti responsabili e le sequenze temporali di risoluzione. Questo rilevamento garantisce che i rischi vengano gestiti e risolti attivamente.

Per ulteriori informazioni, vedere CAF Govern - Valutazione dei rischi cloud

Risorse e strumenti di Azure

Passaggi successivi