# OPS 7. Come fai a sapere se hai tutto pronto per supportare un carico di lavoro?
Valuta la disponibilità 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 Abilitazione 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 possiedi il numero appropriato di risorse del personale 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:**
+ Membri del team qualificati costituiscono 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 alla mancata adozione di questa best practice:** 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à.
1. Forma il personale sul software e sulle piattaforme che costituiscono il carico di lavoro.
1. [AWS Training and Certification](https://aws.amazon.com/training/) offre una raccolta 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 da esperti AWS.
1. Valuta regolarmente 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.
**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 Gestione delle informazioni](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/)
+ [AWS Training and Certification](https://aws.amazon.com/training/)
# OPS07-BP02 Revisione costante della prontezza operativa
Usa le revisioni della prontezza operativa (ORR) per verificare che puoi 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 cogliere 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:** hai 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:** alto
## 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 i 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 [AWS Control Tower Guardrails](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html)per creare le best practice dalla ORR nei 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 tempo, AnyCompany Retail ha utilizzato [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) per individuare le best practices, accelerando il processo ORR.
**Passaggi dell'implementazione**
Per ulteriori informazioni sulle ORR, consulta il [whitepaper Operational Readiness Reviews (ORR) (Revisioni della prontezza operativa (ORR))](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/wa-operational-readiness-reviews.html). 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 gli stakeholder importanti, inclusi i rappresentanti della sicurezza, delle operazioni e dello sviluppo.
1. Chiedi a ogni stakeholder 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 (Appendice B: Domande ORR di esempio)](https://docs.aws.amazon.com/wellarchitected/latest/operational-readiness-reviews/appendix-b-example-orr-questions.html) del whitepaper Operational Readiness Reviews (ORR) (Revisioni della prontezza operativa (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) nella funzione [AWS Well-Architected Tool](https://console.aws.amazon.com/wellarchiected/) per sviluppare la ORR e condividerla tra i tuoi account e l'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 non 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 di Supporto con supporto Enterprise possono richiedere il [workshop Operational Readiness Review (Revisione sulla prontezza operativa)](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/) al proprio Technical Account Manager (TAM). Il workshop è una sessione interattiva *di lavoro a ritroso* per sviluppare il tuo elenco di controllo ORR.
**Livello di impegno per il piano di implementazione:** alto. L'adozione di una procedura ORR nella tua organizzazione richiede la sponsorizzazione dell'esecutivo e l'adesione degli stakeholder. Crea e aggiorna l'elenco di controllo con input provenienti da tutta l'organizzazione.
## Risorse
**Best practice correlate:**
+ [OPS01-BP03 Valutazione dei 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 Fornitura di risorse appropriate ai team](ops_org_culture_team_res_appro.md) - La capacità del team è un buon requisito ORR.
+ [OPS06-BP01 Preparazione di un piano in caso di esito negativo delle modifiche](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 costituiscono eccellenti requisiti ORR.
+ [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 ripristino di emergenza sono un buon requisito ORR.
+ [COST02-BP01 Sviluppo di politiche 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 - Guardrails in AWS Control Tower (Guardrail in AWS Control Tower)](https://docs.aws.amazon.com/controltower/latest/userguide/guardrails.html)
+ [AWS Well-Architected Tool - Custom Lenses (Obiettivi personalizzati)](https://docs.aws.amazon.com/wellarchitected/latest/userguide/lenses-custom.html)
+ [Operational Readiness Review Template by Adrian Hornsby (Modello di revisione della prontezza operativa di Adrian Hornsby)](https://medium.com/the-cloud-architect/operational-readiness-review-template-e23a4bfd8d79)
+ [Whitepaper Operational Readiness Reviews (ORR) (Revisioni della prontezza operativa (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) (AWS ti supporta \$1 Creazione di un'efficace revisione della prontezza operativa (ORR))](https://www.youtube.com/watch?v=Keo6zWMQqS8)
**Esempi correlati:**
+ [Sample Operational Readiness Review (ORR) Lens (Esempio di obiettivi per la revisione della prontezza operativa (ORR))](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'inserimento 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.
A mano a 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 e aggiornati di frequente.
**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 alle 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 eseguire il runbook da un membro diverso del tuo team. A mano a mano che la procedura si evolve, 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. Utilizzando servizi come [Automazioni AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html), puoi 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.
**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.
```
# Titolo runbook ## Informazioni runbook | ID runbook | Descrizione | Strumenti utilizzati | Autorizzazioni speciali | Autore runbook | Data ultimo aggiornamento | POC escalation | |-------|-------|-------|-------|-------|-------|-------| | RUN001 | Argomento runbook Risultato desiderato | Strumenti | Autorizzazioni | Nome e cognome | 21-09-2022 | Nome escalation | ## Passaggi 1. Passaggio 1 2. Passaggio 2
```
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 è un processo 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. Compila il campo `Titolo runbook` e i campi obbligatori nell'area `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. A mano a 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 testo. 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](ops_ops_model_def_proc_owners.md): i runbook devono avere un proprietario responsabile della loro manutenzione.
+ [OPS07-BP04 Utilizzo dei playbook per analizzare i problemi](ops_ready_to_support_use_playbooks.md): i runbook e i playbook sono pressoché simili, con un'unica differenza, ovvero in un runbook è previsto un risultato desiderato. In molti casi, i runbook vengono attivati dopo che un playbook ha individuato una causa principale.
+ [OPS10-BP01 Utilizzo di un processo per la gestione di eventi, incidenti e problemi](ops_event_response_event_incident_problem_process.md): i runbook costituiscono una best practice per la gestione di eventi, incidenti e problemi.
+ [OPS10-BP02 Definizione di un processo per ogni avviso](ops_event_response_process_per_alert.md): i runbook e i playbook devono essere utilizzati in risposta agli avvisi. Nel corso del tempo queste reazioni devono essere automatizzate.
+ [OPS11-BP04 Gestione delle informazioni](ops_evolve_ops_knowledge_management.md): la gestione dei runbook è un elemento fondamentale della gestione delle conoscenze.
**Documenti correlati:**
+ [Achieving Operational Excellence using automated playbook and runbook (Eccellenza operativa mediante playbook e runbook automatizzati)](https://aws.amazon.com/blogs/mt/achieving-operational-excellence-using-automated-playbook-and-runbook/)
+ [AWS Systems Manager: Working with runbooks (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 (Playbook per la migrazione per migrazioni AWS di grandi dimensioni - Attività 4: Ottimizzazione dei runbook per la migrazione)](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 (Utilizzo dei runbook di Automazione AWS Systems Manager per la risoluzione delle attività operative)](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) (Guida fai da te per runbook, report e risposte relativi agli incidenti [SEC318-R1])](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [How to automate IT Operations on AWS \$1 Amazon Web Services (Procedure di automazione delle operazioni IT in AWS \$1 Amazon Web Services)](https://www.youtube.com/watch?v=GuWj_mlyTug)
+ [Integrate Scripts into AWS Systems Manager (Integrazione di script in AWS Systems Manager)](https://www.youtube.com/watch?v=Seh1RbnF-uE)
**Esempi correlati:**
+ [AWS Systems Manager: Automation walkthroughs (Procedure di automazione dettagliate)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk.html)
+ [AWS Systems Manager: Restore a root volume from the latest snapshot runbook (Runbook per il ripristino di un volume root volume dallo snapshot più recente)](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 (Creazione di un runbook per le risposte agli incidenti AWS mediante notebook Jupyter e data lake CloudTrail)](https://catalog.us-east-1.prod.workshops.aws/workshops/a5801f0c-7bd6-4282-91ae-4dfeb926a035/en-US)
+ [Gitlab - Runbooks (Runbook)](https://gitlab.com/gitlab-com/runbooks)
+ [Rubix - A Python library for building runbooks in Jupyter Notebooks (Rubix - Libreria Python per la creazione di runbook in notebook Jupyter)](https://github.com/Nurtch/rubix)
+ [Using Document Builder to create a custom runbook (Utilizzo di Document Builder per creare un runbook personalizzato)](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html)
+ [Well-Architected Labs: Automating operations with Playbooks and Runbooks (Automazione delle operazioni con playbook e runbook)](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
**Servizi correlati:**
+ [AWS Systems Manager Automation (Automazione AWS Systems Manager)](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 funzionalità chiave 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 gli stakeholder 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 centralmente 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 i passaggi di rilevamento. Assicurati di avere i relativi runbook per mitigare le cause principali più comuni.
**Risultato desiderato:** l'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 frequentemente. 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à per mitigare gli 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 accelerano 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 semi automatizzati 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à. Utilizzando servizi come [Automazione AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html), il testo normale può essere trasformato in automazioni che possono essere eseguite 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.
I clienti possono utilizzare [Strumento di gestione degli incidenti AWS Systems Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) per rispondere agli incidenti. Questo servizio fornisce un'unica interfaccia per valutare gli incidenti, informare gli stakeholder circa il rilevamento e la mitigazione e collaborare per tutta la durata dell'incidente. Utilizza Automazione AWS Systems Manager per accelerare il rilevamento e il ripristino.
**Esempio del cliente**
Si è verificato un incidente che ha avuto un impatto sulla produzione della società AnyCompany Retail. L'ingegnere di turno utilizza un playbook per analizzare il problema e man mano che esegue i passaggi, mantiene aggiornati gli stakeholder indicati nel playbook. L'ingegnere identifica la causa principale come una race condition di un servizio di back-end. 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, che è compatibile con la maggior parte dei sistemi di automazione dei playbook. Se parti da zero, utilizza il seguente modello di playbook come esempio.
```
# Titolo del playbook ## Informazioni sul playbook | ID playbook | Descrizione | Strumenti utilizzati | Autorizzazioni speciali | Autore del playbook | Ultimo aggiornamento | POC di escalation | Stakeholder | Piano di comunicazione | |-------|-------|-------|-------|-------|-------|-------|-------|-------| | RUN001 | A cosa serve questo playbook? Per quale incidente viene utilizzato? | Strumenti | Autorizzazioni | Il tuo nome | 21-09-2022 | Nome dell'escalation | Nome dello stakeholder | Come vengono comunicati gli aggiornamenti durante l'analisi? | ## Passaggi 1. Passaggio 1 2. Passaggio 2
```
1. Se non disponi di un repository o di un wiki per i documenti, crea nel sistema di controllo delle versioni in uso un nuovo repository con il controllo delle versioni per i tuoi playbook.
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 i passaggi 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 tutti gli stakeholder.
1. Questa libreria diventerà sempre più ricca man mano che aggiungi altri playbook. Una volta che sono disponibili diversi playbook, inizia ad automatizzarli con strumenti come Automazione 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](ops_ops_model_def_proc_owners.md): i playbook devono avere un proprietario responsabile della manutenzione.
+ [OPS07-BP03 Utilizzo di runbook per eseguire le procedure](ops_ready_to_support_use_runbooks.md): i runbook e i playbook sono praticamente simili con un'unica differenza, ovvero in un runbook è previsto un risultato desiderato. In molti casi, i runbook vengono utilizzati dopo che un playbook ha individuato la causa principale.
+ [OPS10-BP01 Utilizzo di un processo per la gestione di eventi, incidenti e problemi](ops_event_response_event_incident_problem_process.md): i playbook costituiscono una best practice per la gestione di eventi, incidenti e problemi.
+ [OPS10-BP02 Definizione di un processo per ogni avviso](ops_event_response_process_per_alert.md): i runbook e i playbook devono essere utilizzati in risposta agli avvisi. Nel corso del tempo queste reazioni devono essere automatizzate.
+ [OPS11-BP04 Gestione delle informazioni](ops_evolve_ops_knowledge_management.md): la manutenzione dei playbook è un elemento chiave della gestione delle conoscenze.
**Documenti correlati:**
+ [ Achieving Operational Excellence using automated playbook and runbook (Eccellenza operativa mediante playbook e runbook automatizzati) ](https://aws.amazon.com/blogs/mt/achieving-operational-excellence-using-automated-playbook-and-runbook/)
+ [AWS Systems Manager: Utilizzo di runbook](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents.html)
+ [ Use AWS Systems Manager Automation runbooks to resolve operational tasks (Utilizzo dei runbook di Automazione AWS Systems Manager per la risoluzione delle attività operative) ](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) (Guida fai da te per runbook, report e risposte relativi agli incidenti (SEC318-R1)) ](https://www.youtube.com/watch?v=E1NaYN_fJUo)
+ [Strumento di gestione degli incidenti AWS Systems Manager - AWS Virtual Workshops (Workshop virtuali AWS) ](https://www.youtube.com/watch?v=KNOc0DxuBSY)
+ [ Integrate Scripts into AWS Systems Manager (Integrazione di script in AWS Systems Manager) ](https://www.youtube.com/watch?v=Seh1RbnF-uE)
**Esempi correlati:**
+ [AWS Customer Playbook Framework (Framework di playbook del cliente AWS) ](https://github.com/aws-samples/aws-customer-playbook-framework)
+ [AWS Systems Manager: Automation walkthroughs (Procedure di automazione dettagliate) ](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk.html)
+ [ Building an AWS incident response runbook using Jupyter notebooks and CloudTrail Lake (Creazione di un runbook per le risposte agli incidenti AWS mediante notebook Jupyter e data lake CloudTrail) ](https://catalog.workshops.aws/workshops/a5801f0c-7bd6-4282-91ae-4dfeb926a035/en-US)
+ [ Rubix - A Python library for building runbooks in Jupyter Notebooks (Rubix - Libreria Python per la creazione di runbook in notebook Jupyter) ](https://github.com/Nurtch/rubix)
+ [ Using Document Builder to create a custom runbook (Utilizzo di Document Builder per creare un runbook personalizzato) ](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html)
+ [ Well-Architected Labs: Automating operations with Playbooks and Runbooks (Automazione delle operazioni con playbook e runbook) ](https://wellarchitectedlabs.com/operational-excellence/200_labs/200_automating_operations_with_playbooks_and_runbooks/)
+ [ Well-Architected Labs: Incident response playbook with Jupyter (Well-Architected Labs: playbook di risposta agli incidenti con Jupyter) ](https://www.wellarchitectedlabs.com/security/300_labs/300_incident_response_playbook_with_jupyter-aws_iam/)
**Servizi correlati:**
+ [ Automazione AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [Strumento di gestione degli incidenti AWS Systems 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 processi per la gestione delle modifiche efficaci e infruttuose al carico di lavoro. 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 i vantaggi e i 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.
+ Le modifiche sono 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 alla mancata adozione di questa best practice:** 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 i vantaggi e i 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 attiverebbero 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 degli stakeholder in tutta l'organizzazione
## Risorse
**Best practice correlate:**
+ [OPS01-BP03 Valutazione dei requisiti di governance](ops_priorities_governance_reqs.md) – I requisiti di governance sono un fattore chiave per determinare se implementare una modifica.
+ [OPS06-BP01 Preparazione di un piano in caso di esito negativo delle modifiche](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 dei 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 nel Cloud AWS: il giusto equilibrio tra agilità e sicurezza ](https://aws.amazon.com/blogs/apn/governance-in-the-aws-cloud-the-right-balance-between-agility-and-safety/)
# OPS07-BP06 Abilitazione 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 è coinvolto 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 inoltrare il 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 superiore su qualsiasi account su cui hai 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, hanno il supporto Enterprise di AWS abilitato 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. Lavora 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 un mix di strumenti e tecnologie, persone e programmi progettati per aiutarti in modo proattivo a ottimizzare le performance, ridurre i costi e innovare più rapidamente. Il supporto Business di AWS offre vantaggi aggiuntivi, tra cui l'accesso a AWS Trusted Advisor e ad AWS Personal Health Dashboard, nonché tempi di risposta più rapidi.
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:**
+ [ Piani Supporto AWS](https://docs.aws.amazon.com/awssupport/latest/user/aws-support-plans.html)
**Servizi correlati:**
+ [ Supporto del Business AWS](https://aws.amazon.com/premiumsupport/plans/business/)
+ [ Supporto Enterprise AWS](https://aws.amazon.com/premiumsupport/plans/enterprise/)