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à.
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?
-
La documentazione corrente, ad esempio il CMDB o uno strumento equivalente, contiene la mappatura tra applicazioni e infrastrutture? Ogni risorsa dell'infrastruttura è associata a un'applicazione? Ogni applicazione è mappata sull'infrastruttura?
-
La documentazione contiene un catalogo di licenze e accordi di licenza per ogni prodotto?
-
La documentazione 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 prestazioni, monitoraggio, archivi, knowledge base e strumenti di gestione che possono essere utilizzati come fonte di dati.
-
Quali sono le diverse sedi, ad esempio i data center, che ospitano le nostre applicazioni e la nostra infrastruttura?
Dopo aver risposto a queste domande, elenca le fonti di dati identificate. Quindi assegna un livello di fedeltà, o 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 dell'organizzazione in termini di massima tolleranza 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.
Origine dati |
Valutazione del 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 |
Medium-low - 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 |
Medium-high - Il 75-80% dei dati accurati, il 25-20% dei valori presunti o i dati risalgono a 60-90 giorni fa. |
Elevata |
Copre il 90% del patrimonio 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, per 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 |
Application name (Nome applicazione) |
Nome con cui l'applicazione è nota all'organizzazione. Includi il nome del fornitore commerciale standard (COTS) e del prodotto, se applicabile. |
R |
R (D) |
Medium-high |
È COTS? |
Sì o no. Che si tratti di un'applicazione commerciale o di uno sviluppo interno |
R |
R (D) |
Medium-high |
Prodotto e versione COTS |
Nome e versione del prodotto software commerciale |
R |
R (D) |
Media |
Description |
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 |
Medium-high |
Tipo |
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) |
Medium-high |
Conformità e regolamentazione |
Framework applicabili al carico di lavoro (ad es. HIPAA, SOX, ISO, SOC PCI-DSS, FedRAMP) e ai requisiti normativi |
R |
R (D) |
Medium-high |
Dipendenze |
Dipendenze a monte e a valle da applicazioni o servizi interni ed esterni. Non-technical dipendenze come elementi operativi (ad esempio, cicli di manutenzione) |
O |
O |
Medium-low |
mappatura dell'infrastruttura |
Mappatura su risorse and/or virtuali fisiche che compongono l'applicazione |
R |
O |
Media |
Licenza |
Tipo di licenza software commodity (ad esempio, Microsoft SQL Server Enterprise) |
O |
R |
Medium-high |
Costo |
Costi per la licenza software, le operazioni software e la manutenzione |
O |
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 |
Medium-high |
Nome DNS (nome di dominio completo o FQDN) |
Nome DNS |
O |
O |
Media |
Indirizzo IP e maschera di rete |
and/or Indirizzi IP pubblici interni |
O |
O |
Medium-high |
Tipo di asset |
Server fisico o virtuale, hypervisor, contenitore, dispositivo, istanza di database, ecc. |
R |
R |
Medium-high |
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 |
Medium-high |
Configurazione |
CPU allocata, numero di core, thread per core, memoria totale, storage, schede di rete |
R |
R |
Medium-high |
Utilizzo |
Picco e medio di CPU, memoria e storage. Throughput delle istanze di database. |
O |
O |
Medium-high |
Licenza |
Tipo di licenza commodity (ad esempio, RHEL Standard) |
O |
R |
Media |
Mappatura delle applicazioni |
Applicazioni o componenti applicativi eseguiti in questa infrastruttura |
R |
O |
Media |
Costo |
Costi completi per i server bare-metal, inclusi hardware, manutenzione, operazioni, storage (SAN, NAS, oggetti), licenze del sistema operativo, condivisione dello spazio su rack e sovraccarico del data center |
O |
O |
Medium-high |
Reti
Nome 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 |
Posizioni connesse |
Posizioni denominate collegate tramite questo link |
O |
O |
Media |
Utilizzo del collegamento |
Utilizzo medio e massimo, trasferimento dati in uscita () GB/month |
O |
R |
Media |
Latenza (ms) |
Latenza attuale tra le postazioni connesse |
O |
O |
Media |
Costo |
Costo mensile attuale |
N/A |
O |
Media |
Migrazione
Nome dell'attributo |
Descrizione |
Inventario e definizione delle priorità |
Caso aziendale |
Livello di fedeltà consigliato (minimo) |
|---|---|---|---|---|
Costo del rehost |
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/A |
R (F) |
Medium-high |
Costo di ripiattaforma |
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/A |
R (F) |
Medium-high |
Costo del refactoring |
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/A |
R (F) |
Medium-high |
Costo del pensionamento |
Numero di server, costo medio di smantellamento |
N/A |
O |
Medium-high |
Zona di atterraggio |
Re-use existing (Y/N), elenco delle regioni AWS necessarie, costo |
N/A |
R (F) |
Medium-high |
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/A |
R (F) |
Medium-high |
Durata |
Durata della migrazione del carico di lavoro prevista (mesi) |
O |
R (F) |
Medium-high |
Costo parallelo |
Intervallo di tempo e ritmo con cui è possibile rimuovere i costi così come sono durante la migrazione |
N/A |
O |
Medium-high |
Costo parallelo |
Tempi e ritmi di introduzione dei prodotti e servizi AWS e di altri costi dell'infrastruttura durante la migrazione |
N/A |
O |
Medium-high |
Valutazione della necessità di strumenti di scoperta
La tua organizzazione ha bisogno di strumenti di scoperta? La valutazione del portafoglio richiede dati affidabili e aggiornati su applicazioni e 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à aiutano a creare piani di migrazione efficaci e a stimare correttamente l'infrastruttura di destinazione per ridurre i costi e massimizzare i benefici. 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
-
High-confidence pianificazione delle ondate migratorie
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 fornisce una comprensione dell'infrastruttura e della configurazione che saranno richieste in AWS (ad esempio gruppi di sicurezza, tipi di istanze, posizionamento degli account e routing di rete). Inoltre aiuta a raggruppare le applicazioni che devono spostarsi contemporaneamente (come le applicazioni che devono comunicare su reti a bassa latenza).
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. Ottenere dati aggiornati è 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
-
Quali dati vengono raccolti dallo strumento?
-
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.
Architecture
-
Quale infrastruttura è necessaria per implementare lo strumento e quali sono i diversi componenti?
-
È disponibile più di un'architettura o di un modello di implementazione?
-
Lo strumento supporta l'installazione di componenti in zone di sicurezza chiuse dall'aria?
Performance
-
Qual è l'impatto della raccolta dei dati sui miei sistemi?
Compatibilità e ambito di applicazione
-
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 la raccolta di dati senza agente?
-
Agent e Agentless offrono le stesse funzionalità?
-
Qual è il processo di raccolta?
Funzionalità
-
Quali sono le funzionalità disponibili?
-
È in grado di calcolare il costo totale di proprietà (TCO) e la frequenza di Cloud AWS esecuzione stimata?
-
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 +?
Suggerimento
Per trovare e valutare gli strumenti di scoperta, utilizza il sito Discovery, Planning and
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 i runtime, i pacchetti e i framework installati.
-
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).
-
Individuazione dei database: dovrebbe essere in grado di scoprire database, istanze e schemi, inclusi tipi e versioni dei motori.
-
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)
-
Right-sizing raccomandazione (ad esempio, può mappare un' AWS infrastruttura di destinazione 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 assistenza nella creazione di piani di migrazione)
-
Stima dei costi di migrazione (stima dello sforzo di migrazione)
Considerazioni sull'implementazione
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)?
