# OPS 7. Come fai a sapere se hai tutto pronto per supportare un carico di lavoro?
Valuta la prontezza operativa del carico di lavoro, dei processi e delle procedure, nonché del personale per comprendere i rischi operativi correlati al carico di lavoro.
**Topics**
+ [
# OPS07-BP01 Verifica della capacità del personale
](ops_ready_to_support_personnel_capability.md)
+ [
# OPS07-BP02 Revisione costante della prontezza operativa
](ops_ready_to_support_const_orr.md)
+ [
# OPS07-BP03 Utilizzo di runbook per eseguire le procedure
](ops_ready_to_support_use_runbooks.md)
+ [
# OPS07-BP04 Utilizzo dei playbook per analizzare i problemi
](ops_ready_to_support_use_playbooks.md)
+ [
# OPS07-BP05 Adozione di decisioni informate per implementare sistemi e modifiche
](ops_ready_to_support_informed_deploy_decisions.md)
+ [
# OPS07-BP06 Creazione dei piani di supporto per i carichi di lavoro di produzione
](ops_ready_to_support_enable_support_plans.md)
# OPS07-BP01 Verifica della capacità del personale
Predisponi un meccanismo per stabilire se è disponibile il numero appropriato di risorse qualificate per supportare il carico di lavoro. Le risorse devono essere state formate sulla piattaforma e sui servizi che costituiscono il tuo carico di lavoro. Fornisci loro le informazioni necessarie per eseguire il carico di lavoro. Devi avere a disposizione personale qualificato sufficiente per supportare il normale funzionamento del carico di lavoro e gestire gli eventuali incidenti. Predisponi personale sufficiente per la rotazione durante la reperibilità e le ferie per evitare motivi di frustrazione.
**Risultato desiderato:**
+ Presenza di personale qualificato sufficiente per supportare il carico di lavoro nei momenti in cui è disponibile.
+ Capacità di fornire al personale formazione sul software e sui servizi che costituiscono il carico di lavoro.
**Anti-pattern comuni:**
+ Implementazione di un carico di lavoro senza membri del team qualificati per l'esecuzione della piattaforma e dei servizi in uso.
+ Mancanza di personale sufficiente per supportare la reperibilità a rotazione o le richieste di permesso del personale.
**Vantaggi dell'adozione di questa best practice:**
+ Presenza di membri del team qualificati che offrono un supporto efficace al carico di lavoro.
+ Con un numero sufficiente di membri del team, puoi supportare il carico di lavoro e la reperibilità a rotazione, riducendo il rischio di frustrazione.
**Livello di rischio associato se questa best practice non fosse adottata:** elevato
## Guida all'implementazione
Verifica che sia disponibile personale qualificato sufficiente per supportare il carico di lavoro. Assicurati che il numero di membri del team di cui disponi sia sufficiente a coprire le normali attività operative, inclusa la reperibilità a rotazione.
**Esempio del cliente**
AnyCompany Retail si assicura che i team che supportano il carico di lavoro includano personale qualificato sufficiente. L'azienda ha al suo interno un numero sufficiente di tecnici per supportare la reperibilità a rotazione. Il personale riceve formazione sul software e sulla piattaforma su cui è basato il carico di lavoro e viene incoraggiato a conseguire certificazioni. Vi è personale sufficiente per permettere alle persone di richiedere permessi di assenza, continuando a supportare il carico di lavoro durante la reperibilità a rotazione.
### Passaggi dell'implementazione
1. Assegna un numero adeguato di risorse del personale per eseguire e supportare il carico di lavoro, tenendo conto della reperibilità, dei problemi relativi alla sicurezza e degli eventi del ciclo di vita, come la fine del supporto e le attività di rotazione dei certificati.
1. Forma il personale sul software e sulle piattaforme che costituiscono il carico di lavoro.
1. [Formazione e certificazione AWS](https://aws.amazon.com/training/) offre una libreria di corsi su AWS. Sono disponibili corsi gratuiti e a pagamento, online e di persona.
1. [AWS organizza eventi e webinar](https://aws.amazon.com/events/) in cui puoi apprendere dagli esperti AWS.
1. Effettua le seguenti operazioni regolarmente:
+ Valuta le dimensioni e le competenze del team in base al mutare delle condizioni operative e del carico di lavoro.
+ Adegua le dimensioni e le competenze del team ai requisiti operativi.
+ Verifica la capacità di [affrontare gli eventi pianificati del ciclo di vita](https://docs.aws.amazon.com/health/latest/ug/aws-health-planned-lifecycle-events.html), la sicurezza non pianificata e le notifiche operative tramite AWS Health.
**Livello di impegno per il piano di implementazione:** elevato. L'assunzione e la formazione di un team per supportare il carico di lavoro possono richiedere un impegno significativo, ma assicurano solidi vantaggi a lungo termine.
## Risorse
**Best practice correlate:**
+ [OPS11-BP04 Eseguire la gestione della conoscenza](ops_evolve_ops_knowledge_management.md): i membri del team devono disporre delle informazioni necessarie per eseguire e supportare il carico di lavoro. La gestione delle informazioni è il fattore chiave a questo scopo.
**Documenti correlati:**
+ [Eventi e webinar AWS](https://aws.amazon.com/events/)
+ [Formazione e certificazione AWS](https://aws.amazon.com/training/)
# OPS07-BP02 Revisione costante della prontezza operativa
Usa le revisioni sulla prontezza operativa (ORR) per verificare la possibilità di utilizzare il carico di lavoro. ORR è un meccanismo sviluppato da Amazon per verificare che i team possano utilizzare in sicurezza i propri carichi di lavoro. ORR è un processo di revisione e ispezione che utilizza un elenco di controllo per i requisiti. È un'esperienza self-service che i team utilizzano per certificare i propri carichi di lavoro. Le ORR includono le best practice delle lezioni apprese durante gli anni dedicati alla creazione di software.
Un elenco di controllo ORR è composto da suggerimenti sull'architettura, processo operativo, gestione degli eventi e qualità del rilascio. Il nostro processo di correzione dell'errore (CoE, Correction of Error) è uno dei principali fattori trainanti di questi elementi. L'analisi post-incidente deve guidare l'evoluzione della ORR. Una ORR non riguarda solo l'adozione delle best practice, ma anche la prevenzione del ripetersi di eventi già visti. Infine, in una ORR possono essere inclusi anche i requisiti di sicurezza, governance e conformità.
Esegui le ORR prima che un carico di lavoro venga lanciato nella disponibilità generale e quindi durante tutto il ciclo di vita dello sviluppo software. L'esecuzione della ORR prima del lancio aumenta la tua capacità di utilizzare il carico di lavoro in sicurezza. Riesegui periodicamente la ORR sul carico di lavoro per individuare eventuali scostamenti dalle best practice. Puoi usare gli elenchi di controllo ORR per il lancio di nuovi servizi e le ORR per le revisioni periodiche. In tal modo puoi tenerti aggiornato sulle nuove best practice che emergono e incorporare le lezioni apprese dall'analisi post-incidente. Man mano che l'utilizzo del cloud cresce, puoi creare i requisiti di ORR nella tua architettura come valori predefiniti.
**Risultato desiderato:** disponi di un elenco di controllo ORR con le best practice per la tua organizzazione. Le ORR vengono eseguite prima dell'avvio dei carichi di lavoro. Le ORR vengono eseguite periodicamente nel corso del ciclo di vita del carico di lavoro.
**Anti-pattern comuni:**
+ Avvii un carico di lavoro senza sapere se puoi utilizzarlo.
+ I requisiti di governance e sicurezza non sono inclusi nella certificazione di un carico di lavoro per l'avvio.
+ I carichi di lavoro non vengono rivalutati periodicamente.
+ I carichi di lavoro vengono avviati senza le procedure richieste.
+ Si osserva la ripetizione di errori con la stessa causa principale in più carichi di lavoro.
**Vantaggi dell'adozione di questa best practice:**
+ I tuoi carichi di lavoro includono le best practice di architettura, processo e gestione.
+ Le lezioni apprese sono incorporate nel processo ORR.
+ Le procedure richieste sono in atto all'avvio dei carichi di lavoro.
+ Le ORR vengono eseguite durante l'intero ciclo di vita del software dei carichi di lavoro.
**Livello di rischio se questa best practice non fosse adottata:** elevato
## Guida all'implementazione
Una ORR è composta da un processo e un elenco di controllo. Il processo ORR deve essere adottato dall'organizzazione e supportato da uno sponsor esecutivo. Come minimo, le ORR devono essere eseguite prima che il carico di lavoro venga lanciato nella disponibilità generale. Esegui la ORR durante tutto il ciclo di vita dello sviluppo software per mantenerlo aggiornato con le best practice o i nuovi requisiti. L'elenco di controllo ORR deve includere elementi di configurazione, requisiti di sicurezza e governance e best practice dell'organizzazione. Nel tempo, puoi utilizzare servizi come, [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html), [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html), e [guardrail di AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html) per sviluppare best practice dall'ORR ai guardrail per il rilevamento automatico delle best practice.
**Esempio del cliente**
Dopo diversi incidenti di produzione, AnyCompany Retail ha deciso di implementare un processo ORR. Ha creato un elenco di controllo composto da best practice, requisiti di governance e conformità e lezioni apprese dalle interruzioni. I nuovi carichi di lavoro conducono le ORR prima dell'avvio. Ogni carico di lavoro esegue una ORR annuale con un sottoinsieme di best practice per incorporare nuove best practice e requisiti che vengono aggiunti all'elenco di controllo ORR. Nel corso del tempo, AnyCompany Retail ha utilizzato [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) per rilevare alcune best practice, velocizzando il processo ORR.
**Passaggi dell'implementazione**
Per maggiori informazioni sulle ORR, consulta il [whitepaper Operational Readiness Reviews (ORR)](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html). Il documento fornisce informazioni dettagliate sulla cronologia del processo ORR, su come creare la procedura ORR e su come sviluppare il proprio elenco di controllo ORR. I passaggi seguenti costituiscono una versione abbreviata di quel documento. Per una comprensione approfondita di cosa sono le ORR e di come crearne una, ti consigliamo di leggere il whitepaper.
1. Riunisci le parti interessate importanti, inclusi i rappresentanti della sicurezza, delle operazioni e dello sviluppo.
1. Chiedi a ogni parte interessata di indicare almeno un requisito. Per la prima iterazione, prova a limitare il numero di elementi a trenta al massimo.
+ [Appendix B: Example ORR questions](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/appendix-b-example-orr-questions.html) del whitepaper Operational Readiness Reviews (ORR) contiene domande di esempio che puoi utilizzare per iniziare.
1. Raccogli i tuoi requisiti in un foglio di calcolo.
+ Puoi utilizzare gli [obiettivi personalizzati](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html) di [AWS Well-Architected Tool](https://console.aws.amazon.com/wellarchiected/) per creare la tua ORR e condividerla tra i tuoi account e la tua organizzazione AWS.
1. Identifica un carico di lavoro su cui condurre la ORR. L'ideale è un carico di lavoro pre-lancio o un carico di lavoro interno.
1. Scorri l'elenco di controllo ORR e prendi nota di tutti i rilevamenti fatti. I rilevamenti potrebbero essere validi se è in atto una mitigazione. Aggiungi qualsiasi rilevamento privo di mitigazione al tuo backlog di elementi e implementalo prima del lancio.
1. Continua ad aggiungere le best practice e i requisiti all'elenco di controllo ORR nel corso del tempo.
I clienti Supporto con supporto Enterprise possono richiedere il [workshop Operational Readiness Review](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/) al proprio Technical Account Manager. Il workshop è strutturato come una sessione interattiva di *lavoro a ritroso* per sviluppare il proprio elenco di controllo ORR.
**Livello di impegno per il piano di implementazione:** elevato. L'adozione di una procedura ORR nella tua organizzazione richiede la sponsorizzazione dell'esecutivo e l'adesione delle parti interessate. Crea e aggiorna l'elenco di controllo con input provenienti da tutta l'organizzazione.
## Risorse
**Best practice correlate:**
+ [OPS01-BP03 Valuta i requisiti di governance](ops_priorities_governance_reqs.md): i requisiti di governance sono una scelta naturale per un elenco di controllo ORR.
+ [OPS01-BP04 Valutazione dei requisiti di conformità](ops_priorities_compliance_reqs.md): i requisiti di conformità sono talvolta inclusi in un elenco di controllo ORR. Altre volte costituiscono un processo separato.
+ [OPS03-BP07 Team di risorse appropriati](ops_org_culture_team_res_appro.md): la capacità del team è un buon requisito ORR.
+ [OPS06-BP01 Piano per modifiche non riuscite](ops_mit_deploy_risks_plan_for_unsucessful_changes.md): prima di avviare il carico di lavoro, è necessario stabilire un piano di rollback o rollforward.
+ [OPS07-BP01 Verifica della capacità del personale](ops_ready_to_support_personnel_capability.md): per supportare un carico di lavoro è necessario disporre del personale necessario.
+ [SEC01-BP03 Identificazione e convalida degli obiettivi di controllo:](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_control_objectives.html) gli obiettivi di controllo della sicurezza sono requisiti ORR di eccellenza.
+ [REL13-BP01 Definizione degli obiettivi di ripristino in caso di downtime e perdita di dati:](https://docs.aws.amazon.com/wellarchitected/latest/framework/rel_planning_for_recovery_objective_defined_recovery.html) i piani di disaster recovery sono un buon requisito ORR.
+ [COST02-BP01 Sviluppo di policy basate sui requisiti dell'organizzazione:](https://docs.aws.amazon.com/wellarchitected/latest/framework/cost_govern_usage_policies.html) le policy di gestione dei costi sono utili da includere nell'elenco di controllo ORR.
**Documenti correlati:**
+ [AWS Control Tower: guardrail in AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html)
+ [AWS Well-Architected Tool - Custom Lenses](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html)
+ [Operational Readiness Review Template di Adrian Hornsby](https://medium.com/the-cloud-architect/operational-readiness-review-template-e23a4bfd8d79)
+ [Whitepaper Operational Readiness Reviews (ORR)](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html)
**Video correlati:**
+ [Supporto AWSs You \$1 Building an Effective Operational Readiness Review (ORR)](https://www.youtube.com/watch?v=Keo6zWMQqS8)
**Esempi correlati:**
+ [Sample Operational Readiness Review (ORR) Lens](https://github.com/aws-samples/custom-lens-wa-sample/tree/main/ORR-Lens)
**Servizi correlati:**
+ [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)
+ [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)
+ [AWS Well-Architected Tool](https://docs.aws.amazon.com/wellarchitected/latest/userguide/intro.html)
# OPS07-BP03 Utilizzo di runbook per eseguire le procedure
Un *runbook* è un processo documentato finalizzato al raggiungimento di un determinato risultato. I runbook sono composti da una serie di passaggi che è necessario eseguire per conseguire un obiettivo. L'uso dei runbook può essere fatto risalire agli albori dell'aviazione. Nelle operazioni cloud, è possibile utilizzare i runbook per ridurre i rischi e ottenere i risultati desiderati. In estrema sintesi, un runbook è un elenco di controllo da seguire per completare un'attività.
I runbook costituiscono una parte essenziale del funzionamento dei carichi di lavoro. Dall'onboarding di un nuovo membro in un team all'implementazione di una versione principale, i runbook sono processi codificati che garantiscono risultati coerenti indipendentemente da chi li utilizza. I runbook devono essere pubblicati a livello centralizzato e aggiornati in base all'evoluzione del processo. L'aggiornamento dei runbook rappresenta infatti un elemento chiave dell'intero processo di gestione delle modifiche. Devono inoltre includere le linee guida relative a gestione degli errori, strumenti, autorizzazioni, eccezioni ed escalation in caso di problemi.
Man mano che l'organizzazione cresce, è consigliabile automatizzare i runbook. Inizia con runbook concisi e di frequente utilizzo. Utilizza un linguaggio di scripting per automatizzare le procedure o semplificarne l'esecuzione. Dopo aver automatizzato i primi runbook, potrai dedicare altro tempo all'automazione dei runbook più complessi. Gradualmente dovrai automatizzare la maggior parte dei runbook.
**Risultato desiderato:** il team dispone di una raccolta di linee guida dettagliate per l'esecuzione delle attività relative ai carichi di lavoro. I runbook contengono il risultato desiderato, gli strumenti e le autorizzazioni necessari e le istruzioni per la gestione degli errori. Vengono archiviati in una posizione centralizzata (sistema di controllo delle versioni) e aggiornati di frequente. Ad esempio, i runbook forniscono ai team le funzionalità per monitorare, comunicare e rispondere agli eventi AWS Health degli account critici durante gli allarmi delle applicazioni, i problemi operativi e gli eventi del ciclo di vita pianificati.
**Anti-pattern comuni:**
+ Ricorso alla memoria per completare i singoli passaggi di un processo.
+ Implementazione manuale delle modifiche senza utilizzare un elenco di controllo.
+ Vari membri dei team eseguono lo stesso processo con procedure o risultati diversi.
+ Mancato aggiornamento dei runbook in base alle modifiche o ai processi di automazione del sistema.
**Vantaggi dell'adozione di questa best practice:**
+ Riduzione della percentuale degli errori per le attività manuali.
+ Le operazioni vengono eseguite in modo coerente.
+ I nuovi membri dei team possono essere operativi da subito.
+ I runbook possono essere automatizzati per semplificare le operazioni più impegnative.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
I runbook possono avere vari formati, a seconda del livello di "maturità" dell'organizzazione. Nella loro formulazione minima, devono essere un documento di testo in cui sono dettagliate le procedure. Il risultato desiderato deve essere indicato in modo chiaro e preciso. Devono inoltre documentare in modo chiaro le autorizzazioni e gli strumenti speciali necessari. Devono includere linee guida dettagliate relative alla gestione degli errori e ai livelli di escalation nel caso in cui si verifichino problemi o errori. I runbook devono riportare il nome del proprietario ed essere pubblicati in una posizione centralizzata. Dopo averlo compilato, un runbook deve essere convalidato. A tale scopo, devi far predisporre il runbook da un membro diverso del tuo team. Con l'evoluzione della procedura, aggiorna i runbook in base al processo di gestione delle modifiche.
I runbook in formato testuale devono essere automatizzati a seconda dell'evoluzione dell'organizzazione. L'utilizzo di servizi come le [automazioni di AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) ti consentono di trasformare un testo non formattato in automazioni che possono essere eseguite nell'ambito di un carico di lavoro. Queste automazioni possono essere eseguite in risposta a eventi, per ridurre il carico operativo a salvaguardia del carico di lavoro. AWS Systems Manager Automation offre inoltre un'[esperienza di progettazione visiva](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-visual-designer.html) a uso limitato di codice per semplificare la creazione di runbook di automazione.
**Esempio del cliente**
AnyCompany Retail deve eseguire aggiornamenti dello schema del database durante le implementazioni del software. Il team responsabile delle operazioni cloud ha lavorato assieme al team addetto all'amministrazione del database per redigere un runbook per l'implementazione manuale di queste modifiche. Nel runbook sono incluse le procedure dettagliate sotto forma di elenco di controllo. È presente anche una sezione sulla gestione degli errori in caso di problemi. Il runbook è stato pubblicato assieme ad altri runbook sul wiki interno. Il team responsabile delle operazioni cloud pensa di pianificare l'automazione del runbook in futuro.
### Passaggi dell'implementazione
Se non è presente un repository di documenti, è consigliabile creare una libreria di runbook utilizzando un repository per il controllo delle versioni. Puoi creare i runbook utilizzando Markdown. Di seguito è riportato un modello di runbook di esempio che è possibile utilizzare come riferimento per la creazione dei runbook.
```
# Runbook Title
## Runbook Info
| Runbook ID | Description | Tools Used | Special Permissions | Runbook Author | Last Updated | Escalation POC |
|-------|-------|-------|-------|-------|-------|-------|
| RUN001 | What is this runbook for? What is the desired outcome? | Tools | Permissions | Your Name | 2022-09-21 | Escalation Name |
## Steps
1. Step one
2. Step two
```
1. Se non disponi di un repository o di un wiki per la documentazione, crea un repository per il controllo delle versioni nel sistema di controllo delle versioni in uso.
1. Individua un processo che non ha un runbook. Un processo ideale viene eseguito a cadenza più o meno regolare, con un numero limitato di passaggi e con errori a basso impatto.
1. Nel repository di documenti, crea una nuova bozza di documento Markdown utilizzando il modello. Specifica il titolo del runbook e i campi obbligatori in Informazioni runbook.
1. Partendo dal primo passaggio, compila l'area Passaggi del runbook.
1. Associa il runbook a un membro del team. Chiedi a tale membro di utilizzare il runbook per convalidare i passaggi. In caso di informazioni mancanti o poca chiarezza, aggiorna il runbook.
1. Pubblica il runbook nell'archivio della documentazione interna. Comunica l'avvenuta pubblicazione al team e alle altre parti interessate.
1. In questo modo, nel corso del tempo creerai una libreria di runbook. Man mano che la libreria cresce, comincia a pensare di automatizzare i runbook.
**Livello di impegno per il piano di implementazione:** basso Lo standard minimo previsto per i runbook è una guida dettagliata in formato testuale. L'automazione dei runbook può aumentare l'impegno a livello di implementazione.
## Risorse
**Best practice correlate:**
+ [OPS02-BP02 Assegnazione di proprietari identificati a processi e procedure](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_proc_owners.html)
+ [OPS07-BP04 Utilizzo dei playbook per analizzare i problemi](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_playbooks.html)
+ [OPS10-BP01 Utilizzo di un processo per la gestione di eventi, incidenti e problemi](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_event_incident_problem_process.html)
+ [OPS10-BP02 Definizione di un processo per ogni avviso](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_process_per_alert.html)
+ [OPS11-BP04 Gestione delle informazioni](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html)
**Documenti correlati:**
+ [Achieving Operational Excellence using automated playbook and runbook](https://aws.amazon.com/blogs/mt/achieving-operational-excellence-using-automated-playbook-and-runbook/)
+ [AWS Systems Manager: utilizzo dei runbook](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
+ [Migration playbook for AWS large migrations - Task 4: Improving your migration runbooks](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-migration-playbook/task-four-migration-runbooks.html)
+ [Use AWS Systems Manager Automation runbooks to resolve operational tasks](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/)
**Video correlati:**
+ [AWS re:Invent 2019: DIY guide to runbooks, incident reports, and incident response](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [How to automate IT Operations on AWS \$1 Amazon Web Services](https://www.youtube.com/watch?v=GuWj_mlyTug)
+ [Integrate Scripts into AWS Systems Manager](https://www.youtube.com/watch?v=Seh1RbnF-uE)
**Esempi correlati:**
+ [Well-Architected Labs: automazione delle operazioni con playbook e runbook](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
+ [AWS Post del blog : Build a Cloud Automation Practice for Operational Excellence: Best Practices AWS Managed Services](https://aws.amazon.com/blogs/mt/build-a-cloud-automation-practice-for-operational-excellence-best-practices-from-aws-managed-services/)
+ [AWS Systems Manager: Automation walkthroughs](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk.html)
+ [AWS Systems Manager: Restore a root volume from the latest snapshot runbook](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-document-sample-restore.html)
+ [Building an AWS incident response runbook using Jupyter notebooks and CloudTrail Lake](https://catalog.us-east-1.prod.workshops.aws/workshops/a5801f0c-7bd6-4282-91ae-4dfeb926a035/en-US)
+ [Gitlab: runbook](https://gitlab.com/gitlab-com/runbooks)
+ [Rubix: una libreria Python per la creazione di runbook in notebook Jupyter](https://github.com/Nurtch/rubix)
+ [Using Document Builder to create a custom runbook](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html)
**Servizi correlati:**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
# OPS07-BP04 Utilizzo dei playbook per analizzare i problemi
I *playbook* sono guide dettagliate che vengono utilizzate quando si verificano incidenti per analizzare, valutare l'impatto e identificare la causa principale del problema. I playbook sono utili in molti scenari diversi, dalle implementazioni non riuscite agli incidenti di sicurezza. In molti casi, i playbook identificano la causa principale che viene poi mitigata tramite un runbook. I playbook costituiscono un componente essenziale dei piani di risposta agli incidenti di ogni organizzazione.
Un buon playbook include diverse caratteristiche principali che guidano l'utente, passo dopo passo, nel processo di rilevamento. Ma quali passaggi deve eseguire l'utente per diagnosticare un incidente? Illustra chiaramente nel playbook se sono necessari strumenti speciali o autorizzazioni elevate. È essenziale predisporre un piano di comunicazione per aggiornare le parti interessate sullo stato dell'analisi. Nelle situazioni in cui non è possibile identificare la causa principale, il playbook deve prevedere un piano di escalation. Se viene identificata la causa principale, il playbook deve includere il riferimento di un runbook che descrive come risolvere il problema. I playbook devono essere archiviati a livello centrale e aggiornati regolarmente. Se i playbook vengono utilizzati per avvisi specifici, fornisci al team i riferimenti dei playbook all'interno degli avvisi.
Man mano che l'organizzazione acquisisce maturità, puoi automatizzare i playbook. Inizia con i playbook che trattano incidenti a basso rischio. Utilizza gli script per automatizzare le procedure di rilevamento. Assicurati di avere i relativi runbook per mitigare le cause principali più comuni.
**Risultato desiderato:** la tua organizzazione dispone dei playbook per gli incidenti comuni. I playbook sono archiviati in una posizione centrale e disponibili per i membri del team. I playbook vengono aggiornati di frequente. Per qualsiasi causa principale nota, vengono creati i relativi runbook.
**Anti-pattern comuni:**
+ Non esiste un modo standard per analizzare un incidente.
+ I membri del team confidano nella "memoria muscolare" o nelle conoscenze istituzionali per risolvere i problemi di un'implementazione non riuscita.
+ I nuovi membri del team apprendono come analizzare i problemi attraverso tentativi ed errori.
+ Le best practice per l'analisi dei problemi non sono condivise tra i team.
**Vantaggi dell'adozione di questa best practice:**
+ I playbook rendono più efficaci le tue attività di mitigazione degli incidenti.
+ Uno stesso playbook può essere utilizzato da diversi membri del team in modo da identificare la causa principale in modo coerente.
+ Le cause principali note possono già disporre di runbook appositamente sviluppati, accelerando i tempi di ripristino.
+ I playbook contribuiscono ad accelerare la collaborazione tra i membri del team.
+ I team possono applicare i processi su vasta scala tramite i playbook ripetibili.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
Il modo in cui crei e utilizzi i playbook dipende dalla maturità della tua organizzazione. Se non hai familiarità con il cloud, crea i playbook in formato testo in un repository per i documenti centrale. Man mano che l'organizzazione acquisisce maturità, i playbook possono diventare semiautomatizzati tramite script scritti in linguaggi come Python. Questi script possono essere eseguiti all'interno di un notebook Jupyter per accelerare il rilevamento. Le organizzazioni avanzate dispongono di playbook completamente automatizzati per i problemi comuni che vengono risolti automaticamente con i runbook.
Inizia a creare i playbook elencando gli incidenti comuni che si verificano nel tuo carico di lavoro. Scegli i playbook per gli incidenti a basso rischio e in cui la causa principale è riconducibile a pochi problemi. Una volta creati i playbook per gli scenari più semplici, passa agli scenari a rischio più elevato o in cui la causa principale non è ancora nota.
I playbook in formato testo vengono automatizzati man mano che l'organizzazione acquisisce maturità. L'utilizzo di servizi come le [automazioni di AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) ti consentono di trasformare un semplice testo in automazioni eseguibili sul carico di lavoro per accelerare le analisi. Queste automazioni possono essere attivate in risposta agli eventi, riducendo il tempo medio per rilevare e risolvere gli incidenti.
Grazie a [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html), i clienti possono rispondere agli incidenti. Questo servizio fornisce un'unica interfaccia per valutare gli incidenti, informare le parti interessate circa il rilevamento e la mitigazione e collaborare per tutta la durata dell'incidente. Utilizza le automazioni di AWS Systems Manager per accelerare il rilevamento e il ripristino.
**Esempio del cliente**
Si è verificato un incidente che ha avuto un impatto sulla produzione dell'azienda AnyCompany Retail. L'ingegnere di turno utilizza un playbook per analizzare il problema e man mano che esegue i passaggi, mantiene aggiornate le parti interessate indicati nel playbook. L'ingegnere identifica la causa principale come una race condition di un servizio di backend. Utilizzando un runbook, l'ingegnere riavvia il servizio e riporta quindi AnyCompany Retail online.
### Passaggi dell'implementazione
Se non è già presente, è consigliabile creare un repository per i documenti con il controllo delle versioni per la libreria di playbook. Puoi creare i tuoi playbook utilizzando Markdown, compatibile con la maggior parte dei sistemi di automazione dei playbook. Se parti da zero, utilizza il seguente modello di playbook come esempio.
```
# Playbook Title
## Playbook Info
| Playbook ID | Description | Tools Used | Special Permissions | Playbook Author | Last Updated | Escalation POC | Stakeholders | Communication Plan |
|-------|-------|-------|-------|-------|-------|-------|-------|-------|
| RUN001 | What is this playbook for? What incident is it used for? | Tools | Permissions | Your Name | 2022-09-21 | Escalation Name | Stakeholder Name | How will updates be communicated during the investigation? |
## Steps
1. Step one
2. Step two
```
1. Se non disponi di un repository o di un wiki per i documenti, crea un nuovo repository di controllo per il controllo delle versioni per i tuoi playbook nel tuo sistema di controllo delle versioni.
1. Identifica un problema comune che richieda un'analisi, vale a dire uno scenario in cui la causa principale è riconducibile a pochi problemi e la risoluzione è a basso rischio.
1. Utilizzando il modello Markdown, compila la sezione Titolo del playbook e i campi in Informazioni sul playbook.
1. Includi le procedure per la risoluzione dei problemi. Illustra nel modo più chiaro possibile le azioni da eseguire o le aree da analizzare.
1. Chiedi a un membro del team di esaminare e convalidare il tuo playbook. Se manca un'informazione o è necessario un chiarimento, aggiorna il playbook.
1. Pubblica il tuo playbook nel repository per i documenti e informa il tuo team e tutte le parti interessate.
1. Questa libreria di playbook diventerà sempre più ricca man mano che ne aggiungerai altri. Una volta che sono disponibili diversi playbook, inizia ad automatizzarli con strumenti come le automazioni di AWS Systems Manager per mantenere sincronizzati l'automazione e i playbook.
**Livello di impegno per il piano di implementazione:** basso I playbook sono documenti di testo archiviati in una posizione centrale. Le organizzazioni che hanno acquisito maturità applicano l'automazione dei playbook.
## Risorse
**Best practice correlate:**
+ [OPS02-BP02 Assegnazione di proprietari identificati a processi e procedure](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_proc_owners.html)
+ [OPS07-BP03 Utilizzo di runbook per eseguire le procedure](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_runbooks.html)
+ [OPS10-BP01 Utilizzo di un processo per la gestione di eventi, incidenti e problemi](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_event_incident_problem_process.html)
+ [OPS10-BP02 Definizione di un processo per ogni avviso](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_process_per_alert.html)
+ [OPS11-BP04 Gestione delle informazioni](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html)
**Documenti correlati:**
+ [Achieving Operational Excellence using automated playbook and runbook](https://aws.amazon.com/blogs/mt/achieving-operational-excellence-using-automated-playbook-and-runbook/)
+ [AWS Systems Manager: utilizzo dei runbook](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
+ [Use AWS Systems Manager Automation runbooks to resolve operational tasks](https://aws.amazon.com/blogs/mt/use-aws-systems-manager-automation-runbooks-to-resolve-operational-tasks/)
**Video correlati:**
+ [AWS re:Invent 2019: DIY guide to runbooks, incident reports, and incident response (SEC318-R1)](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [AWS Systems Manager Incident Manager - AWS Virtual Workshops](https://www.youtube.com/watch?v=KNOc0DxuBSY)
+ [Integrate Scripts into AWS Systems Manager](https://www.youtube.com/watch?v=Seh1RbnF-uE)
**Esempi correlati:**
+ [AWS Framework per playbook per i clienti](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [AWS Systems Manager: Automation walkthroughs](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk.html)
+ [Building an AWS incident response runbook using Jupyter notebooks and CloudTrail Lake](https://catalog.workshops.aws/workshops/a5801f0c-7bd6-4282-91ae-4dfeb926a035/en-US)
+ [Rubix: una libreria Python per la creazione di runbook in notebook Jupyter](https://github.com/Nurtch/rubix)
+ [Using Document Builder to create a custom runbook](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html)
**Servizi correlati:**
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html)
# OPS07-BP05 Adozione di decisioni informate per implementare sistemi e modifiche
Predisponi i processi per la gestione delle modifiche al carico di lavoro che hanno restituito esito positivo e negativo. Si definisce "pre-mortem" un esercizio in cui il team simula un errore per sviluppare strategie di mitigazione. Utilizza questo esercizio per prevedere errori e creare procedure ove opportuno. Valuta vantaggi e rischi dell'implementazione di modifiche nel carico di lavoro. Verifica che tutte le modifiche siano conformi ai requisiti di governance.
**Risultato desiderato:**
+ Adozione di decisioni informate durante l'implementazione di modifiche nel carico di lavoro.
+ Modifiche conformi ai requisiti di governance.
**Anti-pattern comuni:**
+ Implementazione di una modifica nel carico di lavoro senza un processo per la gestione di un'implementazione errata.
+ Applicazione di modifiche all'ambiente di produzione che non sono conformi ai requisiti di governance.
+ Implementazione di una nuova versione del carico di lavoro senza stabilire valori di riferimento per l'utilizzo delle risorse.
**Vantaggi dell'adozione di questa best practice:**
+ L'azienda è preparata all'effetto di modifiche infruttuose al carico di lavoro.
+ Le modifiche apportate al carico di lavoro sono conformi ai criteri di governance.
**Livello di rischio associato se questa best practice non fosse adottata:** basso
## Guida all’implementazione
Usa esercizi pre-mortem per sviluppare processi per la gestione di modifiche infruttuose. Documenta i processi di gestione delle modifiche infruttuose. Verifica che tutte le modifiche siano conformi ai requisiti di governance. Valuta vantaggi e rischi dell'implementazione di modifiche nel carico di lavoro.
**Esempio del cliente**
AnyCompany Retail svolge regolarmente esercizi pre-mortem per convalidare i propri processi di gestione delle modifiche infruttuose. L'azienda documenta i propri processi in un Wiki condiviso che aggiorna spesso. Tutte le modifiche sono conformi ai requisiti di governance.
**Passaggi dell'implementazione**
1. Prendi decisioni informate durante l'implementazione di modifiche nel carico di lavoro. Definisci ed esamina i criteri per un'implementazione corretta. Sviluppa scenari o criteri che avvierebbero il ripristino dello stato precedente a una modifica. Soppesa i vantaggi dell'implementazione di modifiche rispetto ai rischi di una modifica infruttuosa.
1. Verifica che tutte le modifiche siano conformi ai requisiti di governance.
1. Usa esercizi pre-mortem per pianificare la gestione delle modifiche infruttuose e documentare le strategie di mitigazione. Esegui un esercizio di simulazione di un'emergenza per modellare una modifica infruttuosa e convalidare le procedure di ripristino dello stato precedente.
**Livello di impegno per il piano di implementazione:** moderato L'implementazione di una procedura di pre-mortem richiede il coordinamento e l'impegno delle parti interessate in tutta l'organizzazione
## Risorse
**Best practice correlate:**
+ [OPS01-BP03 Valuta i requisiti di governance](ops_priorities_governance_reqs.md): i requisiti di governance sono un fattore chiave per determinare se implementare una modifica.
+ [OPS06-BP01 Piano per modifiche non riuscite](ops_mit_deploy_risks_plan_for_unsucessful_changes.md): predisponi piani per mitigare un'implementazione non riuscita e usa esercizi di pre-mortem per convalidarli.
+ [OPS06-BP02 Implementazioni di test](ops_mit_deploy_risks_test_val_chg.md): ogni modifica software deve essere testata nel modo adeguato prima dell'implementazione per ridurre gli errori nell'ambiente di produzione.
+ [OPS07-BP01 Verifica della capacità del personale](ops_ready_to_support_personnel_capability.md): la presenza di personale qualificato sufficiente per supportare il carico di lavoro è essenziale per prendere una decisione informata riguardo all'implementazione di una modifica di sistema.
**Documenti correlati:**
+ [ Amazon Web Services: rischio e conformità ](https://docs.aws.amazon.com/whitepapers/latest/aws-risk-and-compliance/welcome.html)
+ [ Modello di responsabilità condivisa AWS](https://aws.amazon.com/compliance/shared-responsibility-model/)
+ [ Governance in the Cloud AWS: The Right Balance Between Agility and Safety ](https://aws.amazon.com/blogs/apn/governance-in-the-aws-cloud-the-right-balance-between-agility-and-safety/)
# OPS07-BP06 Creazione dei piani di supporto per i carichi di lavoro di produzione
Abilita il supporto per qualsiasi software e servizio a cui si affida il tuo carico di lavoro di produzione. Seleziona un livello di supporto adeguato per soddisfare le esigenze di assistenza della produzione. I piani di supporto per queste dipendenze sono necessari nel caso si verifichi un'interruzione del servizio o un problema di software. Documenta i piani di supporto e come chiedere assistenza per tutti i servizi e i fornitori di software. Implementa meccanismi di verifica per controllare che i riferimenti del supporto siano aggiornati.
**Risultato desiderato:**
+ Implementa piani di supporto per software e servizi a cui si affidano i carichi di lavoro di produzione.
+ Scegli un piano di supporto adeguato in base alle esigenze di assistenza.
+ Documenta i piani e i livelli di supporto e come richiedere assistenza.
**Anti-pattern comuni:**
+ Non hai piani di supporto per un fornitore software strategico. Il tuo carico di lavoro ne risente e non puoi fare nulla per accelerare un intervento risolutivo o per ricevere aggiornamenti tempestivi dal fornitore.
+ Uno sviluppatore, che era il punto di contatto primario di un fornitore di software, ha lasciato l'azienda. Non puoi contattare direttamente l'assistenza del fornitore. Devi investire il tuo tempo per cercare le informazioni e orientarti tra sistemi di contatto generici, aumentando così il livello di impegno richiesto per intervenire quando necessario.
+ Si verifica un'interruzione della produzione con un fornitore di software. Non esiste una documentazione su come inserire una richiesta di assistenza.
**Vantaggi dell'adozione di questa best practice:**
+ Con il livello di supporto adeguato, puoi ottenere una risposta nei tempi previsti per soddisfare le esigenze in termini di livelli di servizio.
+ In caso di problemi in produzione, puoi effettuare l'escalation del problema se sei un cliente assistito.
+ Fornitori di software e servizi possono essere di aiuto per la risoluzione dei problemi durante un incidente.
**Livello di rischio associato se questa best practice non fosse adottata:** basso
## Guida all'implementazione
Abilita i piani di supporto per qualsiasi fornitore di software e servizi a cui si affida il tuo carico di lavoro di produzione. Configura piani di supporto adeguati per soddisfare le esigenze di assistenza. Per i clienti AWS, questo significa abilitare il supporto Business di AWS o di livello superiore su qualsiasi account con carichi di lavoro di produzione. Incontra con regolarità i fornitori del servizio di assistenza per ricevere aggiornamenti sulle offerte di supporto, sui processi e sui contatti. Documenta come richiedere assistenza ai fornitori di software e servizi, incluso come inoltrare il problema in caso si verificasse un'interruzione. Implementa meccanismi di aggiornamento dei contatti del supporto.
**Esempio del cliente**
In AnyCompany Retail, tutte le dipendenze di servizi e software commerciali hanno piani di supporto. Ad esempio, l'azienda sfrutta il supporto Enterprise di AWS attivato su tutti gli account con carichi di lavoro di produzione. In caso di problemi, qualsiasi sviluppatore può inserire una richiesta di assistenza. Esiste una pagina wiki con informazioni su come richiedere assistenza, chi contattare e quali best practice seguire per accelerare il processo di risoluzione.
**Passaggi dell'implementazione**
1. Collabora con le parti interessate all'interno della tua organizzazione per identificare i fornitori di software e servizi su cui si basa il tuo carico di lavoro. Documenta queste dipendenze.
1. Stabilisci le esigenze in termini di assistenza del tuo carico di lavoro. Seleziona un piano di supporto in linea con tali esigenze.
1. Per software e servizi commerciali definisci un piano di supporto con i fornitori.
1. Sottoscrivere il supporto Business di AWS o un livello superiore per tutti gli account di produzione garantisce tempi di risposta più rapidi da Supporto AWS ed è una scelta fortemente consigliata. Se non hai il supporto premium, devi avere un piano di azione per gestire i problemi, che richiede l'aiuto di Supporto AWS. Supporto AWS offre una combinazione di strumenti e tecnologie, persone e programmi progettati per aiutarti in modo proattivo a ottimizzare le performance, ridurre i costi e innovare più rapidamente. Inoltre, AWS Business Support offre ulteriori vantaggi, tra cui l'accesso delle API a AWS Trusted Advisor e AWS Health per l'integrazione programmatica con i sistemi, oltre ad altri metodi di accesso come la Console di gestione AWS e i canali Amazon EventBridge.
1. Documenta il tuo piano di supporto nello strumento di gestione delle conoscenze. Includi come richiedere assistenza, chi avvertire se viene inviata una richiesta di assistenza e come inoltrare il problema durante un incidente. Un wiki è un buon meccanismo che consente a tutti di apportare gli aggiornamenti necessari alla documentazione, nel momento in cui vengono a conoscenza di modifiche a processi o contatti del supporto.
**Livello di impegno per il piano di implementazione:** basso La maggior parte di fornitori di servizi e software offre piani di supporto da attivare. Documentando e condividendo le best practice di supporto sul tuo sistema di gestione delle conoscenze, puoi verificare che il tuo team sappia cosa fare quando si verifica un problema in produzione.
## Risorse
**Best practice correlate:**
+ [OPS02-BP02 Assegnazione di proprietari identificati a processi e procedure](ops_ops_model_def_proc_owners.md)
**Documenti correlati:**
+ [Supporto AWS Plans ](https://docs.aws.amazon.com/awssupport/latest/user/aws-support-plans.html)
**Servizi correlati:**
+ [Supporto AWS Business ](https://aws.amazon.com/premiumsupport/plans/business/)
+ [Supporto AWS Enterprise ](https://aws.amazon.com/premiumsupport/plans/enterprise/)