

# OPS 2. Come strutturare la tua organizzazione per supportare i risultati aziendali?
<a name="ops-02"></a>

 I tuoi team devono comprendere quale contributo offrono nel raggiungimento dei risultati aziendali. I team devono avere obiettivi condivisi e comprendere il proprio ruolo nel successo degli altri team. Comprendere la responsabilità, la proprietà, il modo in cui vengono prese le decisioni e chi ha l'autorità decisionale aiuterà a concentrare gli sforzi e a ottimizzare i contributi dei team. 

**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
<a name="ops_ops_model_def_resource_owners"></a>

 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
<a name="implementation-guidance"></a>

 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
<a name="implementation-steps"></a>

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
<a name="resources"></a>

 **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
<a name="ops_ops_model_def_proc_owners"></a>

 È 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
<a name="implementation-guidance"></a>
+  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
<a name="implementation-steps"></a>

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
<a name="resources"></a>

 **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
<a name="ops_ops_model_def_activity_owners"></a>

 È 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
<a name="implementation-guidance"></a>

 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
<a name="implementation-steps"></a>

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
<a name="resources"></a>

 **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à
<a name="ops_ops_model_def_responsibilities_ownership"></a>

 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
<a name="implementation-guidance"></a>

 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
<a name="implementation-steps"></a>

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
<a name="resources"></a>

 **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
<a name="ops_ops_model_req_add_chg_exception"></a>

È 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
<a name="implementation-guidance"></a>

 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
<a name="resources"></a>

 **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
<a name="ops_ops_model_def_neg_team_agreements"></a>

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
<a name="implementation-guidance"></a>

 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
<a name="resources"></a>

 **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)