Racconto del cliente
Nel modulo Attività iniziali è stata condivisa la narrazione di Tailwind Traders. Il team operativo centrale e il team della piattaforma di Tailwind Traders hanno esperienza nella gestione dei data center esistenti dell'azienda. Il progetto in corso per la migrazione di due data center ad Azure sta già evidenziando alcune curve di apprendimento critiche che non possono essere gestite con il set di competenze attuale dell'azienda.
Vincoli importanti
In questo momento gli obiettivi più importanti per l'azienda sono la migrazione e il rispetto dei vincoli temporali per uscire dal data center. Per rispettare questa priorità aziendale, i team aziendali e IT hanno messo in secondo piano i requisiti di sicurezza e conformità a lungo termine fino a quando non potranno completare lo sviluppo della piattaforma cloud principale.
Poiché Tailwind Traders non ha familiarità con il cloud, sono pochi i membri dei team operativo, della piattaforma o di amministrazione IT che hanno esperienza con il cloud. L'azienda vuole passare lentamente alle operazioni, alla sicurezza e alla governance moderne, ma è ancora sprovvista di una base cloud che possa essere ridimensionata per soddisfare tali esigenze man mano che diventano più importanti.
Storicamente Tailwind Traders ha operato esclusivamente dalla prospettiva delle operazioni centrali. Di conseguenza, i team del carico di lavoro non possono interagire con gli ambienti di produzione. L'azienda non ha un modo facile per mappare gli asset (macchine virtuali, dati e app) ai carichi di lavoro definiti, quindi i limiti di ogni carico di lavoro possono a volte risultare poco chiari.
Allineamento alle zone di destinazione di Azure
I team delle operazioni e della piattaforma hanno concordato l'allineamento seguente:
- L'architettura concettuale delle zone di destinazione di Azure fungerà da vision a lungo termine per lo stato futuro dell'ambiente cloud. Tutti i team interessati useranno tale architettura come base per lo sviluppo di competenze cloud e per la configurazione dell'ambiente cloud.
- I team useranno l'acceleratore della zona di destinazione di Azure per iniziare con la configurazione dell'ambiente.
- Se in futuro sarà necessario personalizzare l'ambiente, il team userà una delle opzioni di implementazione personalizzate che si allineano alla distribuzione iniziale basata sull'acceleratore o che la estendono.
Deviazione dalle indicazioni standard per la zona di destinazione di Azure
L'elenco seguente illustra come i vincoli hanno spinto Tailwind Traders a deviare dai principi di progettazione per le zone di destinazione di Azure, nonché l'impatto di ogni decisione:
Governance basata sui criteri: Tailwind Traders non ha automatizzato in passato i criteri aziendali. Volendo eseguire rapidamente la migrazione del data center, l'azienda ha scelto di ridurre al minimo la quantità di governance, anche nella distribuzione iniziale di una zona di destinazione.
L'azienda si è impegnata anche a completare il modulo Learn sulla metodologia di governance del Cloud Adoption Framework dopo aver configurato l'ambiente iniziale. Le limitazioni del personale IT dedicato alla migrazione al cloud sono un fattore importante per questa deviazione. La deviazione è stata ulteriormente influenzata dalla resistenza dell'azienda e del reparto IT all'adozione di una governance cloud completa o "Azure Ops".
Democratizzazione delle sottoscrizioni: il team operativo centrale resterà responsabile delle operazioni di produzione per tutti i carichi di lavoro. Questo team consente raramente a un team del carico di lavoro di accedere a un ambiente di produzione, quindi non segue il principio della democratizzazione delle sottoscrizioni.
Se un team del carico di lavoro richiede una deviazione, il team operativo centrale considererà una zona di destinazione dedicata per i singoli carichi di lavoro caso per caso. In caso contrario, Tailwind Traders è fermamente impegnata a mantenere le operazioni centrali e avrà istanze limitate di carichi di lavoro in ambienti di produzione isolati o zone di destinazione dell'applicazione.
Modello di servizio incentrato sulle applicazioni: i processi correlati all'interruzione possono prendere in considerazione i carichi di lavoro, in particolare per gli asset che supportano carichi di lavoro cruciali. A parte le interruzioni, il team operativo centrale non applica distinzioni tra carichi di lavoro e applicazioni per i processi di gestione delle operazioni. I processi principali del team operano, gestiscono, apportano modifiche e ottimizzano tutte le risorse allo stesso modo, indipendentemente dai limiti del carico di lavoro o dall'architettura. Considerati i vincoli temporali per questa migrazione, non risulta fattibile per il team di Tailwind Traders definire i limiti delle app e stabilire un modello di servizio incentrato sulle app.
Molti dei termini nell'elenco precedente verranno spiegati nelle prossime unità di questo modulo Learn. Molti di questi termini saranno inseriti nelle note per creare opportunità di insegnamento.
Queste deviazioni non sottraggono nulla all'accordo di allineamento. Queste deviazioni influiranno tuttavia su alcune opzioni durante la distribuzione dell'acceleratore della zona di destinazione di Azure. Influiranno anche sulla progettazione di singole zone di destinazione dell'applicazione, che vengono distribuite dopo l'avvio della migrazione delle risorse sul cloud.
Queste deviazioni richiederanno anche che i team di Tailwind Traders completino i moduli Learn sulla gestione, la sicurezza e la governance in Cloud Adoption Framework dopo la distribuzione dell'ambiente iniziale.
Limiti aggiuntivi
I vincoli aggiuntivi seguenti potrebbero influire sulle decisioni di Tailwind.
Operazioni
Il team operativo centrale ha creato in modo organico un set di processi e controlli integrati per gestire il portfolio generale. Il team dipende da System Center Operations Manager e Microsoft Configuration Manager per la baseline operativa.
Il team ha anche integrato strumenti di alta gamma per la gestione delle macchine virtuali, la gestione degli eventi imprevisti e della configurazione, il monitoraggio della rete, le operazioni di sicurezza e i controlli di governance, insieme ad altri strumenti. La maggior parte di questi strumenti è integrata in Azure, tanto da influenzare la decisione di usare Azure come provider di servizi cloud principale dell'azienda. Per usare questi strumenti sono necessari un numero di persone e un capitale elevati.
Strumenti per le operazioni
Le licenze per gli strumenti di gestione delle operazioni (inclusi gli hypervisor) richiedono il 20% del budget dei costi vivi IT. Il nuovo CIO (Chief Information Officer) ha sfidato il team perché rivaluti questi strumenti e processi e trovi alternative cloud-first e operative unificate. La riduzione delle spese per gli strumenti sarà considerata dal CIO come primo indicatore per la riuscita della migrazione.
Processi operativi
Il responsabile IT ha richiesto due nuove assunzioni per supportare il team operativo centrale. Queste persone dovranno bilanciare il carico del team che risulta eccessivo. In particolare, dovranno offrire supporto per le procedure di continuità aziendale e ripristino di emergenza (BCDR, Business Continuity And Disaster Recovery) e i processi di conformità delle patch.
L'azienda non è pronta per un passaggio su larga scala alle operazioni native del cloud, in particolare per le applicazioni cruciali. Il direttore informatico (CIO) ritiene che alcuni investimenti negli strumenti per le operazioni native del cloud contribuirebbero a ridurre il carico sul team operativo centrale spostando alcune di queste responsabilità sul provider di servizi cloud.
Il CIO supervisionerà gli spostamenti delle operazioni per migliorare la soddisfazione dei dipendenti e ridurre il carico del team operativo centrale. Richiederà anche aggiornamenti frequenti sugli effetti del piano di adozione sulle procedure BCDR e sull'applicazione delle patch.
Contratto di servizio
Nonostante tutto il lavoro e i costi legati alle operazioni, il team non sempre soddisfa il contratto di servizio con tempo di attività al 90% per i sistemi cruciali nel data center primario. Per il CIO e l'amministratore delegato (CEO) si tratta di un problema serio in termini di costi. L'hardware obsoleto e un ritardo nel ciclo di aggiornamento nel data center hanno determinato interruzioni frequenti ma brevi.
Sebbene la società abbia accettato con riluttanza questo contratto di servizio, il nuovo CIO non è soddisfatto. Indipendentemente dal risparmio in termini economici, il CIO si aspetta che il team operativo centrale assicuri un contratto di servizio molto più elevato dopo la migrazione.
Retail Innovation
Nella narrazione del cliente del modulo Attività iniziali è stato presentato il team Retail Innovation di Tailwind Traders. Il team era originariamente una startup acquisita da Tailwind Traders. Il CEO originale della startup è ora Chief Technology Officer (CTO) di Tailwind. Il CTO gestisce ancora tale divisione come una startup, privilegiando la sperimentazione e l'innovazione.
Per i processi correnti di gestione delle operazioni è necessario che tutte le innovazioni proposte dal team siano sottoposte a un processo di rilascio. Per motivi di sicurezza, governance e gestione delle operazioni, il team operativo centrale IT ne esamina l'architettura. Quando il team è soddisfatto della soluzione, la rilascia in un ambiente di produzione gestito centralmente. È previsto che il processo continui nel cloud.
Gestione delle identità
Active Directory è l'archivio identità e lo strumento primario per l'autenticazione e il controllo di accesso nei data center di Tailwind Traders. L'azienda ha usato alcuni dei migliori sistemi disponibili per estendere la gestione delle identità in una soluzione di autenticazione a più fattori e Sono state anche federate le identità per distribuire la soluzione Microsoft 365. Ciononostante, Active Directory rimane la soluzione per la gestione delle identità di Tailwind Traders.
Nel cloud l'azienda ha ora più opzioni, ad esempio Microsoft Entra ID o Microsoft Entra Domain Services in esecuzione in un'infrastruttura IaaS (infrastruttura distribuita come servizio). Il team operativo centrale sta faticosamente mettendo a confronto le opzioni per scegliere la soluzione di gestione delle identità migliore per i piani di adozione del cloud.
Topologia di rete e connettività
Tailwind Traders usa linee MPLS (Multiprotocol Label Switching) per connettere i data center e i negozi fisici. Tutto il traffico Internet viene incanalato attraverso il data center principale. A causa di conflitti IP (Internet Protocol) tra i due data center, il traffico è isolato e il routing dipende da tabelle di routing complesse. La connettività esterna al data center o alla sede aziendale fornita tramite rete privata virtuale è limitata e non è consigliata.
I data center primari e secondari usano schemi di indirizzi IP coerenti che sono ben gestiti e organizzati in modo intuitivo. Il terzo data center include 50 blocchi IP diversi con coerenza minima e nessun piano definito per l'organizzazione o la segmentazione. I cicli di innovazione continua sono limitati al terzo data center, ma potrebbero presentare problemi durante la definizione della topologia di rete e del routing nel cloud.
Organizzazione delle risorse
Durante la segmentazione delle risorse tra i data center, ogni raccolta di carichi di lavoro è stata gestita come grande blocco di risorse. Ogni raccolta è stata quindi divisa in base al profilo di rischio per creare segmenti isolati e controllati e consentire un flusso di rete limitato tra carichi di lavoro. I carichi di lavoro che richiedono una connessione di rete in ingresso da qualsiasi rete non protetta sono isolati in uno o più segmenti della rete perimetrale di ogni data center.
Al di là di questa organizzazione di base, esistono incoerenze nel database di gestione della configurazione, quindi è difficile stabilire quali asset sono associati a quali carichi di lavoro. I proprietari dei carichi di lavoro e le catene di escalation degli eventi imprevisti sono ben definiti per i carichi di lavoro cruciali, ma mancano per la maggior parte degli altri tipi di carico di lavoro.
Per i carichi di lavoro meno critici, il proprietario identificato è generalmente un ex dipendente di Tailwind Traders. Il mapping della configurazione spesso fa riferimento a macchine virtuali che sono state terminate. Analogamente, per oltre il 30% degli asset supportati non esiste un mapping chiaro con un singolo carico di lavoro. Durante la migrazione la società avrà bisogno di procedure corrette per garantire l'analisi delle dipendenze e un'organizzazione delle risorse appropriata.