# REL 11 In che modo progetti il carico di lavoro affinché resista ai guasti dei componenti?
I carichi di lavoro con requisiti di disponibilità elevata e MTTR (Mean Time To Recovery) basso devono essere progettati per garantire la resilienza.
**Topics**
+ [REL11-BP01 Monitoraggio di tutti i componenti del carico di lavoro per la rilevazione dei guasti](rel_withstand_component_failures_monitoring_health.md)
+ [REL11-BP02 Failover e passaggio a risorse integre](rel_withstand_component_failures_failover2good.md)
+ [REL11-BP03 Automatizzazione della riparazione a tutti i livelli](rel_withstand_component_failures_auto_healing_system.md)
+ [REL11-BP04 Fare affidamento al piano dati invece che al piano di controllo durante il ripristino](rel_withstand_component_failures_avoid_control_plane.md)
+ [REL11-BP05 Utilizzo della stabilità statica per evitare un comportamento bimodale](rel_withstand_component_failures_static_stability.md)
+ [REL11-BP06 Invio di notifiche quando gli eventi influiscono sulla disponibilità](rel_withstand_component_failures_notifications_sent_system.md)
# REL11-BP01 Monitoraggio di tutti i componenti del carico di lavoro per la rilevazione dei guasti
Monitora continuamente lo stato del carico di lavoro, in modo che tu e i tuoi sistemi automatizzati siate consapevoli del deterioramento o del guasto non appena questo si verifica. Monitora gli indicatori chiave di prestazioni (KPI) in base al valore aziendale.
Tutti i meccanismi di ripristino e correzione devono essere in grado di rilevare rapidamente i problemi. I guasti tecnici devono essere rilevati prima in modo che possano essere risolti. Tuttavia, la disponibilità si basa sulla capacità del carico di lavoro di fornire valore aziendale, quindi gli indicatori chiave di prestazione (KPI) che misurano questo aspetto devono far parte della strategia di rilevamento e correzione.
**Anti-pattern comuni:**
+ Non sono stati configurati allarmi, pertanto le interruzioni si verificano senza notifica.
+ Gli allarmi esistono, ma a soglie che non forniscono tempo adeguato per reagire.
+ I parametri non vengono raccolti abbastanza spesso da soddisfare l'obiettivo di tempo di ripristino (RTO, recovery time objective).
+ Solo il livello del carico di lavoro rivolto al cliente viene monitorato attivamente.
+ Viene effettuata solo la raccolta di parametri tecnici, senza includere quelli delle funzioni aziendali.
+ Non è presente alcun parametro che misuri l'esperienza utente del carico di lavoro.
**Vantaggi dell'adozione di questa best practice:** Eseguire un monitoraggio appropriato a tutti i livelli consente di ridurre i tempi di ripristino riducendo i tempi di rilevamento.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Determina l'intervallo di raccolta per i componenti in base agli obiettivi di ripristino.
+ L'intervallo di monitoraggio dipende dalla velocità con cui è necessario ripristinare Il tempo di ripristino dipende dal tempo necessario a ripristinare, perciò è necessario determinare la frequenza della raccolta considerando tale tempo e l'obiettivo di tempo di ripristino (RTO, recovery time objective).
+ Configura il monitoraggio dettagliato per i componenti.
+ Determinare se è necessario un monitoraggio dettagliato per le istanze EC2 e l'Auto Scaling Il monitoraggio dettagliato fornisce parametri con un intervallo di 1 minuto, mentre il monitoraggio predefinito fornisce parametri con un intervallo di 5 minuti.
+ [Abilitare o disabilitare il monitoraggio dettagliato della propria istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)
+ [Monitoraggio di gruppi con scalabilità automatica e istanze con Amazon CloudWatch](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html)
+ Determinare se è necessario un monitoraggio avanzato per RDS Il monitoraggio avanzato utilizza un agente sulle istanze RDS per ottenere informazioni utili su diversi processi o thread in un'istanza RDS.
+ [Monitoraggio avanzato](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)
+ Creazione di parametri personalizzati per misurare indicatori chiave di prestazione (KPI) aziendali I carichi di lavoro implementano funzioni aziendali chiave. Queste funzioni devono essere utilizzate come KPI che aiutano a identificare quando si verifica un problema indiretto.
+ [Pubblicazione di parametri personalizzati](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ Monitoraggio della presenza di errori nell'esperienza utente tramite le canary degli utenti Il test sintetico delle transazioni (noto anche come "test canary", ma da non confondere con le distribuzioni canary) in grado di eseguire e simulare il comportamento dei clienti è uno dei processi di test più importanti. Esegui questi test costantemente sugli endpoint del carico di lavoro da diverse posizioni remote.
+ [Amazon CloudWatch Synthetics consente di creare i Canary dell'utente](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ Creazione di parametri personalizzati che monitorino l'esperienza dell'utente Dotare l'esperienza del cliente di strumenti consente di determinare quando essa peggiora.
+ [Pubblicazione di parametri personalizzati](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ Imposta gli allarmi per rilevare quando una qualsiasi parte del carico di lavoro non funziona correttamente e per indicare quando effettuare l'Auto Scaling delle risorse. Gli allarmi possono essere visualizzati sui pannelli di controllo, possono essere inviati avvisi tramite Amazon SNS o e-mail e il dimensionamento automatico può essere utilizzato per aumentare o ridurre le risorse per un carico di lavoro.
+ [Utilizzo degli allarmi di Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ Crea pannelli di controllo per visualizzare i parametri. I pannelli di controllo possono essere utilizzati per visualizzare tendenze, valori anomali e altri indicatori di potenziali problemi, oppure per fornire un'indicazione dei problemi che potresti voler esaminare.
+ [Utilizzo dei pannelli di controllo CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
## Risorse
**Documenti correlati:**
+ [Amazon CloudWatch Synthetics consente di creare i Canary dell'utente](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html)
+ [Abilitare o disabilitare il monitoraggio dettagliato della propria istanza](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-cloudwatch-new.html)
+ [Monitoraggio avanzato](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Monitoring.OS.html)
+ [Monitoraggio di gruppi con scalabilità automatica e istanze con Amazon CloudWatch](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-instance-monitoring.html)
+ [Pubblicazione di parametri personalizzati](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html)
+ [Utilizzo degli allarmi di Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Utilizzo dei pannelli di controllo CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html)
**Esempi correlati:**
+ [Corso Well-Architected: Level 300: Implementing Health Checks and Managing Dependencies to Improve Reliability](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP02 Failover e passaggio a risorse integre
Garantisce che laddove si verifichi un errore con una risorsa, le risorse integre possano continuare a soddisfare le richieste. Per gli errori legati alle posizioni (ad esempio una zona di disponibilità o una Regione AWS), assicurati di disporre di sistemi che possano eseguire il failover e passare a risorse integre in posizioni non danneggiate.
I servizi AWS, come Elastic Load Balancing e AWS Auto Scaling, aiutano a distribuire il carico tra le risorse e le zone di disponibilità. Pertanto, il guasto di una singola risorsa (come un'istanza EC2) o la compromissione di una zona di disponibilità possono essere mitigati spostando il traffico sulle risorse integre rimanenti. Per i carichi di lavoro multi-regione, questa operazione è più complicata. Ad esempio, le repliche di lettura tra Regioni consentono di implementare i dati in più Regioni AWS, ma è comunque necessario promuovere la replica di lettura a primaria e indirizzare il traffico verso di essa in caso di failover. Amazon Route 53 e AWS Global Accelerator possono aiutare a instradare il traffico tra Regioni AWS.
Se il carico di lavoro utilizza servizi AWS, ad esempio Amazon S3 o Amazon DynamoDB, questi vengono automaticamente implementati in più zone di disponibilità. In caso di errore, il piano di controllo AWS instrada automaticamente il traffico verso le posizioni integre per te. I dati sono archiviati in modo ridondante in più zone di disponibilità e rimangono disponibili. Per Amazon RDS, è necessario scegliere l'opzione di configurazione Multi-AZ; quindi, in caso di errore, AWS indirizzerà automaticamente il traffico verso l'istanza integra. Per le istanze Amazon EC2, le attività Amazon ECS o i pod Amazon EKS, puoi scegliere le zone di disponibilità in cui implementarli. Elastic Load Balancing, quindi, fornisce la soluzione per rilevare le istanze nelle zone non integre e instradare il traffico verso quelle integre. Elastic Load Balancing può anche instradare il traffico verso i componenti del data center on-premise.
Per gli approcci multi-regione (che potrebbero includere anche data center on-premise), Amazon Route 53 offre un modo per definire domini Internet e assegnare policy di instradamento che possono includere controlli dell'integrità per garantire che il traffico venga instradato verso regioni integre. In alternativa, AWS Global Accelerator fornisce indirizzi IP statici che fungono da punto di ingresso fisso alla tua applicazione, quindi, instrada verso endpoint nelle Regioni AWS a tua scelta, utilizzando la rete globale AWS, anziché Internet, per migliorare le prestazioni e l'affidabilità.
AWS si avvicina alla progettazione dei servizi pensando al ripristino degli errori. Progettiamo servizi per ridurre al minimo i tempi di recupero da guasti e l'impatto sui dati. I nostri servizi utilizzano principalmente archivi di dati che riconoscono le richieste solo dopo che queste sono state archiviate in modo duraturo su più repliche in una Regione. Questi servizi e risorse includono Amazon Aurora, istanze database Multi-AZ Amazon Relational Database Service (Amazon RDS), Amazon S3, Amazon DynamoDB, Amazon Simple Queue Service (Amazon SQS) e Amazon Elastic File System (Amazon EFS). Sono costruiti con il criterio dell'isolamento basato sulle celle ed utilizzano l'isolamento dei guasti fornito dalle zone di disponibilità. Facciamo ampio uso dell'automazione nelle nostre procedure operative. Ottimizziamo anche la nostra funzionalità di sostituzione e riavvio per un ripristino rapidamente dalle interruzioni.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Failover su risorse integre. Garantisce che laddove si verifichi un errore con una risorsa, le risorse integre possano continuare a soddisfare le richieste. Per gli errori legati alle posizioni (ad esempio una zona di disponibilità o una Regione AWS), assicurati di disporre di sistemi che possano eseguire il failover e passare a risorse integre in posizioni non danneggiate.
+ Se il carico di lavoro utilizza servizi AWS, ad esempio Amazon S3 o Amazon DynamoDB, questi vengono automaticamente implementati in più zone di disponibilità. In caso di errore, il piano di controllo AWS instrada automaticamente il traffico verso le posizioni integre per te.
+ Per Amazon RDS, è necessario scegliere l'opzione di configurazione Multi-AZ; quindi, in caso di errore, AWS indirizzerà automaticamente il traffico verso l'istanza integra.
+ [Alta disponibilità (Multi-AZ) per Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)
+ Per le istanze Amazon EC2 o le attività Amazon ECS, puoi scegliere le zone di disponibilità su cui effettuare la distribuzione.Elastic Load Balancing quindi rileverà le istanze in zone non integre e instraderà il traffico verso quelle integre. Elastic Load Balancing può persino instradare il traffico ai componenti nel tuo data center locale.
+ Per approcci multi-regione (che potrebbero includere anche data center in locale), assicurati che i dati e le risorse provenienti da posizioni integre possano continuare a servire le richieste
+ Ad esempio, le repliche di lettura tra Regioni consentono di implementare i dati in più Regioni AWS, ma è comunque necessario promuovere la replica di lettura per dominare e indirizzare il traffico verso di essa in caso di guasto di una posizione primaria.
+ [Panoramica delle repliche di lettura Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)
+ Amazon Route 53 offre un modo per definire domini Internet e assegnare policy di instradamento, che potrebbero includere controlli dell'integrità, per garantire che il traffico venga instradato verso Regioni integre. In alternativa, AWS Global Accelerator fornisce indirizzi IP statici che fungono da punto di ingresso fisso alla tua applicazione, quindi, instrada verso endpoint nelle Regioni AWS a tua scelta, utilizzando la rete globale AWS, anziché Internet, per migliorare le prestazioni e l'affidabilità.
+ [Amazon Route 53: scelta di una policy di instradamento](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)
+ [Che cos'è AWSGlobal Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
## Risorse
**Documenti correlati:**
+ [Partner APN: partner che possono essere d'aiuto con l'automazione della tua tolleranza ai guasti](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [Marketplace AWS: prodotti utilizzabili per la tolleranza ai guasti](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [AWS OpsWorks: Using Auto Healing to Replace Failed Instances (Utilizzo della riparazione automatica per sostituire le istanze in errore)](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ [Amazon Route 53: scelta di una policy di instradamento](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)
+ [Alta disponibilità (Multi-AZ) per Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html)
+ [Panoramica delle repliche di lettura Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html)
+ [Strategie di posizionamento dei processi di Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ [Creating Kubernetes Auto Scaling Groups for Multiple Availability Zones (Creazione di gruppi con scalabilità automatica Kubernetes per più zone di disponibilità)](https://aws.amazon.com/blogs/containers/amazon-eks-cluster-multi-zone-auto-scaling-groups/)
+ [Che cos'è AWS Global Accelerator?](https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html)
**Esempi correlati:**
+ [Corso Well-Architected: Level 300: Implementing Health Checks and Managing Dependencies to Improve Reliability](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP03 Automatizzazione della riparazione a tutti i livelli
Al rilevamento di un guasto, utilizza funzionalità automatizzate per eseguire azioni da correggere.
*La capacità di riavvio* è uno strumento importante per risolvere gli errori. Come illustrato in precedenza per i sistemi distribuiti, una best practice consiste nel rendere i servizi stateless laddove possibile. In questo modo si evita la perdita di dati o la disponibilità al riavvio. Nel cloud, puoi (e generalmente dovresti) sostituire l'intera risorsa (ad esempio, l'istanza EC2 o la funzione Lambda) come parte del riavvio. Il riavvio stesso è un modo semplice e affidabile per eseguire il ripristino in caso di guasto. Molti tipi diversi di guasto si verificano nei carichi di lavoro. Possono verificarsi guasti a livello di hardware, software, comunicazione e operazioni. Anziché creare nuovi meccanismi per intrappolare, identificare e correggere ciascuno dei diversi tipi di guasto, mappa diverse categorie di guasto alla stessa strategia di ripristino. Un'istanza può restituire un guasto causato da un guasto hardware, da un bug del sistema operativo, da una memory leak o da altre cause. Anziché creare una correzione personalizzata per ogni situazione, considera una di esse come un guasto dell'istanza. Termina l'istanza e consenti ad AWS Auto Scaling di sostituirla. In un secondo momento, esegui l'analisi sulla risorsa guasta fuori banda.
Un altro esempio è la possibilità di riavviare una richiesta di rete. Adotta lo stesso approccio di ripristino sia a un timeout di rete sia a un guasto di dipendenza in cui la dipendenza restituisce un guasto. Entrambi gli eventi hanno un effetto simile sul sistema, quindi piuttosto che tentare di trasformare entrambi gli eventi in un "caso speciale", adotta una strategia analoga di nuovi tentativi limitati con un back-off e un jitter esponenziali.
*La capacità di riavvio* è un meccanismo di ripristino presente nelle architetture di cluster ROC (Recovery Oriented Computing) e ad alta disponibilità.
Amazon EventBridge può essere utilizzato per monitorare e filtrare eventi come allarmi CloudWatch o cambiamenti di stato in altri servizi AWS. In base alle informazioni sugli eventi, può quindi attivare AWS Lambda, AWS Systems Manager Automation o altri target per eseguire una logica di riparazione sul carico di lavoro.
Amazon EC2 Auto Scaling può essere configurato per verificare lo stato dell'istanza EC2. Se l'istanza è in uno stato diverso da quello in esecuzione o se lo stato del sistema è danneggiato, Amazon EC2 Auto Scaling considera l'istanza come non integra e ne avvia una sostitutiva. Se utilizzi AWS OpsWorks, puoi configurare la riparazione automatica delle istanze EC2 a livello del layer OpsWorks.
Per le sostituzioni su larga scala (ad esempio la perdita di un'intera zona di disponibilità), anziché cercare di ottenere nuove risorse contemporaneamente è preferibile adottare la stabilità statica per trarre vantaggio dall'elevata disponibilità.
**Anti-pattern comuni:**
+ Implementazione individuale di applicazioni in istanze/container.
+ Distribuzione di applicazioni che non possono essere distribuite in più posizioni senza utilizzare il ripristino automatico.
+ Riparazione manuale delle applicazioni che il dimensionamento e il ripristino automatici non sono stati in grado di riparare.
**Vantaggi dell'adozione di questa best practice:** Il risanamento automatico, anche se il carico di lavoro può essere distribuito in una sola posizione alla volta, ridurrà il tempo medio di ripristino e garantirà la disponibilità del carico di lavoro.
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Utilizzo dei gruppi con scalabilità automatica per implementare livelli in un carico di lavoro. Auto Scaling è in grado di eseguire il risanamento automatico sulle applicazioni stateless e aggiungere e rimuovere capacità.
+ [Come funziona AWS Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ Implementa il ripristino automatico sulle istanze EC2 che includono applicazioni distribuite non distribuibili in più posizioni e possono tollerare il riavvio in caso di guasti. Il ripristino automatico può essere utilizzato per sostituire l'hardware guasto e riavviare l'istanza quando l'applicazione non è in grado di essere distribuita in più posizioni. Vengono conservati i metadati dell'istanza e gli indirizzi IP associati, nonché i volumi Amazon EBS e i punti di montaggio su Elastic File System o file system per Lustre e Windows.
+ [Ripristino automatico Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)
+ [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html)
+ [What is Amazon FSx for Lustre? Che cos'è Amazon FSx for Lustre?)](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [What is Amazon FSx for Windows File Server? (Che cos'è What is FSx for Windows File Server?)](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)
+ Se utilizzi AWS OpsWorks, puoi configurare il la riparazione automatica delle istanze EC2 a livello del layer.
+ [AWS OpsWorks: Using Auto Healing to Replace Failed Instances (Utilizzo della riparazione automatica per sostituire le istanze in errore)](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ Implementa il ripristino automatico utilizzando AWS Step Functions e AWS Lambda quando non è possibile utilizzare il dimensionamento automatico o il ripristino automatico oppure quando il ripristino automatico non riesce. Quando non puoi utilizzare il dimensionamento automatico né il ripristino automatico o il ripristino automatico non riesce, puoi automatizzare la riparazione utilizzando AWS Step Functions e AWS Lambda.
+ [What is AWS Step Functions? (Che cos'è AWS Step Functions?)](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [Cos'è AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ Amazon EventBridge può essere utilizzato per monitorare e filtrare eventi come allarmi CloudWatch o cambiamenti di stato in altri servizi AWS. In base alle informazioni sugli eventi, può quindi attivare AWS Lambda (o altri target) per eseguire una logica di riparazione personalizzata sul tuo carico di lavoro.
+ [Che cos'è Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Utilizzo degli allarmi di Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
## Risorse
**Documenti correlati:**
+ [Partner APN: partner che possono essere d'aiuto con l'automazione della tua tolleranza ai guasti](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [Marketplace AWS: prodotti utilizzabili per la tolleranza ai guasti](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [AWS OpsWorks: Using Auto Healing to Replace Failed Instances (Utilizzo della riparazione automatica per sostituire le istanze in errore)](https://docs.aws.amazon.com/opsworks/latest/userguide/workinginstances-autohealing.html)
+ [Ripristino automatico Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html)
+ [Amazon Elastic Block Store (Amazon EBS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html)
+ [Amazon Elastic File System (Amazon EFS)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEFS.html)
+ [Come funziona AWS Auto Scaling](https://docs.aws.amazon.com/autoscaling/plans/userguide/how-it-works.html)
+ [Utilizzo degli allarmi di Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)
+ [Che cos'è Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Cos'è AWS Lambda?](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)
+ [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [What is AWS Step Functions? (Che cos'è AWS Step Functions?)](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
+ [What is Amazon FSx for Lustre? Che cos'è Amazon FSx for Lustre?)](https://docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html)
+ [What is Amazon FSx for Windows File Server? (Che cos'è What is FSx for Windows File Server?)](https://docs.aws.amazon.com/fsx/latest/WindowsGuide/what-is.html)
**Video correlati:**
+ [Static stability in AWS: AWS re:Invent 2019: Introducing The Amazon Builders' Library (Introduzione alla libreria dei costruttori di Amazon) (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
**Esempi correlati:**
+ [Corso Well-Architected: Level 300: Implementing Health Checks and Managing Dependencies to Improve Reliability](https://wellarchitectedlabs.com/Reliability/300_Health_Checks_and_Dependencies/README.html)
# REL11-BP04 Fare affidamento al piano dati invece che al piano di controllo durante il ripristino
Il piano di controllo è utilizzato per configurare le risorse, mentre il piano dati fornisce servizi. I piani dati hanno tipicamente obiettivi di progettazione della disponibilità più elevati rispetto ai piani di controllo e sono solitamente meno complessi. Quando si implementano risposte di ripristino o mitigazione a eventi potenzialmente dannosi per la resilienza, l'utilizzo di operazioni sul piano di controllo può ridurre la resilienza complessiva della tua architettura. Per esempio, puoi fare affidamento sul piano dati di Amazon Route 53 per instradare in modo affidabile le query DNS basate sui controlli dell'integrità, ma l'aggiornamento delle policy di instradamento Route 53 utilizza il piano di controllo, quindi non fare affidamento su di esso per il ripristino.
I piani dati di Route 53 rispondono alle query DNS ed eseguono e valutano i controlli di integrità. Sono distribuiti a livello globale e progettati per un [accordo sul livello di servizio (SLA) con disponibilità al 100%.](https://aws.amazon.com/route53/sla/) Le API e le console di gestione di Route 53, dove si creano, aggiornano ed eliminano le risorse di Route 53, funzionano su piani di controllo progettati per privilegiare la forte coerenza e la durata necessarie per la gestione del DNS. A tal fine, i piani di controllo sono situati in un'unica regione, US East (N. Virginia). Sebbene entrambi i sistemi siano costruiti per essere molto affidabili, i piani di controllo non sono inclusi nello SLA. Possono verificarsi eventi rari in cui la progettazione resiliente del piano dati consente di mantenere la disponibilità mentre i piani di controllo non lo fanno. Per i meccanismi di ripristino di emergenza e failover, utilizzare le funzioni del piano dati per garantire la migliore affidabilità possibile.
Per ulteriori informazioni sui piani dati, sui piani di controllo e come AWS costruisce i servizi per soddisfare gli obiettivi di alta disponibilità, consulta il documento [stabilità statica utilizzando le zone di disponibilità](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) e la Libreria [degli sviluppatori di Amazon.](https://aws.amazon.com/builders-library/)
**Livello di rischio associato se questa best practice non fosse adottata:** Alta
## Guida all'implementazione
+ Affidati al piano dati e non al piano di controllo quando utilizzi Amazon Route 53 per il ripristino di emergenza. Route 53 Application Recovery Controller aiuta a gestire e coordinare il failover utilizzando i controlli di disponibilità e i controlli di instradamento. Queste funzionalità monitorano continuamente la capacità dell'applicazione di riprendersi dai guasti e permettono di controllarne il ripristino su più Regioni AWS, zone di disponibilità e on-premise.
+ [What is Route 53 Application Recovery Controller (What is Amazon Route 53 Application Recovery Controller?)](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
+ [Creating Disaster Recovery Mechanisms Using Amazon Route 53 (Creazione di meccanismi di ripristino di emergenza con Amazon Route 53)](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
+ [Building highly resilient applications using Amazon Route 53 Application Recovery Controller, Part 1: Single-Region stack (Creazione di applicazioni altamente resilienti con Amazon Route 53 Application Recovery Controller, parte 1: stack a singola regione)](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/)
+ [Building highly resilient applications using Amazon Route 53 Application Recovery Controller, Part 2: Multi-Region stack (Creazione di applicazioni altamente resilienti con Amazon Route 53 Application Recovery Controller, parte 2: stack multi-regione)](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/)
+ Capire quali operazioni sono sul piano dati e quali sul piano di controllo.
+ [The Amazon Builders' Library: Avoiding overload in distributed systems by putting the smaller service in control](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [API Amazon DynamoDB (piano di controllo e piano dati)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html)
+ [AWS Lambda Executions (Esecuzioni Lambda )](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (suddivise in piano di controllo e piano dati)
+ [AWS Lambda Executions (Esecuzioni Lambda )](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (suddivise in piano di controllo e piano dati)
## Risorse
**Documenti correlati:**
+ [Partner APN: partner che possono essere d'aiuto con l'automazione della tua tolleranza ai guasti](https://aws.amazon.com/partners/find/results/?keyword=automation)
+ [Marketplace AWS: prodotti utilizzabili per la tolleranza ai guasti](https://aws.amazon.com/marketplace/search/results?searchTerms=fault+tolerance)
+ [The Amazon Builders' Library: Avoiding overload in distributed systems by putting the smaller service in control](https://aws.amazon.com/builders-library/avoiding-overload-in-distributed-systems-by-putting-the-smaller-service-in-control/)
+ [API Amazon DynamoDB (piano di controllo e piano dati)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html)
+ [AWS Lambda Executions (Esecuzioni Lambda )](https://docs.aws.amazon.com/whitepapers/latest/security-overview-aws-lambda/lambda-executions.html) (suddivise in piano di controllo e piano dati)
+ [Piano dati AWS Elemental MediaStore](https://docs.aws.amazon.com/mediastore/latest/apireference/API_Operations_AWS_Elemental_MediaStore_Data_Plane.html)
+ [Building highly resilient applications using Amazon Route 53 Application Recovery Controller, Part 1: Single-Region stack (Creazione di applicazioni altamente resilienti con Amazon Route 53 Application Recovery Controller, parte 1: stack a singola regione)](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-1-single-region-stack/)
+ [Building highly resilient applications using Amazon Route 53 Application Recovery Controller, Part 2: Multi-Region stack (Creazione di applicazioni altamente resilienti con Amazon Route 53 Application Recovery Controller, parte 2: stack multi-regione)](https://aws.amazon.com/blogs/networking-and-content-delivery/building-highly-resilient-applications-using-amazon-route-53-application-recovery-controller-part-2-multi-region-stack/)
+ [Creating Disaster Recovery Mechanisms Using Amazon Route 53 (Creazione di meccanismi di ripristino di emergenza con Amazon Route 53)](https://aws.amazon.com/blogs/networking-and-content-delivery/creating-disaster-recovery-mechanisms-using-amazon-route-53/)
+ [What is Route 53 Application Recovery Controller (What is Amazon Route 53 Application Recovery Controller?)](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
**Esempi correlati:**
+ [Introduzione a Amazon Route 53 Application Recovery Controller (Introduzione ad Amazon Route 53 Application Recovery Controller)](https://aws.amazon.com/blogs/aws/amazon-route-53-application-recovery-controller/)
# REL11-BP05 Utilizzo della stabilità statica per evitare un comportamento bimodale
Si ha un comportamento bimodale quando il carico di lavoro mostra un comportamento diverso in modalità normale e di guasto, ad esempio facendo affidamento sull'avvio di nuove istanze se una zona di disponibilità ha esito negativo. Devi invece creare carichi di lavoro che siano staticamente stabili e operino in una sola modalità. In questo caso, effettua il provisioning di istanze sufficienti in ciascuna zona di disponibilità per gestire il carico di lavoro se una zona di disponibilità è stata rimossa, quindi utilizza i controlli dello stato di Elastic Load Balancing o Amazon Route 53 per spostare il carico dalle istanze danneggiate.
La stabilità statica per la distribuzione di calcolo (ad esempio istanze EC2 o container) determinerà la massima affidabilità. Questa operazione deve essere valutata in base ai problemi relativi ai costi. Eseguire il provisioning di minore capacità di elaborazione e affidarsi all'avvio di nuove istanze in caso di guasto è meno costoso. Tuttavia, per i guasti su larga scala (ad esempio un errore nella zona di disponibilità), questo approccio è meno efficace perché si basa sulla reazione ai guasti nel momento in cui si verificano, piuttosto che prepararsi a tali problemi prima che accadano. La soluzione deve valutare l'affidabilità rispetto alle esigenze di costo per il carico di lavoro. Utilizzando più zone di disponibilità, la quantità di elaborazione aggiuntiva necessaria per la stabilità statica diminuisce.
![\[Diagramma che mostra la stabilità statica delle istanze EC2 nelle varie zone di disponibilità\]](http://docs.aws.amazon.com/it_it/wellarchitected/2022-03-31/framework/images/static-stability.png)
Dopo il trasferimento del traffico, utilizza AWS Auto Scaling per sostituire in modo asincrono le istanze dalla zona interessata dal guasto e avviarle nelle zone integre.
Un altro esempio di comportamento bimodale potrebbe essere un timeout di rete che potrebbe causare un tentativo di aggiornamento dello stato di configurazione dell'intero sistema. Ciò aggiungerebbe un carico imprevisto a un altro componente, che potrebbe quindi causare un errore, innescando altre conseguenze impreviste. Questo loop di feedback negativo influisce sulla disponibilità del tuo carico di lavoro. Al contrario, è necessario creare sistemi che siano staticamente stabili e funzionino in una sola modalità. Un progetto staticamente stabile sarebbe quello di eseguire un lavoro costante e aggiornare sempre, con cadenze fisse, lo stato di configurazione. Quando una chiamata non riesce, il carico di lavoro utilizza il valore precedentemente memorizzato nella cache e attiva un allarme.
Un altro esempio di comportamento bimodale è consentire ai client di bypassare la cache del carico di lavoro quando si verificano guasti. Potrebbe sembrare una soluzione che soddisfi le esigenze del client, ma non dovrebbe essere consentita perché modifica in modo significativo le richieste sul carico di lavoro e potrebbe causare guasti.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Utilizzo della stabilità statica per evitare un comportamento bimodale. Si ha un comportamento bimodale quando il carico di lavoro mostra un comportamento diverso in modalità normale e di guasto, ad esempio facendo affidamento sull'avvio di nuove istanze se una zona di disponibilità ha esito negativo.
+ [Minimizing Dependencies in a Disaster Recovery Plan](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [The Amazon Builders' Library: Stabilità statica con le zone di disponibilità](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
+ [Static stability in AWS: AWS re:Invent 2019: Introducing The Amazon Builders' Library (Introduzione alla libreria dei costruttori di Amazon) (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
+ Devi invece creare sistemi che siano staticamente stabili e operino in una sola modalità. In questo caso, effettua il provisioning di istanze sufficienti in ciascuna zona di disponibilità per gestire il carico di lavoro se una zona di disponibilità è stata rimossa, quindi utilizza i controlli dell'integrità di Elastic Load Balancing o Amazon Route 53 per spostare il carico dalle istanze danneggiate.
+ Un altro esempio di comportamento bimodale è consentire ai client di bypassare la cache del carico di lavoro quando si verificano guasti. Potrebbe sembrare una soluzione per soddisfare le esigenze del client, ma non dovrebbe essere consentita perché modifica in modo significativo le richieste sul carico di lavoro e potrebbe causare guasti.
## Risorse
**Documenti correlati:**
+ [Minimizing Dependencies in a Disaster Recovery Plan](https://aws.amazon.com/blogs/architecture/minimizing-dependencies-in-a-disaster-recovery-plan/)
+ [The Amazon Builders' Library: Stabilità statica con le zone di disponibilità](https://aws.amazon.com/builders-library/static-stability-using-availability-zones)
**Video correlati:**
+ [Static stability in AWS: AWS re:Invent 2019: Introducing The Amazon Builders' Library (Introduzione alla libreria dei costruttori di Amazon) (DOP328)](https://youtu.be/sKRdemSirDM?t=704)
# REL11-BP06 Invio di notifiche quando gli eventi influiscono sulla disponibilità
Le notifiche vengono inviate al rilevamento di eventi significativi, anche se il problema causato dall'evento è stato risolto automaticamente.
Il ripristino automatizzato consente al tuo carico di lavoro di essere affidabile. Tuttavia, potrebbe anche oscurare problemi sottostanti che hanno bisogno di essere risolti. Implementa il monitoraggio e gli eventi appropriati in modo da poter rilevare i modelli di problemi, inclusi quelli risolti dalla diagnostica automatica e risolvere così i problemi della causa principale. Gli allarmi di Amazon CloudWatch possono essere attivati in base ai guasti che si verificano. Possono anche attivarsi in base alle operazioni di ripristino automatizzato eseguite. Gli allarmi CloudWatch possono essere configurati per l'invio di e-mail o per la registrazione di file di log nei sistemi di monitoraggio di terze parti tramite l'integrazione con Amazon SNS.
**Anti-pattern comuni:**
+ Invio di allarmi su cui nessuno agisce.
+ Esecuzione dell'automazione del risanamento automatico, ma senza la notifica della necessità di una correzione.
**Vantaggi dell'adozione di questa best practice:** Le notifiche degli eventi di ripristino ti consentiranno di non ignorare i problemi che si verificano di rado.
**Livello di rischio associato se questa best practice non fosse adottata:** Medium
## Guida all'implementazione
+ Allarmi su indicatori chiave di prestazione aziendali al superamento di una soglia minima Un allarme su indicatori chiave di prestazione aziendali consente di sapere quando il carico di lavoro non è disponibile o non funziona.
+ [Creare un allarme CloudWatch basato su una soglia statica](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)
+ Allarme su eventi che invocano l'automazione della riparazione Puoi invocare direttamente un'API SNS per inviare notifiche con qualsiasi automazione creata.
+ [Che cos'è Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)
## Risorse
**Documenti correlati:**
+ [Creare un allarme CloudWatch basato su una soglia statica](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ConsoleAlarms.html)
+ [Che cos'è Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/what-is-amazon-eventbridge.html)
+ [Che cos'è Amazon Simple Notification Service?](https://docs.aws.amazon.com/sns/latest/dg/welcome.html)