# Preparazione
**Topics**
+ [OPS 4. Come si implementa l'osservabilità nel carico di lavoro?](ops-04.md)
+ [OPS 5. In che modo riduci i difetti, favorisci la correzione e migliori il flusso nella produzione?](ops-05.md)
+ [OPS 6. In che modo mitighi i rischi della distribuzione?](ops-06.md)
+ [OPS 7. Come fai a sapere se hai tutto pronto per supportare un carico di lavoro?](ops-07.md)
# OPS 4. Come si implementa l'osservabilità nel carico di lavoro?
Implementare l'osservabilità nel carico di lavoro ti permette di comprendere lo stato di quest'ultimo e di adottare decisioni basate sui dati e che riflettono i requisiti aziendali.
**Topics**
+ [OPS04-BP01 Identificazione degli indicatori chiave di prestazione](ops_observability_identify_kpis.md)
+ [OPS04-BP02 Implementazione della telemetria dell'applicazione](ops_observability_application_telemetry.md)
+ [OPS04-BP03 Implementazione della telemetria dell'esperienza utente](ops_observability_customer_telemetry.md)
+ [OPS04-BP04 Implementazione della telemetria delle dipendenze](ops_observability_dependency_telemetry.md)
+ [OPS04-BP05 Implementazione del tracciamento distribuito](ops_observability_dist_trace.md)
# OPS04-BP01 Identificazione degli indicatori chiave di prestazione
L'implementazione dell'osservabilità nel carico di lavoro inizia con la comprensione del suo stato e l'adozione di decisioni basate sui dati che riflettono i requisiti aziendali. Uno dei modi più efficaci per garantire l'allineamento tra le attività di monitoraggio e gli obiettivi aziendali è definire e monitorare gli indicatori chiave di prestazione (KPI).
**Risultato desiderato:** Pratiche di osservabilità efficienti e strettamente allineate agli obiettivi aziendali garantiscono che le attività di monitoraggio siano sempre al servizio di risultati aziendali tangibili.
**Anti-pattern comuni:**
+ KPI non definiti: lavorare senza KPI chiari può portare ad attività di monitoraggio eccessive o insufficienti e alla perdita di segnali vitali.
+ KPI statici: non riesaminare od ottimizzare i KPI man mano che il carico di lavoro o gli obiettivi aziendali si evolvono.
+ Disallineamento: concentrarsi su metriche tecniche non direttamente correlate ai risultati aziendali o che sono più difficili da correlare ai problemi del mondo reale.
**Vantaggi dell'adozione di questa best practice:**
+ Facilità di identificazione dei problemi: i KPI aziendali spesso evidenziano i problemi in modo più chiaro rispetto alle metriche tecniche. Un valore di un KPI aziendale che diminuisce permette di individuare un problema in modo più efficace rispetto alla valutazione di numerose metriche tecniche.
+ Allineamento aziendale: assicura che le attività di monitoraggio supportino direttamente gli obiettivi aziendali.
+ Efficienza: viene data la priorità alle risorse di monitoraggio e al focus sulle metriche che contano.
+ Proattività: riconoscere e risolvere i problemi prima che abbiano implicazioni aziendali più ampie.
**Livello di rischio associato se questa best practice non fosse adottata:** alto
## Guida all'implementazione
Per definire in modo efficace i KPI del carico di lavoro:
1. **Inizia con i risultati aziendali:** prima di approfondire le metriche, comprendi i risultati aziendali desiderati. È stato rilevato un aumento delle vendite, un maggiore coinvolgimento degli utenti o tempi di risposta più rapidi?
1. **Correla le metriche tecniche con gli obiettivi aziendali:** non tutte le metriche tecniche hanno un impatto diretto sui risultati aziendali. Identifica quelli che hanno un impatto, anche se spesso è più immediato individuare un problema utilizzando un KPI aziendale.
1. **Utilizza [Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html):** Utilizza CloudWatch per definire e monitorare le metriche che rappresentano i tuoi KPI.
1. **Rivedi e aggiorna regolarmente i KPI:** man mano che il carico di lavoro e la tua attività si evolvono, mantieni la pertinenza dei tuoi KPI.
1. **Coinvolgi gli stakeholder:** coinvolgi i team tecnici e aziendali nella definizione e revisione dei KPI.
**Livello di impegno per il piano di implementazione:** Medio
## Risorse
**Best practice correlate:**
+ [OPS04-BP02 Implementazione della telemetria dell'applicazione](ops_observability_application_telemetry.md)
+ [OPS04-BP03 Implementazione della telemetria dell'esperienza utente](ops_observability_customer_telemetry.md)
+ [OPS04-BP04 Implementazione della telemetria delle dipendenze](ops_observability_dependency_telemetry.md)
+ [OPS04-BP05 Implementazione del tracciamento distribuito](ops_observability_dist_trace.md)
**Documenti correlati:**
+ [AWS Observability Best Practices ](https://aws-observability.github.io/observability-best-practices/)
+ [ CloudWatch User Guide ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [AWS Observability Skill Builder Course ](https://explore.skillbuilder.aws/learn/course/external/view/elearning/14688/aws-observability)
**Video correlati:**
+ [ Developing an observability strategy ](https://www.youtube.com/watch?v=Ub3ATriFapQ)
**Esempi correlati:**
+ [One Observability Workshop](https://catalog.workshops.aws/observability/en-US)
# OPS04-BP02 Implementazione della telemetria dell'applicazione
La telemetria dell'applicazione è la base su cui si fonda l'osservabilità del carico di lavoro. È fondamentale emettere dati di telemetria che offrano approfondimenti utili sullo stato dell'applicazione e sul raggiungimento degli obiettivi sia tecnici sia aziendali. Dalla risoluzione dei problemi alla misurazione dell'impatto di una nuova funzionalità fino all'allineamento con gli indicatori di prestazione chiave (KPI), la telemetria dell'applicazione garantisce informazioni su cui basare la creazione, il funzionamento e l'evoluzione del carico di lavoro.
Metriche, log e tracce costituiscono i tre pilastri principali dell'osservabilità. Questi operano come strumenti diagnostici che descrivono lo stato dell'applicazione. Nel tempo, aiutano a creare criteri di base e a identificare le anomalie. Tuttavia, per garantire l'allineamento tra le attività di monitoraggio e gli obiettivi aziendali, è fondamentale definire e monitorare i KPI. I KPI aziendali spesso facilitano l'identificazione dei problemi rispetto alle sole metriche tecniche.
Altri tipi di telemetria, come il monitoraggio degli utenti reali (RUM) e le transazioni sintetiche, completano queste origini dati primarie. Il RUM offre informazioni sulle interazioni degli utenti in tempo reale, mentre le transazioni sintetiche simulano i potenziali comportamenti degli utenti, aiutando a rilevare i colli di bottiglia prima che vengano riscontrati dagli utenti reali.
**Risultato desiderato:** Ottieni approfondimenti utili sulle prestazioni del tuo carico di lavoro. Questi approfondimenti consentono di prendere decisioni proattive sull'ottimizzazione delle prestazioni, ottenere una maggiore stabilità del carico di lavoro, semplificare i processi CI/CD e utilizzare le risorse in modo efficace.
**Anti-pattern comuni:**
+ Osservabilità incompleta: trascurare di incorporare l'osservabilità a ogni livello del carico di lavoro, con conseguenti punti ciechi che possono nascondere le prestazioni vitali del sistema e gli approfondimenti sul comportamento.
+ Visualizzazione frammentata dei dati: quando i dati sono sparsi su più strumenti e sistemi, diventa difficile mantenere una visione olistica dello stato e delle prestazioni del carico di lavoro.
+ Problemi segnalati dagli utenti: un segno della mancanza di un rilevamento proattivo dei problemi tramite telemetria e monitoraggio dei KPI aziendali.
**Vantaggi dell'adozione di questa best practice:**
+ Processo decisionale informato: con gli approfondimenti ricavati dalla telemetria e dai KPI aziendali, puoi prendere decisioni basate sui dati.
+ Migliore efficienza operativa: l'utilizzo delle risorse basato sui dati porta a un miglioramento dell'efficienza risparmiando sui costi.
+ Maggiore stabilità del carico di lavoro: rilevamento e risoluzione più rapidi dei problemi con conseguente aumento dei tempi di attività.
+ Processi CI/CD semplificati: gli approfondimenti ricavati dai dati di telemetria facilitano il perfezionamento dei processi e la distribuzione affidabile del codice.
**Livello di rischio associato se questa best practice non fosse adottata:** alto
## Guida all'implementazione
Per implementare la telemetria delle applicazioni per il tuo carico di lavoro, utilizza servizi AWS come [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) e [AWS X-Ray](https://aws.amazon.com/xray/). Amazon CloudWatch fornisce una suite completa di strumenti di monitoraggio, che consente di osservare le risorse e le applicazioni in ambienti AWS e on-premise. Raccoglie, tiene traccia e analizza le metriche, consolida e monitora i dati di log e risponde alle modifiche che interessano le risorse, migliorando la comprensione del funzionamento del carico di lavoro. Integrato con altri servizi, AWS X-Ray consente di tenere traccia, analizzare ed eseguire il debug delle applicazioni, offrendoti una comprensione approfondita del comportamento del tuo carico di lavoro. Grazie a funzionalità come mappe dei servizi, distribuzioni di latenza e tempistiche di tracciamento, X-Ray fornisce informazioni dettagliate sulle prestazioni del carico di lavoro e sui colli di bottiglia che lo interessano.
### Passaggi dell'implementazione
1. **Identifica quali dati raccogliere:** definisci le metriche, i log e le tracce essenziali che potrebbero offrire importanti informazioni dettagliate sullo stato, le prestazioni e il comportamento del tuo carico di lavoro.
1. **Implementa l'agente [CloudWatch](https://aws.amazon.com/cloudwatch/) :** l'agente CloudWatch è fondamentale nel fornire metriche di sistema e dell'applicazione e log dal carico di lavoro e dall'infrastruttura sottostante. L'agente CloudWatch può essere utilizzato anche per raccogliere tracce OpenTelemetry o X-Ray e inviarle a X-Ray.
1. **Definisci e monitora i KPI aziendali:** abilita [metriche personalizzate](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html) in linea con i tuoi [risultati aziendali](https://aws-observability.github.io/observability-best-practices/guides/operational/business/monitoring-for-business-outcomes/).
1. **Fornisci AWS X-Ray alla tua applicazione:** Oltre a implementare l'agente CloudWatch, è fondamentale [dotare la tua applicazione di strumenti](https://docs.aws.amazon.com/xray/latest/devguide/xray-instrumenting-your-app.html) per emettere dati di tracciamento. Questo processo può fornire ulteriori approfondimenti sul comportamento e sulle prestazioni del carico di lavoro.
1. **Standardizza la raccolta dei dati in tutta l'applicazione:** standardizza le pratiche di raccolta dei dati in tutta l'applicazione. L'uniformità aiuta a correlare e analizzare i dati, fornendo una visione completa del comportamento dell'applicazione.
1. **Analizza e agisci sui dati:** una volta completata la raccolta e la normalizzazione dei dati, utilizza [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/features/) per l'analisi delle metriche e dei log, e [AWS X-Ray](https://aws.amazon.com/xray/features/) per l'analisi delle tracce. Tale analisi può fornire approfondimenti cruciali sullo stato, le prestazioni e il comportamento del carico di lavoro, guidando il processo decisionale.
**Livello di impegno per il piano di implementazione:** alto
## Risorse
**Best practice correlate:**
+ [OPS04-BP01 Identificazione degli indicatori chiave di prestazione](ops_observability_identify_kpis.md)
+ [OPS04-BP03 Implementazione della telemetria dell'esperienza utente](ops_observability_customer_telemetry.md)
+ [OPS04-BP04 Implementazione della telemetria delle dipendenze](ops_observability_dependency_telemetry.md)
+ [OPS04-BP05 Implementazione del tracciamento distribuito](ops_observability_dist_trace.md)
**Documenti correlati:**
+ [AWS Observability Best Practices ](https://aws-observability.github.io/observability-best-practices/)
+ [ CloudWatch User Guide ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html)
+ [ Guida per gli sviluppatori AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [ Strumentazione di sistemi distribuiti per visibilità operativa ](https://aws.amazon.com/builders-library/instrumenting-distributed-systems-for-operational-visibility)
+ [AWS Observability Skill Builder Course ](https://explore.skillbuilder.aws/learn/course/external/view/elearning/14688/aws-observability)
+ [ Novità di Amazon CloudWatch ](https://aws.amazon.com/about-aws/whats-new/management-and-governance/?whats-new-content.sort-by=item.additionalFields.postDateTime&whats-new-content.sort-order=desc&awsf.whats-new-products=general-products%23amazon-cloudwatch)
+ [ Novità di AWS X-Ray](https://aws.amazon.com/about-aws/whats-new/developer-tools/?whats-new-content.sort-by=item.additionalFields.postDateTime&whats-new-content.sort-order=desc&awsf.whats-new-products=general-products%23aws-x-ray)
**Video correlati:**
+ [AWS re:Invent 2022 - Observability best practices at Amazon ](https://youtu.be/zZPzXEBW4P8)
+ [AWS re:Invent 2022 - Developing an observability strategy ](https://youtu.be/Ub3ATriFapQ)
**Esempi correlati:**
+ [One Observability Workshop](https://catalog.workshops.aws/observability/en-US)
+ [ Biblioteca di soluzioni AWS: Monitoraggio delle applicazioni con Amazon CloudWatch ](https://aws.amazon.com/solutions/implementations/application-monitoring-with-cloudwatch)
# OPS04-BP03 Implementazione della telemetria dell'esperienza utente
Acquisire informazioni approfondite sulle esperienze dei clienti e sulle interazioni con la tua applicazione è fondamentale. Il monitoraggio dell'utente reale (RUM) e le transazioni sintetiche sono strumenti molto efficaci per questo scopo. RUM fornisce dati sulle interazioni degli utenti reali, garantendo una prospettiva non filtrata della soddisfazione degli utenti, mentre le transazioni sintetiche simulano le interazioni degli utenti, aiutando a rilevare potenziali problemi prima che essi abbiano un impatto sugli utenti reali.
**Risultato desiderato:** Una visione olistica dell'esperienza del cliente, il rilevamento proattivo dei problemi e l'ottimizzazione delle interazioni degli utenti per offrire esperienze digitali fluide.
**Anti-pattern comuni:**
+ Applicazioni senza monitoraggio dell'utente reale (RUM):
+ rilevamento ritardato dei problemi: senza RUM, potresti non accorgerti di rallentamenti o problemi di prestazioni fino a quando non ricevi lamentele da parte degli utenti. Questo approccio reattivo può causare insoddisfazione nei clienti.
+ Mancanza di informazioni sull'esperienza utente: non utilizzare RUM significa perdere dati cruciali che mostrano come gli utenti reali interagiscono con l'applicazione, il che limita la tua capacità di ottimizzare l'esperienza utente.
+ Applicazioni senza transazioni sintetiche:
+ Casi limite trascurati: le transazioni sintetiche consentono di testare percorsi e funzioni che potrebbero non essere utilizzati frequentemente dagli utenti tipici, ma che sono fondamentali per determinate funzioni aziendali. Senza di esse, questi percorsi potrebbero non funzionare correttamente e passare inosservati.
+ Verifica della presenza di problemi quando l'applicazione non viene utilizzata: i test sintetici regolari possono simulare situazioni in cui gli utenti reali non interagiscono attivamente con l'applicazione, garantendo che il sistema funzioni sempre correttamente.
**Vantaggi dell'adozione di questa best practice:**
+ Rilevamento proattivo dei problemi: identifica e risolvi i problemi potenziali prima che abbiano un impatto sugli utenti reali.
+ Esperienza utente ottimizzata: grazie al suo feedback continuo, RUM aiuta a perfezionare e migliorare l'esperienza utente complessiva.
+ Informazioni approfondite sulle prestazioni del dispositivo e del browser: scopri come si comporta la tua applicazione in vari dispositivi e browser e implementa ulteriori ottimizzazioni.
+ Flussi di lavoro aziendali convalidati: transazioni sintetiche regolari assicurano che le funzionalità principali e i percorsi critici siano operativi ed efficienti in maniera costante.
+ Prestazioni delle applicazioni migliorate: sfrutta le informazioni approfondite raccolte dai dati degli utenti reali per migliorare la reattività e l'affidabilità delle applicazioni.
**Livello di rischio associato se questa best practice non fosse adottata:** alto
## Guida all'implementazione
Per eseguire la telemetria delle attività degli utenti sfruttando RUM e le transazioni sintetiche, AWS offre servizi come [Amazon CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) e [Amazon CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html). Metriche, log e tracce, insieme ai dati sulle attività degli utenti, forniscono una visione completa dello stato operativo dell'applicazione e dell'esperienza utente.
### Passaggi dell'implementazione
1. **Implementa Amazon CloudWatch RUM:** integra la tua applicazione con CloudWatch RUM per raccogliere, analizzare e presentare dati relativi agli utenti reali.
1. Utilizza [la libreria JavaScript CloudWatch RUM](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) per integrare RUM con la tua applicazione.
1. Configura dashboard per visualizzare e monitorare i dati relativi agli utenti reali.
1. **Configura CloudWatch Synthetics:** crea canary o routine con script che simulano le interazioni degli utenti con la tua applicazione.
1. Definisci i flussi di lavoro e i percorsi critici delle applicazioni.
1. Progetta canary utilizzando [script di CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) per simulare le interazioni degli utenti per questi percorsi.
1. Pianifica e monitora i canary affinché si attivino a intervalli specifici, in modo da garantire controlli costanti delle prestazioni.
1. **Analizza e intervieni sui dati:** Utilizza i dati provenienti da RUM e transazioni sintetiche per ottenere informazioni e adottare misure correttive quando vengono rilevate anomalie. Usa dashboard CloudWatch e allarmi per ottenere informazioni costanti.
**Livello di impegno per il piano di implementazione:** Medio
## Risorse
**Best practice correlate:**
+ [OPS04-BP01 Identificazione degli indicatori chiave di prestazione](ops_observability_identify_kpis.md)
+ [OPS04-BP02 Implementazione della telemetria dell'applicazione](ops_observability_application_telemetry.md)
+ [OPS04-BP04 Implementazione della telemetria delle dipendenze](ops_observability_dependency_telemetry.md)
+ [OPS04-BP05 Implementazione del tracciamento distribuito](ops_observability_dist_trace.md)
**Documenti correlati:**
+ [ Amazon CloudWatch RUM Guide ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html)
+ [ Amazon CloudWatch Synthetics Guide ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
**Video correlati:**
+ [ Optimize applications through end user insights with Amazon CloudWatch RUM ](https://www.youtube.com/watch?v=NMaeujY9A9Y)
+ [AWS on Air ft. Real-User Monitoring for Amazon CloudWatch ](https://www.youtube.com/watch?v=r6wFtozsiVE)
**Esempi correlati:**
+ [ One Observability Workshop ](https://catalog.workshops.aws/observability/en-US/intro)
+ [ Repository Git per client Web Amazon CloudWatch RUM ](https://github.com/aws-observability/aws-rum-web)
+ [ Using Amazon CloudWatch Synthetics to measure page load time ](https://github.com/aws-samples/amazon-cloudwatch-synthetics-page-performance)
# OPS04-BP04 Implementazione della telemetria delle dipendenze
La telemetria delle dipendenze è essenziale per monitorare lo stato e le prestazioni dei servizi e dei componenti esterni su cui si basa il carico di lavoro. Fornisce preziose informazioni dettagliate su reperibilità, timeout e altri eventi critici correlati alle dipendenze come DNS, database o API di terze parti. Dotando l'applicazione di strumenti per generare metriche, log e tracce relative a queste dipendenze, acquisisci una comprensione più chiara dei potenziali colli di bottiglia, problemi di prestazioni o errori che potrebbero influire sul carico di lavoro.
**Risultato desiderato:** Le dipendenze su cui si basa il carico di lavoro funzionano come previsto, consentendo di gestire i problemi in modo proattivo e garantendo prestazioni ottimali del carico di lavoro.
**Anti-pattern comuni:**
+ Scarsa attenzione alle dipendenze esterne: il focus è rivolto esclusivamente alle metriche interne dell'applicazione, trascurando quelle legate alle dipendenze esterne.
+ Mancanza di monitoraggio proattivo: si attende che si verifichino problemi anziché monitorare costantemente lo stato e le prestazioni delle dipendenze.
+ Monitoraggio isolato in comparti: utilizzo di strumenti di monitoraggio multipli ed eterogenei che possono portare a visioni dello stato delle dipendenze frammentate e incoerenti.
**Vantaggi dell'adozione di questa best practice:**
+ Maggiore affidabilità del carico di lavoro: viene garantito che le dipendenze esterne siano costantemente disponibili e funzionino in modo ottimale.
+ Rilevamento e risoluzione dei problemi più rapidi: identificazione e risoluzione proattiva dei problemi relativi alle dipendenze prima che influiscano sul carico di lavoro.
+ Visione completa: acquisizione di una visione olistica dei componenti interni ed esterni che influenzano lo stato del carico di lavoro.
+ Scalabilità del carico di lavoro migliorata grazie alla comprensione dei limiti di scalabilità e delle caratteristiche prestazionali delle dipendenze esterne.
**Livello di rischio associato se questa best practice non fosse adottata:** alto
## Guida all'implementazione
Implementa la telemetria delle dipendenze iniziando con l'identificazione dei servizi, dell'infrastruttura e dei processi da cui dipende il carico di lavoro. Esegui una valutazione quantitativa delle condizioni ottimali nelle quali tali dipendenze funzionano come previsto e poi determina quali dati sono necessari per misurarle. Con queste informazioni, puoi creare dashboard e avvisi che forniscono informazioni dettagliate ai tuoi team operativi sullo stato di tali dipendenze. Usa gli strumenti AWS per scoprire e quantificare gli impatti quando le dipendenze non riescono a fornire le prestazioni necessarie. Rivedi costantemente la tua strategia per tenere conto dei cambiamenti relativi a priorità, obiettivi e alle informazioni dettagliate acquisite.
### Passaggi dell'implementazione
Per implementare efficacemente la telemetria delle dipendenze:
1. **Identifica le dipendenze esterne:** collabora con gli stakeholder per individuare le dipendenze esterne sulle quali si basa il tuo carico di lavoro. Le dipendenze esterne possono comprendere servizi come database esterni, API di terze parti, percorsi di connettività di rete verso altri ambienti e servizi DNS. Il primo passo verso un'efficace telemetria delle dipendenze è acquisire una comprensione totale di quali esse siano.
1. **Sviluppa una strategia di monitoraggio:** una volta acquisito un quadro chiaro delle dipendenze esterne, progetta una strategia di monitoraggio ad hoc per esse. Trovare la strategia giusta implica comprendere le criticità di tutte le dipendenze, il loro comportamento previsto e gli eventuali accordi od obiettivi sul livello di servizio associato (SLA o SLT). Imposta avvisi proattivi che ti informino riguardo a cambiamenti di stato o deviazioni delle prestazioni.
1. **Sfrutta [Monitor Internet Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-InternetMonitor.html):** fornisce approfondimenti sull'Internet globale, aiutandoti a comprendere interruzioni o perturbazioni che potrebbero influire sulle dipendenze esterne.
1. **Non perdere alcun aggiornamento con [Dashboard AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health-dashboard/):** fornisce avvisi e indicazioni per la correzione qualora AWS sia interessato da eventi che potrebbero influire sui servizi.
1. **Potenzia la tua applicazione con [AWS X-Ray](https://aws.amazon.com/xray/):** AWS X-Ray fornisce informazioni dettagliate sulle prestazioni delle applicazioni e delle relative dipendenze sottostanti. La tracciatura delle richieste dall'inizio alla fine ti permette di identificare colli di bottiglia o guasti nei servizi o nei componenti esterni su cui si basa l'applicazione.
1. **Utilizza [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/):** questo servizio basato sul machine learning identifica i problemi operativi, prevede quando potrebbero verificarsi problemi critici e consiglia azioni specifiche da intraprendere. Fornisce un supporto prezioso per acquisire informazioni dettagliate sulle dipendenze e determinare che queste non siano la fonte di problemi operativi.
1. **Monitora regolarmente:** monitora le metriche e i log relativi alle dipendenze esterne in maniera costante. Imposta avvisi per comportamenti imprevisti o prestazioni ridotte.
1. **Convalida dopo le modifiche:** ogni volta che una dipendenza esterna è interessata da un aggiornamento o una modifica, convalidane le prestazioni e verifica che queste siano in linea con i requisiti dell'applicazione.
**Livello di impegno per il piano di implementazione:** Medio
## Risorse
**Best practice correlate:**
+ [OPS04-BP01 Identificazione degli indicatori chiave di prestazione](ops_observability_identify_kpis.md)
+ [OPS04-BP02 Implementazione della telemetria dell'applicazione](ops_observability_application_telemetry.md)
+ [OPS04-BP03 Implementazione della telemetria dell'esperienza utente](ops_observability_customer_telemetry.md)
+ [OPS04-BP05 Implementazione del tracciamento distribuito](ops_observability_dist_trace.md)
**Documenti correlati:**
+ [ What is AWS Health? ](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html)
+ [ Using Amazon CloudWatch Internet Monitor ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-InternetMonitor.html)
+ [Guida per gli sviluppatori AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [ Amazon DevOps Guru User Guide ](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
**Video correlati:**
+ [ Visibility into how internet issues impact app performance ](https://www.youtube.com/watch?v=Kuc_SG_aBgQ)
+ [ Introduction to Amazon DevOps Guru ](https://www.youtube.com/watch?v=2uA8q-8mTZY)
**Esempi correlati:**
+ [ Gaining operational insights with AIOps using Amazon DevOps Guru ](https://catalog.us-east-1.prod.workshops.aws/workshops/f92df379-6add-4101-8b4b-38b788e1222b/en-US)
+ [AWS Health Aware ](https://github.com/aws-samples/aws-health-aware/)
# OPS04-BP05 Implementazione del tracciamento distribuito
Il tracciamento distribuito offre un modo per monitorare e visualizzare le richieste mentre attraversano vari componenti di un sistema distribuito. Acquisendo i dati di tracciamento da più fonti e analizzandoli in una vista unificata, i team possono comprendere meglio il flusso delle richieste, in quali punti sono presenti colli di bottiglia e dove devono concentrare gli sforzi di ottimizzazione.
**Risultato desiderato:** Una visione olistica del flusso delle richieste nel tuo sistema distribuito, che ti permette di ottenere un debug preciso, prestazioni ottimizzate e migliori esperienze utente.
**Anti-pattern comuni:**
+ Strumentazione incoerente: non tutti i servizi in un sistema distribuito sono dotati di strumentazione per il monitoraggio.
+ Ignorare la latenza: concentrarsi solo sugli errori e non considerare la latenza o il graduale deterioramento delle prestazioni.
**Vantaggi dell'adozione di questa best practice:**
+ Panoramica completa del sistema: visualizzazione dell'intero percorso delle richieste, dall'ingresso all'uscita.
+ Debug avanzato: identificazione rapida dei punti in cui si verificano guasti o problemi di prestazioni.
+ Esperienza utente migliorata: monitoraggio e ottimizzazione in base ai dati effettivi dell'utente, garantendo che il sistema soddisfi le esigenze del mondo reale.
**Livello di rischio associato se questa best practice non fosse adottata:** alto
## Guida all'implementazione
Inizia identificando tutti gli elementi del carico di lavoro che richiedono strumentazione. Una volta presi in considerazione tutti i componenti, sfrutta strumenti come AWS X-Ray e OpenTelemetry per raccogliere dati di tracciamento da analizzare con strumenti come X-Ray e Amazon CloudWatchServiceLens Map. Effettua revisioni periodiche insieme agli sviluppatori e integra queste discussioni con strumenti come Amazon DevOps Guru, X-Ray Analytics e X-Ray Insights per ottenere risultati più approfonditi. Imposta avvisi basati sui dati di tracciamento per notificare quando i risultati sono a rischio, come definito nel piano di monitoraggio del carico di lavoro.
### Passaggi dell'implementazione
Per implementare il tracciamento distribuito in modo efficace:
1. **Adotta [AWS X-Ray](https://aws.amazon.com/xray/):** implementa X-Ray nella tua applicazione per ottenere informazioni dettagliate sul suo comportamento, comprenderne le prestazioni e individuare i punti critici. Utilizza X-Ray Insights per l'analisi automatica dei tracciamenti.
1. **Dota i tuoi servizi di strumenti:** verifica che tutti i servizi, dalle funzioni [AWS Lambda](https://aws.amazon.com/lambda/) alle [istanze EC2](https://aws.amazon.com/ec2/), siano in grado di inviare dati di tracciamento. Più servizi doti di strumentazione, più chiara sarà la visione end-to-end.
1. **Incorpora [il monitoraggio dell'utente reale tramite CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM.html) e [il monitoraggio sintetico](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html):** integra il monitoraggio dell'utente reale (RUM) e il monitoraggio sintetico con X-Ray. Ciò ti consente di acquisire esperienze utenti del mondo reale e simulare le interazioni degli utenti per identificare potenziali problemi.
1. **Utilizza [l'agente CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html):** l'agente può inviare dati di tracciamento da X-Ray o da OpenTelemetry, permettendoti di raccogliere informazioni più approfondite.
1. **Utilizza [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/):** DevOps Guru utilizza dati provenienti da X-Ray, CloudWatch, AWS Config e AWS CloudTrail per fornire suggerimenti fruibili.
1. **Analizza le tracce:** esamina regolarmente i dati di tracciamento per individuare schemi, anomalie o colli di bottiglia che possono influire sulle prestazioni dell'applicazione.
1. **Imposta avvisi:** configura avvisi in [CloudWatch](https://aws.amazon.com/cloudwatch/) per segnalare schemi insoliti o latenze prolungate, il che ti permette di effettuare una risoluzione proattiva dei problemi.
1. **Miglioramento continuo:** riesamina la tua strategia di tracciamento man mano che aggiungi o modifichi servizi per acquisire tutti i punti dati pertinenti.
**Livello di impegno per il piano di implementazione:** Medio
## Risorse
**Best practice correlate:**
+ [OPS04-BP01 Identificazione degli indicatori chiave di prestazione](ops_observability_identify_kpis.md)
+ [OPS04-BP02 Implementazione della telemetria dell'applicazione](ops_observability_application_telemetry.md)
+ [OPS04-BP03 Implementazione della telemetria dell'esperienza utente](ops_observability_customer_telemetry.md)
+ [OPS04-BP04 Implementazione della telemetria delle dipendenze](ops_observability_dependency_telemetry.md)
**Documenti correlati:**
+ [ Guida per gli sviluppatori AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html)
+ [ Amazon CloudWatch agent User Guide ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)
+ [ Amazon DevOps Guru User Guide ](https://docs.aws.amazon.com/devops-guru/latest/userguide/welcome.html)
**Video correlati:**
+ [ Use AWS X-Ray Insights ](https://www.youtube.com/watch?v=tl8OWHl6jxw)
+ [AWS on Air ft. Observability: Amazon CloudWatch and AWS X-Ray](https://www.youtube.com/watch?v=qBDBnPkZ-KI)
**Esempi correlati:**
+ [ Instrumenting your Application with AWS X-Ray](https://aws.amazon.com/getting-started/hands-on/distributed-tracing-with-xray/)
# OPS 5. In che modo riduci i difetti, favorisci la correzione e migliori il flusso nella produzione?
Adotta prassi che migliorino il flusso delle modifiche nella produzione, che attivino la rifattorizzazione e il feedback veloce su qualità e correzione di errori. Tali prassi accelerano l'ingresso in produzione delle modifiche vantaggiose, contengono i problemi che si sono diffusi e permettono di ottenere una rapida identificazione e risoluzione dei problemi introdotti attraverso le attività di implementazione.
**Topics**
+ [OPS05-BP01 Utilizzo del controllo delle versioni](ops_dev_integ_version_control.md)
+ [OPS05-BP02 Test e convalida delle modifiche](ops_dev_integ_test_val_chg.md)
+ [OPS05-BP03 Utilizzo di sistemi di gestione delle configurazioni](ops_dev_integ_conf_mgmt_sys.md)
+ [OPS05-BP04 Utilizzo di sistemi di gestione della compilazione e implementazione](ops_dev_integ_build_mgmt_sys.md)
+ [OPS05-BP05 Esecuzione della gestione delle patch](ops_dev_integ_patch_mgmt.md)
+ [OPS05-BP06 Condivisione degli standard di progettazione](ops_dev_integ_share_design_stds.md)
+ [OPS05-BP07 Implementazione di prassi per migliorare la qualità del codice](ops_dev_integ_code_quality.md)
+ [OPS05-BP08 Utilizzo di più ambienti](ops_dev_integ_multi_env.md)
+ [OPS05-BP09 Applicazione di modifiche frequenti, minime e reversibili](ops_dev_integ_freq_sm_rev_chg.md)
+ [OPS05-BP10 Automazione completa dell'integrazione e della distribuzione](ops_dev_integ_auto_integ_deploy.md)
# OPS05-BP01 Utilizzo del controllo delle versioni
Utilizza il controllo delle versioni per attivare il monitoraggio di modifiche e rilasci.
Molti servizi AWS offrono funzionalità di controllo delle versioni. Utilizza una revisione o un sistema di controllo del codice sorgente come [AWS CodeCommit](https://aws.amazon.com/codecommit/) per gestire il codice e altri artefatti, come i modelli [AWS CloudFormation](https://aws.amazon.com/cloudformation/) controllati dalla versione della tua infrastruttura.
**Risultato desiderato:** I tuoi team collaborano alla gestione del codice. Una volta unito, il codice è coerente e nessuna modifica viene persa. Gli errori possono essere facilmente ripristinati mediante il corretto controllo delle versioni.
**Anti-pattern comuni:**
+ Hai sviluppato e archiviato il codice sulla workstation. Si è verificato un errore di archiviazione non recuperabile sulla workstation e il codice è andato perso.
+ Dopo aver sovrascritto il codice esistente con le modifiche, riavvii l'applicazione e non è più utilizzabile. Non è possibile ripristinare la modifica.
+ Hai un blocco di scrittura su un file di report che deve essere modificato da altri utenti. Ti contattano per chiederti di smettere di utilizzarlo in modo che possano completare le loro attività.
+ Il team di ricerca ha lavorato a un'analisi dettagliata che definisce il tuo lavoro futuro. Qualcuno ha salvato accidentalmente la lista della spesa nel report finale. Non puoi ripristinare la modifica e devi ricreare il report.
**Vantaggi dell'adozione di questa best practice:** Grazie alle funzionalità di controllo delle versioni, puoi ripristinare facilmente gli stati validi noti e le versioni precedenti e limitare il rischio di perdita degli asset.
**Livello di rischio associato se questa best practice non fosse adottata:** alto
## Guida all'implementazione
Mantieni gli asset in repository con controllo delle versioni. In questo modo si supporta il monitoraggio delle modifiche, la distribuzione di nuove versioni, il rilevamento delle modifiche apportate alle versioni esistenti e il ripristino delle versioni precedenti, ad esempio il rollback a uno stato corretto noto in caso di errore. Integra nelle tue procedure le funzionalità di controllo delle versioni dei sistemi di gestione delle configurazioni.
## Risorse
**Best practice correlate:**
+ [OPS05-BP04 Utilizzo di sistemi di gestione della compilazione e implementazione](ops_dev_integ_build_mgmt_sys.md)
**Documenti correlati:**
+ [Che cos'è AWS CodeCommit?](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)
**Video correlati:**
+ [Introduzione ad AWS CodeCommit](https://youtu.be/46PRLMW8otg)
# OPS05-BP02 Test e convalida delle modifiche
Ogni modifica apportata deve essere testata per evitare errori in produzione. Questa best practice si concentra sulla verifica delle modifiche dal controllo di versione alla creazione dell'artefatto. Oltre alle modifiche al codice dell'applicazione, i test dovrebbero includere l'infrastruttura, la configurazione, i controlli di sicurezza e le procedure operative. I test assumono molte forme, dai test unitari all'analisi dei componenti software (SCA). Spostando i test più a sinistra nel processo di integrazione e consegna del software ottieni una maggiore certezza della qualità degli artefatti.
L'organizzazione deve sviluppare standard di test per tutti gli artefatti software. I test automatizzati riducono la fatica ed evitano gli errori dei test manuali. I test manuali potrebbero essere necessari in alcuni casi. Gli sviluppatori devono avere accesso ai risultati dei test automatizzati per creare cicli di feedback che migliorino la qualità del software.
**Risultato desiderato:** Le modifiche software vengono testate prima del rilascio. Gli sviluppatori hanno accesso ai risultati dei test e alle convalide. La tua organizzazione ha uno standard per i test che applica a tutte le modifiche software.
**Anti-pattern comuni:**
+ Implementi una nuova modifica software senza test. Non funziona in produzione e genera un'interruzione.
+ I nuovi gruppi di sicurezza vengono distribuiti con CloudFormation senza essere testati in un ambiente di pre-produzione. I gruppi di sicurezza rendono la tua app irraggiungibile per i clienti.
+ Un metodo viene modificato, ma non ci sono test di unità. Il software ha esito negativo quando viene distribuito in produzione.
**Vantaggi dell'adozione di questa best practice:** Ridotto tasso di fallimento delle implementazioni software. La qualità del software viene migliorata. Gli sviluppatori hanno una maggiore consapevolezza della fattibilità del loro codice. Le policy di sicurezza possono essere implementate in maniera affidabile per supportare la conformità dell'organizzazione. Le modifiche all'infrastruttura, come gli aggiornamenti automatici delle politiche di scaling, vengono testate in anticipo per soddisfare le esigenze del traffico.
**Livello di rischio associato se questa best practice non fosse adottata:** alto
## Guida all'implementazione
I test vengono eseguiti su tutte le modifiche, dal codice dell'applicazione all'infrastruttura, come parte della pratica di integrazione continua. I risultati dei test vengono pubblicati in modo che gli sviluppatori abbiano un feedback rapido. La tua organizzazione ha uno standard per i test che applica a tutte le modifiche software.
**Esempio del cliente**
Nell'ambito della pipeline di integrazione continua, AnyCompany Retail esegue diversi tipi di test su tutti gli artefatti software. Praticano lo sviluppo guidato dai test, per cui tutto il software è dotato di test unitari. Una volta creato l'artefatto, eseguono test end-to-end. Al termine di questa prima serie di test, viene eseguita una scansione statica della sicurezza dell'applicazione, alla ricerca di vulnerabilità note. Gli sviluppatori ricevono messaggi al superamento di ciascun gate di test. Una volta completati tutti i test, l'artefatto software viene archiviato in un repository di artefatti.
### Passaggi dell'implementazione
1. Collaborare con le parti interessate dell'organizzazione per sviluppare uno standard di test per gli artefatti software. Quali test standard devono superare tutti gli artefatti? Ci sono requisiti di conformità o di governance che devono essere inclusi nella copertura dei test? Devi condurre test di qualità del codice? Quando i test sono terminati, chi deve esserne a conoscenza?
1. Il comando [L'architettura di riferimento per pipeline di implementazione AWS](https://pipelines.devops.aws.dev/) contiene un elenco autorevole dei tipi di test che possono essere condotti su artefatti software come parte di una pipeline di integrazione.
1. Fornisci la tua applicazione dei test necessari in base allo standard di test del software. Ogni set di test deve essere completato in meno di dieci minuti. I test devono essere eseguiti come parte della pipeline di integrazione.
1. [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) può testare il codice dell'applicazione per trovare eventuali difetti.
1. Puoi utilizzare [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html) per condurre i test su artefatti software.
1. [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) può organizzare i test software in una pipeline.
## Risorse
**Best practice correlate:**
+ [OPS05-BP01 Utilizzo del controllo delle versioni](ops_dev_integ_version_control.md)
+ [OPS05-BP06 Condivisione degli standard di progettazione](ops_dev_integ_share_design_stds.md)
+ [OPS05-BP10 Automazione completa dell'integrazione e della distribuzione](ops_dev_integ_auto_integ_deploy.md)
**Documenti correlati:**
+ [ Adotta un approccio allo sviluppo basato sul test ](https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-cdk-typescript-iac/development-best-practices.html)
+ [ Automated CloudFormation Testing Pipeline with TaskCat and CodePipeline ](https://aws.amazon.com/blogs/devops/automated-cloudformation-testing-pipeline-with-taskcat-and-codepipeline/)
+ [ Building end-to-end AWS DevSecOps CI/CD pipeline with open source SCA, SAST, and DAST tools ](https://aws.amazon.com/blogs/devops/building-end-to-end-aws-devsecops-ci-cd-pipeline-with-open-source-sca-sast-and-dast-tools/)
+ [ Iniziare a usare applicazioni serverless di test ](https://aws.amazon.com/blogs/compute/getting-started-with-testing-serverless-applications/)
+ [ La mia pipeline CI/CD è la mia release captain ](https://aws.amazon.com/builders-library/cicd-pipeline/)
+ [ Practicing Continuous Integration and Continuous Delivery on AWS Whitepaper ](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/welcome.html)
**Video correlati:**
+ [AWS re:Invent 2020: Testable infrastructure: Integration testing on AWS](https://www.youtube.com/watch?v=KJC380Juo2w)
+ [AWS Summit ANZ 2021 - Driving a test-first strategy with CDK and test driven development ](https://www.youtube.com/watch?v=1R7G_wcyd3s)
+ [ Testare l'infrastruttura come codice con AWS CDK ](https://www.youtube.com/watch?v=fWtuwGSoSOU)
**Risorse correlate:**
+ [AWS Deployment Pipeline Reference Architecture - Application ](https://pipelines.devops.aws.dev/application-pipeline/index.html)
+ [AWS Kubernetes DevSecOps Pipeline ](https://github.com/aws-samples/devsecops-cicd-containers)
+ [ Policy come codice - Workshop – Sviluppo incentrato sui test ](https://catalog.us-east-1.prod.workshops.aws/workshops/9da471a0-266a-4d36-8596-e5934aeedd1f/en-US/pac-tools/cfn-guard/tdd)
+ [ Run unit tests for a Node.js application from GitHub by using AWS CodeBuild](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/run-unit-tests-for-a-node-js-application-from-github-by-using-aws-codebuild.html)
+ [ Usa Serverspec per lo sviluppo incentrato sul test del codice dell'infrastruttura ](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/use-serverspec-for-test-driven-development-of-infrastructure-code.html)
**Servizi correlati:**
+ [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html)
+ [AWS CodeBuild](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
# OPS05-BP03 Utilizzo di sistemi di gestione delle configurazioni
L'utilizzo di sistemi di gestione delle configurazioni permette di effettuare modifiche alle stesse e tenerne traccia. Questi sistemi riducono gli errori causati dai processi manuali e il livello di impegno richiesto per la distribuzione delle modifiche.
Durante l'inizializzazione di una risorsa, la gestione delle configurazioni statiche consente di impostare valori che dovrebbero rimanere coerenti per tutta la vita utile della risorsa. Ne sono alcuni esempi l'azione di configurare un server web o applicativo su un'istanza oppure di definire la configurazione di un servizio AWS nella [Console di gestione AWS](https://docs.aws.amazon.com/awsconsolehelpdocs/index.html) o tramite la [AWS CLI](https://aws.amazon.com/cli/).
Al momento dell'inizializzazione, la gestione delle configurazioni dinamiche consente di impostare valori che possono cambiare nel corso della vita utile di una risorsa. Ad esempio è possibile impostare un interruttore funzionale in grado di attivare una funzionalità nel codice tramite una modifica della configurazione, oppure modificare il livello di dettaglio del log durante un incidente per acquisire un maggior numero di dati e cambiarlo in seguito per tornare al livello di dettaglio precedente, risparmiando così in numero di log e nei relativi costi.
In AWS, è possibile utilizzare [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) per monitorare in modo continuo le configurazioni delle risorse AWS [tra i diversi account e regioni](https://docs.aws.amazon.com/config/latest/developerguide/aggregate-data.html). Questa soluzione aiuta a tenere traccia della cronologia delle configurazioni, a capire che effetto avrebbe la modifica di una configurazione sulle altre risorse e a verificarle rispetto alle configurazioni previste o desiderate tramite [Regole di AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) e [pacchetti di conformità AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html).
Se sulle applicazioni in esecuzione su istanze Amazon EC2, AWS Lambda, container, funzioni serverless, applicazioni mobili o dispositivi IoT sono attive configurazioni dinamiche, è possibile utilizzare [AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html) per configurarle, convalidarle, implementarle e monitorarle nei tuoi ambienti.
In AWS, puoi creare pipeline di integrazione continua/distribuzione continua (CI/CD) utilizzando servizi come gli [Strumenti per sviluppatori in AWS](https://aws.amazon.com/products/developer-tools/) (ad esempio: [AWS CodeCommit](https://aws.amazon.com/codecommit/), [AWS CodeBuild](https://aws.amazon.com/codebuild/), [AWS CodePipeline](https://aws.amazon.com/codepipeline/), [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)e [AWS CodeStar](https://aws.amazon.com/codestar/)).
**Risultato desiderato:** Puoi configurare, convalidare e implementare come parte della tua pipeline di integrazione continua e di distribuzione continua (CI/CD). Esegui il monitoraggio per verificare che le configurazioni siano corrette. Ciò riduce al minimo l'impatto sugli utenti finali e sui clienti.
**Anti-pattern comuni:**
+ Aggiorni manualmente la configurazione del server Web all'interno del parco istanze e un certo numero di server non risponde a causa di errori di aggiornamento.
+ Aggiorni manualmente il parco istanze del server applicazioni nel corso di molte ore. L'incoerenza nella configurazione durante la modifica causa comportamenti imprevisti.
+ Qualcuno ha aggiornato i tuoi gruppi di sicurezza e i server Web non sono più accessibili. Senza sapere cosa è stato modificato, dedichi molto tempo a esaminare il problema prolungando il tempo necessario per il ripristino.
+ Avvii una configurazione di preproduzione in produzione tramite CI/CD senza una convalida. Esponi utenti e clienti a dati e servizi errati.
**Vantaggi dell'adozione di questa best practice:** L'adozione di sistemi di gestione della configurazione riduce il livello di impegno necessario per apportare e tenere traccia delle modifiche e la frequenza degli errori causati dalle procedure manuali. I sistemi di gestione della configurazione forniscono garanzie per quanto riguarda la governance, la conformità e i requisiti normativi.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
I sistemi di gestione della configurazione vengono utilizzati per tenere traccia e implementare le modifiche nelle configurazioni delle applicazioni e degli ambienti. I sistemi di gestione della configurazione vengono utilizzati anche per ridurre gli errori causati dai processi manuali, rendere le modifiche alla configurazione ripetibili e verificabili e per ridurre il livello di impegno.
### Passaggi dell'implementazione
1. Identifica i proprietari della configurazione.
1. Metti a conoscenza i proprietari delle configurazioni di qualsiasi esigenza di conformità, governance o normativa.
1. Identifica gli elementi e i risultati della configurazione.
1. Gli elementi di configurazione sono tutte le configurazioni ambientali e dell'applicazione interessate da un'implementazione all'interno della pipeline CI/CD.
1. I risultati finali includono criteri di successo, convalide e aspetti da monitorare.
1. Seleziona gli strumenti per la gestione della configurazione in base ai requisiti aziendali e alla pipeline di distribuzione.
1. Per modifiche significative alla configurazione, prendi in considerazione le implementazioni ponderate, ad esempio le implementazioni canary, per ridurre al minimo l'impatto di configurazioni errate.
1. Integra la gestione della configurazione nella tua pipeline CI/CD.
1. Convalida tutte le modifiche inserite.
## Risorse
**Best practice correlate:**
+ [OPS06-BP01 Preparazione di un piano in caso di esito negativo delle modifiche](ops_mit_deploy_risks_plan_for_unsucessful_changes.md)
+ [OPS06-BP02 Implementazioni dei test](ops_mit_deploy_risks_test_val_chg.md)
+ [OPS06-BP03 Utilizza strategie di deployment sicure](ops_mit_deploy_risks_deploy_mgmt_sys.md)
+ [OPS06-BP04 Automazione dei test e del rollback](ops_mit_deploy_risks_auto_testing_and_rollback.md)
**Documenti correlati:**
+ [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)
+ [AWS Landing Zone Accelerator ](https://aws.amazon.com/solutions/implementations/landing-zone-accelerator-on-aws/)
+ [AWS Config](https://aws.amazon.com/config/)
+ [ What is AWS Config? ](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)
+ [AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html)
+ [ What is AWS CloudFormation? ](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
+ [Strumenti per sviluppatori in AWS](https://aws.amazon.com/products/developer-tools/)
**Video correlati:**
+ [AWS re:Invent 2022 - Proactive governance and compliance for AWS workloads ](https://youtu.be/PpUnH9Y52X0?si=82wff87KHXcc6nbT)
+ [AWS re:Invent 2020: Achieve compliance as code using AWS Config](https://youtu.be/m8vTwvbzOfw?si=my4DP0FLq1zwKjho)
+ [ Manage and Deploy Application Configurations with AWS AppConfig](https://youtu.be/ztIxMY3IIu0?si=ovYGsxWOBysyQrg0)
# OPS05-BP04 Utilizzo di sistemi di gestione della compilazione e implementazione
Utilizza sistemi di gestione della creazione e distribuzione Questi sistemi riducono gli errori causati dai processi manuali e il livello di impegno richiesto per la distribuzione delle modifiche.
In AWS, puoi compilare pipeline di integrazione continua/implementazione continua (CI/CD) utilizzando servizi come gli [Strumenti per sviluppatori in AWS](https://aws.amazon.com/products/developer-tools/) (ad esempio, AWS CodeCommit, [AWS CodeBuild](https://aws.amazon.com/codebuild/), [AWS CodePipeline](https://aws.amazon.com/codepipeline/), [AWS CodeDeploy](https://aws.amazon.com/codedeploy/)e [AWS CodeStar](https://aws.amazon.com/codestar/)).
**Risultato desiderato:** I sistemi di gestione della costruzione e dell'implementazione supportano il sistema di distribuzione e integrazione continua (CI/CD) dell'organizzazione, che fornisce funzionalità per automatizzare rollout sicuri con le configurazioni corrette.
**Anti-pattern comuni:**
+ Dopo aver compilato il codice nel sistema di sviluppo, copi il file eseguibile nei sistemi di produzione e questo non si avvia. I file di log locali indicano che l'operazione è risultata impossibile a causa della mancanza di dipendenze.
+ Hai creato l'applicazione con nuove funzionalità nel tuo ambiente di sviluppo e fornisci il codice per eseguire il controllo qualità (QA). Il controllo qualità non riesce perché mancano asset statici.
+ Venerdì, dopo un notevole sforzo, hai creato l'applicazione manualmente nel tuo ambiente di sviluppo, incluse le nuove funzionalità codificate. Lunedì non sei in grado di ripetere le fasi che ti hanno consentito di creare correttamente la tua applicazione.
+ Esegui i test creati per la nuova versione. Quindi passi la settimana successiva a configurare un ambiente di test ed eseguire tutti i test di integrazione esistenti seguiti dai test delle prestazioni. Il nuovo codice ha un impatto inaccettabile sulle prestazioni e deve essere risviluppato e quindi ritestato.
**Vantaggi dell'adozione di questa best practice:** Fornendo meccanismi per gestire le attività di compilazione e distribuzione, riduci il livello di impegno necessario per eseguire attività ripetitive, consenti ai membri del team di concentrarsi liberamente sulle loro attività creative di valore elevato e limiti l'introduzione di errori derivanti da procedure manuali.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
I sistemi di gestione della creazione e implementazione vengono utilizzati per tenere traccia e implementare le modifiche, ridurre gli errori causati dai processi manuali e diminuire il livello di impegno richiesto per le implementazioni sicure. Automatizza completamente la pipeline di integrazione e distribuzione dal check-in del codice fino alle fasi di creazione, test, distribuzione e convalida. Ciò riduce il lead time e i costi, incoraggia una maggiore frequenza delle modifiche, riduce il livello di impegno e aumenta la collaborazione.
### Passaggi dell'implementazione
![\[Diagramma che mostra una pipeline CI/CD che utilizza AWS CodePipeline e servizi correlati\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/deployment-pipeline-tooling.png)
1. Utilizza AWS CodeCommit per verificare la versione, archiviare e gestire risorse come documenti, codice sorgente e file binari.
1. Utilizza CodeBuild per compilare il codice sorgente, eseguire test delle unità e produrre artefatti pronti per l'implementazione.
1. Utilizza CodeDeploy come servizio di implementazione per automatizzare l'implementazione delle applicazioni su istanze [Amazon EC2](https://aws.amazon.com/ec2/) , istanze on-premise, [funzioni AWS Lambda serverless](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)o [Amazon ECS](https://aws.amazon.com/ecs/).
1. Monitora le tue implementazioni.
## Risorse
**Best practice correlate:**
+ [OPS06-BP04 Automazione dei test e del rollback](ops_mit_deploy_risks_auto_testing_and_rollback.md)
**Documenti correlati:**
+ [Strumenti per sviluppatori in AWS](https://aws.amazon.com/products/developer-tools/)
+ [ Che cos'è AWS CodeCommit? ](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)
+ [Che cos'è AWS CodeBuild?](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [AWS CodeBuild](https://aws.amazon.com/codebuild/)
+ [Che cos'è AWS CodeDeploy?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
**Video correlati:**
+ [AWS re:Invent 2022 - AWS Well-Architected best practices for DevOps on AWS](https://youtu.be/hfXokRAyorA)
# OPS05-BP05 Esecuzione della gestione delle patch
La gestione delle patch consente di ottenere funzionalità, risolvere problemi e rispettare i requisiti di governance. Automatizza la gestione delle patch per ridurre gli errori causati dai processi manuali, dimensionare e ridurre il livello di impegno richiesto per applicare le patch.
La gestione delle patch e delle vulnerabilità fa parte delle attività di gestione dei rischi e dei vantaggi. È preferibile disporre di infrastrutture immutabili e distribuire carichi di lavoro in stati noti verificati. Se ciò non è realizzabile, l'applicazione di patch sul posto è l'alternativa.
[Amazon EC2 Image Builder](https://aws.amazon.com/image-builder/) fornisce pipeline per l'aggiornamento di immagini AMI. Come parte della gestione delle patch, prendi in considerazione l'utilizzo di [Amazon Machine Image](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html ) (AMI) con una [pipeline di immagini AMI](https://docs.aws.amazon.com/imagebuilder/latest/userguide/start-build-image-pipeline.html) o immagini del container con una [pipeline di immagini Docker](https://docs.aws.amazon.com/imagebuilder/latest/userguide/start-build-container-pipeline.html). Inoltre, puoi utilizzare AWS Lambda, che fornisce modelli per [runtime personalizzati e librerie aggiuntive](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-custom.html) per eliminare le vulnerabilità.
È consigliabile gestire gli aggiornamenti alle [Amazon Machine Image](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AMIs.html) per immagini Linux o Windows Server utilizzando [Amazon EC2 Image Builder](https://aws.amazon.com/image-builder/). Puoi utilizzare [Amazon Elastic Container Registry (Amazon ECR)](https://docs.aws.amazon.com/AmazonECR/latest/userguide/what-is-ecr.html) con la pipeline esistente per gestire le immagini Amazon ECS ed Amazon EKS. Lambda include [funzionalità di gestione delle versioni](https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html).
L'applicazione di patch non deve essere eseguita sui sistemi di produzione senza prima eseguire test in un ambiente sicuro. Le patch devono essere applicate solo se supportano risultati operativi o aziendali. In AWS, è possibile utilizzare [Gestione patch di AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html) per automatizzare il processo di applicazione di patch ai sistemi gestiti e pianificare l'attività utilizzando le [finestre di manutenzione di Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html).
**Risultato desiderato:** Le immagini AMI e dei container sono aggiornate, dotate di patch e pronte per il lancio. È possibile tenere traccia dello stato di tutte le immagini implementate e conoscere la conformità delle patch. Puoi eseguire report sullo stato attuale e disporre di un processo per soddisfare le tue esigenze di conformità.
**Anti-pattern comuni:**
+ Ti viene assegnato il compito di applicare tutte le nuove patch di sicurezza entro 2 ore, il che provoca più interruzioni a causa dell'incompatibilità dell'applicazione con le patch.
+ Una libreria senza patch comporta conseguenze indesiderate in quanto parti sconosciute utilizzano vulnerabilità al suo interno per accedere al carico di lavoro.
+ L'applicazione di patch agli ambienti per sviluppatori viene eseguita automaticamente senza avvisare gli sviluppatori. Gli sviluppatori ti inviano più reclami perché il loro ambiente non funziona come previsto.
+ Non hai applicato patch al software pronto all'uso commerciale su un'istanza persistente. Quando hai problemi con il software e contatti il fornitore, questo ti informa che la versione non è supportata e che devi applicare le patch a un livello specifico per ricevere assistenza.
+ Una patch rilasciata di recente per il software di crittografia utilizzato offre miglioramenti significativi in termini di prestazioni. Il sistema privo di patch presenta problemi di prestazioni che rimangono in vigore a causa della mancata applicazione di patch.
+ Ricevi una notifica di una vulnerabilità zero-day che richiede una correzione di emergenza; quindi devi applicare manualmente le patch a tutti i tuoi ambienti.
**Vantaggi dell'adozione di questa best practice:** Stabilendo un processo di gestione delle patch, inclusi i criteri per l'applicazione di patch e la metodologia di distribuzione tra gli ambienti, sarai in grado di dimensionare e generare report sui livelli di patch. Ciò fornisce garanzie sull'applicazione delle patch di sicurezza e una chiara visibilità sullo stato delle correzioni note in atto. Ciò incoraggia l'adozione delle caratteristiche e funzionalità desiderate, aiuta a eliminare rapidamente i problemi e a mantenere la conformità alla governance. Implementa sistemi di gestione delle patch e automazione per ridurre il livello di impegno per distribuire le patch e limitare gli errori causati dai processi manuali.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
Applica patch ai sistemi per correggere gli errori, ottenere le funzionalità o le capacità desiderate e assicurare la conformità alle policy di governance e ai requisiti di supporto del vendor. Nei sistemi immutabili, distribuisci con il set di patch appropriato per raggiungere il risultato desiderato. Automatizza il meccanismo di gestione delle patch per ridurre il tempo necessario per applicare le patch, evitare gli errori causati dai processi manuali e diminuire il livello di impegno richiesto per applicare le patch.
### Passaggi dell'implementazione
Per Amazon EC2 Image Builder:
1. specifica i dettagli della pipeline utilizzando Amazon EC2 Image Builder:
1. Crea una pipeline di immagini e assegnale un nome
1. Definisci la pianificazione e il fuso orario della pipeline
1. Configura eventuali dipendenze
1. Scegli una ricetta:
1. Seleziona una ricetta esistente o creane una nuova
1. Seleziona il tipo di immagine
1. Assegna un nome e una versione alla tua ricetta
1. Seleziona l'immagine di base
1. Aggiungi componenti di compilazione e inseriscili nel registro di destinazione
1. Facoltativo: definisci la configurazione dell'infrastruttura.
1. Facoltativo: definisci le impostazioni di configurazione.
1. Revisiona le impostazioni.
1. Mantieni il livello di igiene delle ricette a livelli ottimali.
Per Gestione patch di Systems Manager:
1. Crea una patch di base.
1. Seleziona un metodo per le operazioni di definizione del percorso.
1. Abilita il report e la scansione della conformità.
## Risorse
**Best practice correlate:**
+ [OPS06-BP04 Automazione dei test e del rollback](ops_mit_deploy_risks_auto_testing_and_rollback.md)
**Documenti correlati:**
+ [ What is Amazon EC2 Image Builder ](https://docs.aws.amazon.com/imagebuilder/latest/userguide/what-is-image-builder.html)
+ [ Create an image pipeline using the Amazon EC2 Image Builder ](https://docs.aws.amazon.com/imagebuilder/latest/userguide/start-build-image-pipeline.html)
+ [ Create a container image pipeline ](https://docs.aws.amazon.com/imagebuilder/latest/userguide/start-build-container-pipeline.html)
+ [Gestione patch di AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-patch.html)
+ [ Working with Patch Manager ](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-console.html)
+ [ Working with patch compliance reports ](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-compliance-reports.html)
+ [ Strumenti per sviluppatori in AWS](https://aws.amazon.com/products/developer-tools)
**Video correlati:**
+ [CI/CD per applicazioni serverless su AWS](https://www.youtube.com/watch?v=tEpx5VaW4WE)
+ [Progettare nell'ottica Ops](https://youtu.be/uh19jfW7hw4)
**Esempi correlati:**
+ [ Well-Architected Labs: Inventario e gestione delle patch ](https://wellarchitectedlabs.com/operational-excellence/100_labs/100_inventory_patch_management)
+ [AWS Systems Manager Patch Manager tutorials ](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-tutorials.html)
# OPS05-BP06 Condivisione degli standard di progettazione
Condividi le best practice con i team per incrementare la consapevolezza e potenziare al massimo i vantaggi delle attività di sviluppo. Documentale e mantienile aggiornate di pari passo con l'evoluzione dell'architettura. Se nella tua organizzazione vengono applicati standard condivisi, è fondamentale che esistano meccanismi per richiedere aggiunte, modifiche ed eccezioni agli standard. Senza questa opzione, gli standard diventano un ostacolo per l'innovazione.
**Risultato desiderato:** Gli standard di progettazione vengono condivisi fra team nelle organizzazioni. Vengono documentati e tenuti aggiornati in base all'evoluzione delle best practice.
**Anti-pattern comuni:**
+ Due team di sviluppo hanno creato ciascuno un servizio di autenticazione utente. Gli utenti devono mantenere un set separato di credenziali per ogni parte del sistema a cui vogliono accedere.
+ Ogni team gestisce la propria infrastruttura. Un nuovo requisito di conformità impone una modifica all'infrastruttura e ogni team la implementa in modo diverso.
**Vantaggi dell'adozione di questa best practice:** L'uso di standard condivisi incoraggia l'applicazione di best practice e permette di ottenere i massimi vantaggi dalle attività di sviluppo. La documentazione e l'aggiornamento degli standard di progettazione tengono l'organizzazione al passo con le best practice e i requisiti di sicurezza e conformità.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
Condividi le best practice, gli standard di progettazione, gli elenchi di controllo, le procedure operative, le linee guida e i requisiti di governance esistenti tra team diversi. Definisci procedure per richiedere modifiche, aggiunte ed eccezioni agli standard di progettazione per supportare il miglioramento e l'innovazione. Rendi noto ai team il contenuto pubblicato. Predisponi un meccanismo per mantenere aggiornati gli standard di progettazione in base all'emergere di nuove best practice.
**Esempio del cliente**
AnyCompany Retail ha un team interfunzionale che crea modelli di architettura software. Questo team crea l'architettura con conformità e governance integrate. I team che adottano gli standard condivisi traggono vantaggio dall'integrazione di conformità e governance. Possono creare rapidamente soluzioni sulla base degli standard di progettazione. Il team responsabile dell'architettura si incontra ogni trimestre per valutare i modelli architetturali e aggiornarli, se necessario.
### Passaggi dell'implementazione
1. Identifica un team interfunzionale responsabile dello sviluppo e dell'aggiornamento degli standard di progettazione. Questo team collaborerà con gli stakeholder in tutta l'organizzazione per sviluppare standard di progettazione, procedure operative, elenchi di controllo, linee guida e requisiti di governance. Documenta gli standard di progettazione e condividili internamente all'organizzazione.
1. [AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html) può aiutarti a creare portfolio che rappresentano gli standard di progettazione usando il modello Infrastruttura come codice (IaC). Puoi condividere portfolio tra più account.
1. Predisponi un meccanismo per mantenere aggiornati gli standard di progettazione man mano che vengono identificate nuove best practice.
1. Se gli standard di progettazione vengono applicati a livello centrale, definisci un processo per richiedere modifiche, aggiornamenti ed eccezioni.
**Livello di impegno per il piano di implementazione:** medio. Lo sviluppo di un processo per creare e condividere standard di progettazione può richiedere il coordinamento e la cooperazione con gli 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 influiscono sugli standard di progettazione.
+ [OPS01-BP04 Valutazione dei requisiti di conformità](ops_priorities_compliance_reqs.md) – La conformità è un fattore essenziale nella creazione di standard di progettazione.
+ [OPS07-BP02 Revisione costante della prontezza operativa](ops_ready_to_support_const_orr.md) – Gli elenchi di controllo della prontezza operativa sono un meccanismo per implementare standard di progettazione durante la progettazione del carico di lavoro.
+ [OPS11-BP01 Definizione di un processo per il miglioramento continuo](ops_evolve_ops_process_cont_imp.md) – L'aggiornamento degli standard di progettazione contribuisce a un miglioramento continuo.
+ [OPS11-BP04 Gestione delle informazioni](ops_evolve_ops_knowledge_management.md) – Nell’ambito della procedura di gestione delle informazioni, documenta e condividi gli standard di progettazione.
**Documenti correlati:**
+ [ Automate AWS Backups with AWS Service Catalog](https://aws.amazon.com/blogs/mt/automate-aws-backups-with-aws-service-catalog/)
+ [AWS Service Catalog Account Factory-Enhanced ](https://aws.amazon.com/blogs/mt/aws-service-catalog-account-factory-enhanced/)
+ [ Expedia Group crea un'offerta Database as a Service (DBaaS) usando il AWS Service Catalog](https://aws.amazon.com/blogs/mt/how-expedia-group-built-database-as-a-service-dbaas-offering-using-aws-service-catalog/)
+ [ Mantenimento della visibilità sull'uso di modelli architetturali cloud ](https://aws.amazon.com/blogs/architecture/maintain-visibility-over-the-use-of-cloud-architecture-patterns/)
+ [ Simplify sharing your AWS Service Catalog portfolios in an AWS Organizations setup ](https://aws.amazon.com/blogs/mt/simplify-sharing-your-aws-service-catalog-portfolios-in-an-aws-organizations-setup/)
**Video correlati:**
+ [AWS Service Catalog – Getting Started ](https://www.youtube.com/watch?v=A9kKy6WhqVA)
+ [AWS re:Invent 2020: Manage your AWS Service Catalog portfolios like an expert ](https://www.youtube.com/watch?v=lVfXkWHAtR8)
**Esempi correlati:**
+ [AWS Service Catalog Reference Architecture ](https://github.com/aws-samples/aws-service-catalog-reference-architectures)
+ [AWS Service Catalog Workshop ](https://catalog.us-east-1.prod.workshops.aws/workshops/d40750d7-a330-49be-9945-cde864610de9/en-US)
**Servizi correlati:**
+ [AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html)
# OPS05-BP07 Implementazione di prassi per migliorare la qualità del codice
Implementa prassi per migliorare la qualità del codice e ridurre al minimo i difetti. Alcuni esempi includono sviluppo basato su test, revisioni del codice, adozione degli standard e programmazione in coppia. Inserisci queste prassi nel processo di integrazione continua e distribuzione continua.
**Risultato desiderato:** L'organizzazione usa best practice come le revisioni del codice e la programmazione in coppia per migliorare la qualità del codice. Sviluppatori e operatori adottano le best practice per la qualità del codice nell'ambito del ciclo di vita di sviluppo del software.
**Anti-pattern comuni:**
+ Commit del codice nel ramo principale dell'applicazione senza alcuna revisione. In questo modo, la modifica viene automaticamente implementata nell'ambiente di produzione e causa un'interruzione.
+ Sviluppo di una nuova applicazione senza unit test, test end-to-end o test di integrazione. Non è possibile in alcun modo testare l'applicazione prima dell'implementazione.
+ I team apportano modifiche manuali nell'ambiente di produzione per gestire gli errori. Le modifiche non vengono sottoposte a test o revisioni del codice, né vengono acquisite o registrate durante i processi di integrazione continua e distribuzione continua.
**Vantaggi dell'adozione di questa best practice:** L'adozione di pratiche per migliorare la qualità del codice ti consente di ridurre al minimo i problemi di produzione. La qualità del codice aumenta se vengono usate best practice come la programmazione in coppia e le revisioni del codice.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
Implementa prassi per migliorare la qualità del codice in modo da ridurre gli errori prima dell'implementazione. Usa prassi come lo sviluppo basato su test, le revisioni del codice e la programmazione in coppia per migliorare la qualità dello sviluppo.
**Esempio del cliente**
AnyCompany Retail adotta diverse prassi per migliorare la qualità del codice. L'azienda ha adottato lo sviluppo basato su test come standard per la scrittura di applicazioni. Per alcune nuove funzionalità, gli sviluppatori eseguono la programmazione in coppia durante uno sprint. Ogni richiesta pull viene sottoposta a una revisione del codice da parte di uno sviluppatore senior prima di essere integrata e implementata.
### Passaggi dell'implementazione
1. Adotta prassi per la qualità del codice come lo sviluppo basato su test, le revisioni del codice e la programmazione in coppia nel processo di integrazione continua e distribuzione continua. Usa queste tecniche per migliorare la qualità del software.
1. [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html) può fornire suggerimenti di programmazione per il codice Java e Python tramite il machine learning.
1. Con [AWS Cloud9](https://docs.aws.amazon.com/cloud9/latest/user-guide/welcome.html) puoi creare ambienti di sviluppo condivisi nei quali collaborare allo sviluppo del codice.
**Livello di impegno per il piano di implementazione:** medio. Esistono molti modi per implementare questa best practice, ma la realizzazione dell'adozione da parte dell'organizzazione può essere problematica.
## Risorse
**Best practice correlate:**
+ [OPS05-BP06 Condivisione degli standard di progettazione](ops_dev_integ_share_design_stds.md) - Puoi condividere gli standard di progettazione nell'ambito della prassi per la qualità del codice.
**Documenti correlati:**
+ [ Agile Software Guide ](https://martinfowler.com/agile.html)
+ [La mia pipeline CI/CD è la mia release captain](https://aws.amazon.com/builders-library/cicd-pipeline/)
+ [ Automazione delle revisioni del codice con il Amazon CodeGuru Reviewer ](https://aws.amazon.com/blogs/devops/automate-code-reviews-with-amazon-codeguru-reviewer/)
+ [ Adotta un approccio allo sviluppo basato sul test ](https://docs.aws.amazon.com/prescriptive-guidance/latest/best-practices-cdk-typescript-iac/development-best-practices.html)
+ [ DevFactory crea applicazioni migliori con Amazon CodeGuru ](https://aws.amazon.com/blogs/machine-learning/how-devfactory-builds-better-applications-with-amazon-codeguru/)
+ [ On Pair Programming ](https://martinfowler.com/articles/on-pair-programming.html)
+ [ RENGA Inc. automatizza le revisioni del codice con Amazon CodeGuru ](https://aws.amazon.com/blogs/machine-learning/renga-inc-automates-code-reviews-with-amazon-codeguru/)
+ [ The Art of Agile Development: Test-Driven Development ](http://www.jamesshore.com/v2/books/aoad1/test_driven_development)
+ [ Why code reviews matter (and actually save time\$1) ](https://www.atlassian.com/agile/software-development/code-reviews)
**Video correlati:**
+ [AWS re:Invent 2020: Continuous improvement of code quality with Amazon CodeGuru ](https://www.youtube.com/watch?v=iX1i35H1OVw)
+ [AWS Summit ANZ 2021 - Driving a test-first strategy with CDK and test driven development ](https://www.youtube.com/watch?v=1R7G_wcyd3s)
**Servizi correlati:**
+ [Amazon CodeGuru Reviewer](https://docs.aws.amazon.com/codeguru/latest/reviewer-ug/welcome.html)
+ [ Amazon CodeGuru Profiler ](https://docs.aws.amazon.com/codeguru/latest/profiler-ug/what-is-codeguru-profiler.html)
+ [AWS Cloud9](https://docs.aws.amazon.com/cloud9/latest/user-guide/welcome.html)
# OPS05-BP08 Utilizzo di più ambienti
Utilizza ambienti multipli per sperimentare, sviluppare e testare il carico di lavoro. Applica livelli crescenti di controlli man mano che gli ambienti si avvicinano alla fase di produzione per avere la certezza che il carico di lavoro funzioni come previsto una volta implementato.
**Risultato desiderato:** Disponi di più ambienti che riflettono le tue esigenze di conformità e governance. Testi e promuovi il codice negli ambienti lungo il tuo percorso verso la produzione.
**Anti-pattern comuni:**
+ Stai sviluppando in un ambiente di sviluppo condiviso e un altro sviluppatore sovrascrive le tue modifiche al codice.
+ I controlli di sicurezza restrittivi nell'ambiente di sviluppo condiviso impediscono di sperimentare nuovi servizi e funzionalità.
+ Esegui test di carico sui tuoi sistemi di produzione e causa un'interruzione per i tuoi utenti.
+ Si è verificato un errore critico che ha causato la perdita di dati nella produzione. Nel tuo ambiente di produzione tenti di ricreare le condizioni che portano alla perdita di dati in modo da poter identificare come si è verificata e impedire che si ripeta. Per evitare un'ulteriore perdita di dati durante il test, devi rendere l'applicazione non disponibile per i tuoi utenti.
+ Stai operando un servizio multi-tenant e non sei in grado di supportare la richiesta di un cliente per un ambiente dedicato.
+ Ogni volta che esegui un test, lo fai nel tuo ambiente di produzione.
+ Ritieni che la semplicità di un singolo ambiente prevalga sulla portata dell'impatto che possono avere modifiche all'interno dell'ambiente.
**Vantaggi dell'adozione di questa best practice:** puoi supportare più ambienti di sviluppo, test e produzione simultanei senza creare conflitti tra sviluppatori o community di utenti.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
Utilizza più ambienti e fornisci agli sviluppatori ambienti di sperimentazione (sandbox) con controlli minimi per incoraggiare la sperimentazione. Fornisci ambienti di sviluppo individuali per facilitare il lavoro in parallelo, incrementando l'agilità dello sviluppo. Implementa controlli più rigorosi negli ambienti che si avvicinano alla produzione per consentire agli sviluppatori di innovare. Utilizza l'approccio Infrastructure-as-Code e sistemi di gestione delle configurazioni per distribuire ambienti configurati in modo coerente con i controlli presenti in produzione per assicurare che i sistemi funzionino nel modo previsto quando vengono distribuiti. Quando gli ambienti non vengono utilizzati, disattivali per evitare costi associati alle risorse inattive, ad esempio i sistemi di sviluppo nelle ore serali e nei fine settimana. Durante i test di carico, è necessario implementare ambienti equivalenti a quelli di produzione per migliorare la validità dei risultati.
## Risorse
**Documenti correlati:**
+ [ Pianificatore di istanze su AWS](https://aws.amazon.com/solutions/implementations/instance-scheduler-on-aws/)
+ [Che cos'è AWS CloudFormation?](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)
# OPS05-BP09 Applicazione di modifiche frequenti, minime e reversibili
Le modifiche frequenti, minime e reversibili riducono la portata e l'impatto di una modifica. Le modifiche frequenti, minime e reversibili, se effettuate utilizzando congiuntamente sistemi di gestione delle modifiche, di gestione della configurazione e di compilazione e distribuzione, riducono la portata e l'impatto di una modifica. Questo si traduce in una risoluzione dei problemi più efficace, accelerando la correzione e mantenendo la possibilità di rollback delle modifiche.
**Anti-pattern comuni:**
+ Distribuisci una nuova versione della tua applicazione ogni trimestre con una finestra di modifica, il che comporta la disattivazione di un servizio di base.
+ Spesso apporti modifiche allo schema del database senza che ne venga tenuta traccia nei sistemi di gestione.
+ Esegui aggiornamenti manuali sul posto, sovrascrivendo le installazioni e le configurazioni esistenti, senza avere un chiaro piano di rollback.
**Vantaggi dell'adozione di questa best practice:** Le attività di sviluppo sono più rapide grazie all'implementazione frequente di modifiche minime. Quando le modifiche sono minime, è molto più semplice identificare se hanno conseguenze indesiderate e, in tal caso, ripristinare la condizione precedente. Quando le modifiche sono reversibili, il rischio di implementare le modifiche è minore in quanto il ripristino è semplificato. Il processo di modifica comporta un rischio ridotto e l'impatto di una modifica non corretta è ridotto.
**Livello di rischio associato se questa best practice non fosse adottata:** basso
## Guida all'implementazione
Applica modifiche frequenti, minime e reversibili per ridurre la portata e l'impatto di una modifica. In questo modo si semplifica la risoluzione dei problemi, si velocizza la correzione ed è possibile eseguire il rollback di una modifica. Inoltre, aggiunge più rapidamente valore al business.
## Risorse
**Best practice correlate:**
+ [OPS05-BP03 Utilizzo di sistemi di gestione delle configurazioni](ops_dev_integ_conf_mgmt_sys.md)
+ [OPS05-BP04 Utilizzo di sistemi di gestione della compilazione e implementazione](ops_dev_integ_build_mgmt_sys.md)
+ [OPS06-BP04 Automazione dei test e del rollback](ops_mit_deploy_risks_auto_testing_and_rollback.md)
**Documenti correlati:**
+ [ Implementazione di microservizi in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)
+ [ Microservices - Observability ](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/observability.html)
# OPS05-BP10 Automazione completa dell'integrazione e della distribuzione
Automatizza la creazione, la distribuzione e il test del carico di lavoro. Questo riduce gli errori causati dai processi manuali e l'impegno necessario per distribuire le modifiche.
Applica i metadati utilizzando i [tag delle risorse](https://docs.aws.amazon.com/general/latest/gr/aws_tagging.html) e [AWS Resource Groups](https://docs.aws.amazon.com/ARG/latest/APIReference/Welcome.html) seguendo una [strategia di applicazione dei tag](https://aws.amazon.com/answers/account-management/aws-tagging-strategies/) per agevolare l'identificazione delle risorse. Applica tag alle risorse per organizzare, monitorare i costi e controllare gli accessi e ottimizza l'esecuzione delle attività operative automatizzate.
**Risultato desiderato:** Chi si occupa di sviluppo utilizza strumenti per distribuire codice ed effettuare la promozione a produzione. Gli sviluppatori non devono effettuare il login alla Console di gestione AWS per fornire gli aggiornamenti. Esiste un audit trail completo di modifiche e configurazioni che soddisfa le esigenze di governance e conformità. I processi sono ripetibili e standardizzati tra i team. Gli sviluppatori sono liberi di concentrarsi sullo sviluppo e sui rilasci del codice, aumentando la produttività.
**Anti-pattern comuni:**
+ Venerdì termini la creazione del nuovo codice per il ramo delle funzionalità. Lunedì, dopo aver eseguito gli script di test di qualità del codice e tutti gli script dei test di unità, effettui il check-in del codice per il prossimo rilascio programmato.
+ Ti verrà assegnato di codificare una correzione per un problema critico che interessa un numero elevato di clienti nella produzione. Dopo aver testato la correzione, esegui il commit del codice e richiedi via e-mail alla gestione delle modifiche l'approvazione per implementarlo in produzione.
+ In qualità di sviluppatore, accedi alla Console di gestione AWS per creare un nuovo ambiente di sviluppo utilizzando metodi e sistemi non standard.
**Vantaggi dell'adozione di questa best practice:** Implementando sistemi di gestione automatizzati di compilazione e implementazione, si riduce il numero di errori causati dai processi manuali e lo sforzo di distribuire le modifiche aiutando i membri del team a concentrarsi sull'offerta di valore aggiunto. Maggiore velocità di consegna man mano che procedi verso la promozione a produzione.
**Livello di rischio associato se questa best practice non fosse adottata:** basso
## Guida all'implementazione
Utilizza i sistemi di gestione della compilazione e implementazione per tenere traccia e implementare le modifiche, ridurre gli errori causati dai processi manuali e ridurre il livello di impegno richiesto. Automatizza completamente la pipeline di integrazione e distribuzione dal check-in del codice fino alle fasi di creazione, test, distribuzione e convalida. In questo modo è possibile diminuire il lead time, incoraggiare una maggiore frequenza di modifica, ridurre il livello di impegno e accelerare il time-to-market, il che si traduce in una maggiore produttività e in un aumento della sicurezza del codice man mano che procedi con la promozione verso la produzione.
## Risorse
**Best practice correlate:**
+ [OPS05-BP03 Utilizzo di sistemi di gestione delle configurazioni](ops_dev_integ_conf_mgmt_sys.md)
+ [OPS05-BP04 Utilizzo di sistemi di gestione della compilazione e implementazione](ops_dev_integ_build_mgmt_sys.md)
**Documenti correlati:**
+ [Che cos'è AWS CodeBuild?](https://docs.aws.amazon.com/codebuild/latest/userguide/welcome.html)
+ [Che cos'è AWS CodeDeploy?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
**Video correlati:**
+ [AWS re\$1:Invent 2022 - AWS Well-Architected best practices for DevOps on AWS](https://youtu.be/hfXokRAyorA)
# OPS 6. In che modo mitighi i rischi della distribuzione?
Adotta prassi per fornire un feedback rapido sulla qualità e che permettano un ripristino veloce dalle modifiche che non hanno i risultati previsti. L'uso di queste prassi consente di mitigare l'impatto dei problemi introdotti attraverso la distribuzione delle modifiche.
**Topics**
+ [OPS06-BP01 Preparazione di un piano in caso di esito negativo delle modifiche](ops_mit_deploy_risks_plan_for_unsucessful_changes.md)
+ [OPS06-BP02 Implementazioni dei test](ops_mit_deploy_risks_test_val_chg.md)
+ [OPS06-BP03 Utilizza strategie di deployment sicure](ops_mit_deploy_risks_deploy_mgmt_sys.md)
+ [OPS06-BP04 Automazione dei test e del rollback](ops_mit_deploy_risks_auto_testing_and_rollback.md)
# OPS06-BP01 Preparazione di un piano in caso di esito negativo delle modifiche
Pianifica il ripristino di uno stato corretto noto o la correzione nell'ambiente di produzione nel caso in cui l'implementazione generi un risultato indesiderato. Disporre di una politica per stabilire un piano di questo tipo aiuta tutti i team a sviluppare strategie di ripristino dalle modifiche con esito negativo. Alcune strategie di esempio sono le fasi di deployment e rollback, le politiche di modifica, i flag di funzionalità, l'isolamento del traffico e lo spostamento del traffico. Una singola release può includere più modifiche ai componenti correlati. La strategia dovrebbe fornire la capacità di resistere o ripristinare in caso di guasto generato da qualsiasi modifica dei componenti.
**Risultato desiderato:** hai preparato un piano di ripristino dettagliato per la modifica in caso di fallimento. Inoltre, hai ridotto le dimensioni della release per ridurre al minimo il potenziale impatto su altri componenti del carico di lavoro. Di conseguenza, hai ridotto l'impatto aziendale abbreviando i potenziali tempi di inattività causati da una modifica non riuscita e aumentando la flessibilità e l'efficienza dei tempi di ripristino.
**Anti-pattern comuni:**
+ Hai eseguito un deployment e l'applicazione è diventata instabile, ma sembra che ci siano utenti attivi sul sistema. Devi decidere se eseguire il rollback della modifica e influire sugli utenti attivi o aspettare di eseguire il rollback della modifica, sapendo che gli utenti potranno essere comunque influenzati.
+ Dopo aver apportato una modifica di routine, i nuovi ambienti sono accessibili, ma una delle sottoreti è diventata irraggiungibile. Devi decidere se eseguire il rollback di tutto o provare a correggere il problema della sottorete inaccessibile. Mentre prendi tale decisione, la sottorete rimane irraggiungibile.
+ I tuoi sistemi non sono progettati in modo da consentire loro di essere aggiornati con release più piccole. Di conseguenza, è difficile annullare tali modifiche di massa (bulk changes) durante un deployment conclusosi con esito negativo.
+ Non utilizzi l'Infrastruttura come codice (IaC) e hai apportato aggiornamenti manuali all'infrastruttura che hanno portato a configurazioni indesiderate. Non è possibile tracciare e ripristinare in modo efficace le modifiche manuali.
+ Poiché non hai misurato l'aumento della frequenza dei deployment, il tuo team non è incentivato a ridurre le dimensioni delle modifiche e a migliorare i piani di rollback per ogni modifica, con conseguente aumento dei rischi e dei tassi di fallimento.
+ Non misura la durata totale di un'interruzione causata da modifiche con esito negativo. Il tuo team non è in grado di stabilire le priorità e migliorare il processo di deployment e l'efficacia del piano di ripristino.
**Vantaggi dell'adozione di questa best practice:** Avere un piano per il ripristino dopo le modifiche non riuscite riduce al minimo il tempo medio di ripristino (MTTR) e riduce l'impatto sull'azienda.
**Livello di rischio associato se questa best practice non fosse adottata:** alto
## Guida all'implementazione
Una politica e una pratica coerenti e documentate adottate dai team di rilascio consentono a un'organizzazione di pianificare cosa dovrebbe succedere in caso di modifiche con esito negativo. In circostanze specifiche la politica dovrebbe consentire la possibilità di apportare correzioni per garantire la prosecuzione del processo. In entrambe le situazioni, un piano di correzione (fix forward) o ripristino (rollback) deve essere ben documentato e testato prima dell'implementazione nei sistemi di produzione live, in modo da ridurre al minimo il tempo necessario per ripristinare una modifica.
### Passaggi dell'implementazione
1. Documenta le politiche che richiedono ai team di disporre di piani efficaci per invertire le modifiche entro un periodo di tempo specificato.
1. Le politiche devono specificare quando è consentita una situazione di applicazione di correzioni per garantire la prosecuzione del processo.
1. Richiedi un piano di rollback documentato che sia accessibile a tutti i soggetti coinvolti.
1. Specifica i requisiti per il rollback (ad esempio, quando si rileva che sono state implementate modifiche non autorizzate).
1. Analizza il livello di impatto di tutte le modifiche relative a ciascun componente di un carico di lavoro.
1. Consenti che le modifiche ripetibili siano standardizzate, basate su modelli e preautorizzate se seguono un flusso di lavoro coerente che applica le politiche di modifica.
1. Riduci il potenziale impatto di qualsiasi modifica riducendone le dimensioni, in modo che il ripristino richieda meno tempo e abbia un impatto minore sulle attività aziendali.
1. Assicurati che le procedure di rollback riportino il codice allo stato corretto noto per evitare incidenti, ove possibile.
1. Integra strumenti e flussi di lavoro per applicare le tue politiche in modo programmatico.
1. Rendi visibili i dati sulle modifiche agli altri responsabili di carichi di lavoro per migliorare la velocità di diagnosi di eventuali modifiche con esito negativo che non possono essere ripristinate.
1. Misura il successo di questa pratica utilizzando dati di modifica visibili e identifica miglioramenti iterativi.
1. Utilizza gli strumenti di monitoraggio per verificare il successo o il fallimento di un deployment per accelerare il processo decisionale sul rollback.
1. Misura la durata dell'interruzione durante una modifica con esito negativo per migliorare continuamente i tuoi piani di ripristino.
**Livello di impegno per il piano di implementazione:** Medio
## Risorse
**Best practice correlate:**
+ [OPS06-BP04 Automazione dei test e del rollback](ops_mit_deploy_risks_auto_testing_and_rollback.md)
**Documenti correlati:**
+ [AWS Builders Library \$1 Ensuring Rollback Safety During Deployments ](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments/)
+ [AWS Whitepaper \$1 Change Management in the Cloud ](https://docs.aws.amazon.com/whitepapers/latest/change-management-in-the-cloud/change-management-in-the-cloud.html)
**Video correlati:**
+ [ re:Invent 2019 \$1 Amazon’s approach to high-availability deployment ](https://aws.amazon.com/builders-library/amazon-approach-to-high-availability-deployment/)
# OPS06-BP02 Implementazioni dei test
Testa le procedure di rilascio in pre-produzione utilizzando la stessa configurazione di deployment, i controlli di sicurezza, i passaggi e le procedure utilizzati nell'ambiente di produzione. Verifica che tutte le fasi implementate siano state completate come previsto, ad esempio l'ispezione di file, configurazioni e servizi. Verifica ulteriormente tutte le modifiche con test funzionali, di integrazione e di carico, oltre ad attivare tutte le attività di monitoraggio come i controlli dell'integrità. Eseguendo questi test, è possibile identificare tempestivamente i problemi di deployment con l'opportunità di pianificarli e mitigarli prima del passaggio nell'ambiente di produzione.
Puoi creare ambienti paralleli temporanei per testare ogni modifica. Automatizza il deployment degli ambienti di test utilizzando l'Infrastruttura come codice (IaC) per ridurre la quantità di lavoro necessaria e garantire stabilità, coerenza e una distribuzione più rapida delle funzionalità.
**Risultato desiderato:** La tua organizzazione adotta una cultura di sviluppo che include il test delle implementazioni. Ciò garantisce che i team siano concentrati sulla realizzazione di valore aziendale anziché sulla gestione delle release. I team vengono coinvolti fin dall'identificazione dei rischi di deployment per determinare il percorso di mitigazione appropriato.
**Anti-pattern comuni:**
+ Durante le release di produzione, le implementazioni non testate causano problemi frequenti che richiedono una risoluzione mirata e l'escalation.
+ La tua release contiene porzioni di Infrastruttura come codice (IaC) che aggiornano le risorse esistenti. Non sei sicuro che l'IaC funzionerà correttamente e non avrà un impatto sulle risorse.
+ Viene implementata una nuova funzionalità interessante nella tua applicazione. Non funziona come previsto e non c'è visibilità finché non viene segnalata dagli utenti interessati.
+ I certificati vengono aggiornati. Si installano accidentalmente i certificati sui componenti sbagliati, il che non viene rilevato e influisce sui visitatori poiché non è possibile stabilire una connessione sicura al sito web.
**Vantaggi dell'adozione di questa best practice:** Test approfonditi in fase di pre-produzione delle procedure di implementazione e delle modifiche da queste introdotte riducono al minimo il potenziale impatto sulla produzione causato dalle fasi di implementazione. Ciò aumenta la fiducia durante il rilascio in produzione e riduce al minimo la necessità di supporto operativo senza rallentare la velocità di distribuzione delle modifiche apportate.
**Livello di rischio associato se questa best practice non fosse adottata:** alto
## Guida all'implementazione
Testare il processo di deployment è importante quanto testare le modifiche derivanti dal deployment. Ciò può essere ottenuto testando le fasi di deployment in un ambiente di pre-produzione che rispecchi il più fedelmente possibile quello di produzione. I problemi più comuni, come fasi di deployment incomplete o contenenti errori o configurazioni errate, possono essere individuati di conseguenza prima di passare all'ambiente di produzione. Inoltre, è possibile testare le fasi di ripristino.
**Esempio del cliente**
Nell'ambito della sua pipeline di integrazione continua e distribuzione continua (CI/CD), AnyCompany Retail esegue i passaggi definiti necessari per rilasciare aggiornamenti dell'infrastruttura e del software per i propri clienti in un ambiente simile a quello di produzione. La pipeline comprende controlli preliminari per rilevare il “drift” (il rilevamento delle modifiche alle risorse eseguite al di fuori dell'IaC) nelle risorse prima del deployment, nonché per convalidare le azioni che l'IaC intraprende al suo avvio. Convalida le fasi di deployment, ad esempio la verifica che determinati file e configurazioni siano presenti e che i servizi siano in esecuzione e rispondano correttamente ai controlli di integrità sull'host locale, prima di effettuare nuovamente la registrazione sul sistema di bilanciamento del carico. Inoltre, tutte le modifiche attivano una serie di test automatici, come test funzionali, di sicurezza, di regressione, di integrazione e di carico.
### Passaggi dell'implementazione
1. Esegui controlli di pre-installazione per rispecchiare l'ambiente di pre-produzione in produzione.
1. utilizza [il rilevamento della deviazione](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift.html) per rilevare quando le risorse sono state modificate all'esterno di CloudFormation.
1. utilizza [i set di modifiche](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets.html) per verificare che l'intento dell'aggiornamento dello stack corrisponda alle azioni intraprese da CloudFormation quando viene avviato il set di modifiche.
1. Ciò attiva una fase di approvazione manuale in [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/approvals.html) per autorizzare l'implementazione nell'ambiente di preproduzione.
1. Utilizza configurazioni di implementazione come [file AWS CodeDeploy AppSpec](https://docs.aws.amazon.com/codedeploy/latest/userguide/application-specification-files.html) per definire le fasi di implementazione e convalida.
1. Ove applicabile, [integra AWS CodeDeploy con altri servizi AWS](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-aws.html) o [integra AWS CodeDeploy con prodotti e servizi dei partner](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-partners.html).
1. [Monitora le implementazioni](https://docs.aws.amazon.com/codedeploy/latest/userguide/monitoring.html) usando le notifiche di eventi Amazon CloudWatch, AWS CloudTrail e Amazon SNS.
1. Esegui test automatici post-deployment, inclusi test funzionali, di sicurezza, di regressione, di integrazione e di carico.
1. [Risoluzione dei problemi](https://docs.aws.amazon.com/codedeploy/latest/userguide/troubleshooting.html) di implementazione.
1. La corretta convalida dei passaggi precedenti dovrebbe attivare un flusso di lavoro di approvazione manuale per autorizzare l'implementazione nell'ambiente di produzione.
**Livello di impegno per il piano di implementazione:** alto
## Risorse
**Best practice correlate:**
+ [OPS05-BP02 Test e convalida delle modifiche](ops_dev_integ_test_val_chg.md)
**Documenti correlati:**
+ [AWS Builders' Library \$1 Automating safe, hands-off deployments \$1 Test Deployments ](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/#Test_deployments_in_pre-production_environments)
+ [AWS Whitepaper \$1 Practicing Continuous Integration and Continuous Delivery on AWS](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/testing-stages-in-continuous-integration-and-continuous-delivery.html)
+ [ The Story of Apollo - Amazon's Deployment Engine ](https://www.allthingsdistributed.com/2014/11/apollo-amazon-deployment-engine.html)
+ [Come eseguire test e debug con AWS CodeDeploy in locale prima di distribuire il codice](https://aws.amazon.com/blogs/devops/how-to-test-and-debug-aws-codedeploy-locally-before-you-ship-your-code/)
+ [ Integrating Network Connectivity Testing with Infrastructure Deployment ](https://aws.amazon.com/blogs/networking-and-content-delivery/integrating-network-connectivity-testing-with-infrastructure-deployment/)
**Video correlati:**
+ [ re:Invent 2020 \$1 Testing software and systems at Amazon ](https://www.youtube.com/watch?v=o1sc3cK9bMU)
**Esempi correlati:**
+ [ Tutorial \$1 Deploy and Amazon ECS service with a validation test ](https://docs.aws.amazon.com/codedeploy/latest/userguide/tutorial-ecs-deployment-with-hooks.html)
# OPS06-BP03 Utilizza strategie di deployment sicure
I roll-out sicuri della produzione controllano il flusso di modifiche vantaggiose con l'obiettivo di ridurre al minimo l'impatto percepito di tali modifiche sui clienti. I controlli di sicurezza forniscono meccanismi di ispezione per convalidare i risultati desiderati e limitare l'ambito di impatto derivante da eventuali difetti introdotti dalle modifiche o da errori di deployment. I roll-out sicuri possono includere strategie come feature-flags, one-box, roll-out (release canary), immutabili, suddivisioni del traffico e deployment blu/verdi.
**Risultato desiderato:** l'organizzazione utilizza un sistema di distribuzione e integrazione continua (CI/CD) che fornisce funzionalità per automatizzare roll-out sicuri. I team sono tenuti a utilizzare strategie di roll-out sicure appropriate.
**Anti-pattern comuni:**
+ Distribuisci una modifica non riuscita a tutta la produzione contemporaneamente. Di conseguenza, tutti i clienti vengono colpiti contemporaneamente.
+ Un difetto introdotto in un deployment simultaneo su tutti i sistemi richiede una release di emergenza. La correzione per tutti i clienti richiede diversi giorni.
+ La gestione della release di produzione richiede la pianificazione e la partecipazione di diversi team. Ciò limita la tua capacità di aggiornare frequentemente le funzionalità per i tuoi clienti.
+ Esegui un deployment variabile modificando i sistemi esistenti. Dopo aver scoperto che la modifica non è andata a buon fine, devi modificare nuovamente i sistemi per ripristinare la versione precedente estendendo il tempo di ripristino.
**Vantaggi dell'adozione di questa best practice:** Le implementazioni automatizzate bilanciano la velocità dei roll-out con la fornitura costante di modifiche vantaggiose per i clienti. La limitazione dell'impatto previene costosi errori di deployment e massimizza la capacità dei team di rispondere in modo efficiente ai guasti.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
Gli errori della distribuzione continua possono portare a una ridotta disponibilità del servizio e a esperienze dei clienti negative. Per massimizzare il tasso di deployment di successo, implementa i controlli di sicurezza nel processo di rilascio end-to-end per ridurre al minimo gli errori di deployment, con l'obiettivo di raggiungere il traguardo di zero errori.
**Esempio del cliente**
La missione di AnyCompany Retail è raggiungere deployment con tempi di inattività minimi o pari a zero, il che significa che non vi deve essere alcun impatto percepibile dagli utenti durante i deployment. A tal fine, l'azienda ha stabilito modelli di deployment (vedere il seguente diagramma del flusso di lavoro) come roll-out e deployment blu/verdi. Tutti i team adottano uno o più di questi modelli nella loro pipeline CI/CD.
| flusso di lavoro CodeDeploy per Amazon EC2 | flusso di lavoro CodeDeploy per Amazon ECS | flusso di lavoro CodeDeploy per Lambda |
| --- | --- | --- |
| ![\[Flusso del processo di implementazione per Amazon EC2\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/deployment-process-ec2.png) | ![\[Flusso del processo di implementazione per Amazon ECS\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/deployment-process-ecs.png) | ![\[Flusso del processo di implementazione per Lambda\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/deployment-process-lambda.png) |
### Passaggi dell'implementazione
1. Utilizza un flusso di lavoro di approvazione per avviare la sequenza delle fasi di roll-out della produzione al momento della promozione alla produzione.
1. Utilizza un sistema di implementazione automatizzato come [AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html). AWS CodeDeploy [opzioni di implementazione](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-steps.html) include le implementazioni locali (in-place) per EC2/on-premise e le implementazioni blu/verdi per EC2/on-premise AWS Lambda e Amazon ECS (vedi il diagramma del flusso di lavoro precedente).
1. Ove applicabile, [integra AWS CodeDeploy con altri servizi AWS](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-aws.html) o [integra AWS CodeDeploy con prodotti e servizi dei partner](https://docs.aws.amazon.com/codedeploy/latest/userguide/integrations-partners.html).
1. Utilizza implementazioni blu/verdi per database come [Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/blue-green-deployments.html) e [Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments.html).
1. [Monitora le implementazioni](https://docs.aws.amazon.com/codedeploy/latest/userguide/monitoring.html) usando le notifiche di eventi Amazon CloudWatch, AWS CloudTrail e Amazon SNS.
1. Esegui test automatici post-implementazione, inclusi test funzionali, di sicurezza, di regressione, di integrazione e di carico.
1. [Risoluzione dei problemi](https://docs.aws.amazon.com/codedeploy/latest/userguide/troubleshooting.html) di implementazione.
**Livello di impegno per il piano di implementazione:** Medio
## Risorse
**Best practice correlate:**
+ [OPS05-BP02 Test e convalida delle modifiche](ops_dev_integ_test_val_chg.md)
+ [OPS05-BP09 Applicazione di modifiche frequenti, minime e reversibili](ops_dev_integ_freq_sm_rev_chg.md)
+ [OPS05-BP10 Automazione completa dell'integrazione e della distribuzione](ops_dev_integ_auto_integ_deploy.md)
**Documenti correlati:**
+ [AWS Builders Library \$1 Automating safe, hands-off deployments \$1 Production deployments ](https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/?did=ba_card&trk=ba_card#Production_deployments)
+ [AWS Builders Library \$1 My CI/CD pipeline is my release captain \$1 Safe, automatic production releases](https://aws.amazon.com//builders-library/cicd-pipeline/#Safe.2C_automatic_production_releases)
+ [AWS Whitepaper \$1 Practicing Continuous Integration and Continuous Delivery on AWS \$1 Deployment methods](https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/deployment-methods.html)
+ [Guida per l'utente di AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
+ [Utilizzo di configurazioni di distribuzione in AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployment-configurations.html)
+ [Configurazione della distribuzione di una release Canary di API Gateway ](https://docs.aws.amazon.com/apigateway/latest/developerguide/canary-release.html)
+ [Amazon ECS Deployment Types](https://docs.aws.amazon.com/)
+ [Fully Managed Blue/Green Deployments in Amazon Aurora and Amazon RDS](https://aws.amazon.com/blogs/aws/new-fully-managed-blue-green-deployments-in-amazon-aurora-and-amazon-rds/)
+ [Distribuzioni blu/verde con AWS Elastic Beanstalk](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.CNAMESwap.html)
**Video correlati:**
+ [re:Invent 2020 \$1 Hands-off: Automating continuous delivery pipelines at Amazon](https://www.youtube.com/watch?v=ngnMj1zbMPY)
+ [re:Invent 2019 \$1 Amazon's Approach to high-availability deployment](https://www.youtube.com/watch?v=bCgD2bX1LI4)
**Esempi correlati:**
+ [Prova un'implementazione blu/verde di esempio in AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/applications-create-blue-green.html)
+ [Workshop \$1 Buiding CI/CD pipelines for Lambda canary deployments using AWS CDK](https://catalog.us-east-1.prod.workshops.aws/workshops/5195ab7c-5ded-4ee2-a1c5-775300717f42/en-US)
+ [Workshop \$1 Blue/Green and Canary Deployment for EKS and ECS](https://catalog.us-east-1.prod.workshops.aws/workshops/2175d94a-cd79-4ed2-8e7e-1f0dd1956a3a/en-US)
+ [Workshop \$1 Building a Cross-account CI/CD Pipeline](https://catalog.us-east-1.prod.workshops.aws/workshops/00bc829e-fd7c-4204-9da1-faea3cf8bd88/en-US)
# OPS06-BP04 Automazione dei test e del rollback
Per aumentare la velocità, l'affidabilità e la sicurezza del processo di deployment, rendi disponibile una strategia per le funzionalità di test e rollback automatizzate negli ambienti di pre-produzione e produzione. Automatizza i test durante il deployment in produzione per simulare le interazioni umane e di sistema che verificano le modifiche implementate. Automatizza il rollback per tornare rapidamente allo stato precedente corretto noto. Il rollback deve essere avviato automaticamente in condizioni predefinite, ad esempio quando il risultato desiderato della modifica non viene raggiunto o quando il test automatico fallisce. L'automazione di queste due attività migliora la percentuale di successo dei deployment, riduce al minimo i tempi di ripristino e riduce il potenziale impatto sulle attività aziendali.
**Risultato desiderato:** I test automatici e le strategie di rollback sono integrati nella pipeline di integrazione continua e distribuzione continua (CI/CD). Il monitoraggio è in grado di eseguire la convalida in base ai criteri di successo e avviare il rollback automatico in caso di errore. Ciò riduce al minimo l'impatto sugli utenti finali e sui clienti. Ad esempio, quando tutti i risultati dei test sono stati soddisfatti, promuovi il codice nell'ambiente di produzione in cui vengono avviati i test di regressione automatizzati, sfruttando gli stessi casi di test. Se i risultati dei test di regressione non corrispondono alle aspettative, viene avviato il rollback automatico nel flusso di lavoro della pipeline.
**Anti-pattern comuni:**
+ I tuoi sistemi non sono progettati in modo da consentire loro di essere aggiornati con release più piccole. Di conseguenza, è difficile annullare tali modifiche di massa (bulk changes) durante un deployment conclusosi con esito negativo.
+ Il processo di deployment consiste in una serie di passaggi manuali. Dopo aver distribuito le modifiche al carico di lavoro, inizi i test post-deployment. Dopo il test, ti rendi conto che il tuo carico di lavoro è inutilizzabile e i clienti sono disconnessi. Inizi quindi a eseguire il rollback alla versione precedente. Tutti questi passaggi manuali ritardano il ripristino complessivo del sistema e provocano un impatto prolungato sui clienti.
+ Hai impiegato del tempo a sviluppare casi di test automatizzati per funzionalità che non vengono utilizzate frequentemente nella tua applicazione, riducendo al minimo il ritorno sull'investimento nella tua capacità di eseguire test automatizzati.
+ La versione è composta da applicazioni, infrastrutture, patch e aggiornamenti di configurazione indipendenti l'uno dall'altro. Tuttavia, è disponibile un'unica pipeline CI/CD che fornisce tutte le modifiche contemporaneamente. Un guasto in un componente obbliga a ripristinare tutte le modifiche, rendendo il rollback complesso e inefficiente.
+ Il tuo team completa il lavoro di codifica nello sprint uno e inizia il lavoro dello sprint due, ma il tuo piano non includeva i test fino allo sprint tre. Come conseguenza, i test automatici hanno rivelato difetti dello sprint uno che dovevano essere risolti prima di poter avviare il test dei deliverable dello sprint due e l'intera release viene ritardata, rendendo inutili i test automatizzati.
+ I casi di test di regressione automatizzati per la release di produzione sono completi, ma non stai monitorando lo stato del carico di lavoro. Poiché non è possibile verificare se il servizio è stato riavviato o meno, non sei sicuro se il rollback sia necessario o se sia già avvenuto.
**Vantaggi dell'adozione di questa best practice:** I test automatizzati aumentano la trasparenza del processo di verifica e la capacità di coprire più funzionalità in un periodo di tempo più breve. Testando e convalidando le modifiche nella produzione, è possibile identificare immediatamente i problemi. Il miglioramento della coerenza con strumenti di test automatizzati consente una migliore rilevazione dei difetti. Effettuando automaticamente il rollback alla versione precedente, l'impatto sui clienti viene ridotto al minimo. In ultima analisi, il rollback automatizzato ispira maggiore fiducia nelle capacità di deployment riducendo l'impatto sulle attività aziendali. Nel complesso, queste funzionalità riducono i tempi di consegna garantendo al contempo la qualità.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
Automatizza i test degli ambienti distribuiti per verificare che i risultati siano quelli desiderati. Automatizza il rollback a uno stato corretto noto quando non vengono raggiunti i risultati previsti, per ridurre al minimo il tempo di ripristino e gli errori causati dai processi manuali. Integra gli strumenti di test con il flusso di lavoro della pipeline per testare in modo coerente e ridurre al minimo gli input manuali. Dai priorità all'automazione dei casi di test, come quelli che mitigano i rischi maggiori e devono essere testati frequentemente a ogni modifica. Inoltre, automatizza il rollback in base a condizioni specifiche predefinite nel tuo piano di test.
### Passaggi dell'implementazione
1. Stabilisci un ciclo di vita di test per il tuo ciclo di vita di sviluppo che definisca ogni fase del processo di test, dalla pianificazione dei requisiti allo sviluppo dei test case, alla configurazione degli strumenti, ai test automatizzati e alla chiusura dei test case.
1. Crea un approccio di test specifico per il carico di lavoro partendo dalla tua strategia di test complessiva.
1. Prendi in considerazione una strategia di test continuo, laddove appropriato, durante tutto il ciclo di vita dello sviluppo.
1. Seleziona strumenti automatizzati per il test e il rollback in base ai requisiti aziendali e agli investimenti nella pipeline.
1. Decidi quali casi di test desideri automatizzare e quali devono essere eseguiti manualmente. Questi possono essere definiti in base alla priorità del valore aziendale della funzionalità testata. Allinea tutti i membri del team su questo piano e verifica la responsabilità per l'esecuzione di test manuali.
1. Applica le funzionalità di test automatico a casi di test specifici che è opportuno automatizzare, come i casi ripetibili o eseguiti di frequente, quelli che richiedono attività ripetitive o quelli che sono necessari per più configurazioni.
1. Definisci gli script di automazione dei test e i criteri di successo nello strumento di automazione in modo da poter avviare l'automazione continua del flusso di lavoro quando casi specifici falliscono.
1. Definisci criteri di errore specifici per il rollback automatico.
1. Dai priorità all'automazione dei test per ottenere risultati coerenti con lo sviluppo accurato e completo di casi di test in cui la complessità e l'interazione umana hanno un rischio maggiore di fallimento.
1. Integra i tuoi strumenti di test e rollback automatizzati nella tua pipeline CI/CD.
1. Sviluppa criteri di successo chiari per le tue modifiche.
1. Monitora e osserva per rilevare questi criteri e annullare automaticamente le modifiche quando vengono soddisfatti criteri di rollback specifici.
1. Esegui diversi tipi di test di produzione automatizzati, come:
1. Test A/B, per mostrare i risultati rispetto alla versione corrente tra due gruppi di utenti di test.
1. Test Canary, che consente di distribuire la modifica a un sottoinsieme di utenti prima di rilasciarla a tutti.
1. Test con flag delle funzionalità, che consente di attivare e disattivare una singola funzionalità della nuova versione alla volta dall'esterno dell'applicazione, in modo che ogni nuova funzionalità possa essere convalidata una alla volta.
1. Test di regressione, per verificare nuove funzionalità con componenti correlati esistenti.
1. Monitora gli aspetti operativi dell'applicazione, delle transazioni e delle interazioni con altre applicazioni e componenti. Sviluppa report per mostrare il successo delle modifiche in base al carico di lavoro in modo da poter identificare quali parti dell'automazione e del flusso di lavoro possono essere ulteriormente ottimizzate.
1. Sviluppa report sui risultati dei test che ti aiutino a prendere decisioni rapide sull'opportunità o meno di richiamare o meno le procedure di rollback.
1. Implementa una strategia che consenta il rollback automatico basato su condizioni di errore predefinite derivanti da uno o più metodi di test.
1. Sviluppa i tuoi casi di test automatizzati per consentire la riutilizzabilità in caso di modifiche ripetibili future.
**Livello di impegno per il piano di implementazione:** Medio
## Risorse
**Best practice correlate:**
+ [OPS06-BP01 Preparazione di un piano in caso di esito negativo delle modifiche](ops_mit_deploy_risks_plan_for_unsucessful_changes.md)
+ [OPS06-BP02 Implementazioni dei test](ops_mit_deploy_risks_test_val_chg.md)
**Documenti correlati:**
+ [AWS Builders Library \$1 Ensuring rollback safety during deployments ](https://aws.amazon.com/builders-library/ensuring-rollback-safety-during-deployments/)
+ [Redeploy and rollback a deployment with AWS CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/deployments-rollback-and-redeploy.html)
+ [ 8 best practices when automating your deployments with AWS CloudFormation](https://aws.amazon.com/blogs/infrastructure-and-automation/best-practices-automating-deployments-with-aws-cloudformation/)
**Esempi correlati:**
+ [ Serverless UI testing using Selenium, AWS Lambda, AWS Fargate, and AWS Developer Tools ](https://aws.amazon.com/blogs/devops/using-aws-codepipeline-aws-codebuild-and-aws-lambda-for-serverless-automated-ui-testing/)
**Video correlati:**
+ [ re:Invent 2020 \$1 Hands-off: Automating continuous delivery pipelines at Amazon ](https://www.youtube.com/watch?v=ngnMj1zbMPY)
+ [ re:Invent 2019 \$1 Amazon's Approach to high-availability deployment ](https://www.youtube.com/watch?v=bCgD2bX1LI4)
# 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/)