# Rappresentazioni del modello operativo 2x2 Queste rappresentazioni del modello operativo 2x2 sono illustrazioni che ti aiutano a comprendere le relazioni tra i team nel tuo ambiente. Questi diagrammi si concentrano sulle competenze e sulle relazioni tra i team, ma discuteremo anche di governance e processi decisionali nel contesto di questi esempi. I team possono avere responsabilità in vari ambiti di più modelli, a seconda del carico di lavoro che supportano. Potrebbe esserti utile effettuare una suddivisione in aree disciplinari più specializzate, rispetto a quelle di alto livello qui descritte. Questi modelli offrono infinite possibilità di variazioni, separando o aggregando le attività o sovrapponendo i team e fornendo dettagli più specifici. Potresti rilevare che disponi di funzionalità sovrapposte o non riconosciute da un team all'altro, che possono fornire ulteriori vantaggi o migliorare l'efficienza. Potresti inoltre identificare le esigenze insoddisfatte nella tua organizzazione e pianificare di affrontarle. Durante la valutazione del cambiamento organizzativo, esamina i compromessi tra i diversi modelli, la posizione dei singoli team all'interno dei modelli (allo stato attuale e dopo il cambiamento), come cambieranno le relazioni e le responsabilità dei team e se i vantaggi meritano l'impatto sulla tua organizzazione. È possibile utilizzare con successo ciascuno dei seguenti quattro modelli operativi. Alcuni modelli sono più appropriati per casi d'uso specifici o in momenti specifici dello sviluppo. Alcuni di questi modelli possono offrire vantaggi rispetto a quelli in uso nel tuo ambiente. **Topics** + [Modello operativo completamente separato](fully-separated-operating-model.md) + [DevOps con fornitori di servizi gestiti sul cloud](devops-with-cloud-managed-service-provider.md) + [Operatività cloud e abilitazione della piattaforma (COPE)](cloud-operations-and-platform-enablement.md) + [DevOps distribuito](distributed-devops.md) + [DevOps decentralizzato](decentralized-devops.md) + [Evoluzione del modello operativo](evolving-your-ops-model.md) # Modello operativo completamente separato Nel seguente diagramma, sull'asse verticale si trovano applicazioni e piattaforma. Le applicazioni si riferiscono al carico di lavoro preposto a un risultato aziendale e possono consistere di software sviluppato in modo personalizzato o pronto all'uso. La piattaforma si riferisce all'infrastruttura fisica e virtuale e ad altri software che supportano tale carico di lavoro. Sull'asse orizzontale si trovano progettazione e operazioni. La progettazione si riferisce allo sviluppo, alla realizzazione e all'esecuzione di test di applicazioni e infrastruttura. Le operazioni consistono nell'implementazione, l'aggiornamento e il supporto continuo delle applicazioni e dell'infrastruttura. ![\[Diagramma del modello tradizionale\]](http://docs.aws.amazon.com/it_it/wellarchitected/latest/operational-excellence-pillar/images/full-seperate.png) Da sempre, le organizzazioni adottano framework come ITIL o norme come ISO e modellano le loro attività operative sulla base di questi elementi, il che spesso porta a una topologia completamente separata. In questo modello, l'esecuzione delle attività in ciascun quadrante avviene a opera di un team separato. Il lavoro è trasferito da un team all'altro attraverso meccanismi quali richieste di lavoro, code, ticket o utilizzando un sistema di gestione dei servizi IT (ITSM). La transizione delle attività verso o tra i team aumenta la complessità e crea ritardi e colli di bottiglia. Le richieste tendono a essere posticipate finché non rappresentano una priorità. I difetti identificati in ritardo potrebbero richiedere una rilavorazione significativa e un secondo passaggio attraverso gli stessi team e le loro funzioni. Se ci sono incidenti che richiedono un'azione da parte dei team di tecnici, le loro risposte vengono ritardate dall'attività di consegna. Quando i team aziendali, di sviluppo e operativi sono organizzati in base alle attività o alle funzioni eseguite, esiste un maggiore rischio di disallineamento. Questo può portare i team a concentrarsi sulle loro responsabilità specifiche anziché sul raggiungimento dei risultati aziendali. I team possono essere strettamente specializzati, fisicamente isolati o logicamente isolati, ostacolando la comunicazione e la collaborazione. # DevOps con fornitori di servizi gestiti sul cloud Il modello DevOps con fornitori di servizi gestiti sul cloud segue la metodologia *chi crea, esegue* per i team applicativi. Tuttavia, la tua organizzazione potrebbe non avere le competenze o il personale per supportare un team dedicato alla progettazione e alle operazioni della piattaforma, oppure potresti non essere nella posizione di investire tempo e fatica in questa direzione. In alternativa, potresti disporre di un team di piattaforma incentrato sulla creazione di funzionalità che differenzieranno la tua attività, ma desideri esternalizzare le operazioni quotidiane indifferenziate. I fornitori di servizi gestiti, come [AWS Managed Services](https://aws.amazon.com/managed-services/) o i fornitori della [AWS Partner Network](https://aws.amazon.com/partners/find/results/?keyword=Managed+Service+Provider) offrono esperienza nell'implementazione di ambienti cloud e supportano i requisiti di sicurezza e conformità e gli obiettivi aziendali. ![\[DevOps con fornitori di servizi gestiti sul cloud\]](http://docs.aws.amazon.com/it_it/wellarchitected/latest/operational-excellence-pillar/images/devops-msp.en.png) Per questa variante, prendiamo in esame la governance centralizzata e gestita dal team della piattaforma, con la creazione di account e la gestione di policy con AWS Organizations e AWS Control Tower. Questo modello richiede di modificare i tuoi meccanismi affinché funzionino con quelli del fornitore di servizi. Non risolve i colli di bottiglia e i ritardi creati dalla transizione delle attività tra i team, tra cui il fornitore di servizi, né le potenziali rilavorazioni correlate all'identificazione tardiva dei difetti. Puoi trarre vantaggio dagli standard, dalle best practice, dai processi e dalle competenze dei tuoi fornitori. Inoltre, ottieni i vantaggi dello sviluppo continuo delle loro offerte di servizi. L'aggiunta di servizi gestiti al tuo modello operativo ti consente di risparmiare tempo e risorse e ti permette di mantenere i team interni snelli e focalizzati sui risultati strategici che differenzieranno la tua attività, anziché sullo sviluppo di nuove competenze e funzionalità. Inoltre, può concederti il tempo necessario per creare e sviluppare le funzionalità della tua piattaforma senza rallentare i programmi di migrazione al cloud. # Operatività cloud e abilitazione della piattaforma (COPE) Il modello di operatività cloud e abilitazione della piattaforma (COPE) è finalizzato a stabilire una metodologia *chi crea, esegue*, supportando i team applicativi nell'esecuzione delle attività ingegneristiche e operative per i loro carichi di lavoro, adottando una cultura DevOps. I team applicativi potrebbero essere in fase di migrazione, di adozione del cloud o di modernizzazione dei carichi di lavoro e non disporre delle competenze necessarie per supportare adeguatamente operazioni e architettura del cloud. È probabile che questa mancanza di competenze e conoscenze tra i team applicativi rallenti l'agilità dell'organizzazione e pregiudichi i risultati aziendali. Per risolvere questo problema, utilizza le competenze operative esistenti all'interno dell'organizzazione per supportare i team applicativi nel loro percorso verso le operazioni sul cloud. Può trattarsi di un team dedicato di esperti o di un team virtuale con partecipanti selezionati da tutta l'organizzazione. Tuttavia, l'obiettivo è lo stesso: fornire un supporto operativo che rafforzi le capacità del team addetto ai carichi di lavoro, utilizzando i principi di automazione cloud first, eliminando i lavori più impegnativi indifferenziati, fornendo modelli standardizzati e promuovendo l'autonomia. L'obiettivo è raggiungere una maturità sufficiente tra le funzionalità cloud e ridurre la barriera delle responsabilità operative in modo che ai team delle applicazioni non serva più supporto aggiuntivo. Il modello COPE è incentrato sul livello del carico di lavoro. Se questo approccio serve per più team allo stesso momento, se stai eseguendo un progetto di migrazione complesso, su vasta scala e pluriennale o se stai creando una piattaforma per supportare tali iniziative, prendi in considerazione l'utilizzo di un Centro di eccellenza del Cloud (CCoE) Si tratta di un meccanismo da molti ritenuto efficace nell'accelerare le migrazioni verso il cloud e nel trasformare radicalmente la propria organizzazione. ![\[Schema dell'operatività cloud e abilitazione della piattaforma\]](http://docs.aws.amazon.com/it_it/wellarchitected/latest/operational-excellence-pillar/images/cope.en.png) Il team di progettazione della piattaforma crea un piccolo livello di funzionalità di base condivise della piattaforma, basate su standard predefiniti che i team applicativi possono adottare, e fornite dal team COPE. Il team di ingegneri della piattaforma codifica le architetture e i modelli di riferimento aziendali che vengono forniti ai team applicativi attraverso un meccanismo self-service. Utilizzando un servizio come AWS Service Catalog, i team applicativi possono distribuire architetture di riferimento, modelli, servizi e configurazioni approvati, conformi per impostazione predefinita agli standard di sicurezza e di governance centralizzati. Il team di progettazione della piattaforma fornisce un set standardizzato di servizi (ad esempio, strumenti di sviluppo, strumenti di osservabilità, strumenti di backup e ripristino e rete) ai team applicativi. Il team COPE gestisce e supporta i servizi standardizzati, oltre a fornire assistenza ai team applicativi nello stabilire la propria presenza sul cloud in base ad architetture e modelli di riferimento. Collabora con i team applicativi per aiutarli a definire le operazioni di base. Durante il processo, i team applicativi assumono nel tempo sempre più responsabilità per i propri sistemi e risorse. Il team COPE promuove il miglioramento continuo insieme al team di ingegneri della piattaforma e agisce come promotore per i team applicativi. I team applicativi ricevono assistenza per la creazione di ambienti, pipeline CI/CD, gestione delle modifiche, osservabilità e monitoraggio, nonché per la creazione di processi di gestione degli incidenti e degli eventi con il team COPE integrato, secondo necessità. Il team COPE partecipa con i team applicativi allo svolgimento di tali attività operative, riducendo gradualmente l'impegno del team COPE nel corso del tempo, man mano che i team applicativi se ne assumono la responsabilità. Il team applicativo beneficia delle competenze del team COPE e delle lezioni apprese dall'organizzazione. È protetto dai guardrail stabiliti dalla governance centralizzata. Il team applicativo si basa sui successi riconosciuti e ottiene il beneficio di uno sviluppo continuo degli standard organizzativi adottati. Grazie al processo di osservabilità e monitoraggio, le persone acquisiscono una maggiore conoscenza del funzionamento del loro carico di lavoro e sono in grado di comprendere meglio l'impatto delle modifiche ad esso apportate. Il team COPE potrebbe anche mantenere l'accesso necessario per supportare le attività operative, fornire una visione delle operazioni aziendali che abbracci i team applicativi e offrire un supporto alla gestione degli incidenti critici. Il team COPE mantiene la responsabilità delle attività considerate come indifferenziate e a basso valore aggiunto, che soddisfa attraverso soluzioni standard supportabili su larga scala. Continua inoltre a gestire attività programmatiche e automatizzate ben comprese dai team applicativi, in modo che possano concentrarsi sulla differenziazione delle loro applicazioni. In questo modo approfitti del vantaggio degli standard, delle best practice, dei processi e delle competenze dell'organizzazione, derivanti dai successi dei suoi team. Stabilisci un meccanismo per replicare questi modelli di successo per i nuovi team che adottano o modernizzano il cloud. Questo modello pone l'accento sulla capacità del team COPE di aiutare il team applicativo ad avviare le attività e a trasferire conoscenze e artefatti. Riduce gli oneri operativi dei team applicativi, con il rischio che questi ultimi non riescano a diventare indipendenti. Definisce le relazioni tra team di ingegneri, COPE e applicativi, creando un ciclo di feedback a supporto di ulteriori evoluzioni e innovazioni. L'istituzione di team di ingegneri della piattaforma e COPE, oltre alla definizione di standard a livello di organizzazione, possono facilitare l'adozione del cloud e sostenere gli sforzi di modernizzazione. Attraverso il supporto aggiuntivo di un team COPE che agisce come consulente e partner dei team applicativi, è possibile rimuovere le barriere di livello del carico di lavoro, che rallentano l'adozione delle vantaggiose funzionalità cloud da parte dei team applicativi. # DevOps distribuito Il modello DevOps distribuito separa (o distribuisce) le operazioni di ingegneria delle applicazioni e le responsabilità operative degli ingegneri dell'infrastruttura tra i team di progettazione, secondo la metodologia [COPE](cloud-operations-and-platform-enablement.md). Gli ingegneri applicativi si occupano sia della progettazione sia del funzionamento dei propri carichi di lavoro. Analogamente, i tecnici dell'infrastruttura si occupano sia della progettazione sia del funzionamento delle piattaforme che utilizzano per supportare i team applicativi. ![\[Diagramma del modello DevOps distribuito\]](http://docs.aws.amazon.com/it_it/wellarchitected/latest/operational-excellence-pillar/images/distributed-devops.en.png) Per questo esempio, consideriamo la governance come centralizzata altrove all'interno dell'organizzazione. Gli standard sono distribuiti, forniti o condivisi ai team applicativi e della piattaforma. Utilizza strumenti o servizi che consentono di gestire centralmente gli ambienti su più account, ad esempio [AWS Organizations](https://aws.amazon.com/organizations/). Servizi come [AWS Control Tower](https://aws.amazon.com/controltower/features/) ampliano questa funzionalità di gestione consentendoti di definire blueprint (a supporto dei tuoi modelli operativi) per configurare gli account, applicare la governance continua tramite AWS Organizations e automatizzare il provisioning di nuovi account. *"Chi crea, esegue"* non significa che il team applicativo sia responsabile dell'intero stack, della catena di strumenti e della piattaforma nel loro complesso. Il team di progettazione della piattaforma fornisce un set standardizzato di servizi (ad esempio, strumenti di sviluppo, strumenti di monitoraggio, strumenti di backup e ripristino e rete) al team applicativo. Il team della piattaforma può anche fornire al team applicativo l'accesso a servizi di fornitori di servizi cloud approvati, configurazioni specifiche dello stesso o entrambi. I meccanismi che forniscono funzionalità self-service per l'implementazione di servizi e configurazioni approvati, come Service Catalog, limitano i ritardi associati alle richieste di adempimento, applicando al contempo la governance. Il team della piattaforma attiva la visibilità a stack completo, in modo che i team applicativi possano distinguere tra i problemi dei componenti dell'applicazione e i problemi dei componenti dei servizi e dell'infrastruttura utilizzati dalle applicazioni. Il team della piattaforma può inoltre fornire assistenza per la configurazione di questi servizi, nonché indicazioni su come migliorare le operazioni dei team applicativo. Come illustrato in precedenza, è fondamentale che il team applicativo disponga di meccanismi per richiedere aggiunte, modifiche ed eccezioni agli standard, a supporto delle attività e dell'innovazione della loro applicazione. Il modello DevOps distribuito fornisce cicli di feedback solidi ai team applicativi. Le operazioni quotidiane di un carico di lavoro aumentano il contatto con i clienti attraverso l'interazione diretta o indirettamente, attraverso richieste di supporto e funzionalità. Questa maggiore visibilità consente ai team applicativi di risolvere i problemi più rapidamente. Il coinvolgimento più profondo e la relazione più stretta forniscono informazioni sulle esigenze dei clienti e consentono un'innovazione più rapida. Tutto ciò vale anche per il team della piattaforma che supporta i team applicativi, vedendo tali team come propri clienti. Gli standard adottati possono essere pre-approvati per l'uso, riducendo la quantità di revisione necessaria per entrare in produzione. L'utilizzo di standard supportati e testati forniti dal team della piattaforma può ridurre la frequenza dei problemi relativi a tali servizi. L'adozione degli standard aiuta i team applicativi a concentrarsi sulla differenziazione dei propri carichi di lavoro. # DevOps decentralizzato Il modello DevOps decentralizzato costituisce una variante della metodologia *chi crea esegue* in cui le operazioni sono perlopiù di proprietà dei team responsabili dei carichi di lavoro. Gli ingegneri delle applicazioni si occupano sia della progettazione sia del funzionamento dei propri carichi di lavoro. Analogamente, i tecnici dell'infrastruttura si occupano sia della progettazione sia del funzionamento delle piattaforme che utilizzano per supportare i team applicativi. ![\[Diagramma del modello DevOps decentralizzato\]](http://docs.aws.amazon.com/it_it/wellarchitected/latest/operational-excellence-pillar/images/decentralized-devops.en.png) Per questo esempio, considereremo la governance come decentralizzata. Gli standard sono ancora distribuiti, forniti o condivisi ai team applicativi dal team della piattaforma, ma i team applicativi sono liberi di progettare e gestire nuove funzionalità della piattaforma a supporto del proprio carico di lavoro. In questo modello, ci sono meno vincoli per il team applicativo, ma ciò comporta un aumento significativo delle responsabilità. Devono essere presenti ulteriori competenze, e potenzialmente altri membri del team, per supportare le funzionalità aggiuntive della piattaforma. Il rischio di rilavorazione significativa aumenta se i set di competenze non sono adeguati e i difetti non vengono riconosciuti in anticipo. Applica policy che non siano specificamente delegate ai team applicativi. Utilizza strumenti o servizi che consentono di gestire centralmente gli ambienti su più account, ad esempio [AWS Organizations](https://aws.amazon.com/organizations/). Servizi come [AWS Control Tower](https://aws.amazon.com/controltower/features/) ampliano questa funzionalità di gestione consentendoti di definire blueprint (a supporto dei tuoi modelli operativi) per configurare gli account, applicare la governance continua tramite AWS Organizations e automatizzare il provisioning di nuovi account. È preferibile che il team applicativo disponga di meccanismi per richiedere aggiunte e modifiche agli standard. Il team può contribuire a nuovi standard che possono fornire vantaggi ad altri team applicativi. I team della piattaforma possono decidere che fornire supporto diretto per queste funzionalità aggiuntive sia un contributo efficace ai risultati aziendali. Questo modello limita i vincoli all'innovazione e presenta requisiti significativi in termini di competenze e personale. Risolve molti dei colli di bottiglia e dei ritardi creati dalla transizione delle attività tra i team, promuovendo allo stesso tempo lo sviluppo di relazioni efficaci tra team e clienti. # Evoluzione del modello operativo I modelli forniti si evolvono in modo progressivo verso una maggiore autonomia a livello di carico di lavoro, in linea con il principio del team da due pizze. È importante capire che questo percorso da un approccio tradizionale al modello DevOps decentralizzato (come base per una continua evoluzione verso un modello di team da due pizze) richiederà probabilmente tempo, oltre alla creazione di una maturità attraverso una serie di capacità. Ecco perché abbiamo fornito un esempio di transizione da un modello all'altro nel corso del percorso di trasformazione aziendale di team e organizzazione. In ciascun cambiamento o modello, la tua evoluzione procede verso team più autonomi, ma sempre in linea con l'organizzazione. ![\[Diagramma di evoluzione del modello operativo del cloud da flussi e processi di valore on-premises a flussi di valore e processi automatizzati\]](http://docs.aws.amazon.com/it_it/wellarchitected/latest/operational-excellence-pillar/images/evolving-ops.en.png) Durante la valutazione del modo i cui i tuoi team possono supportare l'evoluzione dell'organizzazione, esamina i compromessi tra i vari modelli, la posizione dei singoli team all'interno dei modelli (durante la loro transizione ed evoluzione), come cambieranno le relazioni e le responsabilità dei team e se i vantaggi giustificano l'impatto sulla tua organizzazione. Tieni presente che il cambiamento non è mai lineare. Alcuni modelli sono più adeguati a casi d'uso o momenti specifici del percorso e alcuni di questi possono offrire vantaggi rispetto a quelli applicati nel tuo ambiente.