# Operatività
**Topics**
+ [OPS 8. Come utilizzi l'osservabilità del carico di lavoro nella tua organizzazione?](ops-08.md)
+ [OPS 9. Come fai a comprendere lo stato delle operazioni?](ops-09.md)
+ [OPS 10. In che modo gestisci gli eventi del carico di lavoro e delle operazioni?](ops-10.md)
# OPS 8. Come utilizzi l'osservabilità del carico di lavoro nella tua organizzazione?
Garantisci l'integrità del carico di lavoro sfruttando l'osservabilità. Utilizza metriche, log e tracce pertinenti per ottenere una visione completa delle prestazioni del carico di lavoro e risolvere i problemi in modo efficiente.
**Topics**
+ [OPS08-BP01 Analisi delle metriche del carico di lavoro](ops_workload_observability_analyze_workload_metrics.md)
+ [OPS08-BP02 Analizza i log relativi ai carichi di lavoro](ops_workload_observability_analyze_workload_logs.md)
+ [OPS08-BP03 Analisi delle tracce del carico di lavoro](ops_workload_observability_analyze_workload_traces.md)
+ [OPS08-BP04 Creare avvisi fruibili](ops_workload_observability_create_alerts.md)
+ [OPS08-BP05 Creare dashboard](ops_workload_observability_create_dashboards.md)
# OPS08-BP01 Analisi delle metriche del carico di lavoro
Dopo aver implementato la telemetria dell'applicazione, analizza regolarmente le metriche raccolte. Sebbene latenza, richieste, errori e capacità (o quote) forniscano informazioni dettagliate sulle prestazioni del sistema, è fondamentale dare priorità alla revisione delle metriche relative ai risultati aziendali. Ciò ti assicura di prendere decisioni basate sui dati in linea con i tuoi obiettivi aziendali.
**Risultato desiderato:** Informazioni dettagliate sulle prestazioni del carico di lavoro che guidano decisioni basate sui dati, garantendo l'allineamento con gli obiettivi aziendali.
**Anti-pattern comuni:**
+ Analisi isolata delle metriche senza considerare il loro impatto sui risultati aziendali.
+ Eccessiva dipendenza dalle metriche tecniche trascurando quelle aziendali.
+ Revisione poco frequente delle metriche, perdita di opportunità di prendere decisioni in tempo reale.
**Vantaggi dell'adozione di questa best practice:**
+ Comprensione migliorata della correlazione tra prestazioni tecniche e risultati aziendali.
+ Processo decisionale migliorato basato su dati in tempo reale.
+ Identificazione e mitigazione proattive dei problemi prima che influiscano sui risultati aziendali.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
Sfrutta strumenti come Amazon CloudWatch per l'esecuzione di analisi delle metriche. Utilizza servizi AWS come AWS Cost Anomaly Detection e Amazon DevOps Guru per rilevare anomalie, soprattutto quando le soglie statiche non sono conosciute o quando i modelli di comportamento evidenziano possibili anomalie.
### Passaggi dell'implementazione
1. **Analizza e revisiona:** revisiona e interpreta regolarmente le metriche relative al carico di lavoro.
1. Dai priorità alle metriche relative ai risultati aziendali rispetto a quelle puramente tecniche.
1. Comprendi l'importanza di picchi, cali o schemi nei dati.
1. **Utilizza Amazon CloudWatch:** utilizza Amazon CloudWatch per una visualizzazione centralizzata e un'analisi approfondita.
1. Configura dashboard CloudWatch per visualizzare le tue metriche e confrontarle nel tempo.
1. Utilizza [percentili in CloudWatch](https://aws-observability.github.io/observability-best-practices/guides/operational/business/sla-percentile/) per avere una visione chiara della distribuzione delle metriche, il che può aiutarti a definire gli SLA e a identificare valori anomali.
1. Configura [AWS Cost Anomaly Detection](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) per identificare modelli insoliti senza fare affidamento su soglie statiche.
1. Implementa [l'osservabilità CloudWatch tra account](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html) per monitorare e risolvere i problemi delle applicazioni che si estendono su più account all'interno di una regione.
1. Utilizza [gli approfondimenti sulle metriche CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/query_with_cloudwatch-metrics-insights.html) per interrogare e analizzare i dati delle metriche tra account e regioni, identificando tendenze e anomalie.
1. Applica [Metrica matematica CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) per trasformare, aggregare o eseguire calcoli sulle metriche per ottenere informazioni più approfondite.
1. **Impiega Amazon DevOps Guru:** incorpora [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/) per il rilevamento delle anomalie basato sul machine learning, che consente di identificare i primi segnali di problemi operativi che riguardano le applicazioni serverless e di correggerli prima che abbiano un impatto sui clienti.
1. **Ottimizza in base agli approfondimenti: ** prendi decisioni informate sulla base dell'analisi delle metriche per adeguare e migliorare i carichi di lavoro.
**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)
**Documenti correlati:**
+ [ The Wheel Blog - Emphasizing the importance of continually reviewing metrics ](https://aws.amazon.com/blogs/opensource/the-wheel/)
+ [ Percentile are important ](https://aws-observability.github.io/observability-best-practices/guides/operational/business/sla-percentile/)
+ [ Utilizzo di AWS Cost Anomaly Detection](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html)
+ [ CloudWatch cross-account observability ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html)
+ [ Query your metrics with CloudWatch Metrics Insights ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/query_with_cloudwatch-metrics-insights.html)
**Video correlati:**
+ [ Enable Cross-Account Observability in Amazon CloudWatch ](https://www.youtube.com/watch?v=lUaDO9dqISc)
+ [ Introduction to Amazon DevOps Guru ](https://www.youtube.com/watch?v=2uA8q-8mTZY)
+ [ Continuously Analyze Metrics using AWS Cost Anomaly Detection](https://www.youtube.com/watch?v=IpQYBuay5OE)
**Esempi correlati:**
+ [ One Observability Workshop ](https://catalog.workshops.aws/observability/en-US/intro)
+ [ Gaining operation insights with AIOps using Amazon DevOps Guru ](https://catalog.us-east-1.prod.workshops.aws/workshops/f92df379-6add-4101-8b4b-38b788e1222b/en-US)
# OPS08-BP02 Analizza i log relativi ai carichi di lavoro
L'analisi regolare dei log dei carichi di lavoro è essenziale per acquisire una comprensione più approfondita degli aspetti operativi dell'applicazione. Attraverso l'analisi, la consultazione e l'interpretazione efficiente dei dati di log, è possibile ottimizzare continuamente le prestazioni e la sicurezza delle applicazioni.
**Risultato desiderato:** Informazioni dettagliate sul comportamento dell'applicazione e sulle operazioni derivanti da un'analisi completa dei log, che garantisce la rilevazione e la mitigazione proattiva dei problemi.
**Anti-pattern comuni:**
+ Trascurare l'analisi dei log fino a quando non si verifica un problema critico.
+ Il mancato utilizzo della suite completa degli strumenti disponibili per l'analisi dei log comporta la perdita di approfondimenti importanti.
+ Fare affidamento esclusivamente sulla revisione manuale dei log senza sfruttare le funzionalità di automazione e di interrogazione.
**Vantaggi dell'adozione di questa best practice:**
+ Identificazione proattiva dei colli di bottiglia operativi, delle minacce alla sicurezza e di altri problemi potenziali.
+ Utilizzo efficiente dei dati di log per l'ottimizzazione continua dell'applicazione.
+ Comprensione migliorata del comportamento dell'applicazione, facilitando il debug e la risoluzione dei problemi.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
[Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html) è un potente strumento per l'analisi dei log. Le funzionalità integrate come CloudWatch Logs Insights e Contributor Insights rendono il processo di derivazione di approfondimenti significativi dai log intuitivo ed efficiente.
### Passaggi dell'implementazione
1. **Configura CloudWatch Logs:** configura applicazioni e servizi per inviare log a CloudWatch Logs.
1. **Configura CloudWatch Logs Insights:** Utilizza [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) per cercare e analizzare in modo interattivo i dati di log.
1. Crea query per estrarre modelli, visualizzare i dati di log e ricavare approfondimenti utili.
1. **Sfrutta Contributor Insights** Utilizza [Contributor Insights di CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html) per identificare i top talkers in dimensioni ad alta cardinalità come gli indirizzi IP o gli utenti-agenti.
1. **Implementa filtri di metriche per CloudWatch Logs:** configura [filtri di metriche per log di CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) per convertire i dati di log in metriche fruibili. Ciò consente di impostare allarmi o analizzare ulteriormente i modelli.
1. **Revisione e ottimizzazione regolari:** rivedi periodicamente le tue strategie di analisi dei log per acquisire tutte le informazioni pertinenti e ottimizzare continuamente le prestazioni delle applicazioni.
**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)
+ [OPS08-BP01 Analisi delle metriche del carico di lavoro](ops_workload_observability_analyze_workload_metrics.md)
**Documenti correlati:**
+ [ Analisi dei dati di log con CloudWatch Logs Insights ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html)
+ [ Using CloudWatch Contributor Insights ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights.html)
+ [ Creazione e gestione di filtri di metriche per log di CloudWatch Logs ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html)
**Video correlati:**
+ [ Analyze Log Data with CloudWatch Logs Insights ](https://www.youtube.com/watch?v=2s2xcwm8QrM)
+ [ Use CloudWatch Contributor Insights to Analyze High-Cardinality Data ](https://www.youtube.com/watch?v=ErWRBLFkjGI)
**Esempi correlati:**
+ [ Query di esempio di CloudWatch Logs ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_QuerySyntax-examples.html)
+ [ One Observability Workshop ](https://catalog.workshops.aws/observability/en-US/intro)
# OPS08-BP03 Analisi delle tracce del carico di lavoro
L'analisi dei dati di tracciamento è fondamentale per ottenere una visione completa del percorso operativo di un'applicazione. Visualizzando e comprendendo le interazioni tra i vari componenti, è possibile ottimizzare le prestazioni, identificare i colli di bottiglia e migliorare l'esperienza utente.
**Risultato desiderato:** Ottieni una chiara visibilità sulle operazioni distribuite della tua applicazione, che si traduce in una risoluzione più rapida dei problemi e in un'esperienza utente migliorata.
**Anti-pattern comuni:**
+ I dati di tracciamento vengono trascurati e ci si affida esclusivamente a log e metriche.
+ I dati di tracciamento non sono correlati ai log associati.
+ Vengono ignorate le metriche derivate dalle tracce, come la latenza e i tassi di errore.
**Vantaggi dell'adozione di questa best practice:**
+ Miglioramento della risoluzione dei problemi e riduzione del tempo medio di risoluzione (MTTR).
+ Informazioni dettagliate sulle dipendenze e sul loro impatto.
+ Identificazione e correzione rapide dei problemi di prestazione.
+ Vengono sfruttate le metriche derivate dalle tracce per un processo decisionale informato.
+ Esperienze utente migliorate attraverso interazioni con i componenti ottimizzate.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
[AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) offre una suite completa per l'analisi dei dati di tracciamento, fornendo una visione olistica delle interazioni con i servizi, monitorando le attività degli utenti e rilevando i problemi di prestazioni. Funzionalità come ServiceLens, X-Ray Insights, X-Ray Analytics e Amazon DevOps Guru permettono di ottenere informazioni fruibili più approfondite derivate dai dati di tracciamento.
### Passaggi dell'implementazione
I seguenti passaggi offrono un approccio strutturato per implementare efficacemente l'analisi dei dati di tracciamento utilizzando i servizi AWS:
1. **Integra AWS X-Ray:** Assicurati che X-Ray sia integrato con le tue applicazioni per acquisire dati di tracciamento.
1. **Analizza le metriche X-Ray:** analizza le metriche derivate dalle tracce di X-Ray, quali latenza, tassi di richiesta, percentuali di errore e distribuzioni dei tempi di risposta utilizzando [la mappa dei servizi](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-servicemap.html#xray-console-servicemap-view) per monitorare l'integrità delle applicazioni.
1. **Usa ServiceLens:** sfrutta la [mappa di ServiceLens](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/servicelens_service_map.html) per una maggiore osservabilità dei tuoi servizi e applicazioni. Ciò consente la visualizzazione integrata di tracce, metriche, log, allarmi e altre informazioni correlate all'integrità.
1. **Abilita X-Ray Insights:**
1. Attiva [X-Ray Insights](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-insights.html) per il rilevamento automatico delle anomalie nelle tracce.
1. Esamina le informazioni dettagliate per individuare i modelli e determinare le cause ultime, come l'aumento dei tassi di errore o delle latenze.
1. Consulta la cronologia delle informazioni dettagliate per un'analisi cronologica dei problemi rilevati.
1. **Usa X-Ray Analytics:** [X-Ray Analytics](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-analytics.html) consente di esplorare a fondo i dati di tracciamento, individuare modelli ed estrarre informazioni dettagliate.
1. **Usa i gruppi inX-Ray:** crea gruppi X-Ray per filtrare le tracce in base a criteri come l'elevata latenza, per un'analisi più mirata.
1. **Incorpora Amazon DevOps Guru:** Integra [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/) per trarre vantaggio dai modelli di machine learning che individuano le anomalie operative nelle tracce.
1. **Usa CloudWatch Synthetics:** utilizza [CloudWatch Synthetics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries_tracing.html) per creare canary per il monitoraggio continuo degli endpoint e dei flussi di lavoro. Questi canary possono integrarsi con X-Ray per fornire dati di tracciamento per un'analisi approfondita delle applicazioni testate.
1. **Usa Real User Monitoring (RUM):** con [AWS X-Ray e CloudWatch RUM](https://docs.aws.amazon.com/xray/latest/devguide/xray-services-RUM.html)è possibile analizzare ed eseguire il debug del percorso della richiesta a partire dagli utenti finali dell'applicazione tramite servizi AWS gestiti a valle. Ciò ti aiuta a identificare le tendenze e gli errori di latenza che hanno un impatto sugli utenti.
1. **Esegui correlazioni con i log:** esegui correlazioni [tra i dati di tracciamento e i relativi log](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/servicelens_troubleshooting.html#servicelens_troubleshooting_Nologs) all'interno della vista tracce di X-Ray per una prospettiva granulare sul comportamento delle applicazioni. Ciò consente di visualizzare gli eventi di log associati direttamente alle transazioni tracciate.
**Livello di impegno per il piano di implementazione:** medio.
## Risorse
**Best practice correlate:**
+ [OPS08-BP01 Analisi delle metriche del carico di lavoro](ops_workload_observability_analyze_workload_metrics.md)
+ [OPS08-BP02 Analizza i log relativi ai carichi di lavoro](ops_workload_observability_analyze_workload_logs.md)
**Documenti correlati:**
+ [ Using ServiceLens to Monitor Application Health ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ServiceLens.html)
+ [ Exploring Trace Data with X-Ray Analytics ](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-analytics.html)
+ [ Detecting Anomalies in Traces with X-Ray Insights ](https://docs.aws.amazon.com/xray/latest/devguide/xray-insights.html)
+ [ Continuous Monitoring with CloudWatch Synthetics ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
**Video correlati:**
+ [ Analyze and Debug Applications Using Amazon CloudWatch Synthetics and AWS X-Ray](https://www.youtube.com/watch?v=s2WvaV2eDO4)
+ [ Use AWS X-Ray Insights ](https://www.youtube.com/watch?v=tl8OWHl6jxw)
**Esempi correlati:**
+ [ One Observability Workshop ](https://catalog.workshops.aws/observability/en-US/intro)
+ [ Implementing X-Ray with AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/services-xray.html)
+ [ CloudWatch Synthetics Canary Templates ](https://github.com/aws-samples/cloudwatch-synthetics-canary-terraform)
# OPS08-BP04 Creare avvisi fruibili
Rilevare e rispondere tempestivamente alle deviazioni di comportamento dell'applicazione è fondamentale. È importante riconoscere quando i risultati basati sugli indicatori chiave di prestazione (KPI) sono a rischio o quando si verificano anomalie impreviste. Basare gli avvisi sui KPI garantisce che i segnali ricevuti siano direttamente correlati all'impatto aziendale od operativo. Questo approccio verso avvisi fruibili promuove risposte proattive e aiuta a mantenere le prestazioni e l'affidabilità del sistema.
**Risultato desiderato:** Si ricevono avvisi tempestivi, pertinenti e fruibili per l'identificazione e la mitigazione rapida di potenziali problemi, soprattutto quando i risultati dei KPI sono a rischio.
**Anti-pattern comuni:**
+ Impostazione di troppi avvisi non critici, con conseguente affaticamento da avvisi ("alert fatigue").
+ Non viene data priorità agli avvisi in base ai KPI, il che rende difficile comprendere l'impatto dei problemi sull'azienda.
+ Non affrontare le cause profonde porta a ricevere avvisi ripetuti per lo stesso problema.
**Vantaggi dell'adozione di questa best practice:**
+ Riduzione dell'affaticamento da avvisi ("alert fatigue") concentrandosi su avvisi pertinenti e fruibili.
+ Maggiore operatività e affidabilità del sistema grazie al rilevamento e alla mitigazione proattiva dei problemi.
+ Migliore collaborazione tra team e risoluzione più rapida dei problemi grazie all'integrazione con i più diffusi strumenti di avviso e comunicazione.
**Livello di rischio associato se questa best practice non fosse adottata:** alto
## Guida all'implementazione
Per creare un meccanismo di avviso efficace, è fondamentale utilizzare metriche, log e dati di tracciamento che segnalino quando i risultati basati sui KPI sono a rischio o vengono rilevate anomalie.
### Passaggi dell'implementazione
1. **Definisci gli indicatori chiave di prestazione (KPI):** identifica i KPI della tua applicazione. Gli avvisi devono essere correlati a questi KPI per riflettere accuratamente l'impatto aziendale.
1. **Implementa il rilevamento delle anomalie:**
+ **Utilizza AWS Cost Anomaly Detection:** Configura [AWS Cost Anomaly Detection](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html) per rilevare automaticamente schemi insoliti, garantendo che gli avvisi vengano generati solo per anomalie autentiche.
+ **Utilizza X-Ray Insights:**
1. Configura [X-Ray Insights](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-insights.html) per rilevare anomalie nei dati di tracciamento.
1. Configura [notifiche per X-Ray Insights](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-insights.html#xray-console-insight-notifications) per ricevere avvisi quando si rilevano problemi.
+ **Esegui l'integrazione conDevOps Guru:**
1. sfrutta [Amazon DevOps Guru](https://aws.amazon.com/devops-guru/) e le sue capacità di machine learning nel rilevare anomalie operative con i dati esistenti.
1. Passa alle [impostazioni di notifica](https://docs.aws.amazon.com/devops-guru/latest/userguide/update-notifications.html#navigate-to-notification-settings) in DevOps Guru per impostare avvisi di anomalie.
1. **Implementa avvisi fruibili:** progetta avvisi che forniscano informazioni adeguate per intraprendere un'azione immediata.
1. **Riduci l'affaticamento da avvisi:** riduci al minimo gli avvisi non critici. Sovraccaricare i team con numerosi avvisi insignificanti può portare a trascurare problemi critici e a ridurre l'efficacia complessiva del meccanismo di avviso.
1. **Configura allarmi compositi:** utilizza [gli allarmi compositi di Amazon CloudWatch](https://aws.amazon.com/blogs/mt/improve-monitoring-efficiency-using-amazon-cloudwatch-composite-alarms-2/) per raggruppare più allarmi.
1. **Esegui l'integrazione con strumenti di avviso:** incorpora strumenti come [Ops Genie](https://www.atlassian.com/software/opsgenie) e [PagerDuty](https://www.pagerduty.com/).
1. **Integra Amazon Q Developer in chat applications** Integra [Amazon Q Developer in chat applications](https://aws.amazon.com/chatbot/)per inoltrare avvisi a Chime, Microsoft Teams e Slack.
1. **Avviso basato sui log:** utilizza [filtri di metriche per log](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) in CloudWatch per creare allarmi basati su eventi di log specifici.
1. **Revisiona e itera:** riesamina e ottimizza regolarmente le configurazioni degli avvisi.
**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)
+ [OPS04-BP05 Implementazione del tracciamento distribuito](ops_observability_dist_trace.md)
+ [OPS08-BP01 Analisi delle metriche del carico di lavoro](ops_workload_observability_analyze_workload_metrics.md)
+ [OPS08-BP02 Analizza i log relativi ai carichi di lavoro](ops_workload_observability_analyze_workload_logs.md)
+ [OPS08-BP03 Analisi delle tracce del carico di lavoro](ops_workload_observability_analyze_workload_traces.md)
**Documenti correlati:**
+ [ Utilizzo degli allarmi di Amazon CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [ Create a composite alarm ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Composite_Alarm.html)
+ [ Create a CloudWatch alarm based on anomaly detection ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Create_Anomaly_Detection_Alarm.html)
+ [ DevOps Guru Notifications ](https://docs.aws.amazon.com/devops-guru/latest/userguide/update-notifications.html)
+ [ X-Ray Insights notifications ](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-insights.html#xray-console-insight-notifications)
+ [ Monitora, gestisci e risolvi i problemi delle tue risorse AWS con ChatOps interattive ](https://aws.amazon.com/chatbot/)
+ [ Amazon CloudWatch Integration Guide \$1 PagerDuty ](https://support.pagerduty.com/docs/amazon-cloudwatch-integration-guide)
+ [ Integrate OpsGenie with Amazon CloudWatch ](https://support.atlassian.com/opsgenie/docs/integrate-opsgenie-with-amazon-cloudwatch/)
**Video correlati:**
+ [ Create Composite Alarms in Amazon CloudWatch ](https://www.youtube.com/watch?v=0LMQ-Mu-ZCY)
+ [ Amazon Q Developer in chat applications Overview ](https://www.youtube.com/watch?v=0jUSEfHbTYk)
+ [AWS on Air ft. Mutative Commands in Amazon Q Developer in chat applications ](https://www.youtube.com/watch?v=u2pkw2vxrtk)
**Esempi correlati:**
+ [ Alarms, incident management, and remediation in the cloud with Amazon CloudWatch ](https://aws.amazon.com/blogs/mt/alarms-incident-management-and-remediation-in-the-cloud-with-amazon-cloudwatch/)
+ [ Tutorial: Creating an Amazon EventBridge rule that sends notifications to Amazon Q Developer in chat applications ](https://docs.aws.amazon.com/chatbot/latest/adminguide/create-eventbridge-rule.html)
+ [ One Observability Workshop ](https://catalog.workshops.aws/observability/en-US/intro)
# OPS08-BP05 Creare dashboard
Le dashboard rappresentano la visualizzazione incentrata sull'utente dei dati di telemetria dei carichi di lavoro. Sebbene forniscano un'interfaccia visiva fondamentale, non dovrebbero sostituire i meccanismi di allarme, ma integrarli. Se realizzate con cura, sono in grado di fornire approfondimenti rapidi sullo stato e sulle prestazioni del sistema e possono informare gli stakeholder in tempo reale riguardo ai risultati aziendali e all'impatto dei problemi.
**Risultato desiderato:** Informazioni chiare e fruibili sullo stato del sistema e dell'azienda attraverso rappresentazioni visive.
**Anti-pattern comuni:**
+ Dashboard eccessivamente complicate con troppe metriche.
+ Affidarsi a dashboard senza avvisi per il rilevamento delle anomalie.
+ Non aggiornare le dashboard man mano che i carichi di lavoro si evolvono.
**Vantaggi dell'adozione di questa best practice:**
+ Visibilità immediata delle metriche e dei KPI critici di sistema.
+ Miglioramento della comunicazione e della comprensione con gli stakeholder.
+ Informazioni dettagliate rapide sull'impatto dei problemi operativi.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
**Dashboard incentrate sul business**
Le dashboard personalizzate in base ai KPI aziendali coinvolgono una gamma più ampia di stakeholder. Anche se queste persone potrebbero non essere interessate alle metriche di sistema, desiderano comprendere le implicazioni aziendali di questi numeri. Una dashboard incentrata sul business garantisce che tutte le metriche tecniche e operative monitorate e analizzate siano allineate con gli obiettivi aziendali generali. Questo allineamento fornisce chiarezza, garantendo che tutti siano sulla stessa lunghezza d'onda per quanto riguarda ciò che è essenziale e ciò che non lo è. Inoltre, le dashboard che mettono in evidenza i KPI aziendali tendono ad essere più fruibili. Gli stakeholder possono comprendere rapidamente lo stato delle operazioni, le aree che richiedono attenzione e il potenziale impatto sui risultati aziendali.
Con questo in mente, al momento di creare una dashboard, assicurati che ci sia un equilibrio tra metriche tecniche e KPI aziendali. Entrambi sono fondamentali, ma si rivolgono a un pubblico diverso. Idealmente, dovresti disporre di dashboard che forniscano una visione olistica dello stato e delle prestazioni del sistema, mettendo in evidenza al contempo i principali risultati aziendali e le loro implicazioni.
Le dashboard di Amazon CloudWatch sono home page personalizzabili nella console CloudWatch che puoi utilizzare per monitorare le tue risorse in un'unica visualizzazione, anche quelle distribuite tra Regioni AWS e account diversi.
### Passaggi dell'implementazione
1. **Crea una dashboard di base:** [crea una nuova dashboard in CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create_dashboard.html)assegnandole un nome descrittivo.
1. **Usa i widget Markdown:** prima di iniziare a lavorare con le metriche, usa [widget Markdown](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/add_remove_text_dashboard.html) per aggiungere un contesto testuale nella parte superiore della dashboard. Esso dovrebbe specificare cosa riguarda la dashboard, qual è l'importanza delle metriche rappresentate e può contenere anche link ad altri dashboard e strumenti di risoluzione dei problemi.
1. **Crea variabili della dashboard:** [incorpora le variabili della dashboard](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_dashboard_variables.html) ove appropriato per consentire una visualizzazione dinamica e flessibile.
1. **Crea widget relativi alle metriche:** [aggiungi widget relativi alle metriche](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create-and-work-with-widgets.html) per visualizzare varie metriche emesse dall'applicazione e personalizza questi widget in modo che rappresentino efficacemente lo stato del sistema e i risultati aziendali.
1. **Richieste di informazioni sui log:** Utilizza [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_ExportQueryResults.html) per ricavare metriche utilizzabili dai log e visualizzare queste informazioni sulla tua dashboard.
1. **Imposta allarmi:** integra [avvisi CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/add_remove_alarm_dashboard.html) nella tua dashboard per una rapida visualizzazione di tutte le metriche che superano le soglie prestabilite.
1. **Usa Contributor Insights:** incorpora [Contributor Insights di CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ContributorInsights-ViewReports.html) per analizzare i campi ad alta cardinalità e comprendere meglio i principali fattori di contribuzione della tua risorsa.
1. **Progetta widget personalizzati:** per esigenze specifiche non soddisfatte dai widget standard, valuta la possibilità di creare [widget personalizzati](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/add_custom_widget_dashboard.html). Questi possono attingere da varie origini dati o rappresentare i dati in modi unici.
1. **Itera e perfeziona:** man mano che la tua applicazione si evolve, riesamina regolarmente la dashboard per assicurarne la pertinenza.
## Risorse
**Best practice correlate:**
+ [OPS04-BP01 Identificazione degli indicatori chiave di prestazione](ops_observability_identify_kpis.md)
+ [OPS08-BP01 Analisi delle metriche del carico di lavoro](ops_workload_observability_analyze_workload_metrics.md)
+ [OPS08-BP02 Analizza i log relativi ai carichi di lavoro](ops_workload_observability_analyze_workload_logs.md)
+ [OPS08-BP03 Analisi delle tracce del carico di lavoro](ops_workload_observability_analyze_workload_traces.md)
+ [OPS08-BP04 Creare avvisi fruibili](ops_workload_observability_create_alerts.md)
**Documenti correlati:**
+ [ Creazione di pannelli di controllo per visibilità operativa ](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/)
+ [ Utilizzo dei pannelli di controllo Amazon CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
**Video correlati:**
+ [ Create Cross Account & Cross Region CloudWatch Dashboards ](https://www.youtube.com/watch?v=eIUZdaqColg)
+ [AWS re:Invent 2021 - Gain enterprise visibility with Cloud AWS operation dashboards ](https://www.youtube.com/watch?v=NfMpYiGwPGo)
**Esempi correlati:**
+ [ One Observability Workshop ](https://catalog.workshops.aws/observability/en-US/intro)
+ [ Monitoraggio delle applicazioni con Amazon CloudWatch ](https://aws.amazon.com/solutions/implementations/application-monitoring-with-cloudwatch/)
# OPS 9. Come fai a comprendere lo stato delle operazioni?
Definisci, acquisisci e analizza i parametri delle operazioni per ottenere visibilità sugli eventi delle operazioni, in modo da intraprendere le azioni appropriate.
**Topics**
+ [OPS09-BP01 Misura gli obiettivi operativi e i KPI con le metriche](ops_operations_health_measure_ops_goals_kpis.md)
+ [OPS09-BP02 Comunicare lo stato e le tendenze per garantire la visibilità delle operazioni](ops_operations_health_communicate_status_trends.md)
+ [OPS09-BP03 Revisione delle metriche operative e assegnazione delle priorità per favorire il miglioramento](ops_operations_health_review_ops_metrics_prioritize_improvement.md)
# OPS09-BP01 Misura gli obiettivi operativi e i KPI con le metriche
Ottieni obiettivi e KPI dalla tua organizzazione che definiscano il successo delle operazioni e stabilisci metriche che li riflettano. Definisci previsioni da utilizzare come riferimento e rivalutale regolarmente. Sviluppa meccanismi per raccogliere queste metriche dai team per la valutazione.
**Risultato desiderato:**
+ Gli obiettivi e i KPI per i team operativi dell'organizzazione sono stati pubblicati e condivisi.
+ Vengono stabilite metriche che riflettono questi KPI. Gli esempi possono includere:
+ Lunghezza della coda dei ticket o età media del ticket
+ Numero di ticket raggruppati per tipo di problema
+ Tempo impiegato per lavorare ai problemi con o senza una procedura operativa standardizzata (SOP)
+ Tempo impiegato per il ripristino dopo un push di codice non riuscito
+ Volume delle chiamate
**Anti-pattern comuni:**
+ Le scadenze di implementazione non vengono rispettate perché gli sviluppatori sono costretti a dedicarsi alle attività di risoluzione dei problemi. I team di sviluppo chiedono più personale, ma non possono quantificarne il numero perché il tempo impiegato non può essere misurato.
+ È stato installato un desk di livello 1 per gestire le chiamate degli utenti. Nel corso del tempo, sono aumentati i carichi di lavoro ma non il personale assegnato al desk di livello 1. La soddisfazione dei clienti ne risente a causa dell'aumento dei tempi di chiamata e di quelli per arrivare a una soluzione, ma il team manageriale non vede indicatori di questo problema e non intraprende azioni.
+ Un carico di lavoro problematico è stato affidato a un team operativo separato per la gestione. A differenza di altri carichi di lavoro, questo non è accompagnato dalla documentazione e dai runbook adeguati. Pertanto, i team dedicano più tempo alla risoluzione dei problemi e alla gestione degli errori. Tuttavia, non esistono metriche che lo documentino, il che rende difficile comprendere le responsabilità.
**Vantaggi dell'adozione di questa best practice:** Quando il monitoraggio del carico di lavoro mostra lo stato delle nostre applicazioni e servizi, i team operativi dedicati al monitoraggio forniscono ai proprietari informazioni dettagliate sui cambiamenti avvenuti tra i consumatori di tali carichi di lavoro, come le mutate esigenze aziendali. Misura l'efficacia di questi team e valutali rispetto agli obiettivi aziendali creando metriche in grado di riflettere lo stato delle operazioni. Le metriche possono evidenziare problemi relativi al supporto o identificare quando si verificano deviazioni rispetto a un obiettivo di livello di servizio.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
Fissa un appuntamento per parlare con i leader aziendali e gli stakeholder per stabilire gli obiettivi generali del servizio. Stabilisci quali devono essere i compiti dei vari team operativi e quali sfide potrebbero affrontare. Utilizza queste informazioni per un'attività di brainstorming sugli indicatori chiave di prestazione (KPI) che potrebbero riflettere questi obiettivi operativi. Questi potrebbero essere la soddisfazione del cliente, il tempo trascorso dall'ideazione della funzionalità alla sua implementazione, il tempo medio di risoluzione dei problemi e altro.
Partendo dai KPI, identifica le metriche e le origini di dati che potrebbero rispecchiare al meglio questi obiettivi. La soddisfazione del cliente può essere una combinazione di diverse metriche, come i tempi di attesa o di risposta durante le chiamate, i punteggi di soddisfazione e i tipi di problemi sollevati. I tempi di implementazione possono essere la somma del tempo necessario per il test e l'implementazione, con l'aggiunta di eventuali correzioni post-implementazione. Le statistiche che mostrano il tempo dedicato a diversi tipi di problemi (o il numero di tali problemi) possono fornire indicazioni su dove è necessario un impegno mirato.
## Risorse
**Documenti correlati:**
+ [ Quick - Using KPIs ](https://docs.aws.amazon.com/quicksight/latest/user/kpi.html)
+ [ Amazon CloudWatch - Using Metrics ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
+ [ Creazione di pannelli di controllo ](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/)
+ [ How to track your cost optimization KPIs with KPI Dashboard ](https://aws.amazon.com/blogs/aws-cloud-financial-management/how-to-track-your-cost-optimization-kpis-with-the-kpi-dashboard/)
# OPS09-BP02 Comunicare lo stato e le tendenze per garantire la visibilità delle operazioni
Conoscere lo stato delle operazioni e la direzione verso la quale tendono a muoversi è necessario per identificare quando i risultati possono essere a rischio, se è possibile supportare o meno carichi di lavoro aggiuntivi o per verificare gli effetti che le modifiche hanno avuto sui team. Durante gli eventi operativi, disporre di pagine di stato a cui gli utenti e i team operativi possono fare riferimento per ottenere informazioni può ridurre la pressione sui canali di comunicazione e diffondere informazioni in modo proattivo.
**Risultato desiderato:**
+ I responsabili delle operazioni hanno a disposizione informazioni dettagliate per conoscere il volume di chiamate che i loro team stanno gestendo e quali operazioni sono in corso, ad esempio le implementazioni.
+ Quando si verificano eventi che possono compromettere le normali operazioni, vengono inviati avvisi agli stakeholder e alle comunità di utenti.
+ Quando ricevono un avviso o si verifica un problema, la leadership dell'organizzazione e gli stakeholder possono controllare una pagina di stato e ottenere informazioni relative a un evento operativo, come punti di contatto, informazioni sui ticket e tempi di ripristino stimati.
+ I report messi a disposizione della leadership e degli stakeholder contengono statistiche operative come il volume delle chiamate in un periodo di tempo, i punteggi di soddisfazione degli utenti, il numero e l'età di ticket in sospeso.
**Anti-pattern comuni:**
+ Se un carico di lavoro si interrompe, il servizio diventa non disponibile. Il volume delle chiamate aumenta quando gli utenti chiedono di sapere cosa sta succedendo. Le richieste dei manager di sapere chi sta risolvendo un problema comportano un ulteriore aumento del volume. Vari team operativi duplicano gli sforzi mentre effettuano indagini.
+ La volontà di acquisire una nuova capacità porta a riassegnare gli sforzi di alcuni membri del personale verso compiti di tipo tecnico. Non viene fornito alcun backfill e i tempi di risoluzione dei problemi aumentano. Queste informazioni non vengono acquisite e i manager vengono a conoscenza del problema solo dopo diverse settimane o quando viene ricevuto il feedback negativo degli utenti.
**Vantaggi dell'adozione di questa best practice:** A volte, durante eventi operativi che hanno un impatto sull'azienda, si spreca molto tempo ed energia in query per ottenere informazioni da vari team nel tentativo di comprendere la situazione. Grazie alla creazione di pagine di stato e dashboard ampiamente diffuse, gli stakeholder possono ottenere rapidamente informazioni, ad esempio, se è stato rilevato o meno un problema, chi è a capo delle attività di risoluzione o quando è previsto un ritorno alle normali operazioni. Ciò permette ai membri del team di avere più tempo per affrontare i problemi, perché non devono dilungarsi a comunicare lo stato agli altri.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
Crea dashboard che mostrino le metriche fondamentali attuali per i tuoi team operativi e rendile facilmente accessibili ai responsabili operativi e ai manager.
Crea pagine di stato aggiornabili rapidamente per diffondere informazioni relative a un incidente o un evento, come chi ne è responsabile e chi coordina la risposta. Condividi in questa pagina eventuali passaggi o soluzioni alternative che gli utenti dovrebbero prendere in considerazione e divulga ampiamente la posizione della pagina. Incoraggia gli utenti a controllare prima questa pagina quando si trovano di fronte a un problema sconosciuto.
Raccogli e fornisci report che mostrino lo stato di salute delle operazioni nel tempo e distribuiscili a leader e responsabili decisionali per illustrare il lavoro dei team operativi e le loro sfide ed esigenze.
Condividi con i team le metriche e i report che meglio riflettono gli obiettivi e i KPI e come hanno influito nel guidare il cambiamento. Dedica del tempo a queste attività per aumentare l'importanza delle operazioni nei e tra i team.
## Risorse
**Documenti correlati:**
+ [ Measure Progress ](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-cloud-operating-model/measure-progress.html)
+ [ Creazione di pannelli di controllo per visibilità operativa ](https://aws.amazon.com/builders-library/building-dashboards-for-operational-visibility/)
**Soluzioni correlate:**
+ [ Data Operations ](https://aws.amazon.com/solutions/app-development/data-operations)
# OPS09-BP03 Revisione delle metriche operative e assegnazione delle priorità per favorire il miglioramento
L'assegnazione di tempo e risorse per la revisione dello stato delle operazioni garantisce che servire il settore d'attività rimanga una priorità quotidiana. Effettua regolarmente riunioni con i responsabili operativi e gli stakeholder per rivedere le metriche, riconfermare o modificare traguardi e obiettivi e dare priorità ai miglioramenti.
**Risultato desiderato:**
+ I responsabili operativi e il personale si incontrano regolarmente per esaminare le metriche in un determinato periodo di riferimento. Si comunicano le sfide, si celebrano le vittorie e si condividono le lezioni apprese.
+ Gli stakeholder e i leader aziendali vengono regolarmente informati sullo stato delle operazioni e sollecitati a fornire input su obiettivi, KPI e iniziative future. Vengono discusse e contestualizzate le scelte tra erogazione dei servizi, operazioni e manutenzione.
**Anti-pattern comuni:**
+ Viene lanciato un nuovo prodotto, ma i team operativi di livello 1 e 2 non sono adeguatamente formati per fornire supporto oppure non dispongono di personale aggiuntivo. I leader non vedono le metriche che mostrano la diminuzione dei tempi di risoluzione dei ticket e l'aumento del volume degli incidenti. Si agisce settimane dopo, quando i numeri delle sottoscrizioni iniziano a diminuire a causa di utenti scontenti che abbandonano la piattaforma.
+ Da molto tempo esiste un processo manuale per eseguire la manutenzione su un carico di lavoro. La volontà di automatizzare, seppur presente, costituiva una priorità bassa data la scarsa importanza del sistema. Nel corso del tempo, tuttavia, l'importanza del sistema è cresciuta e ora i team operativi sono impegnati per la maggior parte del tempo in questi processi manuali. Non sono previste risorse per fornire una maggiore strumentazione ai team operativi oberati dall'aumento dei carichi di lavoro, con rischi di burnout per il personale. La leadership viene a conoscenza del problema una volta che viene segnalato da un membro del personale che lascia l'azienda per un concorrente.
**Vantaggi dell'adozione di questa best practice:** In alcune organizzazioni, può diventare difficile dedicare lo stesso tempo e la stessa attenzione alla fornitura di servizi e a nuovi prodotti od offerte. Quando ciò si verifica, il settore d'attività può risentirne a causa del lento deterioramento del livello di servizio atteso. Questo perché le operazioni non cambiano e non si evolvono di pari passo con la crescita del business e possono diventare presto obsolete. Senza una revisione regolare delle informazioni raccolte dai team operativi, il rischio che l'azienda corre potrebbe diventare visibile solo quando è troppo tardi. Dedicare tempo alla revisione delle metriche e delle procedure insieme al personale operativo e alla leadership, permette di mettere in luce il ruolo cruciale svolto dai team operativi nell'identificare i rischi molto prima che raggiungano livelli critici. I team operativi ottengono una visione migliore dei cambiamenti e delle iniziative aziendali imminenti, il che permette di intraprendere azioni proattive. Grazie alla visibilità delle metriche operative, la leadership è consapevole del ruolo che i team operativi svolgono nel garantire la soddisfazione dei clienti, sia interni che esterni, ed è in grado di valutare meglio le scelte in base alle priorità o di garantire che ci sia sufficiente tempo per modificare e fare evolvere operazioni e risorse attraverso nuove iniziative aziendali e di carico di lavoro.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
Dedica del tempo alla revisione delle metriche operative con gli stakeholder e i team operativi e alla revisione dei dati dei report. Inserisci questi report nel contesto degli scopi e degli obiettivi dell'organizzazione per stabilire se vengono raggiunti. Identifica le cause di ambiguità quando gli obiettivi non sono chiari o possono esserci conflitti tra ciò che viene chiesto e ciò che viene fornito.
Identifica come il tempo, le persone e gli strumenti possono contribuire agli esiti delle operazioni. Stabilisci quali KPI ne verrebbero influenzati e quali devono essere gli obiettivi di successo. Effettua regolarmente una revisione per assicurarti che i team operativi dispongano di risorse sufficienti per supportare il settore d'attività.
## Risorse
**Documenti correlati:**
+ [ Amazon Athena ](https://aws.amazon.com/athena/)
+ [ Documentazione di riferimento su parametri e dimensioni di Amazon CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CW_Support_For_AWS.html)
+ [ Amazon Quick ](https://aws.amazon.com/quicksight/)
+ [AWS Glue](https://aws.amazon.com/glue/)
+ [AWS Glue Data Catalog](https://docs.aws.amazon.com/glue/latest/dg/populate-data-catalog.html)
+ [ Collect metrics and logs from Amazon EC2 instances and on-premises servers with the Amazon CloudWatch Agent ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)
+ [ Utilizzare i parametri Amazon CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/working_with_metrics.html)
# OPS 10. In che modo gestisci gli eventi del carico di lavoro e delle operazioni?
Prepara e convalida le procedure in risposta agli eventi per ridurre al minimo il loro impatto sul tuo carico di lavoro.
**Topics**
+ [OPS10-BP01 Utilizzo di un processo per la gestione di eventi, incidenti e problemi](ops_event_response_event_incident_problem_process.md)
+ [OPS10-BP02 Definizione di un processo per ogni avviso](ops_event_response_process_per_alert.md)
+ [OPS10-BP03 Definizione della priorità degli eventi operativi in base agli effetti sul business](ops_event_response_prioritize_events.md)
+ [OPS10-BP04 Definizione dei percorsi di escalation](ops_event_response_define_escalation_paths.md)
+ [OPS10-BP05 Definizione di un piano di comunicazione con i clienti per le interruzioni](ops_event_response_push_notify.md)
+ [OPS10-BP06 Comunicazione dello stato tramite pannelli di controllo](ops_event_response_dashboards.md)
+ [OPS10-BP07 Automazione delle risposte agli eventi](ops_event_response_auto_event_response.md)
# OPS10-BP01 Utilizzo di un processo per la gestione di eventi, incidenti e problemi
L'organizzazione dispone di processi per gestire eventi, incidenti e problemi. *Gli eventi* sono costituiti da quanto accade nel carico di lavoro che non necessita di un intervento umano. *Gli incidenti* sono invece eventi che richiedono un intervento. *I problemi* sono eventi ricorrenti che richiedono un intervento o che non possono essere risolti. È necessario disporre di processi per ridurre l'impatto degli eventi sull'azienda e accertarsi di reagire in modo tempestivo e appropriato.
Quando nel carico di lavoro si verificano problemi o incidenti, è necessario utilizzare i processi per gestirli. In che modo puoi comunicare lo stato dell'evento alle parti coinvolte? Chi supervisiona la gestione delle risposte? Quali sono gli strumenti da utilizzare per ridurre l'impatto dell'evento? Questi sono solo alcuni esempi delle domande a cui devi rispondere per creare un processo di risposta affidabile.
I processi devono essere documentati in una posizione centralizzata, nonché essere disponibili a chiunque sia coinvolto nel carico di lavoro. Se non è presente un wiki o un archivio di documenti centralizzato, è possibile utilizzare un repository per il controllo delle versioni. In questo modo sarà possibile mantenere aggiornati i piani in modo conforme all'evoluzione dei processi.
I problemi possono essere automatizzati. Il tempo richiesto per la gestione di questo tipo di eventi potrebbe essere altrimenti destinato all'innovazione. Comincia a creare un processo ripetibile per ridurre il più possibile l'impatto del problema. Gradualmente cerca di concentrarti sull'automazione della riduzione o risoluzione del problema sottostante. In questo modo il tempo risparmiato potrà essere dedicato a migliorare il carico di lavoro.
**Risultato desiderato:** l'organizzazione dispone di un processo per gestire eventi, incidenti e problemi. Questi processi sono documentati e archiviati in una posizione centralizzata e vengono aggiornati in base alle modifiche apportate.
**Anti-pattern comuni:**
+ Un incidente si verifica durante il fine settimana e il tecnico di turno non sa cosa fare.
+ Un cliente invia un messaggio e-mail indicando che l'applicazione non è disponibile. Riavvii il server per correggere il problema. Questo incidente si verifica di frequente.
+ Si verifica un incidente e più team si mettono a lavorare in modo indipendente per risolvere il problema.
+ Le implementazioni vengono eseguite nel carico di lavoro senza essere documentate.
**Vantaggi dell'adozione di questa best practice:**
+ Nel carico di lavoro è presente un itinerario di audit degli eventi.
+ Viene ridotto il tempo necessario per il ripristino in seguito a un incidente.
+ I membri dei team riescono a risolvere incidenti e problemi in modo coerente.
+ Durante l'analisi di un incidente, l'approccio è condiviso e più consolidato.
**Livello di rischio associato se questa best practice non fosse adottata:** alto
## Guida all'implementazione
L'implementazione di questa best practice prevede la registrazione degli eventi dei carichi di lavoro. Per la gestione di incidenti e problemi, è necessario ricorrere ai processi. I processi sono documentati, condivisi e aggiornati con frequenza. I problemi vengono identificati, classificati in base alla priorità e corretti.
**Esempio del cliente**
AnyCompany Retail ha dedicato una parte del proprio wiki interno ai processi destinati alla gestione di eventi, incidenti e problemi. Tutti gli eventi vengono inviati ad [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html). I problemi vengono classificati come OpsItems (elementi di lavoro operativi) in [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html) e classificati in base alla loro priorità al fine della loro risoluzione, in modo da ridurre eventuali attività indifferenziate. Quando i processi subiscono variazioni, vengono aggiornati nel wiki interno. Viene utilizzato [Strumento di gestione degli incidenti AWS Systems Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) per gestire gli incidenti e coordinare le attività di riduzione dell'impatto.
## Passaggi dell'implementazione
1. Eventi
+ Tieni traccia degli eventi che si verificano nel carico di lavoro, anche se non è richiesto alcun intervento umano.
+ Collabora con le parti coinvolte a livello di piano di lavoro per redigere un elenco di eventi di cui tenere traccia, ad esempio implementazioni completate o applicazioni di patch riuscite.
+ Puoi utilizzare servizi come [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) oppure [Amazon Simple Notification Service](https://docs.aws.amazon.com/sns/latest/dg/welcome.html) per generare eventi personalizzati per il monitoraggio.
1. Incidenti
+ Per prima cosa, definisci il piano di comunicazione per gli incidenti. Quali parti coinvolte devono essere informate? In che modo le tieni costantemente aggiornate? Chi supervisiona il coordinamento di tutte queste attività? È consigliabile creare un canale di chat per le comunicazioni e il coordinamento.
+ Definisci un percorso di escalation per i team di supporto del carico di lavoro, soprattutto se il team non dispone di turni di rotazione della disponibilità. A seconda del livello di supporto, è possibile segnalare un caso anche mediante il Supporto.
+ Crea un playbook per l'analisi dell'incidente. È necessario includere il piano di comunicazione e, in dettaglio, i passaggi del processo di indagine. Includi il controllo del [Dashboard AWS Health](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html) nel processo di indagine.
+ Documenta il piano di risposta agli incidenti. Comunica il piano di gestione degli incidenti in modo che i clienti esterni siano consapevoli delle regole da seguire e dei comportamenti richiesti previsti. Fornisci formazione ai membri dei team su come utilizzare tale piano di gestione.
+ I clienti possono utilizzare [Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) per configurare e gestire il piano di risposta agli incidenti.
+ I clienti del supporto Enterprise possono richiedere di seguire il [workshop relativo alla gestione degli incidenti](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives) al proprio Technical Account Manager (TAM). Questo workshop guidato consente di verificare il piano di risposta agli incidenti esistente e ti aiuta a individuare eventuali aree da migliorare.
1. Problemi
+ I problemi devono essere identificati e registrati nel sistema ITSM in uso.
+ Identifica tutti i problemi noti ed eseguine una catalogazione in base all'impegno necessario per correggerli e al relativo impatto sul carico di lavoro.
![\[Matrice delle priorità delle operazioni per la catalogazione dei problemi.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/impact-effort-chart.png)
+ Per prima cosa risolvi i problemi caratterizzati dall'impatto più alto e dal minore impegno. Dopodiché, passa alla risoluzione dei problemi che rientrano nel quadrante basso impatto/basso impegno.
+ Puoi utilizzare [Systems Manager OpsCenter](systems-manager/latest/userguide/OpsCenter.html) per identificare i problemi, associarvi runbook e tenerne traccia.
**Livello di impegno per il piano di implementazione:** medio. Devi disporre sia di un processo che degli strumenti per implementare questa best practice. Documenta i processi e rendili disponibili a chiunque sia coinvolto nel carico di lavoro. Aggiornali con frequenza. È disponibile un processo per la gestione e la migrazione o la risoluzione dei problemi.
## Risorse
**Best practice correlate:**
+ [OPS07-BP03 Utilizzo di runbook per eseguire le procedure](ops_ready_to_support_use_runbooks.md): i problemi noti necessitano di un runbook associato in modo tale che le attività di attenuazione dell'impatto siano coerenti.
+ [OPS07-BP04 Utilizzo dei playbook per analizzare i problemi](ops_ready_to_support_use_playbooks.md): gli incidenti devono essere analizzati con il supporto di playbook.
+ [OPS11-BP02 Esecuzione di analisi post-incidente](ops_evolve_ops_perform_rca_process.md): esegui sempre un post-mortem dopo aver eseguito un ripristino in seguito a un incidente.
**Documenti correlati:**
+ [Atlassian - Incident management in the age of DevOps (Atlassian - Gestione degli incidenti nell'era di DevOps)](https://www.atlassian.com/incident-management/devops)
+ [AWS Security Incident Response Guide (Guida alle risposte agli incidenti di sicurezza di AWS)](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+ [Incident Management in the Age of DevOps and SRE (Gestione degli incidenti nell'era di DevOps e SRE)](https://www.infoq.com/presentations/incident-management-devops-sre/)
+ [PagerDuty - What is Incident Management? (PagerDuty - Che cos'è la gestione degli incidenti?)](https://www.pagerduty.com/resources/learn/what-is-incident-management/)
**Video correlati:**
+ [AWS re:Invent 2020: Incident management in a distributed organization (Gestione degli incidenti in un'organizzazione distribuita)](https://www.youtube.com/watch?v=tyS1YDhMVos)
+ [AWS re:Invent 2021 - Building next-gen applications with event-driven architectures (Sviluppo di applicazioni di nuova generazione con architetture basate su eventi)](https://www.youtube.com/watch?v=U5GZNt0iMZY)
+ [AWS Supports You \$1 Exploring the Incident Management Tabletop Exercise (Esplorazione degli esercizi di simulazione relativi alla gestione degli incidenti)](https://www.youtube.com/watch?v=0m8sGDx-pRM)
+ [Strumento di gestione degli incidenti AWS Systems Manager - AWS Virtual Workshops (Workshop virtuali AWS)](https://www.youtube.com/watch?v=KNOc0DxuBSY)
+ [AWS What's Next ft. Incident Manager \$1 AWS Events (Novità di AWS e Incident Manager \$1 Eventi AWS)](https://www.youtube.com/watch?v=uZL-z7cII3k)
**Esempi correlati:**
+ [AWS Management and Governance Tools Workshop - OpsCenter (Workshop sugli strumenti di gestione e governance AWS - OpsCenter)](https://mng.workshop.aws/ssm/capability_hands-on_labs/opscenter.html)
+ [AWS Proactive Services – Incident Management Workshop (Servizi AWS proattivi – Workshop relativo alla gestione degli incidenti)](https://aws.amazon.com/premiumsupport/technology-and-programs/proactive-services/#Operational_Workshops_and_Deep_Dives)
+ [Building an event-driven application with Amazon EventBridge (Sviluppo di un'applicazione basata su eventi con Amazon EventBridge)](https://aws.amazon.com/blogs/compute/building-an-event-driven-application-with-amazon-eventbridge/)
+ [Building event-driven architectures on AWS (Sviluppo di architetture basate su eventi in AWS)](https://catalog.us-east-1.prod.workshops.aws/workshops/63320e83-6abc-493d-83d8-f822584fb3cb/en-US/)
**Servizi correlati:**
+ [Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html)
+ [Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
+ [Dashboard AWS Health](https://docs.aws.amazon.com/health/latest/ug/what-is-aws-health.html)
+ [Strumento di gestione degli incidenti AWS Systems Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html)
+ [AWS Systems Manager OpsCenter](https://docs.aws.amazon.com/systems-manager/latest/userguide/OpsCenter.html)
# OPS10-BP02 Definizione di un processo per ogni avviso
Predisponi una risposta specifica (runbook o playbook), con un proprietario espressamente identificato, per ogni evento per cui viene generato un avviso. Questo consente di rispondere agli eventi operativi in modo rapido ed efficace, evitando che gli eventi che richiedono un'azione vengano oscurati da notifiche meno importanti.
**Anti-pattern comuni:**
+ Il sistema di monitoraggio presenta un flusso di connessioni approvate insieme ad altri messaggi. Il volume di messaggi è così grande che vengono ignorati dei messaggi di errore periodici che richiedono il tuo intervento.
+ Ricevi un avviso che informa che il sito Web è inattivo. Non esiste un processo definito per quando ciò si verifica. Sei costretto ad adottare un approccio ad hoc per diagnosticare e risolvere il problema. Lo sviluppo di questo processo durante l'esecuzione prolunga il tempo di ripristino.
**Vantaggi dell'adozione di questa best practice:** Generando avvisi solo quando è necessaria un'operazione, eviti che gli avvisi di basso valore nascondano quelli più importanti. Creando un processo per ogni avviso che richiede un'azione, puoi attivare una risposta coerente e immediata agli eventi nel tuo ambiente.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Un processo per ogni avviso: a ogni evento per cui viene generato un avviso deve corrispondere una risposta specifica (runbook o playbook) con un responsabile specificatamente identificato (ad esempio, una persona, un team o un ruolo) a cui spetta il compito di completare correttamente l'azione. L'esecuzione della risposta può essere automatizzata o condotta da un altro team, ma il proprietario è tenuto ad assicurarsi che il processo produca i risultati previsti. Questi processi consentono di rispondere agli eventi operativi in modo rapido ed efficace, evitando che gli eventi che richiedono un'azione vengano oscurati da notifiche meno importanti. Ad esempio, è possibile applicare l'auto scaling per ridimensionare un front-end Web, ma il team operativo può essere tenuto a garantire che le regole e i limiti di auto scaling siano appropriati per le esigenze del carico di lavoro.
## Risorse
**Documenti correlati:**
+ [Funzionalità di Amazon CloudWatch](https://aws.amazon.com/cloudwatch/features/)
+ [Che cos'è Amazon CloudWatch Events?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
**Video correlati:**
+ [Creazione di un piano di monitoraggio](https://www.youtube.com/watch?v=OMmiGETJpfU)
# OPS10-BP03 Definizione della priorità degli eventi operativi in base agli effetti sul business
Quando più eventi richiedono un intervento, assicurati che quelli più significativi per il business vengano affrontati per primi. Sono esempi di effetti il decesso o l'infortunio, le perdite finanziarie o i danni alla reputazione o alla fiducia.
**Anti-pattern comuni:**
+ Ricevi una richiesta di supporto per aggiungere una configurazione della stampante per un utente. Durante la risoluzione del problema, ricevi una richiesta di supporto per sito di vendita al dettaglio non disponibile. Dopo aver completato la configurazione della stampante per l'utente, inizi a lavorare sul problema del sito Web.
+ Ti viene segnalato che il sito Web di vendita al dettaglio e il sistema delle buste paga non sono disponibili. Non sai quale deve avere la priorità.
**Vantaggi dell'adozione di questa best practice:** Dare priorità alle risposte agli incidenti che determinano il maggiore impatto sull'azienda consente di gestire tale impatto.
**Livello di rischio associato se questa best practice non fosse adottata:** Medio
## Guida all'implementazione
+ Definizione della priorità degli eventi operativi in base agli effetti sul business: assicurati che quando più eventi richiedono un intervento, quelli più significativi per l'azienda vengano affrontati per primi. Sono esempi di effetti il decesso o l'infortunio, le perdite finanziarie, le violazioni alle normative o i danni alla reputazione o alla fiducia.
# OPS10-BP04 Definizione dei percorsi di escalation
Definisci percorsi di escalation nei tuoi runbook e playbook, compresi gli eventi che attivano l'escalation e le procedure di escalation. In particolare, identifica i proprietari per ogni azione per assicurare risposte rapide ed efficaci agli eventi operativi.
Stabilisci in quali circostanze serve una decisione umana prima che venga intrapresa un'azione. Collabora con i responsabili delle decisioni affinché questa decisione venga presa in anticipo e l'operazione sia preapprovata, in modo che la MTTR non si prolunghi in attesa di una risposta.
**Anti-pattern comuni:**
+ Il sito di vendita al dettaglio non è disponibile. Il runbook per il ripristino del sito non è chiaramente comprensibile. Inizi a chiamare i colleghi sperando che qualcuno possa aiutarti.
+ Ricevi un caso di supporto per un'applicazione irraggiungibile. Non disponi delle autorizzazioni per amministrare il sistema. Non sai a chi compete questo compito. Tenti di contattare il proprietario del sistema che ha aperto il caso ma non ricevi risposta. Né tu né i tuoi colleghi sapete chi bisogna contattare per il sistema.
**Vantaggi dell'adozione di questa best practice:** Definendo le escalation e i trigger e le procedure per l'escalation, abiliti l'aggiunta sistematica di risorse a un incidente con una rapidità adeguata all'impatto.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Definizione di percorsi di escalation: definisci percorsi di escalation nei tuoi runbook e playbook, compresi gli eventi che attivano l'escalation e le relative procedure. Ad esempio, l'escalation di un problema dai tecnici del supporto ai tecnici del supporto senior quando i runbook non riescono a risolvere il problema o quando è trascorso un determinato periodo di tempo. Un altro esempio di percorso di escalation appropriato è l'inoltro dai tecnici del supporto senior al team di sviluppo per un carico di lavoro quando i playbook non sono in grado di identificare un percorso di correzione o quando è trascorso un determinato periodo di tempo. In particolare, identifica i proprietari per ogni azione per assicurare risposte rapide ed efficaci agli eventi operativi. Le escalation possono includere terze parti, ad esempio un provider di connettività di rete o un produttore di software. Possono anche includere i responsabili decisionali autorizzati identificati per i sistemi interessati.
# OPS10-BP05 Definizione di un piano di comunicazione con i clienti per le interruzioni
Definisci e testa un piano di comunicazione affidabile per le interruzioni del sistema in modo da tenere informati clienti e stakeholder durante le interruzioni. Comunica direttamente con gli utenti sia quando i servizi che usano subiscono un'interruzione sia quando tornano alla normalità.
**Risultato desiderato:**
+ Presenza di un piano di comunicazione per situazioni che includono dalla manutenzione pianificata a errori imprevisti di grande entità, inclusa l'attivazione di piani di ripristino di emergenza.
+ Disponibilità di informazioni chiare e trasparenti sui problemi relativi ai sistemi, in modo che i clienti non siano costretti a congetture sulle prestazioni dei propri sistemi.
+ Uso di pagine di stato e messaggi di errore personalizzati per ridurre i picchi nelle richieste all'help desk e tenere informati gli utenti.
+ Esecuzione regolare di test del piano di comunicazione per verificarne il funzionamento nel modo previsto quando si verifica realmente un'interruzione.
**Anti-pattern comuni:**
+ Si verifica un'interruzione del carico di lavoro, ma non è disponibile un piano di comunicazione. Gli utenti sovraccaricano di richieste il sistema di gestione dei ticket di assistenza perché non hanno informazioni sull'interruzione.
+ Durante un'interruzione, invii una notifica tramite e-mail agli utenti. Il messaggio non contiene informazioni sulle tempistiche per il ripristino del servizio e gli utenti non possono pianificare le proprie attività durante l'interruzione.
+ Esiste un piano di comunicazione per le interruzioni, ma non è mai stato testato. Si verifica un'interruzione e il piano di comunicazione non riesce perché non include un passaggio critico che avrebbe potuto essere identificato tramite test.
+ Durante un'interruzione, invii una notifica agli utenti con troppi dettagli tecnici e informazioni rispetto a quanto indicato nell'accordo di non divulgazione AWS.
**Vantaggi dell'adozione di questa best practice:**
+ Il mantenimento della comunicazione durante le interruzioni fornisce ai clienti la visibilità sullo stato dei problemi e sul tempo stimato per la risoluzione.
+ Lo sviluppo di un piano di comunicazione ben definito permette di verificare che clienti e utenti finali vengano correttamente informati in modo da poter adottare i passaggi aggiuntivi necessari per attenuare l'impatto delle interruzioni.
+ Con comunicazioni appropriate e una maggiore consapevolezza delle interruzioni pianificate e impreviste, puoi migliorare la soddisfazione dei clienti, limitare le reazioni involontarie e favorire la fidelizzazione dei clienti.
+ Comunicazioni tempestive e trasparenti sulle interruzioni del sistema creano la fiducia necessaria per mantenere le relazioni con i clienti.
+ Una strategia di comunicazione collaudata durante un'interruzione o una crisi riduce congetture e dicerie che potrebbero ostacolare la tua capacità di ripristinare il sistema.
**Livello di rischio associato alla mancata adozione di questa best practice:** medio
## Guida all'implementazione
I piani di comunicazione che tengono informati i clienti durante le interruzioni sono olistici e includono più interfacce, tra cui le pagine di errore destinate ai clienti, i messaggi di errore delle API personalizzati, i banner sullo stato del sistema e le pagine di stato sull'integrità. Se il sistema include utenti registrati, puoi comunicare attraverso canali di messaggistica come e-mail, SMS o notifiche push per inviare messaggi con contenuti personalizzati ai clienti.
**Strumenti di comunicazione con i clienti**
Come prima linea di difesa, le applicazioni Web e per dispositivi mobili devono fornire messaggi di errore intuitivi e informativi durante un'interruzione ed essere in grado di reindirizzare il traffico a una pagina di stato. [Amazon CloudFront](https://aws.amazon.com/cloudfront/) è una rete di distribuzione di contenuti (CDN) completamente gestita che include funzionalità per definire e distribuire contenuti personalizzati sugli errori. Le pagine di errore personalizzate in CloudFront sono un ottimo tipo iniziale di messaggistica ai clienti per le interruzioni a livello di componente. CloudFront può anche semplificare la gestione e l'attivazione di una pagina di stato per intercettare tutte le richieste durante interruzioni pianificate o impreviste.
Messaggi di errore personalizzati sulle API possono aiutare a identificare e ridurre l'impatto quando le interruzioni sono separate in servizi dedicati. [Amazon API Gateway](https://aws.amazon.com/api-gateway/) permette di configurare risposte personalizzate per le REST API. In questo modo, puoi fornire messaggi chiari e significativi agli utenti di API quando API Gateway non è in grado di raggiungere i servizi back-end. Puoi usare messaggi personalizzati anche per supportare contenuti e notifiche dei banner sulle interruzioni quando una determinata funzionalità del sistema risulta danneggiata a causa di interruzioni a livello di servizio.
La messaggistica diretta è il tipo più personalizzato di messaggistica per i clienti. [Amazon Pinpoint](https://aws.amazon.com/pinpoint/) è un servizio gestito per comunicazioni multicanale scalabili. Amazon Pinpoint ti permette di creare campagne per la trasmissione di messaggi a tutta la clientela interessata tramite SMS, e-mail, messaggi vocali, notifiche push o canali personalizzati da te definiti. Quando gestisci la messaggistica con Amazon Pinpoint, le campagne di messaggi sono ben definite, verificabili e possono essere applicate in modo intelligente ai segmenti di clientela desiderati. Una volta create, le campagne possono essere pianificate o attivate da eventi e testate facilmente.
**Esempio del cliente**
Quando il carico di lavoro risulta danneggiato, AnyCompany Retail invia una notifica tramite e-mail ai propri utenti. L'e-mail specifica le funzionalità aziendali interessate e fornisce una stima realistica delle tempistiche per il ripristino del servizio. Inoltre, l'azienda ha una pagina di stato che mostra informazioni in tempo reali sull'integrità del carico di lavoro. Il piano di comunicazione viene testato in un ambiente di sviluppo due volte all'anno per convalidarne l'efficienza.
**Passaggi dell'implementazione**
1. Determina i canali di comunicazione per la strategia di messaggistica. Tieni conto degli aspetti architetturali dell'applicazione e determina la migliore strategia per fornire feedback ai clienti. Possono essere incluse una o più delle strategie definite per le linee guida, tra cui pagine di errore e di stato, risposte personalizzate agli errori delle API o messaggistica diretta.
1. Progetta pagine di stato per l'applicazione. Se hai deciso che le pagine personalizzate di errore o di stato sono l'opzione più adatta per i clienti, dovrai progettarne il contenuto e la messaggistica. Le pagine di errore spiegano agli utenti perché un'applicazione non è disponibile, quando potrebbe tornare disponibile e che cosa possono fare gli utenti nel frattempo. Se l'applicazione usa Amazon CloudFront, puoi distribuire [risposte personalizzate agli errori](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/GeneratingCustomErrorResponses.html) o usare Lambda in posizioni edge per [tradurre gli errori](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-examples.html#lambda-examples-update-error-status-examples) e riscrivere il contenuto delle pagine. CloudFront permette anche di scambiare le destinazioni dal contenuto dell'applicazione a un'origine di contenuto [Amazon S3](https://aws.amazon.com/s3/) statica che include la pagina di stato sulla manutenzione o sull'interruzione.
1. Progetta il set corretto di stati di errore delle API per il servizio. I messaggi di errore generati da API Gateway quando non riesce a raggiungere i servizi back-end, nonché le eccezioni a livello di servizio, potrebbero contenere messaggi non intuitivi e inadatti per la visualizzazione agli utenti finali. Anziché apportare modifiche di codice ai servizi back-end, puoi configurare [risposte personalizzate agli errori](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-gatewayResponse-definition.html) in API Gateway per mappare codici di risposta HTTP a messaggi di errore delle API selezionati.
1. Progetta la messaggistica da un punto di vista commerciale in modo che sia pertinente per gli utenti finali del sistema e non contenga dettagli tecnici. Esamina i destinatari e allinea la messaggistica di conseguenza. Ad esempio, potresti indirizzare gli utenti interni a una soluzione alternativa o a un processo manuale che utilizza un sistema alternativo. Potresti richiedere agli utenti esterni di attendere il ripristino del sistema o di iscriversi agli aggiornamenti per ricevere una notifica quando il sistema viene ripristinato. Definisci una messaggistica approvata per più scenari, tra cui interruzioni impreviste, manutenzione pianificata ed errori parziali del sistema in cui una funzionalità specifica potrebbe essere danneggiata o non disponibile.
1. Crea modelli per la messaggistica ai clienti e automatizzane la gestione. Dopo aver definito il contenuto dei messaggi, puoi usare [Amazon Pinpoint](https://docs.aws.amazon.com/pinpoint/latest/developerguide/welcome.html) o altri strumenti per automatizzare la campagna di messaggistica. Con Amazon Pinpoint puoi creare segmenti di clientela di destinazione per utenti interessati specifici e trasformare i messaggi in modelli. Consulta il [tutorial su Amazon Pinpoint](https://docs.aws.amazon.com/pinpoint/latest/developerguide/tutorials.html) per informazioni su come configurare una campagna di messaggistica.
1. Evita l'accoppiamento stretto di funzionalità di messaggistica con il sistema rivolto ai clienti. La strategia di messaggistica non deve avere rigide dipendenze dai servizi e dagli archivi di dati del sistema, in modo da permettere l'invio corretto di messaggi quando riscontri interruzioni. Valuta se introdurre la possibilità di inviare messaggi da più di [una zona di disponibilità o regione](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_fault_isolation_multiaz_region_system.html) ai fini della disponibilità della messaggistica. Se usi servizi AWS per inviare messaggi, utilizza operazioni del piano dati anziché [operazioni del piano di controllo (control-plane)](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/rel_withstand_component_failures_avoid_control_plane.html) per richiamare la messaggistica.
**Livello di impegno per il piano di implementazione:** elevato Lo sviluppo di un piano di comunicazione e del suo meccanismo di invio può richiedere un impegno significativo.
## Risorse
**Best practice correlate:**
+ [OPS07-BP03 Utilizzo di runbook per eseguire le procedure](ops_ready_to_support_use_runbooks.md) – Al piano di comunicazione deve essere associato un runbook, in modo che il personale sappia come rispondere.
+ [OPS11-BP02 Esecuzione di analisi post-incidente](ops_evolve_ops_perform_rca_process.md) – Dopo un'interruzione, esegui un'analisi post-incidente per evitarne altre.
**Documenti correlati:**
+ [ Modelli di gestione degli errori in Amazon API Gateway e AWS Lambda](https://aws.amazon.com/blogs/compute/error-handling-patterns-in-amazon-api-gateway-and-aws-lambda/)
+ [ Risposte di Amazon API Gateway ](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-gatewayResponse-definition.html#supported-gateway-response-types)
**Esempi correlati:**
+ [ Dashboard AWS Health](https://aws.amazon.com/premiumsupport/technology/aws-health-dashboard/)
+ [ Riepilogo dell'evento di assistenza AWS nella regione della Virginia settentrionale (US-EAST-1) ](https://aws.amazon.com/message/12721/)
**Servizi correlati:**
+ [Supporto AWS](https://aws.amazon.com/premiumsupport/)
+ [ Accordo cliente AWS](https://aws.amazon.com/agreement/)
+ [ Amazon CloudFront ](https://aws.amazon.com/cloudfront/)
+ [ Amazon API Gateway ](https://aws.amazon.com/api-gateway/)
+ [ Amazon Pinpoint ](https://aws.amazon.com/pinpoint/)
+ [ Amazon S3 ](https://aws.amazon.com/s3/)
# OPS10-BP06 Comunicazione dello stato tramite pannelli di controllo
Fornisci pannelli di controllo personalizzati in base ai destinatari, ad esempio i team tecnici interni, la dirigenza e i clienti, per comunicare lo stato operativo corrente del business e fornire i parametri desiderati.
Puoi creare pannelli di controllo utilizzando [Amazon CloudWatch Dashboards](https://aws.amazon.com/blogs/aws/cloudwatch-dashboards-create-use-customized-metrics-views/) sulle home page personalizzabili nella console di CloudWatch. Utilizzando servizi di business intelligence come [Quick](https://aws.amazon.com/quicksight/) è possibile creare e pubblicare pannelli di controllo interattivi sullo stato del carico di lavoro e delle operazioni (ad esempio tassi di ordinazione, utenti connessi e tempi di transazione). Crea pannelli di controllo che mostrino visualizzazioni dei parametri a livello di sistema e a livello di azienda.
**Anti-pattern comuni:**
+ Su richiesta, esegui un report sull'utilizzo corrente dell'applicazione per la gestione.
+ Durante un incidente, vieni contattato ogni 20 minuti da un responsabile di sistema preoccupato, che desidera sapere se il problema è stato risolto.
**Vantaggi dell'adozione di questa best practice:** Creando pannelli di controllo, abiliti l'accesso self-service alle informazioni consentendo ai clienti di informarsi autonomamente e decidere se devono intervenire.
**Livello di rischio associato se questa best practice non fosse adottata:** Medio
## Guida all'implementazione
+ Comunicazione dello stato tramite pannelli di controllo: fornisci pannelli di controllo personalizzati in base ai destinatari, ad esempio i team tecnici, la leadership e i clienti, per comunicare l'attuale stato operativo del business e fornire i parametri rilevanti. Offrire un'opzione self-service per le informazioni di stato riduce le interruzioni derivanti dalla gestione delle richieste di stato da parte dei team operativi. Ne sono esempi i pannelli di controllo di Amazon CloudWatch e Dashboard AWS Health.
+ [I pannelli di controllo di CloudWatch creano e utilizzano visualizzazioni dei parametri personalizzate](https://aws.amazon.com/blogs/aws/cloudwatch-dashboards-create-use-customized-metrics-views/)
## Risorse
**Documenti correlati:**
+ [Quick](https://aws.amazon.com/quicksight/)
+ [I pannelli di controllo di CloudWatch creano e utilizzano visualizzazioni dei parametri personalizzate](https://aws.amazon.com/blogs/aws/cloudwatch-dashboards-create-use-customized-metrics-views/)
# OPS10-BP07 Automazione delle risposte agli eventi
Automatizza le risposte agli eventi per ridurre gli errori causati dai processi manuali e assicurare risposte rapide e coerenti.
I modi per automatizzare le azioni di runbook o playbook su AWS sono molteplici. Per rispondere a un evento dovuto a una modifica dello stato nelle risorse AWS o a eventi personalizzati, è necessario creare [regole CloudWatch Events](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html) per attivare risposte tramite destinazioni CloudWatch (ad esempio funzioni Lambda, argomenti Amazon Simple Notification Service (Amazon SNS), attività Amazon ECS e AWS Systems Manager Automation).
Per rispondere a un determinato parametro che supera una soglia per una certa risorsa (ad es. il tempo di attesa), è consigliabile creare [avvisi CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) per eseguire una o più azioni utilizzando azioni Amazon EC2 e azioni Auto Scaling o per inviare una notifica a un argomento Amazon SNS. Se è necessario eseguire azioni personalizzate in risposta a un avviso, richiama Lambda con una notifica Amazon SNS. Utilizza Amazon SNS per pubblicare notifiche di eventi e messaggi di escalation, in modo tale che le persone ne siano informate.
AWS supporta, inoltre, sistemi di terze parti attraverso API e SDK del servizio AWS. Esistono numerosi strumenti forniti da partner AWS e da terze parti che consentono di monitorare e inviare notifiche e risposte. Alcuni di questi strumenti sono New Relic, Splunk, Loggly, SumoLogic e Datadog.
Rendi disponibili le procedure manuali cruciali in modo tale che possano essere utilizzate quando le procedure automatiche non riescono.
**Anti-pattern comuni:**
+ Uno sviluppatore controlla il proprio codice. Questo evento avrebbe potuto essere utilizzato per avviare una compilazione e quindi eseguire il test, ma non accade nulla.
+ L'applicazione registra un errore specifico prima di smettere di funzionare. La procedura per riavviare l'applicazione è ben nota e può essere creata con script. Puoi utilizzare l'evento di log per richiamare uno script e riavviare l'applicazione. Ricevi, invece, una chiamata alle 3 di domenica mattina, quando si verifica l'errore, perché sei reperibile come risorsa responsabile della correzione del sistema.
**Vantaggi dell'adozione di questa best practice:** Utilizzando le risposte automatizzate agli eventi, riduci il tempo necessario per rispondere e limiti l'introduzione di errori da attività manuali.
**Livello di rischio associato se questa best practice non fosse adottata:** Bassa
## Guida all'implementazione
+ Automazione delle risposte agli eventi: automatizza le risposte agli eventi per ridurre gli errori causati dai processi manuali e per assicurare risposte rapide e coerenti.
+ [Che cos'è Amazon CloudWatch Events?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
+ [Creazione di una regola di CloudWatch Events che si attiva al verificarsi di un evento](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-Rule.html)
+ [Creazione di una regola di CloudWatch Events che si attiva con una chiamata API AWS tramite AWS CloudTrail](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-CloudTrail-Rule.html)
+ [Esempi di eventi CloudWatch Events dai servizi supportati](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html)
## Risorse
**Documenti correlati:**
+ [Funzionalità di Amazon CloudWatch](https://aws.amazon.com/cloudwatch/features/)
+ [Esempi di eventi CloudWatch Events dai servizi supportati](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/EventTypes.html)
+ [Creazione di una regola di CloudWatch Events che si attiva con una chiamata API AWS tramite AWS CloudTrail](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-CloudTrail-Rule.html)
+ [Creazione di una regola di CloudWatch Events che si attiva al verificarsi di un evento](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/Create-CloudWatch-Events-Rule.html)
+ [Che cos'è Amazon CloudWatch Events?](https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/WhatIsCloudWatchEvents.html)
**Video correlati:**
+ [Creazione di un piano di monitoraggio](https://www.youtube.com/watch?v=OMmiGETJpfU)
**Esempi correlati:**