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à.
Valutazione dettagliata dell'applicazione
L'obiettivo di una valutazione dettagliata dell'applicazione è la comprensione completa dell'applicazione interessata e dell'infrastruttura associata (elaborazione, storage e rete). I dati ad alta fedeltà sono necessari per evitare insidie. Ad esempio, è normale che le organizzazioni presumano di comprendere appieno l'applicazione. Questo è naturale ed è vero in molti casi. Tuttavia, per ridurre al minimo i rischi per l'azienda, è importante convalidare le conoscenze istituzionali e la documentazione statica ottenendo il maggior numero possibile di dati programmatici. In questo modo si risolverà la parte pesante del processo di scoperta. Puoi concentrarti sugli elementi di dati che provengono da fonti alternative, come informazioni aziendali specifiche, tabelle di marcia strategiche e altro.
La chiave è evitare modifiche dell'ultimo minuto durante e dopo la migrazione. Ad esempio, durante la migrazione, è importante evitare modifiche basate su dipendenze non identificate che potrebbero richiedere l'inclusione di un server in un'ondata di migrazione in corso. Subito dopo la migrazione, è importante evitare modifiche basate sui requisiti di piattaforma associati per consentire il traffico o implementare servizi aggiuntivi. Questi tipi di modifiche non pianificate aumentano il rischio di problemi operativi e di sicurezza. Consigliamo vivamente di utilizzare strumenti di rilevamento programmatico per convalidare i modelli di traffico e le dipendenze durante l'esecuzione di valutazioni dettagliate delle applicazioni.
All'inizio della valutazione, è necessario identificare gli stakeholder dell'applicazione. Questi sono in genere i seguenti:
-
Responsabili delle unità aziendali
-
Proprietari delle applicazioni
-
Architetti
-
Operazioni e supporto
-
Team di abilitazione al cloud
-
Team di piattaforme specifiche come elaborazione, archiviazione e reti
Esistono due approcci per una scoperta dettagliata. L'individuazione dall'alto verso il basso inizia dall'applicazione, o anche dall'utente, e arriva fino all'infrastruttura. Questo è l'approccio consigliato quando l'identificazione dell'applicazione è chiara. Al contrario, la scoperta dal basso verso l'alto inizia dall'infrastruttura e arriva fino all'applicazione o al servizio e ai relativi utenti. Questo approccio è utile quando i programmi di migrazione sono guidati dai team dell'infrastruttura e quando la application-to-infrastructure mappatura non è chiara. In generale, è probabile che utilizzi una combinazione di entrambi.
Per approfondire un'applicazione, i diagrammi di architettura esistenti sono un buon punto di partenza. Se questi non sono disponibili, creane uno basato sulle conoscenze attuali. Non sottovalutate l'importanza di questa attività, anche per semplici strategie di migrazione di rehosting o trasferimento. La creazione di diagrammi architettonici consente di identificare le inefficienze che possono essere risolte rapidamente con piccole modifiche quando si è nel cloud.
A seconda che si stia adottando un approccio dall'alto verso il basso o dal basso verso l'alto, il diagramma iniziale riporterà i componenti e i servizi dell'applicazione o i componenti dell'infrastruttura come server e sistemi di bilanciamento del carico. Dopo aver identificato i componenti e le interfacce principali, convalidali con dati programmatici provenienti dagli strumenti di scoperta e dagli strumenti di monitoraggio delle prestazioni delle applicazioni. Gli strumenti devono supportare l'analisi delle dipendenze e fornire informazioni di comunicazione tra i componenti. Ogni componente che compone questa applicazione deve essere identificato. Successivamente, documenta le dipendenze da altre applicazioni e servizi, sia interni che esterni.
In assenza di strumenti per convalidare le dipendenze e la mappatura, è necessario un approccio manuale. Ad esempio, è possibile accedere ai componenti dell'infrastruttura ed eseguire script per raccogliere informazioni di comunicazione come porte aperte e connessioni stabilite. Allo stesso modo, è possibile identificare i processi in esecuzione e il software installato. Non sottovalutate lo sforzo richiesto per l'individuazione manuale. Gli strumenti programmatici possono acquisire e segnalare la maggior parte delle dipendenze in pochi giorni, ad eccezione di quelle che si verificano a intervalli maggiori (in genere una piccola percentuale). L'individuazione manuale può richiedere settimane per raccogliere e unire tutti i punti dati e può comunque essere soggetta a errori e dati mancanti.
Procedi all'ottenimento delle informazioni specificate nella sezione sui requisiti dei dati per ogni applicazione prioritaria e l'infrastruttura mappata. Successivamente, utilizza il seguente questionario per guidarti attraverso il processo di valutazione dettagliato. Incontra le parti interessate identificate per discutere le risposte a queste domande.
Generali
-
Qual è il livello di criticità di questa applicazione? Genera entrate? È un'applicazione aziendale strategica o di supporto aziendale? È un servizio di infrastruttura di base condiviso da altri sistemi?
-
Esiste un progetto di trasformazione in corso per questa applicazione?
-
Si tratta di un'applicazione rivolta all'interno o all'esterno?
Architettura
-
Qual è il tipo di architettura attuale (ad esempio, SOA, microservizi, monolith)? Quanti livelli ha l'architettura? È accoppiato strettamente o in modo lasco?
-
Quali sono i componenti (ad esempio, elaborazione, database, storage remoto, sistemi di bilanciamento del carico, servizi di memorizzazione nella cache)?
-
Cosa sono le API? Descrivili, tra cui il nome dell'API, le operazioni, gli URL, le porte e i protocolli.
-
Qual è la latenza massima tollerata tra i componenti e tra questa e altre applicazioni o servizi?
Operazioni
-
In quali luoghi funziona questa applicazione?
-
Chi gestisce l'applicazione e l'infrastruttura? Sono gestiti da team interni o AWS partner?
-
Cosa succede se l'applicazione non funziona? Chi è interessato? Qual è l'impatto?
-
Dove si trovano gli utenti o i clienti? Come accedono all'applicazione? Qual è il numero di utenti simultanei?
-
Quando è stato l'ultimo aggiornamento tecnologico? È previsto un aggiornamento in futuro? In caso affermativo, quando?
-
Quali sono i rischi e i problemi noti di questa applicazione? Qual è la cronologia delle interruzioni e degli incidenti di media e alta gravità?
-
Qual è il ciclo di utilizzo (in orario lavorativo)? Qual è il fuso orario di funzionamento?
-
Quali sono i periodi di blocco delle modifiche?
-
Quale soluzione viene utilizzata per monitorare questa applicazione?
Prestazioni
-
Cosa mostrano le informazioni sulle prestazioni raccolte? L'utilizzo è intenso o costante e prevedibile? Quali sono l'intervallo di tempo, l'intervallo e la data dei dati sulle prestazioni disponibili?
-
Esistono processi batch pianificati che fanno parte o interagiscono con questa applicazione?
Ciclo di vita del software
-
Qual è il tasso di variazione attuale (settimanale, mensile, trimestrale o annuale)?
-
Qual è il ciclo di vita dello sviluppo (ad esempio, test, sviluppo, QA, UAT, preproduzione, produzione)?
-
Quali sono i metodi di implementazione per l'applicazione e l'infrastruttura?
-
Quali sono gli strumenti di distribuzione?
-
Questa applicazione o infrastruttura utilizza l'integrazione continua (CI) /la distribuzione continua (CD)? Qual è il livello di automazione? Quali sono le attività manuali?
-
Quali sono i requisiti di licenza per l'applicazione e l'infrastruttura?
-
Cos'è il contratto sul livello di servizio (SLA)?
-
Quali sono gli attuali meccanismi di test? Quali sono le fasi del test?
Migrazione
-
Quali sono le considerazioni sulla migrazione?
A questo punto, prendi nota di tutte le considerazioni relative alla migrazione di questa applicazione. Per una valutazione più completa e accurata, chiedi risposte a questa domanda alle diverse parti interessate. Quindi confronta le loro conoscenze e opinioni.
Resilienza
-
Qual è l'attuale metodo di backup? Quali prodotti vengono utilizzati per il backup? Qual è la pianificazione dei backup? Qual è la politica di conservazione dei backup?
-
Quali sono gli attuali Recovery Point Objective (RPO) e Recovery Time Objective (RTO)?
-
Questa applicazione dispone di un piano di disaster recovery (DR)? In caso affermativo, qual è la soluzione DR?
-
Quando è stato l'ultimo test DR?
Conformità e sicurezza
-
Quali sono i quadri normativi e di conformità che si applicano a questa applicazione? Quali sono le date dell'ultimo e del prossimo audit?
-
Questa applicazione ospita dati sensibili? Cos'è la classificazione dei dati?
-
I dati sono crittografati in transito o a riposo o entrambi? Cos'è il meccanismo di crittografia?
-
Questa applicazione utilizza certificati Secure Sockets Layer (SSL)? Qual è l'autorità emittente?
-
Qual è il metodo di autenticazione per utenti, componenti e altre applicazioni e servizi?
Database
-
Quali database utilizza questa applicazione?
-
Qual è il numero tipico di connessioni simultanee al database? Quali sono il numero minimo e il numero massimo di connessioni?
-
Qual è il metodo di connessione (ad esempio, JDBC, ODBC)?
-
Le stringhe di connessione sono documentate? In caso affermativo, dove?
-
Quali sono gli schemi del database?
-
Il database utilizza tipi di dati personalizzati?
Dipendenze
-
Qual è la dipendenza tra i componenti? Nota tutte le dipendenze che non possono essere risolte e che richiedono la migrazione congiunta dei componenti.
-
I componenti sono suddivisi in diverse ubicazioni? Qual è la connettività tra queste località (ad esempio, WAN, VPN)?
-
Quali sono le dipendenze di questa applicazione rispetto ad altre applicazioni o servizi?
-
Quali sono le dipendenze operative? Ad esempio, cicli di manutenzione e rilascio come l'applicazione di patch a Windows.
