Individuare l'inventario del carico di lavoro esistente

Questa sezione si applica alle organizzazioni con carichi di lavoro IT esistenti all'esterno di Azure (locale o altri cloud) che richiedono la migrazione ad Azure. Un inventario completo del carico di lavoro è la base di un solido piano di adozione del cloud per tali organizzazioni. Non è possibile prendere decisioni su come o se eseguire la migrazione di un sistema se non lo si conosce o se ne comprende le caratteristiche. Il piano di adozione del cloud deve includere i passaggi per individuare tutti i carichi di lavoro, raccogliere i dati chiave su ognuno e classificarli in ordine di priorità per la migrazione.

Individuare l'inventario del carico di lavoro

Un inventario completo degli asset tecnici costituisce la base del piano di adozione del cloud. L'inventario identifica tutti i sistemi, le applicazioni e i componenti dell'infrastruttura nell'ambiente. È necessario questo inventario per decidere quale strategia di migrazione cloud è la scelta migliore.

1. Definire ogni carico di lavoro e i relativi limiti. Un carico di lavoro è una raccolta di componenti IT, ad esempio server, macchine virtuali (VM), servizi cloud, applicazioni, codice, dati o appliance, che supportano uno o più processi aziendali. È necessario definire ogni carico di lavoro per comprendere il valore aziendale e il footprint tecnico. Questa chiarezza consente di classificare in ordine di priorità le attività di migrazione e modernizzazione. Usare gli strumenti di monitoraggio del traffico di rete e mapping delle dipendenze per identificare i limiti del carico di lavoro e visualizzare le relazioni tra i componenti.

2. Usare strumenti di individuazione automatizzati.Azure Migrate offre funzionalità di individuazione gratuite per ambienti locali e cloud. Questo strumento identifica automaticamente server, applicazioni e le relative interdipendenze. È necessario usare l'individuazione automatica per accelerare la creazione dell'inventario e ridurre gli errori manuali. Se Azure Migrate non supporta completamente l'ambiente, usare strumenti come Dr Migrate o CloudPilot che estendono le funzionalità di Azure Migrate.

3. Includere tutti i componenti in tutti gli ambienti. L'inventario deve acquisire i componenti dell'infrastruttura e dell'applicazione in tutte le piattaforme. È necessario includere server, macchine virtuali, applicazioni, database, modelli di comunicazione, integrazioni, identità e servizi cloud da Azure, AWS, Google Cloud e altri provider. Questa visione completa garantisce che nessun asset critico venga trascurato durante la pianificazione o la migrazione.

4. Usare l'individuazione manuale quando l'automazione non è possibile. Alcuni ambienti limitano gli strumenti di individuazione automatizzati a causa di criteri di sicurezza o limitazioni tecniche. Usare il modello di importazione di Azure Migrate per documentare manualmente gli asset in ambienti con restrizioni. La documentazione manuale garantisce l'acquisizione di asset a cui gli strumenti automatizzati non possono accedere.

Assegnare priorità ai carichi di lavoro in base al valore aziendale e alla fattibilità

Un lungo elenco di inventario può essere travolgente. Il piano deve includere un metodo per classificare in ordine di priorità i carichi di lavoro da affrontare per primi nel lavoro di adozione del cloud. Non tutti i carichi di lavoro sono ugualmente importanti o ugualmente adatti per la migrazione immediata, quindi usare un framework di definizione delle priorità.

1. Utilizzare la criticità aziendale. Classificare i carichi di lavoro in base alla criticità delle operazioni aziendali, dei ricavi o dell'esperienza dei clienti. Spesso alcuni carichi di lavoro sono cruciali (in caso di calo, perdite aziendali importanti) mentre altri sono meno critici. I sistemi di valore aziendale elevato possono essere altamente prioritari per garantire che possano trarre vantaggio dalla scalabilità o dalla resilienza del cloud o a volte una priorità inferiore se il rischio di migrazione è troppo elevato.

2. Stimare l'idoneità al cloud. Eseguire stime rapide e generali su come è pronto ogni carico di lavoro per la migrazione cloud, in base a quanto già noto. In seguito viene fornita una valutazione tecnica dettagliata, ma per il momento prendere in considerazione fattori come la complessità tecnica, i componenti legacy e i rischi noti. Alcuni carichi di lavoro potrebbero essere facili da vincere, mentre altri potrebbero richiedere una rielaborazione significativa. È possibile classificare in ordine di priorità i carichi di lavoro più semplici per creare slancio o scegliere un sistema moderatamente complesso ma ad alto valore per massimizzare il successo precoce.

3. Prendere nota delle dipendenze. In questa fase, valutare le dipendenze a un livello elevato usando le conoscenze esistenti. Un mapping completo delle dipendenze viene eseguito in un secondo momento, ma, per il momento, identifica i carichi di lavoro strettamente associati ad altri. I sistemi con molte connessioni potrebbero dover essere migrati insieme per evitare interruzioni. In alcuni casi, potrebbe essere necessario spostare un carico di lavoro con priorità più bassa in precedenza perché dipende da un sistema con priorità più alta. Usare queste informazioni dettagliate per raggruppare i carichi di lavoro correlati in onde di migrazione logiche.

4. Prendere in considerazione l'allineamento strategico. Se alcuni carichi di lavoro sono fondamentali per le iniziative strategiche, è possibile assegnarle priorità per spostarsi prima. D'altra parte, i carichi di lavoro destinati a essere ritirati o sostituiti presto dovrebbero essere deprioritizzati per la migrazione.

5. Creare un backlog con priorità. Questo backlog può essere un elenco o una tabella con categorie come "Fase 1: carichi di lavoro A, B, C. Fase 2: carichi di lavoro D, E". Assicurati di convalidare quest'ordine con gli stakeholder. I proprietari aziendali e i proprietari IT dovrebbero esaminare e concordare che la sequenza abbia senso. Vuoi ottenere il loro consenso ed evitare resistenza in seguito. Ad esempio, se si pianifica per ultimo una app critica di un reparto senza il loro input, potrebbero obiettare. Modificare il piano in base al feedback per bilanciare la logica tecnica con le esigenze aziendali.

Raccogliere i dettagli aziendali su ciascun carico di lavoro

Per ogni carico di lavoro identificato, il piano deve acquisire il contesto aziendale e i requisiti principali. Queste informazioni guidano la strategia di migrazione (sezione successiva) e garantiscono l'allineamento delle decisioni alle esigenze aziendali. Dettagli importanti per il documento

1. Proprietari e stakeholder: il documento "possiede" il carico di lavoro dal punto di vista aziendale (VP delle vendite di un CRM) e dal punto di vista IT (responsabile dell'applicazione, responsabile dell'infrastruttura). Elencare tutti gli stakeholder che devono essere coinvolti nella pianificazione della sua mossa.

2. Funzione aziendale e criticità: documenta cosa fa il carico di lavoro e quanto è importante. Registrare una breve descrizione dello scopo e classificarne il livello di criticità (alto/medio/basso). La criticità spesso è legata a quanto tempo di inattività può essere tollerato.

3. Riservatezza e conformità dei dati: prendere nota della classificazione dei dati gestiti dal sistema (pubblico, interno, riservato, estremamente riservato). Documentare i requisiti di conformità (PCI, HIPAA, GDPR) che si applicano a questo carico di lavoro. Ad esempio, se la residenza dei dati è necessaria in una determinata area, ciò influisce sull'architettura cloud.

4. Vincoli operativi: documentare finestre di manutenzione specifiche, periodi di inattività (periodi di traffico elevato) e requisiti di operatività. Documentare tali vincoli perché influiscono sulla pianificazione della migrazione e sull'architettura di destinazione (esigenze di disponibilità elevata).

5. Sequenza temporale o scadenze previste: se è presente una sequenza temporale desiderata per la migrazione di questo carico di lavoro, annotarlo. Ad esempio, è possibile che si disponga di rinnovi del contratto o della scadenza del contratto di locazione del data center. Questi fattori influiscono sulla pianificazione generale della roadmap.

Per un esempio, consultare il Piano di adozione della migrazione.

Strumenti e risorse di individuazione e valutazione di Azure

Passaggi successivi