# OPS 2. Come strutturare la tua organizzazione per supportare i risultati aziendali?
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 Associazione di proprietari identificati alle risorse](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 Conoscenza della propria responsabilità da parte dei membri del team](ops_ops_model_know_my_job.md)
+ [OPS02-BP05 Definizione di meccanismi per identificare responsabilità e proprietà](ops_ops_model_find_owner.md)
+ [OPS02-BP06 Definizione di meccanismi per richiedere aggiunte, modifiche ed eccezioni](ops_ops_model_req_add_chg_exception.md)
+ [OPS02-BP07 Predefinizione o negoziazione delle responsabilità tra i team](ops_ops_model_def_neg_team_agreements.md)
# OPS02-BP01 Associazione di proprietari identificati alle risorse
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 titolari sono assegnati a carichi di lavoro, account, infrastrutture, piattaforme e applicazioni. La proprietà viene registrata 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 hanno identificato i titolari tramite i metadati o un registro centrale.
+ I membri del team possono identificare chi è il titolare delle risorse.
+ Gli account hanno un solo proprietario, laddove possibile.
**Anti-pattern comuni:**
+ I contatti alternativi per il tuo Account AWS non sono inseriti.
+ Le risorse non hanno tag che identificano i team che le possiedono.
+ Hai una coda ITSM senza una mappatura delle e-mail.
+ Due team hanno 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 Retail definisce il proprietario come il team o l'individuo responsabile delle modifiche e del supporto per le risorse. Si avvale di AWS Organizations per gestire gli Account AWS. Contatti alternativi degli account vengono configurati con caselle di posta di gruppo. Ogni coda ITSM è mappata su un alias e-mail. I tag identificano il proprietario delle risorse AWS. Per altre piattaforme e infrastrutture hanno una pagina wiki che identifica la proprietà e le informazioni di contatto.
**Passaggi dell'implementazione**
1. Inizia definendo la proprietà della tua organizzazione. La proprietà può significare essere proprietari del rischio collegato alla risorsa, essere proprietari delle modifiche alla risorsa o supportare la risorsa 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 centralmente i contatti alternativi per i tuoi account.
1. Se usi indirizzi e-mail e numeri di telefono di proprietà dell'azienda come informazioni di contatto puoi accedervi anche se le persone a cui appartengono non sono più parte della tua 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. Molteplici persone riceveranno notifiche AWS e potranno rispondere, anche se qualcuno è in vacanza, ha cambiato ruolo o ha lasciato l'azienda.
1. Se un account non è gestito da [AWS Organizations](https://aws.amazon.com/organizations/), i contatti alternativi degli account aiutano AWS a entrare in contatto con il personale richiesto, se necessario. Configura i contatti alternativi dell'account per indirizzare le persone a un gruppo invece che a un individuo.
1. Usa i tag per identificare i proprietari delle risorse AWS. Puoi specificare sia i proprietari sia le loro informazioni di contatto in tag separati.
1. Puoi usare le regole [AWS Config](https://aws.amazon.com/config/) per avere la certezza che le risorse abbiano i tag di proprietà richiesti.
1. Per linee guida dettagliate su come creare una strategia per l'applicazione di tag per la tua organizzazione, consulta [Whitepaper sulle best practice per l'applicazione di tag AWS](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html).
1. Per altre risorse, piattaforme e infrastrutture, crea la documentazione che identifica 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 degli account per assegnare la proprietà delle risorse AWS. Per altre risorse puoi usare qualcosa di semplice come una tabella in un wiki per registrare le informazioni su proprietà e contatti o usare uno strumento ITSM per mappare la proprietà.
## Risorse
**Best practice correlate:**
+ [OPS02-BP02 Assegnazione di proprietari identificati a processi e procedure](ops_ops_model_def_proc_owners.md) - I processi e le procedure a supporto delle risorse dipendono dalla proprietà delle risorse stesse.
+ [OPS02-BP04 Conoscenza della propria responsabilità da parte dei membri del team](ops_ops_model_know_my_job.md) - I membri del team devono sapere di quali risorse sono proprietari.
+ [OPS02-BP05 Definizione di meccanismi per identificare responsabilità e proprietà](ops_ops_model_find_owner.md) - La proprietà deve essere identificata tramite meccanismi come tag o contatti di account..
**Documenti correlati:**
+ [ Gestione degli account AWS - Aggiornare le informazioni di contatto ](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact.html#manage-acct-update-contact-alternate-edit.html)
+ [ Regole AWS Config - Tag richiesti ](https://docs.aws.amazon.com/config/latest/developerguide/required-tags.html)
+ [AWS Organizations - Aggiornare contatti alternativi nella tua organizzazione ](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_update_contacts.html)
+ [Whitepaper Best practice per l'applicazione di tag AWS](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)
**Esempi correlati:**
+ [ Regole AWS Config - Amazon EC2 con tag richiesti e valori validi ](https://github.com/awslabs/aws-config-rules/blob/master/python/ec2_require_tags_with_valid_values.py)
**Servizi correlati:**
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Organizations](https://aws.amazon.com/organizations/)
# OPS02-BP02 Assegnazione di proprietari identificati a processi e procedure
È utile comprendere chi ha la proprietà della definizione di singoli processi e procedure, perché tali processi e procedure specifici vengono utilizzati e perché tale proprietà esiste. Comprendere i motivi per cui vengono utilizzati processi e procedure specifici consente di identificare le opportunità di miglioramento.
**Vantaggi dell'adozione di questa best practice:** Capire a chi spetta la proprietà permette di identificare chi può approvare e/o implementare i miglioramenti.
**Livello di rischio associato se questa best practice non fosse adottata:** Alto
## Guida all'implementazione
+ Assegnazione di proprietari identificati a processi e procedure: acquisisci i processi e le procedure utilizzati nel tuo ambiente e il singolo o il team responsabile della loro definizione.
+ Identificazione di processi e procedure: identifica le attività operative eseguite a supporto dei carichi di lavoro. Documenta queste attività in un percorso individuabile.
+ Definizione del proprietario della determinazione di un processo o di una procedura: identifica in modo univoco la persona o il team responsabile della specifica di un'attività. Questo soggetto deve assicurare che essa possa essere eseguita correttamente dal componente di un team adeguatamente qualificato, che disponga di autorizzazioni, accesso e strumenti adeguati. In caso di problemi nello svolgimento di tale attività, i membri del team che la eseguono sono responsabili di fornire il feedback dettagliato necessario per migliorarla.
+ Inclusione della proprietà nei metadati dell'artefatto dell'attività: le procedure automatizzate di servizi quali AWS Systems Manager, tramite documenti, e AWS Lambda, come funzioni, supportano l'acquisizione di informazioni sui metadati sotto forma di tag. Acquisisci la proprietà delle risorse utilizzando tag o gruppi di risorse, specificando proprietà e informazioni di contatto. Utilizza AWS Organizations per creare policy di tagging e garantire che vengano acquisite proprietà e informazioni di contatto.
# OPS02-BP03 Assegnazione di proprietari identificati alle operazioni che siano responsabili delle relative prestazioni
È utile comprendere chi ha la responsabilità di eseguire attività specifiche su carichi di lavoro definiti e perché tale responsabilità esiste. Comprendere chi ha la responsabilità di eseguire le attività fornisce indicazioni su eseguirà l'attività, su chi convaliderà il risultato e su chi fornirà feedback al proprietario dell'attività.
**Vantaggi dell'adozione di questa best practice:** Comprendere chi è responsabile di eseguire un'attività fornisce indicazioni su chi notificare quando è necessaria un'azione, su chi la eseguirà, su chi convaliderà il risultato e su chi fornirà un feedback al proprietario dell'attività.
**Livello di rischio associato se questa best practice non fosse adottata:** Alto
## Guida all'implementazione
+ Assegnazione di proprietari identificati alle operazioni che siano responsabili delle relative prestazioni: acquisisci la responsabilità dell'esecuzione dei processi e delle procedure utilizzati nel tuo ambiente
+ Identificazione di processi e procedure: identifica le attività operative eseguite a supporto dei carichi di lavoro. Documenta queste attività in un percorso individuabile.
+ Definizione di chi è responsabile dell'esecuzione di ciascuna attività: identifica il team responsabile di un'attività. Assicurati che disponga dei dettagli dell'attività, delle competenze necessarie e di autorizzazioni, accesso e strumenti appropriati per svolgerla. Il team deve comprendere la condizione in cui deve essere eseguita (ad esempio, in un evento o in una pianificazione). Rendi queste informazioni individuabili in modo che i membri della tua organizzazione possano identificare chi contattare, team o individuale, per esigenze specifiche.
# OPS02-BP04 Conoscenza della propria responsabilità da parte dei membri del team
Comprendere le responsabilità del tuo ruolo e il modo in cui contribuisci ai risultati aziendali fornisce indicazioni sulle priorità delle tue attività e sul perché il tuo ruolo è importante. In questo modo i membri del team possono riconoscere le esigenze e rispondere in modo appropriato.
**Vantaggi dell'adozione di questa best practice:** comprendere le tue responsabilità fornisce indicazioni sulle decisioni che prendi, le azioni che intraprendi e le tue attività di distribuzione ai proprietari appropriati.
**Livello di rischio associato se questa best practice non fosse adottata:** Elevato
## Guida all'implementazione
+ Comprensione da parte dei membri del team dei propri ruoli e responsabilità: identifica i ruoli e le responsabilità dei membri del team e assicurati che comprendano le aspettative del loro ruolo. Rendi queste informazioni individuabili in modo che i membri della tua organizzazione possano identificare chi contattare, team o individuale, per esigenze specifiche.
# OPS02-BP05 Definizione di meccanismi per identificare responsabilità e proprietà
Quando non viene identificato alcun individuo o team, esistono percorsi di escalation definiti nei confronti di soggetti dotati dell'autorità per assegnare la proprietà o la pianificazione connesse al soddisfacimento dell'esigenza in questione.
**Vantaggi dell'adozione di questa best practice:** Comprendere chi ha la responsabilità o la proprietà ti permette di contattare il team o il componente del team appropriati per presentare una richiesta o trasferire un'attività. Avere una persona identificata che ha l'autorità di assegnare la responsabilità o la proprietà o che può pianificare il soddisfacimento delle esigenze riduce il rischio di inerzia e il pericolo che le esigenze non vengano affrontate.
**Livello di rischio associato se questa best practice non fosse adottata:** Alto
## Guida all'implementazione
+ Definizione di meccanismi per l'identificazione di responsabilità e proprietà: fornisci ai membri della tua organizzazione meccanismi accessibili per scoprire e identificare proprietà e responsabilità. Questo consentirà loro di identificare il team o l'individuo da contattare per esigenze specifiche.
# OPS02-BP06 Definizione di meccanismi per richiedere aggiunte, modifiche ed eccezioni
È possibile effettuare richieste ai proprietari 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 ripristino di emergenza 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. Se non hai implementato [OPS02-BP01 Associazione di proprietari identificati alle risorse](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), comincia per prima cosa da questi.
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 dei carichi 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 Associazione di proprietari identificati alle risorse](ops_ops_model_def_resource_owners.md) - I titolari delle risorse devono essere identificati prima di definire un processo di gestione delle modifiche.
+ [OPS02-BP02 Assegnazione di proprietari identificati a processi e procedure](ops_ops_model_def_proc_owners.md) - I titolari dei processi devono essere identificati prima di definire 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) - I titolari delle attività operative devono essere identificati prima di definire un processo di gestione delle modifiche.
**Documenti correlati:**
+ [ Prontuario AWS - Playbook di base per grandi migrazioni AWS: 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-BP07 Predefinizione o negoziazione delle responsabilità tra i team
Fai in modo che esistano accordi definiti o negoziati 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 sia di non affrontare le attività necessarie in modo tempestivo sia 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, riceverà 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 su come i team devono collaborare.
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 titolarità dei processi deve essere stabilita prima di definire gli 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 titolarità delle attività operative deve essere stabilita prima di definire gli accordi tra i team.
**Documenti correlati:**
+ [AWS Executive Insights - Promuovere l'innovazione con i team da due pizze ](https://aws.amazon.com/executive-insights/content/amazon-two-pizza-team/)
+ [ Introduzione a DevOps su AWS - I team da due pizze ](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/two-pizza-teams.html)