# Modello operativo
Questa sezione presenta un modo per comprendere il modello operativo che si utilizza, le relative modalità di visualizzazione e in che modo, a livello di team, dovresti evolverti per ottenere il massimo valore dal tuo investimento nei servizi cloud. In questo modo, potrai migliorare le tue pratiche operative, creare team e carichi di lavoro agili e apportare un contributo positivo ai risultati aziendali.
È normale che il team si trovi all'interno di più livelli organizzativi e che tali livelli presentino modalità di lavoro già in atto. Partecipare con il team al conseguimento dei risultati aziendali significa capire dove si trovano i team in tali livelli, la posizione dei team con cui interagisci e le loro modalità di lavoro. Inoltre, i team devono comprendere il loro ruolo nel successo degli altri team, conoscere il ruolo degli altri team nel loro successo e avere obiettivi condivisi.
Tali livelli costituiscono il modello operativo generale dell'organizzazione. Il funzionamento dell'organizzazione per conseguire i risultati aziendale dipende da diversi fattori, come la tipologia, il settore, la geografia, le dimensioni e il livello di autonomia. Tuttavia, è probabile che rientri in tre grandi categorie:
+ Centralizzato
+ Decentralizzato
+ Federato
Tali topologie a livello di organizzazione sono illustrate in [Organize for success](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-cloud-operating-model/implement-roadmap.html#organize).
Team e carico di lavoro si trovano nel modello operativo dell'organizzazione. Tuttavia, non è ragionevole aspettarsi che un singolo modello operativo sia in grado di supportare tutti i team e i relativi carichi di lavoro. Pertanto, anche al tuo team serve un proprio modello operativo. Questo modo di lavorare dipende dalla tua organizzazione, dal tuo reparto, dalla composizione del team e dalle caratteristiche del carico di lavoro stesso.
Il passaggio al cloud per la maggior parte delle organizzazioni avviene nell'ambito di un programma di trasformazione aziendale volto a individuare nuovi modi di lavorare (il modello operativo) a supporto degli obiettivi strategici a lungo termine. Questo percorso non è immediato, ma si tratta di un processo che richiede un'evoluzione continua e progressi crescenti verso l'obiettivo strategico. Ciò consente ai proprietari dei carichi di lavoro di adattarsi all'evoluzione del modello operativo con interruzioni minime.
Amazon costituisce spesso l'esempio di come una grande organizzazione sia in grado di innovare su larga scala permettendo ai team di restare vicini ai clienti, lanciare in modo rapido prodotti e servizi innovativi e sfruttare le architetture tecniche che supportano velocità e agilità. Tutto questo ci ha imposto di rivedere le modalità organizzative dei nostri team, noti oggi come *team da due pizze*. Un team da due pizze dispone di tutte le risorse necessarie al suo interno (progettazione, test, gestione dei prodotti e dei programmi e operazioni) per la gestione ed esecuzione di un carico di lavoro dall'inizio alla fine.
Consigliamo di adottare questo modello operativo collaudato per consentire ai team dei carichi di lavoro di agire rapidamente e contribuire ai risultati aziendali complessivi nel modo più adatto ai propri clienti.
Le organizzazioni che cercano di emulare questo successo potrebbero dover adattare il proprio modello operativo durante il percorso di trasformazione. A livello di organizzazione e di team, ciò richiede valutazioni, pianificazioni e comunicazione. La seguente sezione offre un modo per visualizzare questi modelli operativi a livello di team e le relative modalità di evoluzione in base al principio *chi crea, esegue*.
# 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.
# Relazioni e proprietà
Il modello operativo definisce le relazioni tra i team e supporta proprietà e responsabilità identificabili.
**Topics**
+ [OPS02-BP01 Le risorse hanno identificato i proprietari](ops_ops_model_def_resource_owners.md)
+ [OPS02-BP02 Assegnazione di proprietari identificati a processi e procedure](ops_ops_model_def_proc_owners.md)
+ [OPS02-BP03 Assegnazione di proprietari identificati alle operazioni che siano responsabili delle relative prestazioni](ops_ops_model_def_activity_owners.md)
+ [OPS02-BP04 Definizione di meccanismi per gestire responsabilità e titolarità](ops_ops_model_def_responsibilities_ownership.md)
+ [OPS02-BP05 Definizione di meccanismi per richiedere aggiunte, modifiche ed eccezioni](ops_ops_model_req_add_chg_exception.md)
+ [OPS02-BP06 Predefinizione o negoziazione delle responsabilità tra i team](ops_ops_model_def_neg_team_agreements.md)
# OPS02-BP01 Le risorse hanno identificato i proprietari
Le risorse per il tuo carico di lavoro devono disporre di proprietari identificati per il controllo delle modifiche, la risoluzione dei problemi e altre funzioni. I proprietari sono assegnati a carichi di lavoro, account, infrastrutture, piattaforme e applicazioni. La registrazione della proprietà avviene tramite strumenti come un registro centrale o metadati collegati alle risorse. Il valore aziendale dei componenti è alla base dei processi e delle procedure applicate.
**Risultato desiderato:**
+ Le risorse presentano proprietari identificati tramite i metadati o un registro centrale.
+ I membri del team possono identificare chi è il proprietario delle risorse.
+ Gli account hanno un solo proprietario, laddove possibile.
**Anti-pattern comuni:**
+ I tuoi contatti alternativi non sono popolati. Account AWS
+ Risorse prive di tag che identificano i team proprietari.
+ Hai una ITSM coda senza una mappatura delle email.
+ Due team con entrambi la proprietà di una parte critica dell'infrastruttura.
**Vantaggi dell'adozione di questa best practice:**
+ Il controllo delle modifiche per le risorse è immediato con la proprietà assegnata.
+ Puoi coinvolgere i proprietari corretti quando risolvi i problemi.
**Livello di rischio associato se questa best practice non fosse adottata:** elevato
## Guida all'implementazione
Definisci qual è il significato della proprietà per i casi d'uso delle risorse nel tuo ambiente. Proprietà significa supervisionare le modifiche alla risorsa, supportare la risorsa durante la risoluzione dei problemi o essere finanziariamente affidabile. Specifica e registra i proprietari delle risorse, con nome, informazioni di contatto, organizzazione e team.
**Esempio del cliente**
AnyCompany La vendita al dettaglio definisce la proprietà come il team o l'individuo responsabile delle modifiche e del supporto alle risorse. Sfruttano AWS Organizations per gestire le proprie Account AWS. Contatti alternativi degli account sono configurati con caselle di posta di gruppo. Ogni ITSM coda è associata a un alias e-mail. I tag identificano chi possiede le risorse. AWS Per altre piattaforme e infrastrutture, è presente una pagina wiki che identifica proprietà e informazioni di contatto.
### Passaggi dell'implementazione
1. Inizia definendo la proprietà dell'organizzazione. La proprietà può significare essere proprietari del rischio collegato alla risorsa, delle modifiche alla risorsa o supportare la stessa durante la risoluzione dei problemi. Proprietà può anche significare proprietà amministrativa o finanziaria della risorsa.
1. Usa [AWS Organizations](https://aws.amazon.com/organizations/) per gestire gli account. Puoi gestire a livello centrale i contatti alternativi per gli account.
1. Se usi indirizzi e-mail e numeri di telefono aziendali come informazioni di contatto, puoi accedervi anche se le persone a cui appartengono non fanno più parte dell'organizzazione. Ad esempio, crea elenchi di distribuzione delle e-mail separati per fatturazione, operazioni e sicurezza e configurali come contatti per Fatturazione, Sicurezza e Operazioni in ogni Account AWS attivo. Più persone riceveranno AWS notifiche e saranno in grado di rispondere, anche se qualcuno è in vacanza, cambia ruolo o lascia l'azienda.
1. Se un account non è gestito da [AWS Organizations](https://aws.amazon.com/organizations/), i contatti alternativi dell'account aiutano AWS a contattare il personale opportuno, se necessario. Configura i contatti alternativi dell'account per indirizzare le persone a un gruppo invece che a un individuo.
1. Utilizza i tag per identificare i proprietari AWS delle risorse. Puoi specificare i proprietari e le loro informazioni di contatto in tag separati.
1. Puoi utilizzare le regole di [AWS Config](https://aws.amazon.com/config/) per far sì che le risorse presentino i tag di proprietà richiesti.
1. Per una guida approfondita su come creare una strategia di tagging per la tua organizzazione, consulta il [whitepaper AWS Tagging Best Practices](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html).
1. Usa [Amazon Q Business](https://aws.amazon.com/q/business/), un assistente conversazionale che utilizza l'IA generativa per migliorare la produttività della forza lavoro, rispondere a domande e completare attività in base alle informazioni presenti nei sistemi aziendali.
1. Collega Amazon Q Business all'origine dati della tua azienda. Amazon Q Business offre connettori predefiniti per oltre 40 fonti di dati supportate, tra cui Amazon Simple Storage Service (Amazon S3), SharePoint Microsoft, Salesforce e Atlassian Confluence. Per ulteriori informazioni, consulta [Connettori di Amazon Q Business](https://aws.amazon.com/q/business/connectors/).
1. Per altre risorse, piattaforme e infrastrutture, crea la documentazione che stabilisce la proprietà. Tutti i membri del team devono poter accedere a queste informazioni.
**Livello di impegno per il piano di implementazione:** basso Sfrutta le informazioni di contatto e i tag dell'account per assegnare la proprietà delle risorse. AWS Per altre risorse puoi usare qualcosa di semplice come una tabella in un wiki per registrare la proprietà e le informazioni di contatto, oppure usare ITSM uno strumento per mappare la proprietà.
## Risorse
**Best practice correlate:**
+ [OPS02-BP02 I processi e le procedure hanno identificato i proprietari](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_proc_owners.html)
+ [OPS02-BP04 Esistono meccanismi per gestire le responsabilità e la proprietà](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_responsibilities_ownership.html)
**Documenti correlati:**
+ [AWS Account Management - Updating contact information](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact.html)
+ [AWS Organizations - Aggiornamento dei contatti alternativi all'interno dell'organizzazione](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_update_contacts.html)
+ [Whitepaper AWS Tagging Best Practices](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)
+ [Crea app di intelligenza artificiale generativa aziendali private e sicure con Amazon Q Business e AWS IAM Identity Center](https://aws.amazon.com/blogs/machine-learning/build-private-and-secure-enterprise-generative-ai-apps-with-amazon-q-business-and-aws-iam-identity-center/)
+ [Amazon Q Business, now generally available, helps boost workforce productivity with generative AI](https://aws.amazon.com/blogs/aws/amazon-q-business-now-generally-available-helps-boost-workforce-productivity-with-generative-ai/)
+ [Cloud AWS Blog Operations & Migrations - Implementazione di controlli di tagging automatizzati e centralizzati con e AWS ConfigAWS Organizations](https://aws.amazon.com/blogs/mt/implementing-automated-and-centralized-tagging-controls-with-aws-config-and-aws-organizations/)
+ [AWS Blog sulla sicurezza - Estendi i tuoi hook di pre-commit con AWS CloudFormation Guard](https://aws.amazon.com/blogs/security/extend-your-pre-commit-hooks-with-aws-cloudformation-guard/)
+ [AWS DevOps Blog - Integrazione AWS CloudFormation Guard nelle pipeline CI/CD](https://aws.amazon.com/blogs/devops/integrating-aws-cloudformation-guard/)
**Workshop correlati:**
+ [Workshop AWS - Tagging](https://catalog.workshops.aws/tagging/)
**Esempi correlati:**
+ [Regole di AWS Config - Amazon EC2 con tag obbligatori e valori validi](https://github.com/awslabs/aws-config-rules/blob/master/python/ec2_require_tags_with_valid_values.py)
**Servizi correlati:**
+ [Regole di AWS Config - tag obbligatori](https://docs.aws.amazon.com/config/latest/developerguide/required-tags.html)
+ [AWS Organizations](https://aws.amazon.com/organizations/)
# OPS02-BP02 Assegnazione di proprietari identificati a processi e procedure
È utile sapere chi ha la proprietà della definizione di singoli processi e procedure, poiché tali processi e procedure specifici vengono utilizzati e perché tale proprietà esiste. Comprendere i motivi per cui vengono utilizzati processi e procedure specifici aiuta a identificare le opportunità di miglioramento.
**Risultato desiderato:** la tua organizzazione dispone di una serie di processi e procedure per le attività operative ben definiti e gestiti. L'archiviazione di processi e procedure avviene in una posizione centrale e questi sono a disposizione dei membri del team. I processi e le procedure vengono aggiornati di frequente attraverso l'assegnazione chiara della proprietà. Ove possibile, script, modelli e documenti di automazione vengono implementati come codice.
**Anti-pattern comuni:**
+ Mancata documentazione dei processi. È possibile la presenza di script frammentati su workstation degli operatori isolate.
+ Conoscenza relativa all'uso degli script nelle mani di pochi individui oppure l'acquisizione avviene in modo informale come conoscenza di team.
+ Necessità di aggiornare un processo legacy, ma manca chiarezza circa la proprietà dell'aggiornamento e l'autore originale non fa più parte dell'organizzazione.
+ Non è possibile individuare processi e script, quindi non sono immediatamente disponibili quando necessario (ad esempio, in risposta a un incidente).
**Vantaggi dell'adozione di questa best practice:**
+ Processi e procedure incentivano l'impegno nella gestione dei carichi di lavoro.
+ I nuovi membri del team diventano efficienti in modo più rapido.
+ Riduzione dei tempi di mitigazione degli incidenti.
+ Membri del team (e team) diversi possono utilizzare gli stessi processi e procedure in modo coerente.
+ I team procedono a scalare i processi tramite processi ripetibili.
+ Processi e procedure standardizzati aiutano a mitigare l'impatto del trasferimento delle responsabilità del carico di lavoro tra i team.
**Livello di rischio associato se questa best practice non fosse adottata:** elevato
## Guida all’implementazione
+ Esistono proprietari identificati di processi e procedure, responsabili della loro definizione.
+ Identifica le attività operative eseguite a supporto dei carichi di lavoro. Documenta queste attività in un percorso individuabile.
+ Identifica in modo univoco la persona o il team responsabile della specifica di un'attività. Questo soggetto deve verificare la possibilità che questa possa essere correttamente eseguita dal componente di un team con opportune competenze, dotato di autorizzazioni, accesso e strumenti adeguati. In caso di problemi nello svolgimento di tale attività, i membri del team che la eseguono sono responsabili della redazione di feedback dettagliati necessari per migliorarla.
+ Acquisisci la responsabilità dei metadati dell'artefatto dell'attività tramite servizi come AWS Systems Manager, documenti e AWS Lambda. Acquisisci la responsabilità delle risorse utilizzando tag o gruppi di risorse, specificando proprietà e informazioni di contatto. Utilizza AWS Organizations per creare policy di tagging e garantire l'acquisizione di proprietà e informazioni di contatto.
+ Nel tempo, queste procedure si evolvono per essere eseguibili come codice, riducendo la necessità dell'intervento umano.
+ Ad esempio, prendi in considerazione le funzioni AWS Lambda, i modelli CloudFormation o i documenti di automazione di AWS Systems Manager.
+ Esegui il controllo delle versioni nei repository appropriati.
+ Applica i tag adeguati alle risorse, in modo da agevolare l'identificazione di proprietari e documentazione.
**Esempio del cliente**
AnyCompany Retail definisce come proprietario il team o l'individuo responsabile dei processi per un'applicazione o gruppi di applicazioni (che condividono procedure e tecnologie architetturali comuni). Inizialmente, processi e procedure vengono documentati nel sistema di gestione dei documenti come guide dettagliate, individuabili tramite i tag dell'Account AWS che ospita l'applicazione e di gruppi specifici di risorse all'interno dell'account. AnyCompany Retail si avvale di AWS Organizations per gestire gli Account AWS. Nel tempo, questi processi vengono convertiti in codice e le risorse vengono definite utilizzando l'infrastructure as code (ad esempio CloudFormation o modelli AWS Cloud Development Kit (AWS CDK)). I processi operativi diventano documenti di automazione in AWS Systems Manager o funzioni di AWS Lambda, avviabili come attività pianificate in risposta a eventi, ad esempio allarmi AWS di CloudWatch o eventi AWS di EventBridge, oppure avviati da richieste all'interno di una piattaforma di gestione dei servizi IT (ITSM). Tutti i processi dispongono di tag per l'identificazione della proprietà. La documentazione per l'automazione e il processo viene mantenuta all'interno delle pagine wiki generate dal repository di codice per il processo.
### Passaggi dell'implementazione
1. Documenta processi e procedure esistenti.
1. Rivedili e mantienili aggiornati.
1. Identifica un proprietario per ciascun processo o procedura.
1. Applica a ognuno il controllo delle versioni.
1. Ove possibile, condividi processi e procedure tra carichi di lavoro e ambienti che condividono progetti architetturali.
1. Stabilisci meccanismi di feedback e miglioramento.
1. Definisci policy relative alla frequenza di revisione dei processi.
1. Definisci i processi per revisori e approvatori.
1. Implementa i problemi o crea una coda di ticket per fornire e monitorare il feedback.
1. Ove possibile, i processi e le procedure vanno approvati preventivamente e classificati in base ai rischi da parte di un comitato di approvazione delle modifiche (CAB).
1. Verifica che processi e procedure siano accessibili e individuabili da chi deve eseguirli.
1. Utilizza i tag per indicare dove è possibile accedere a processi e procedure per il carico di lavoro.
1. Utilizza messaggi di errore ed eventi significativi per indicare processi o procedure appropriati per risolvere un problema.
1. Usa i wiki e la gestione dei documenti per rendere processi e procedure consultabili in modo coerente in tutta l'organizzazione.
1. Usa [Amazon Q Business](https://aws.amazon.com/q/business/), un assistente conversazionale che utilizza l'IA generativa per migliorare la produttività della forza lavoro, rispondere a domande e completare attività in base alle informazioni presenti nei sistemi aziendali.
1. Collega Amazon Q Business all'origine dati della tua azienda. Amazon Q Business offre connettori predefiniti per oltre 40 origini dati supportate, tra cui Amazon S3, Microsoft SharePoint, Salesforce e Atlassian Confluence. Per ulteriori informazioni, consulta [Connettori di Amazon Q](https://aws.amazon.com/q/business/connectors/).
1. Automatizza quando appropriato.
1. È opportuno eseguire le automazioni quando servizi e tecnologie forniscono un'API.
1. Fornisci indicazioni adeguate in merito ai processi. Sviluppa casi utente e requisiti per automatizzare i processi.
1. Misura correttamente l'uso di processi e procedure e crea problemi o ticket come un'opportunità di miglioramento continuo.
**Livello di impegno per il piano di implementazione:** medio
## Risorse
**Best practice correlate:**
+ [OPS02-BP01 Associazione di proprietari identificati alle risorse](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_resource_owners.html)
+ [OPS02-BP04 Definizione di meccanismi per gestire responsabilità e titolarità](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_responsibilities_ownership.html)
+ [OPS11-BP04 Gestione delle informazioni](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html)
**Documenti correlati:**
+ [AWS Whitepaper - Introduzione a DevOps in AWS](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/automation.html)
+ [Whitepaper AWS - Best Practices for Tagging AWS Resources](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)
+ [Whitepaper AWS: Organizing Your AWS Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)
+ [Cloud AWS Operations and Migrations Blog - Using Amazon Q Business to streamline your operations ](https://aws.amazon.com/blogs/mt/streamline-operations-using-amazon-q-for-business/)
+ [Cloud AWS Post del blog Operations & Migrations - Build a Cloud Automation Practice for Operational Excellence: Best Practices from AWS Managed Services](https://aws.amazon.com/blogs/mt/build-a-cloud-automation-practice-for-operational-excellence-best-practices-from-aws-managed-services/)
+ [Post del blog Cloud AWS Operations & Migrations - Implementing automated and centralized tagging controls with AWS Config and AWS Organizations](https://aws.amazon.com/blogs/mt/implementing-automated-and-centralized-tagging-controls-with-aws-config-and-aws-organizations/)
+ [AWS Post del blog Security - Extend your pre-commit hooks with AWS CloudFormation Guard](https://aws.amazon.com/blogs/security/extend-your-pre-commit-hooks-with-aws-cloudformation-guard/)
+ [Post del blog AWS DevOps - Integrating AWS CloudFormation Guard into CI/CD pipelines](https://aws.amazon.com/blogs/devops/integrating-aws-cloudformation-guard/)
**Workshop correlati:**
+ [AWS Well-Architected Operational Excellence Workshop](https://catalog.workshops.aws/well-architected-operational-excellence/en-US/)
+ [AWS Workshop - Tagging](https://catalog.workshops.aws/tagging/)
**Video correlati:**
+ [How to automate IT Operations on AWS](https://www.youtube.com/watch?v=GuWj_mlyTug)
+ [AWS re:Invent 2020 - Automate anything with AWS Systems Manager](https://www.youtube.com/watch?v=AaI2xkW85yE)
+ [AWS re:Inforce 2022 - Automating patch management and compliance using AWS (NIS306)](https://www.youtube.com/watch?v=gL3baXQJvc0)
+ [Supportos You - Diving Deep into AWS Systems Manager](https://www.youtube.com/watch?v=xHNLNTa2xGU)
**Servizi correlati:**
+ [AWS Systems Manager - Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Service Management Connector](https://aws.amazon.com/service-management-connector/)
# OPS02-BP03 Assegnazione di proprietari identificati alle operazioni che siano responsabili delle relative prestazioni
È utile sapere chi ha la responsabilità di eseguire attività specifiche su carichi di lavoro definiti e perché tale responsabilità esiste. Conoscere chi ha la responsabilità di eseguire le attività fornisce indicazioni su chi eseguirà l'attività, chi convaliderà il risultato e chi fornirà feedback al proprietario dell'attività.
**Risultato desiderato:**
L'organizzazione definisce chiaramente le responsabilità per eseguire attività specifiche su carichi di lavoro stabiliti e rispondere agli eventi generati dai carichi di lavoro. L'organizzazione documenta la responsabilità dei processi e degli adempimenti e rende queste informazioni individuabili. Esamini e aggiorni le responsabilità in caso di cambiamenti organizzativi e i team monitorano e misurano le prestazioni delle attività di identificazione di difetti e inefficienze. Implementi i meccanismi di feedback per monitorare difetti e miglioramenti e supportare il miglioramento continuo.
**Anti-pattern comuni:**
+ Mancata documentazione delle responsabilità.
+ Esistono script frammentati su workstation degli operatori isolate. Solo poche persone sanno come usarli o li chiamano informalmente *conoscenze del team*.
+ Necessità di aggiornare un processo legacy, ma non si sa chi è il proprietario e l'autore originale non fa più parte dell'organizzazione.
+ Mancata possibilità di individuare processi e script, quindi non sono immediatamente disponibili quando necessario, ad esempio, in risposta a un incidente.
**Vantaggi dell'adozione di questa best practice:**
+ Sai chi è responsabile dell'esecuzione di un'attività, a chi notificare un'azione necessaria e chi esegue l'azione, convalida il risultato e fornisce il feedback al titolare dell'attività.
+ Processi e procedure incentivano l'impegno nella gestione dei carichi di lavoro.
+ I nuovi membri del team diventano efficienti in modo più rapido.
+ Riduci il tempo necessario per mitigare gli incidenti.
+ Team diversi utilizzano medesimi processi e procedure per eseguire le attività in modo coerente.
+ I team procedono a scalare i processi tramite processi ripetibili.
+ Processi e procedure standardizzati aiutano a mitigare l'impatto del trasferimento delle responsabilità del carico di lavoro tra i team.
**Livello di rischio associato se questa best practice non fosse adottata:** elevato
## Guida all’implementazione
Per definire le responsabilità, inizia usando la documentazione esistente, ad esempio matrici di responsabilità, processi e procedure, ruoli e responsabilità, strumenti e automazione. Esamina la documentazione e organizza discussioni sulle responsabilità dei processi documentati. Collaborando con i team, identifica i disallineamenti tra le responsabilità e i processi documentati. Parla dei servizi offerti con i clienti interni dei team per identificare le divergenze nelle aspettative tra i team.
Analizza e risolvi le discrepanze. Identifica le opportunità di miglioramento e le attività richieste di frequente e con uso intensivo di risorse, in genere ottime candidate al miglioramento. Esamina best practice, modelli e linee guida prescrittive per semplificare e standardizzare i miglioramenti. Registra le opportunità di miglioramento e monitora i miglioramenti fino al completamento.
Nel tempo, queste procedure si evolvono per essere eseguibili come codice, riducendo la necessità dell'intervento umano. Ad esempio, è possibile avviare le procedure come funzioni AWS Lambda, modelli CloudFormation o documenti di automazione AWS Systems Manager. Verifica che queste procedure siano sottoposte al controllo delle versioni nei repository appropriati e includano i corretti tag delle risorse in modo che i team possano identificare prontamente responsabili e documentazione. Documenta la responsabilità dello svolgimento delle attività, quindi monitora l'avvio e il funzionamento delle automazioni, nonché le prestazioni dei risultati desiderati.
**Esempio del cliente**
AnyCompany Retail definisce come proprietario il team o l'individuo responsabile dei processi per un'applicazione o gruppi di applicazioni (che condividono procedure e tecnologie architetturali comuni). Inizialmente, l'azienda documenta processi e procedure come guide dettagliate nel sistema di gestione dei documenti. Rende le procedure individuabili applicando i tag nell'Account AWS che ospita l'applicazione e in gruppi specifici di risorse dell'account, utilizzando AWS Organizations per gestire gli Account AWS. Nel tempo, AnyCompany Retail converte questi processi in codice e definisce le risorse utilizzando l'infrastructure as code, tramite servizi come CloudFormation o modelli AWS Cloud Development Kit (AWS CDK). I processi operativi diventano documenti di automazione in AWS Systems Manager o funzioni di AWS Lambda, avviabili come attività pianificate in risposta a eventi, ad esempio allarmi di Amazon CloudWatch o eventi di Amazon EventBridge, oppure avviati da richieste all'interno di una piattaforma di gestione dei servizi IT (ITSM). Tutti i processi dispongono dei tag per identificare il proprietario. I team gestiscono la documentazione per l'automazione e il processo nelle pagine wiki generate dal repository di codice per il processo.
### Passaggi dell'implementazione
1. Documenta processi e procedure esistenti.
1. Esamina e verifica che siano aggiornati.
1. Verifica che ogni processo o procedura abbia un proprietario.
1. Applica alle procedure il controllo delle versioni.
1. Ove possibile, condividi processi e procedure tra carichi di lavoro e ambienti che condividono progetti architetturali.
1. Stabilisci meccanismi di feedback e miglioramento.
1. Definisci policy relative alla frequenza di revisione dei processi.
1. Definisci i processi per revisori e approvatori.
1. Implementa i problemi o crea una coda di ticket per fornire e monitorare il feedback.
1. Ove possibile, i processi e le procedure devono essere approvati preventivamente e classificati in base ai rischi da parte di un comitato di approvazione delle modifiche (CAB).
1. Rendi i processi e le procedure accessibili e individuabili dagli utenti che devono eseguirli.
1. Utilizza i tag per indicare dove è possibile accedere a processi e procedure per il carico di lavoro.
1. Utilizza messaggi di errore ed eventi significativi per indicare il processo o la procedura appropriata per risolvere il problema.
1. Usa i wiki o la gestione dei documenti per rendere i processi e le procedure consultabili in modo coerente in tutta l'organizzazione.
1. Automatizza quando è opportuno farlo.
1. Laddove servizi e tecnologie forniscono un'API, sviluppa le automazioni.
1. Verifica che i processi siano ben compresi e sviluppa casi utente e requisiti per automatizzare i processi.
1. Misura l'uso corretto di processi e procedure e sfrutta i problemi per supportare il miglioramento continuo.
**Livello di impegno per il piano di implementazione:** medio
## Risorse
**Best practice correlate:**
+ [OPS02-BP01 Associazione di proprietari identificati alle risorse](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_resource_owners.html)
+ [OPS02-BP02 Assegnazione di proprietari identificati a processi e procedure](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_resource_owners.html)
+ [OPS02-BP04 Definizione di meccanismi per gestire responsabilità e titolarità](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_responsibilities_ownership.html)
+ [OPS02-BP05 Definizione di meccanismi per identificare responsabilità e proprietà](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_find_owner.html)
+ [OPS11-BP04 Gestione delle informazioni](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html)
**Documenti correlati:**
+ [Whitepaper AWS \$1 Introduzione a DevOps in AWS](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/automation.html)
+ [Whitepaper AWS \$1 Best Practices for Tagging AWS Resources](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)
+ [Whitepaper AWS \$1 Organizing Your AWS Environment Using Multiple Accounts](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)
+ [Post del blog Cloud AWS Operations & Migrations \$1 Build a Cloud Automation Practice for Operational Excellence: Best Practices from AWS Managed Services](https://aws.amazon.com/blogs/mt/build-a-cloud-automation-practice-for-operational-excellence-best-practices-from-aws-managed-services/)
+ [Workshop AWS - Tagging](https://catalog.workshops.aws/tagging/)
+ [AWS Service Management Connector](https://aws.amazon.com/service-management-connector/)
**Video correlati:**
+ [AWS Knowledge Center Live \$1 Tagging AWS Resources](https://www.youtube.com/watch?v=MX9DaAQS15I)
+ [AWS re:Invent 2020 \$1 Automate anything with AWS Systems Manager](https://www.youtube.com/watch?v=AaI2xkW85yE)
+ [AWS re:Inforce 2022 \$1 Automating patch management and compliance using AWS (NIS306)](https://www.youtube.com/watch?v=gL3baXQJvc0)
+ [Supportos You \$1 Diving Deep into AWS Systems Manager](https://www.youtube.com/watch?v=xHNLNTa2xGU)
# OPS02-BP04 Definizione di meccanismi per gestire responsabilità e titolarità
Comprendi le responsabilità del tuo ruolo e il modo in cui contribuisci ai risultati aziendali in quanto questa conoscenza fornisce indicazioni sulle priorità delle tue attività e sul perché il tuo ruolo è importante. I membri del team possono quindi riconoscere le esigenze e rispondere in modo appropriato. Quando i membri del team comprendono il proprio ruolo, possono stabilire la titolarità, identificare le opportunità di miglioramento e capire come influenzare o apportare le modifiche appropriate.
Occasionalmente, una responsabilità potrebbe non avere un titolare definito. In queste situazioni, progetta un meccanismo per risolvere la lacuna. Crea un percorso di escalation ben definito a qualcuno con l'autorità di assegnare la responsabilità o il piano per risolvere il problema.
**Risultato desiderato:** responsabilità definite in modo chiaro per i team all'interno dell'organizzazione, che comprendono il modo in cui sono correlate alle risorse, alle azioni da eseguire, ai processi e alle procedure. Queste responsabilità sono in linea con le responsabilità e gli obiettivi del team, nonché con le responsabilità degli altri team. Documenti i percorsi di escalation in modo coerente e individuabile e inserisci queste decisioni in artefatti di documentazione, come matrici di responsabilità, definizioni di team o pagine wiki.
**Anti-pattern comuni:**
+ Le responsabilità del team sono ambigue o mal definite.
+ Il team non allinea i ruoli alle responsabilità.
+ Il team non allinea scopi e obiettivi alle responsabilità, rendendo difficile misurare il successo delle attività.
+ Le responsabilità dei membri del team non sono in linea con il team e l'organizzazione in generale.
+ Il team non mantiene aggiornate le responsabilità rendendole incoerenti con le attività svolte dal team.
+ I percorsi di escalation per determinare le responsabilità non sono definiti o non sono chiari.
+ I percorsi di escalation non hanno un unico responsabile del thread per garantire una risposta tempestiva.
+ Ruoli, responsabilità e percorsi di escalation non sono individuabili e quindi non sono immediatamente disponibili quando richiesto, ad esempio in risposta a un incidente.
**Vantaggi dell'adozione di questa best practice:**
+ Una volta compreso chi ha la responsabilità o la titolarità, puoi contattare il team o il membro del team appropriato per effettuare una richiesta o trasferire un'attività.
+ Per ridurre il rischio di inattività e di esigenze non soddisfatte, identifichi una persona che ha l'autorità di assegnare responsabilità o titolarità.
+ Quando si definisce chiaramente l'ambito di una responsabilità, i membri del team acquisiscono autonomia e titolarità.
+ Le tue responsabilità forniscono indicazioni sulle decisioni che prendi, sulle azioni che intraprendi e sulle tue attività di distribuzione ai titolari appropriati.
+ Ti sarà facile identificare le responsabilità abbandonate perché hai una chiara comprensione di ciò che non rientra nelle responsabilità del tuo team e quindi potrai effettuare l'escalation per chiedere chiarimenti.
+ I team evitano confusione e tensione e possono gestire in modo più adeguato i carichi di lavoro e le risorse.
**Livello di rischio associato se questa best practice non fosse adottata:** elevato
## Guida all’implementazione
Identifica i ruoli e le responsabilità dei membri del team e verifica che comprendano le aspettative del proprio ruolo. Rendi queste informazioni individuabili in modo che i membri della tua organizzazione possano identificare il team o la persona da contattare per esigenze specifiche. Man mano che le organizzazioni capitalizzano le opportunità di migrare e modernizzare su AWS, i ruoli e le responsabilità potrebbero cambiare. Rendi i team e i membri consapevoli delle loro responsabilità e offri la formazione appropriata per svolgere le attività durante questo cambiamento.
Determina il ruolo o il team che deve ricevere le escalation per identificare responsabilità e titolarità. Questo team può interagire con varie parti interessate per prendere le decisioni. Tuttavia, è proprietario della gestione del processo decisionale.
Fornisci ai membri della tua organizzazione meccanismi accessibili per scoprire e identificare titolarità e responsabilità. Questi meccanismi insegnano loro a chi rivolgersi per esigenze specifiche.
**Esempio del cliente**
AnyCompany Retail ha recentemente completato una migrazione dei carichi di lavoro da un ambiente on-premises alla zona di destinazione in AWS con un approccio lift and shift. Ha eseguito una revisione delle operazioni per esaminare come vengono svolte le attività operative comuni e ha verificato che la matrice di responsabilità esistente rifletta le operazioni nel nuovo ambiente. Quando ha eseguito la migrazione dall'ambiente on-premises ad AWS, ha ridotto le responsabilità dei team dell'infrastruttura relative all'hardware e all'infrastruttura fisica. Questo passaggio ha anche rivelato nuove opportunità per evolvere il modello operativo dei carichi di lavoro.
Oltre ad aver identificato, risolto e documentato la maggior parte delle responsabilità, ha anche definito i percorsi di escalation per eventuali responsabilità mancanti o che potrebbero cambiare con l'evolversi delle procedure operative. Per la ricerca di nuove opportunità per standardizzare e migliorare l'efficienza dei carichi di lavoro, fornisci l'accesso a strumenti operativi come AWS Systems Manager e strumenti di sicurezza come AWS Security Hub CSPM e Amazon GuardDuty. AnyCompany Retail combina una revisione delle responsabilità e della strategia sulla base dei miglioramenti che intende eseguire per primi. Man mano che l'azienda adotta nuovi modi di lavorare e modelli tecnologici, aggiorna la propria matrice di responsabilità di conseguenza.
### Passaggi dell'implementazione
1. Inizia con la documentazione esistente. Alcuni documenti di origine tipici possono essere:
1. Matrici di responsabilità o responsabili, affidabili, consultabili e informate (RACI).
1. Definizioni dei team o pagine wiki.
1. Definizioni e offerte di servizi.
1. Ruolo o descrizione delle mansioni lavorative.
1. Esamina la documentazione e organizza discussioni sulle responsabilità documentate:
1. Collaborando con i team identifica i disallineamenti tra le responsabilità documentate e quelle normalmente assunte dai team.
1. Esamina i potenziali servizi offerti dai clienti interni per identificare le lacune nelle aspettative tra i team.
1. Analizza e risolvi le discrepanze.
1. Identifica le opportunità di miglioramento.
1. Identifica le richieste più frequenti e con uso intensivo di risorse, che in genere sono ottime candidate al miglioramento.
1. Esamina le best practice, comprendi i modelli, segui le linee guida prescrittive per semplificare e standardizzare i miglioramenti.
1. Registra le opportunità di miglioramento e monitorale fino al completamento.
1. Se nessuno nel team è responsabile della gestione e del monitoraggio dell'assegnazione delle responsabilità, identifica qualcuno che assuma tale responsabilità.
1. Definisci un processo per consentire ai team di richiedere chiarimenti sulla responsabilità.
1. Esamina il processo e verifica che sia chiaro e semplice da usare.
1. Assicurati che qualcuno sia proprietario e segua le escalation fino al completamento.
1. Stabilisci le metriche operative per misurare l'efficacia.
1. Crea un meccanismo di feedback per verificare che i team possano evidenziare le opportunità di miglioramento.
1. Implementa un meccanismo di revisione periodica.
1. Rendi i documenti disponibili in una posizione individuabile e accessibile.
1. I wiki o il portale di documentazione sono le posizioni normalmente scelte.
**Livello di impegno per il piano di implementazione:** medio
## Risorse
**Best practice correlate:**
+ [OPS01-BP06 Valutazione dei compromessi](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_priorities_eval_tradeoffs.html)
+ [OPS03-BP02 Potere di intervento dei membri del team quando i risultati sono a rischio](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_team_emp_take_action.html)
+ [OPS03-BP03 Incoraggiamento all'escalation](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_team_enc_escalation.html)
+ [OPS03-BP07 Fornitura di risorse appropriate ai team](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_team_res_appro.html)
+ [OPS09-BP01 Misura gli obiettivi operativi e i KPI con le metriche](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_operations_health_measure_ops_goals_kpis.html)
+ [OPS09-BP03 Revisione delle metriche operative e assegnazione delle priorità per favorire il miglioramento](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_operations_health_review_ops_metrics_prioritize_improvement.html)
+ [OPS11-BP01 Definizione di un processo per il miglioramento continuo](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_process_cont_imp.html)
**Documenti correlati:**
+ [Whitepaper AWS - Introduzione a DevOps in AWS](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/automation.html)
+ [Whitepaper AWS - Cloud AWS Adoption Framework: Operations Perspective](https://docs.aws.amazon.com/whitepapers/latest/aws-caf-operations-perspective/aws-caf-operations-perspective.html)
+ [Eccellenza operativa del Framework AWS Well-Architected: topologie del modello operativo a livello di carico di lavoro](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/operating-model-2-by-2-representations.html)
+ [AWS Prescriptive Guidance - Building your Cloud Operating Model](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-cloud-operating-model/welcome.html)
+ [AWS Prescriptive Guidance - Create a RACI or RASCI matrix for a cloud operating model](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/create-a-raci-or-rasci-matrix-for-a-cloud-operating-model.html)
+ [Blog sulle operazioni e le migrazioni Cloud AWS - Delivering Business Value with Cloud Platform Teams](https://aws.amazon.com/blogs/mt/delivering-business-value-with-cloud-platform-teams/)
+ [Blog sulle operazioni e le migrazioni Cloud AWS - Why a Cloud Operating Model?](https://aws.amazon.com/blogs/mt/why-a-cloud-operating-model/)
+ [Blog AWS DevOps - How organizations are modernizing for cloud operations](https://aws.amazon.com/blogs/devops/how-organizations-are-modernizing-for-cloud-operations/)
**Video correlati:**
+ [AWS Summit Online - Cloud Operating Models for Accelerated Transformation](https://www.youtube.com/watch?v=ksJ5_UdYIag)
+ [AWS re:Invent 2023 - Future-proofing cloud security: A new operating model](https://www.youtube.com/watch?v=GFcKCz1VO2I)
# OPS02-BP05 Definizione di meccanismi per richiedere aggiunte, modifiche ed eccezioni
È possibile effettuare richieste ai titolari di processi, procedure e risorse. Tra le richieste figurano aggiunte, modifiche ed eccezioni. Tali richieste passano attraverso un processo di gestione delle modifiche Prendi decisioni informate per approvare le richieste quando vengono ritenute fattibili e appropriate dopo una valutazione dei vantaggi e dei rischi.
**Risultato desiderato:**
+ Puoi effettuare richieste per modificare processi, procedure e risorse sulla base della titolarità assegnata.
+ Le modifiche vengono eseguite in modo deliberato, valutando benefici e rischi.
**Anti-pattern comuni:**
+ Devi aggiornare il modo di implementare la tua applicazione, ma non esiste un metodo per richiedere una modifica al processo di implementazione al team operativo.
+ Il piano di disaster recovery deve essere aggiornato, ma non è stato identificato il proprietario a cui richiedere le modifiche.
**Vantaggi dell'adozione di questa best practice:**
+ Processi, procedure e risorse possono evolvere mentre cambiano i requisiti.
+ I titolati possono prendere decisioni mirate su quando effettuare le modifiche.
+ Le modifiche vengono eseguite deliberatamente.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all’implementazione
Per implementare questa best practice devi essere in grado di richiedere modifiche a processi, procedure e risorse. Il processo di gestione delle modifiche può essere semplice. Documenta il processo di gestione delle modifiche.
**Esempio del cliente**
AnyCompany Retail usa una matrice di assegnazione delle responsabilità (RACI) per identificare il proprietario delle modifiche per processi, procedure e risorse. L'azienda dispone di un processo documentato di gestione delle modifiche, semplice e facile da seguire. Tramite il processo e la matrice RACI, tutti possono inviare richieste di modifiche.
**Passaggi dell'implementazione**
1. Identifica i processi, le procedure e le risorse per il tuo carico di lavoro e i proprietari di ciascun elemento. Documentali nel tuo sistema di gestione delle conoscenze.
1. In caso di mancata implementazione, inizia da [OPS02-BP01 Le risorse hanno identificato i proprietari](ops_ops_model_def_resource_owners.md), [OPS02-BP02 Assegnazione di proprietari identificati a processi e procedure](ops_ops_model_def_proc_owners.md) o [OPS02-BP03 Assegnazione di proprietari identificati alle operazioni che siano responsabili delle relative prestazioni](ops_ops_model_def_activity_owners.md).
1. Collabora con le parti interessate all'interno della tua azienda per sviluppare un processo di gestione delle modifiche. Il processo deve includere aggiunte, modifiche ed eccezioni per risorse, processi e procedure.
1. Puoi utilizzare [AWS Systems Manager Change Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/change-manager.html) come piattaforma di gestione delle modifiche per le risorse del carico di lavoro.
1. Documenta il processo di gestione delle modifiche nel tuo sistema di gestione delle conoscenze.
**Livello di impegno per il piano di implementazione:** medio Sviluppare un processo di gestione delle modifiche significa garantire un allineamento con più parti interessate all'interno dell'organizzazione.
## Risorse
**Best practice correlate:**
+ [OPS02-BP01 Le risorse hanno identificato i proprietari](ops_ops_model_def_resource_owners.md): le risorse richiedono proprietari identificati prima di creare un processo di gestione delle modifiche.
+ [OPS02-BP02 Assegnazione di proprietari identificati a processi e procedure](ops_ops_model_def_proc_owners.md): i processi richiedono proprietari identificati prima di creare un processo di gestione delle modifiche.
+ [OPS02-BP03 Assegnazione di proprietari identificati alle operazioni che siano responsabili delle relative prestazioni](ops_ops_model_def_activity_owners.md): le attività di operazioni richiedono proprietari identificati prima di creare un processo di gestione delle modifiche.
**Documenti correlati:**
+ [AWS Prescriptive Guidance, playbook di base per migrazioni di AWS grandi dimensioni: creazione di matrici RACI](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-foundation-playbook/team-org.html#raci)
+ [ Whitepaper sulla gestione delle modifiche nel cloud ](https://docs.aws.amazon.com/whitepapers/latest/change-management-in-the-cloud/change-management-in-the-cloud.html)
**Servizi correlati:**
+ [AWS Systems Manager Change Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/change-manager.html)
# OPS02-BP06 Predefinizione o negoziazione delle responsabilità tra i team
Predisponi accordi definiti o concordati tra i team che descrivono come funzionano e si supportano reciprocamente (ad esempio, tempi di risposta, obiettivi o contratti relativi al livello di servizio). I canali di comunicazione tra team sono documentati. Comprendere l'impatto del lavoro dei team sui risultati aziendali e sui risultati di altri team e organizzazioni fornisce indicazioni in merito alla priorità dei loro compiti e consente loro di rispondere in modo appropriato.
Quando la responsabilità e la proprietà sono indefinite o sconosciute, rischi di non affrontare le attività necessarie in modo tempestivo e di impiegare sforzi ridondanti e potenzialmente conflittuali per rispondere a tali esigenze.
**Risultato desiderato:**
+ Il lavoro tra team o gli accordi di assistenza vengono concordati e documentati.
+ I team che supportano o lavorano con altri hanno definito i canali di comunicazione e le aspettative in termini di risposte.
**Anti-pattern comuni:**
+ In produzione si verifica un problema e due team separati iniziano a cercare la soluzione senza confrontarsi. Il loro impegno separato prolunga l'interruzione.
+ Il team operativo ha bisogno di assistenza dal team di sviluppo, ma non c'è un accordo sui tempi di risposta. La richiesta si blocca nel backlog.
**Vantaggi dell'adozione di questa best practice:**
+ I team sanno come interagire e supportarsi a vicenda.
+ Le aspettative relative ai tempi di risposta sono note.
+ I canali di comunicazione sono definiti in modo chiaro.
**Livello di rischio associato se questa best practice non fosse adottata:** basso
## Guida all’implementazione
Se si implementa questa best practice non ci saranno dubbi sulla collaborazione tra team. Gli accordi formali codificano il modo di collaborare o di assistersi a vicenda dei team. I canali di comunicazione tra team sono documentati.
**Esempio del cliente**
Il team SRE di AnyCompany Retail ha un contratto sul livello di servizio (SLA) con il team di sviluppo. Ogni volta che il team di sviluppo effettua una richiesta nel sistema di ticketing, riceve una risposta entro 15 minuti. Se si verifica un malfunzionamento presso la sede, il team SRE assume il comando delle indagini con il supporto del team di sviluppo.
**Passaggi dell'implementazione**
1. Collaborando con le parti interessate all'interno dell'organizzazione, sviluppa accordi tra team basati su processi e procedure.
1. Se i due team condividono un processo o una procedura, crea un runbook sulle modalità di collaborazione dei team.
1. Se esistono dipendenze tra i team, concorda uno SLA per le risposte alle richieste.
1. Inserisci le responsabilità nel tuo sistema di gestione delle conoscenze.
**Livello di impegno per il piano di implementazione:** medio Se non esistono accordi tra i team, può essere impegnativo raggiungere un accordo con le parti interessate all'interno dell'organizzazione.
## Risorse
**Best practice correlate:**
+ [OPS02-BP02 Assegnazione di proprietari identificati a processi e procedure](ops_ops_model_def_proc_owners.md): la proprietà del processo deve essere identificata prima di stabilire accordi tra i team.
+ [OPS02-BP03 Assegnazione di proprietari identificati alle operazioni che siano responsabili delle relative prestazioni](ops_ops_model_def_activity_owners.md): la proprietà delle operazioni deve essere identificata prima di stabilire accordi tra i team.
**Documenti correlati:**
+ [AWS Executive Insights - Empowering Innovation with the Two-Pizza Team ](https://aws.amazon.com/executive-insights/content/amazon-two-pizza-team/)
+ [ Introduction to DevOps on AWS - Two-Pizza Teams ](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/two-pizza-teams.html)