Comprensione dei requisiti relativi ai dati di valutazione iniziale

La raccolta dei dati può richiedere molto tempo e diventare facilmente un ostacolo quando non c'è chiarezza su quali dati sono necessari e quando sono necessari. La chiave è capire l'equilibrio tra i dati insufficienti e quelli che sono troppi per i risultati di questa fase. Per concentrarti sui dati e sul livello di fedeltà richiesti per questa fase iniziale della valutazione del portafoglio, adotta un approccio iterativo alla raccolta dei dati.

Fonti di dati e requisiti in materia di dati

Il primo passaggio consiste nell'identificare le fonti di dati. Inizia identificando le principali parti interessate all'interno della tua organizzazione in grado di soddisfare i requisiti in materia di dati. Si tratta in genere di membri dei team di gestione dei servizi, operazioni, pianificazione della capacità, monitoraggio e supporto e dei proprietari delle applicazioni. Stabilisci sessioni di lavoro con i membri di questi gruppi. Comunica i requisiti in materia di dati e ottieni un elenco di strumenti e documentazione esistente in grado di fornire i dati.

Per guidare queste conversazioni, usa la seguente serie di domande:

• Quanto è accurato e aggiornato l'attuale inventario dell'infrastruttura e delle applicazioni? Ad esempio, per quanto riguarda il database di gestione della configurazione aziendale (CMDB), sappiamo già quali sono le lacune?

• Disponiamo di strumenti e processi attivi che mantengono aggiornato il CMDB (o uno equivalente)? In caso affermativo, con quale frequenza viene aggiornato? Qual è la data di aggiornamento più recente?

• L'inventario corrente, ad esempio il CMDB, contiene application-to-infrastructure mappature? Ogni risorsa dell'infrastruttura è associata a un'applicazione? Ogni applicazione è mappata sull'infrastruttura?

• L'inventario contiene un catalogo di licenze e contratti di licenza per ogni prodotto?

• L'inventario contiene dati sulle dipendenze? Nota l'esistenza di dati di comunicazione come da server a server, da applicazione a applicazione, da applicazione o da server a database.

• Quali altri strumenti in grado di fornire informazioni sulle applicazioni e sull'infrastruttura sono disponibili nell'ambiente? Nota l'esistenza di strumenti di prestazioni, monitoraggio e gestione che possono essere utilizzati come fonte di dati.

• Quali sono le diverse sedi, come i data center, che ospitano le nostre applicazioni e infrastrutture?

Dopo aver risposto a queste domande, elenca le fonti di dati identificate. Quindi assegna un livello di fedeltà, o un livello di fiducia, a ciascuna di esse. I dati convalidati di recente (entro 30 giorni) da fonti programmatiche attive, come gli strumenti, hanno il massimo livello di fedeltà. I dati statici sono considerati di bassa fedeltà e meno affidabili. Esempi di dati statici sono documenti, cartelle di lavoro, CMDB aggiornati manualmente o qualsiasi altro set di dati non gestito a livello di programmazione o la cui data di ultimo aggiornamento è precedente a 60 giorni.

I livelli di fedeltà dei dati nella tabella seguente sono forniti a titolo di esempio. Si consiglia di valutare i requisiti della propria organizzazione in termini di tolleranza massima alle ipotesi e ai rischi associati per determinare quale sia il livello di fedeltà appropriato. Nella tabella, le conoscenze istituzionali si riferiscono a qualsiasi informazione sulle applicazioni e sull'infrastruttura non documentata.

Fonti di dati	Livello di fedeltà	Copertura del portafoglio	Commenti
Conoscenza istituzionale	Bassa: fino al 25% dei dati accurati, il 75% dei valori presunti o i dati risalgono a più di 150 giorni.	Bassa	Scarso, focalizzato su applicazioni critiche
Knowledge base	Medio-basso: il 35-40% dei dati accurati, il 65-60% dei valori presunti o i dati risalgono a 120-150 giorni fa.	Media	Livelli di dettaglio non coerenti mantenuti manualmente
CMDB	Medio: ~ 50% dei dati accurati, ~ 50% dei valori presunti o i dati risalgono a 90-120 giorni fa.	Media	Contiene dati provenienti da fonti miste, diverse lacune di dati
Esportazioni con VMware vCenter	Medio-alto: 75-80% di dati accurati, 25-20% di valori presunti oppure i dati risalgono a 60-90 giorni fa.	Elevata	Copre il 90% dello spazio virtualizzato
Monitoraggio delle prestazioni delle applicazioni	Alto: dati per lo più accurati, valori presunti pari a circa il 5% o dati risalgono a 0-60 giorni fa.	Bassa	Limitato ai sistemi di produzione critici (copre il 15% del portafoglio di applicazioni)

Le tabelle seguenti specificano gli attributi dei dati richiesti e facoltativi per ciascuna classe di asset (applicazioni, infrastruttura, reti e migrazione), l'attività specifica (inventario o business case) e la fedeltà dei dati consigliata per questa fase di valutazione. Le tabelle utilizzano le seguenti abbreviazioni:

• R, per obbligatorio

• (D), per il business case direzionale, necessario per confrontare il costo totale di proprietà (TCO) e i business case direzionali

• (F), per un business case completamente direzionale, necessario per il confronto del TCO e per i casi aziendali direzionali che includono i costi di migrazione e modernizzazione

• O, per opzione

• N/A, in quanto non applicabile

Applicazioni

Nome attributo	Descrizione	Inventario e definizione delle priorità	Caso aziendale	Livello di fedeltà consigliato (minimo)
Identificatore univoco	Ad esempio, ID dell'applicazione. In genere disponibile su CMDB esistenti o altri inventari e sistemi di controllo interni. Prendi in considerazione la possibilità di creare ID univoci ogni volta che questi non sono definiti nella tua organizzazione.	R	R (D)	Elevata
Nome applicazione	Nome con cui l'applicazione è nota all'organizzazione. Includi il nome del fornitore commerciale off-the-shelf (COTS) e del prodotto, se applicabile.	R	R (D)	Medio-alta
È COTS?	Sì o no. Che si tratti di un'applicazione commerciale o di uno sviluppo interno	R	R (D)	Medio-alta
Prodotto e versione COTS	Nome e versione del prodotto software commerciale	R	R (D)	Media
Descrizione	Funzione e contesto dell'applicazione principali	R	O	Media
Criticità	Ad esempio, un'applicazione strategica o che genera entrate o che supporta una funzione critica	R	O	Medio-alta
Type	Ad esempio, database, gestione delle relazioni con i clienti (CRM), applicazioni Web, contenuti multimediali, servizi IT condivisi	R	O	Media
Ambiente	Ad esempio, produzione, pre-produzione, sviluppo, test, sandbox	R	R (D)	Medio-alta
Conformità e regolamentazione	Framework applicabili al carico di lavoro (ad es. HIPAA, SOX, PCI-DSS, ISO, SOC, FedRAMP) e requisiti normativi	R	R (D)	Medio-alta
Dipendenze	Dipendenze a monte e a valle da applicazioni o servizi interni ed esterni. Dipendenze non tecniche come elementi operativi (ad esempio, cicli di manutenzione)	O	O	Medio-Bassa
Mappatura dell'infrastruttura	Mappatura su risorse fisiche e/o virtuali che compongono l'applicazione	O	O	Media
Licenza	Tipo di licenza software commodity (ad esempio, Microsoft SQL Server Enterprise)	O	R	Medio-alta
Costo	Costi per la licenza software, le operazioni software e la manutenzione	N/D	O	Media

Infrastruttura

Nome dell'attributo	Descrizione	Inventario e definizione delle priorità	Caso aziendale	Livello di fedeltà consigliato (minimo)
Identificatore univoco	Ad esempio, ID del server. In genere disponibile sui CMDB esistenti o su altri inventari e sistemi di controllo interni. Prendi in considerazione la possibilità di creare ID univoci ogni volta che questi non sono definiti nella tua organizzazione.	R	R	Elevata
Nome della rete	Nome della risorsa nella rete (ad es. nome host)	R	O	Medio-alta
Nome DNS (nome di dominio completo o FQDN)	Nome DNS	O	O	Media
Indirizzo IP e maschera di rete	Indirizzi IP interni e/o pubblici	R	O	Medio-alta
Asset type (Tipo asset)	Server fisico o virtuale, hypervisor, contenitore, dispositivo, istanza di database, ecc.	R	R	Medio-alta
Product name (Nome del prodotto)	Nome del fornitore commerciale e del prodotto (ad esempio, VMware ESXi, IBM Power Systems, Exadata)	R	R	Media
Sistema operativo	Ad esempio, REHL 8, Windows Server 2019, AIX 6.1	R	R	Medio-alta
Configurazione	CPU allocata, numero di core, thread per core, memoria totale, storage, schede di rete	R	R	Medio-alta
Utilizzo	Picco e medio di CPU, memoria e storage. Throughput delle istanze di database.	R	O	Medio-alta
Licenza	Tipo di licenza commodity (ad esempio, RHEL Standard)	R	R	Media
L'infrastruttura è condivisa?	Sì o No per indicare i servizi di infrastruttura che forniscono servizi condivisi come provider di autenticazione, sistemi di monitoraggio, servizi di backup e servizi simili	R	R (D)	Media
Mappatura delle applicazioni	Applicazioni o componenti applicativi eseguiti in questa infrastruttura	O	O	Media
Costo	Costi completi per i server bare-metal, inclusi hardware, manutenzione, operazioni, storage (SAN, NAS, Object), licenza del sistema operativo, quota dello spazio su rack e spese generali del data center	N/D	O	Medio-alta

Reti

Nome dell'attributo	Descrizione	Inventario e definizione delle priorità	Caso aziendale	Livello di fedeltà consigliato (minimo)
Dimensioni del tubo (MB/s), ridondanza (Y/N)	Specifiche attuali del collegamento WAN (ad esempio, 1000 MB/s ridondanti)	O	R	Media
Utilizzo del collegamento	Utilizzo medio e massimo, trasferimento dati in uscita (GB/mese)	O	R	Media
Latenza (ms)	Latenza attuale tra le postazioni connesse.	O	O	Media
Costo	Costo mensile attuale	N/D	O	Media

Migrazione

Nome dell'attributo	Descrizione	Inventario e definizione delle priorità	Caso aziendale	Livello di fedeltà consigliato (minimo)
Riospitare	Impegno dei clienti e dei partner per ogni carico di lavoro (persona/giorno), costi giornalieri per clienti e partner, costo degli strumenti, numero di carichi di lavoro	N/D	R (F)	Medio-alta
Conversione piattaforma	Impegno dei clienti e dei partner per ogni carico di lavoro (persona/giorno), costi giornalieri dei clienti e dei partner, numero di carichi di lavoro	N/D	R (F)	Medio-alta
Rifattorizzare	Impegno dei clienti e dei partner per ogni carico di lavoro (persona/giorno), costi giornalieri dei clienti e dei partner, numero di carichi di lavoro	N/D	O	Medio-alta
Ritiro	Numero di server, costo medio di smantellamento	N/D	O	Medio-alta
Zona di atterraggio	Riutilizzo dell'esistente (Y/N), elenco delle AWS regioni necessarie, costo	N/D	R (F)	Medio-alta
Le persone e il cambiamento	Numero di personale da formare nelle operazioni e nello sviluppo del cloud, costo della formazione per persona, costo del tempo di formazione per persona	N/D	R (F)	Medio-alta
Durata	Durata della migrazione del carico di lavoro prevista (mesi)	O	R (F)	Medio-alta
Costo parallelo	Intervallo di tempo e ritmo con cui è possibile rimuovere i costi così come sono durante la migrazione	N/D	O	Medio-alta
	Tempi e ritmi di introduzione di AWS prodotti e servizi e altri costi infrastrutturali durante la migrazione	N/D	O	Medio-alta

Valutazione della necessità di strumenti di scoperta

La tua organizzazione ha bisogno di strumenti di scoperta? La valutazione del portafoglio richiede up-to-date dati altamente affidabili sulle applicazioni e sull'infrastruttura. Le fasi iniziali della valutazione del portafoglio possono utilizzare ipotesi per colmare le lacune nei dati.

Tuttavia, man mano che si fanno progressi, i dati ad alta fedeltà consentono la creazione di piani di migrazione efficaci e la stima corretta dell'infrastruttura di destinazione per ridurre i costi e massimizzare i vantaggi. Riduce inoltre i rischi abilitando implementazioni che tengono conto delle dipendenze ed evitano le insidie della migrazione. Il caso d'uso principale degli strumenti di discovery nei programmi di migrazione al cloud consiste nel ridurre i rischi e aumentare i livelli di fiducia nei dati attraverso quanto segue:

• Raccolta di dati automatizzata o programmatica, con conseguente ottenimento di dati convalidati e altamente affidabili

• Accelerazione della velocità di acquisizione dei dati, miglioramento della velocità del progetto e riduzione dei costi

• Aumento dei livelli di completezza dei dati, inclusi i dati di comunicazione e le dipendenze non tipicamente disponibili nei CMDB

• Ottenimento di informazioni quali l'identificazione automatizzata delle applicazioni, l'analisi del TCO, i tassi di esecuzione previsti e i consigli di ottimizzazione

• Pianificazione delle ondate migratorie ad alta sicurezza

In caso di incertezza sull'esistenza di sistemi in una determinata posizione, la maggior parte degli strumenti di rilevamento è in grado di scansionare le sottoreti di rete e individuare i sistemi che rispondono alle richieste ping o SNMP (Simple Network Management Protocol). Tieni presente che non tutte le configurazioni di rete o di sistema consentiranno il traffico ping o SNMP. Discutete queste opzioni con i vostri team tecnici e di rete.

Le fasi successive della valutazione e della migrazione del portafoglio di applicazioni si basano principalmente su informazioni accurate sulla mappatura delle dipendenze. La mappatura delle dipendenze consente di comprendere l'infrastruttura e la configurazione necessarie AWS (ad esempio gruppi di sicurezza, tipi di istanze, posizionamento degli account e routing di rete). Inoltre, consente di raggruppare le applicazioni che devono spostarsi contemporaneamente (ad esempio le applicazioni che devono comunicare su reti a bassa latenza). Inoltre, la mappatura delle dipendenze fornisce informazioni per l'evoluzione del business case.

Quando si sceglie uno strumento di scoperta, è importante considerare tutte le fasi del processo di valutazione e anticipare i requisiti in materia di dati. Le lacune nei dati possono potenzialmente diventare un ostacolo, quindi è fondamentale prevederle analizzando i requisiti e le fonti di dati futuri. L'esperienza sul campo indica che la maggior parte dei progetti di migrazione in fase di stallo dispone di un set di dati limitato in cui le applicazioni interessate, l'infrastruttura associata e le relative dipendenze non sono chiaramente identificate. Questa mancanza di identificazione può portare a metriche, decisioni e ritardi errati. L'acquisizione di up-to-date dati è il primo passo verso progetti di migrazione di successo.

Come selezionare uno strumento di scoperta?

Diversi strumenti di scoperta disponibili sul mercato offrono caratteristiche e funzionalità diverse. Considerate le vostre esigenze. E decidi l'opzione più appropriata per la tua organizzazione. I fattori più comuni nella scelta di uno strumento di scoperta per le migrazioni sono i seguenti:

Sicurezza

• Qual è il metodo di autenticazione per accedere all'archivio dei dati dello strumento o ai motori di analisi?

• Chi può accedere ai dati e quali sono i controlli di sicurezza per accedere allo strumento?

• In che modo lo strumento raccoglie i dati? Ha bisogno di credenziali dedicate?

• Di quali credenziali e livello di accesso ha bisogno lo strumento per accedere ai miei sistemi e ottenere dati?

• Come vengono trasferiti i dati tra i componenti dello strumento?

• Lo strumento supporta la crittografia dei dati inattivi e in transito?

• I dati sono centralizzati in un unico componente all'interno o all'esterno del mio ambiente?

• Quali sono i requisiti di rete e firewall?

Assicurati che i team di sicurezza siano coinvolti nelle prime conversazioni sugli strumenti di scoperta.

Sovranità dei dati

• Dove vengono archiviati ed elaborati i dati?

• Lo strumento utilizza un modello SaaS (Software as a Service)?

• Ha la possibilità di conservare tutti i dati entro i limiti del mio ambiente?

• È possibile esaminare i dati prima che escano dai confini della mia organizzazione?

Considerate le esigenze della vostra organizzazione in termini di requisiti di residenza dei dati.

Architettura

• Quale infrastruttura è richiesta e quali sono i diversi componenti?

• È disponibile più di un'architettura?

• Lo strumento supporta l'installazione di componenti in zone di sicurezza chiuse dall'aria?

Prestazioni

• Qual è l'impatto della raccolta dei dati sui miei sistemi?

Compatibilità e ambito

• Lo strumento supporta tutti o la maggior parte dei miei prodotti e versioni? Consulta la documentazione dello strumento per verificare le piattaforme supportate rispetto alle informazioni correnti sull'ambito in uso.

• La maggior parte dei miei sistemi operativi è supportata per la raccolta dei dati? Se non conosci le versioni del tuo sistema operativo, prova a restringere l'elenco degli strumenti di scoperta a quelli con la più ampia gamma di sistemi supportati.

Metodi di raccolta

• Lo strumento richiede l'installazione di un agente su ogni sistema di destinazione?

• Supporta implementazioni senza agente?

• Agent e Agent-Less offrono le stesse funzionalità?

• Qual è il processo di raccolta?

Caratteristiche

• Quali sono le funzionalità disponibili?

• Può calcolare il costo totale di proprietà (TCO) e la velocità di esecuzione stimata del AWS cloud?

• Supporta la pianificazione della migrazione?

• Misura le prestazioni?

• Può consigliare l' AWS infrastruttura di destinazione?

• Esegue la mappatura delle dipendenze?

• Quale livello di mappatura delle dipendenze fornisce?

• Fornisce l'accesso alle API? (ad esempio, è possibile accedervi programmaticamente per ottenere dati?)

Prendi in considerazione gli strumenti con potenti funzioni di mappatura delle dipendenze delle applicazioni e dell'infrastruttura e quelli in grado di dedurre le applicazioni dai modelli di comunicazione.

Costo

• Qual è il modello di licenza?

• Quanto costa la licenza?

• Il prezzo è riferito a ciascun server? Si tratta di prezzi differenziati?

• Esistono opzioni con funzionalità limitate che possono essere concesse in licenza su richiesta?

Gli strumenti Discovery vengono in genere utilizzati durante l'intero ciclo di vita dei progetti di migrazione. Se il tuo budget è limitato, prendi in considerazione almeno 6 mesi. Tuttavia, l'assenza di strumenti di rilevamento comporta in genere un aumento del lavoro manuale e dei costi interni.

Modello Support

• Quali livelli di supporto vengono forniti di default?

• È disponibile un piano di supporto?

• Quali sono i tempi di risposta agli incidenti?

Servizi professionali

• Il fornitore offre servizi professionali per analizzare i risultati delle scoperte?

• Possono coprire gli elementi di questa guida?

• Sono previsti sconti o pacchetti per i servizi Tooling +?

Funzionalità consigliate per lo strumento di scoperta

Per evitare il provisioning e la combinazione di dati provenienti da più strumenti nel tempo, uno strumento di rilevamento dovrebbe includere le seguenti funzionalità minime:

• Software: lo strumento di rilevamento dovrebbe essere in grado di identificare i processi in esecuzione e il software installato.

• Mappatura delle dipendenze: dovrebbe essere in grado di raccogliere informazioni sulle connessioni di rete e creare mappe delle dipendenze in entrata e in uscita dei server e delle applicazioni in esecuzione. Inoltre, lo strumento di rilevamento dovrebbe essere in grado di dedurre le applicazioni da gruppi di infrastrutture in base a modelli di comunicazione.

• Individuazione del profilo e della configurazione: dovrebbe essere in grado di riportare il profilo dell'infrastruttura, ad esempio la famiglia di CPU (ad esempio, x86, PowerPC), il numero di core della CPU, le dimensioni della memoria, il numero di dischi e le dimensioni e le interfacce di rete.

• Rilevamento dello storage di rete: dovrebbe essere in grado di rilevare e profilare le condivisioni di rete dai sistemi NAS (Network-Attached Storage).

• Prestazioni: dovrebbe essere in grado di segnalare l'utilizzo medio e massimo di CPU, memoria, disco e rete.

• Analisi delle lacune: dovrebbe essere in grado di fornire informazioni sulla quantità e sulla fedeltà dei dati.

• Scansione della rete: dovrebbe essere in grado di scansionare le sottoreti di rete e scoprire risorse infrastrutturali sconosciute.

• Rapporti: dovrebbe essere in grado di fornire lo stato della raccolta e dell'analisi.

• Accesso alle API: dovrebbe essere in grado di fornire strumenti programmatici per accedere ai dati raccolti.

Funzionalità aggiuntive da considerare

• Analisi del TCO per fornire un confronto dei costi tra il costo locale corrente e il costo previsto AWS .

• Consigli per l'analisi e l'ottimizzazione delle licenze per i sistemi Microsoft SQL Server e Oracle in scenari di rehosting e ripiattaforma.

• Raccomandazione sulla strategia di migrazione (lo strumento di rilevamento può fornire consigli di migrazione di tipo R predefiniti in base alla tecnologia attuale?)

• Esportazione dell'inventario (in formato CSV o in un formato simile)

• Raccomandazione per il corretto dimensionamento (ad esempio, può mappare un'infrastruttura di destinazione AWS consigliata?)

• Visualizzazione delle dipendenze (ad esempio, la mappatura delle dipendenze può essere visualizzata in modalità grafica?)

• Vista architettonica (ad esempio, è possibile produrre automaticamente diagrammi architettonici?)

• Assegnazione delle priorità alle applicazioni (può assegnare peso o rilevanza agli attributi dell'applicazione e dell'infrastruttura per creare criteri di prioritizzazione per la migrazione?)

• Pianificazione delle ondate (ad esempio, gruppi di applicazioni consigliati e possibilità di creare piani ondeggianti di migrazione)

• Stima dei costi di migrazione (stima dello sforzo di migrazione)

Considerazioni sulla distribuzione

Dopo aver selezionato e acquistato uno strumento di scoperta, ponete le seguenti domande per favorire il dialogo con i team responsabili dell'implementazione dello strumento nella vostra organizzazione:

• I server o le applicazioni sono gestiti da terze parti? Ciò potrebbe imporre il coinvolgimento dei team e i processi da seguire.

• Qual è il processo di alto livello per ottenere l'approvazione per l'implementazione degli strumenti di scoperta?

• Qual è il processo di autenticazione principale per accedere a sistemi come server, container, storage e database? Le credenziali del server sono locali o centralizzate? Qual è la procedura per ottenere le credenziali? Saranno necessarie credenziali per raccogliere dati dai sistemi (ad esempio contenitori, server virtuali o fisici, hypervisor e database). Ottenere le credenziali per consentire allo strumento di rilevamento di connettersi a ciascuna risorsa può essere difficile, soprattutto quando tali risorse non sono centralizzate.

• Qual è la struttura delle zone di sicurezza della rete? Sono disponibili diagrammi di rete?

• Qual è la procedura per richiedere le regole del firewall nei data center?

• Quali sono gli attuali accordi sui livelli di servizio di supporto (SLA) in relazione alle operazioni dei data center (installazione di strumenti di rilevamento, richieste di firewall)?