Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Comprendere la disponibilità
La disponibilità è uno dei modi principali in cui possiamo misurare quantitativamente la resilienza. Definiamo la disponibilità, *A*, come la percentuale di tempo in cui un carico di lavoro è disponibile per l'uso. È il rapporto tra il «tempo di attività» previsto (disponibilità) e il tempo totale misurato (il «tempo di attività» previsto più il «tempo di inattività» previsto).
![\[Immagine dell'equazione. A = uptime/(uptime + downtime)\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/availability-and-beyond-improving-resilience/images/availability.png)
Per comprendere meglio questa formula, vedremo come misurare i tempi di attività e i tempi di inattività. Innanzitutto, vogliamo sapere per quanto tempo durerà il carico di lavoro senza errori. Lo chiamiamo *Mean Time Between Failure* (MTBF), il tempo medio che intercorre tra l'inizio del normale funzionamento di un carico di lavoro e il successivo guasto. Quindi, vogliamo sapere quanto tempo ci vorrà per il ripristino dopo il fallimento.
Questo periodo è denominato *Mean Time to Repair (or Recovery)* (MTTR), un periodo di tempo in cui il carico di lavoro non è disponibile mentre il sottosistema guasto viene riparato o rimesso in servizio. Un periodo di tempo importante nell'MTTR è il tempo *medio di rilevamento (MTTD), il periodo di tempo che* intercorre tra il verificarsi di un guasto e l'inizio delle operazioni di riparazione. Il diagramma seguente mostra come tutte queste metriche sono correlate.
![\[Diagramma che mostra la relazione tra MTTD, MTTR e MTBF\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/availability-and-beyond-improving-resilience/images/availability-metrics.png)
Possiamo quindi esprimere la disponibilità, *A*, utilizzando MTBF, il momento in cui il carico di lavoro è attivo e MTTR, il momento in cui il carico di lavoro è inattivo.
![\[Immagine dell'equazione. A = MTBF/(MTBF + MTTR)\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation2.png)
*E la probabilità che il carico di lavoro sia «inattivo» (cioè non disponibile) è la probabilità di fallimento, F.*
![\[Immagine dell'equazione. F = 1 - A\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation3.png)
L'[affidabilità](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/reliability.html) è la capacità di un carico di lavoro di fare la cosa giusta, quando richiesto, entro il tempo di risposta specificato. Questo è ciò che misura la disponibilità. Un carico di lavoro che si guasta meno frequentemente (MTBF più lungo) o un tempo di riparazione più breve (MTTR più breve) ne migliora la disponibilità.
**Regola 1**
Guasti meno frequenti (MTBF più lungo), tempi di rilevamento dei guasti più brevi (MTTD più brevi) e tempi di riparazione più brevi (MTTR più breve) sono i tre fattori utilizzati per migliorare la disponibilità nei sistemi distribuiti.
**Topics**
+ [Disponibilità del sistema distribuito](distributed-system-availability.md)
+ [Disponibilità con dipendenze](availability-with-dependencies.md)
+ [Disponibilità con ridondanza](availability-with-redundancy.md)
+ [Teorema CAP](cap-theorem.md)
+ [Tolleranza e isolamento dei guasti](fault-tolerance-and-fault-isolation.md)
# Disponibilità del sistema distribuito
I sistemi distribuiti sono costituiti sia da componenti software che da componenti hardware. Alcuni componenti software potrebbero essere essi stessi un altro sistema distribuito. La disponibilità dei componenti hardware e software sottostanti influisce sulla conseguente disponibilità del carico di lavoro.
Il calcolo della disponibilità mediante MTBF e MTTR affonda le sue radici nei sistemi hardware. Tuttavia, i sistemi distribuiti falliscono per ragioni molto diverse rispetto a quelle di un componente hardware. Se un produttore è in grado di calcolare in modo coerente il tempo medio che precede l'usura di un componente hardware, gli stessi test non possono essere applicati ai componenti software di un sistema distribuito. L'hardware segue in genere una curva approssimativa del tasso di guasto, mentre il software segue una curva sfalsata causata da difetti aggiuntivi che vengono introdotti con ogni nuova versione (vedi Affidabilità del [software](https://users.ece.cmu.edu/~koopman/des_s99/sw_reliability)).
![\[Diagramma che mostra i tassi di guasto hardware e software\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/availability-and-beyond-improving-resilience/images/failure-rates.png)
Inoltre, il software nei sistemi distribuiti cambia in genere a velocità esponenzialmente superiori a quelle dell'hardware. [Ad esempio, un disco rigido magnetico standard potrebbe avere un tasso di guasto annualizzato medio (AFR) dello 0,93% che, in pratica per un HDD, può significare una durata di almeno 3-5 anni prima che raggiunga il periodo di usura, potenzialmente più lungo (vedi Backblaze Hard Drive Data and Stats, 2020).](https://www.backblaze.com/b2/hard-drive-test-data.html) Il disco rigido non cambia sostanzialmente durante quel ciclo di vita, dove, in 3-5 anni, ad esempio, Amazon potrebbe implementare più di 450-750 milioni di modifiche ai suoi sistemi software. (Vedi [Amazon Builders' Library — Automatizzazione di distribuzioni sicure e pratiche](https://aws.amazon.com/about-aws/whats-new/2020/06/new-abl-article-automating-safe-hands-off-deployments/)).
L'hardware è inoltre soggetto al concetto di obsolescenza pianificata, ossia ha una durata di vita incorporata e dovrà essere sostituito dopo un certo periodo di tempo. (Vedi [The Great](https://spectrum.ieee.org/tech-history/dawn-of-electronics/the-great-lightbulb-conspiracy) Lightbulb Conspiracy.) Il software, in teoria, non è soggetto a questo vincolo, non ha un periodo di usura e può essere utilizzato a tempo indeterminato.
Tutto ciò significa che gli stessi modelli di test e previsione utilizzati per l'hardware per generare i numeri MTBF e MTTR non si applicano al software. Ci sono stati centinaia di tentativi di creare modelli per risolvere questo problema a partire dagli anni '70, ma generalmente rientrano tutti in due categorie: modelli di previsione e modelli di stima. (Vedi [Elenco dei modelli di affidabilità del software](https://en.wikipedia.org/wiki/List_of_software_reliability_models)).
Pertanto, il calcolo di un MTBF e di un MTTR lungimiranti per sistemi distribuiti, e quindi di una disponibilità previsionale, sarà sempre derivato da qualche tipo di previsione o previsione. Possono essere generati mediante modellazione predittiva, simulazione stocastica, analisi storica o test rigorosi, ma tali calcoli non garantiscono tempi di attività o tempi di inattività.
I motivi per cui un sistema distribuito ha fallito in passato potrebbero non ripresentarsi mai. Le ragioni per cui fallirà in futuro saranno probabilmente diverse e forse inconoscibili. I meccanismi di ripristino necessari potrebbero inoltre essere diversi per i guasti futuri rispetto a quelli utilizzati in passato e richiedere tempi significativamente diversi.
Inoltre, MTBF e MTTR sono valori medi. Ci sarà una certa varianza tra il valore medio e i valori effettivi visti (la deviazione standard, ₂, misura questa variazione). Pertanto, i carichi di lavoro possono trascorrere un periodo di tempo più o meno lungo tra i guasti e i tempi di ripristino nell'effettivo utilizzo in produzione.
Detto questo, la disponibilità dei componenti software che costituiscono un sistema distribuito è ancora importante. Il software può fallire per numerose ragioni (discusse più approfonditamente nella prossima sezione) e influire sulla disponibilità del carico di lavoro. Pertanto, per i sistemi distribuiti ad alta disponibilità, occorre prestare la stessa attenzione al calcolo, alla misurazione e al miglioramento della disponibilità dei componenti software per quanto riguarda l'hardware e i sottosistemi software esterni.
**Regola 2**
La disponibilità del software nel carico di lavoro è un fattore importante della disponibilità complessiva del carico di lavoro e dovrebbe ricevere la stessa attenzione degli altri componenti.
È importante notare che, nonostante MTBF e MTTR siano difficili da prevedere per i sistemi distribuiti, forniscono comunque informazioni chiave su come migliorare la disponibilità. La riduzione della frequenza dei guasti (MTBF più elevato) e la riduzione del tempo di ripristino dopo il verificarsi del guasto (MTTR inferiore) porteranno entrambe a una maggiore disponibilità empirica.
## Tipi di guasti nei sistemi distribuiti
Esistono generalmente due classi di bug nei sistemi distribuiti che influiscono sulla disponibilità, chiamate affettuosamente *Bohrbug e *Heisenbug** (vedi [«A Conversation with Bruce Lindsay», ACM Queue vol. 2,](http://queue.acm.org/detail.cfm?id=1036486) n. 8 — novembre 2004).
Un Bohrbug è un problema software funzionale ripetibile. Con lo stesso input, il bug produrrà costantemente lo stesso output errato (come il modello atomico deterministico di Bohr, che è solido e facilmente rilevabile). Questi tipi di bug sono rari quando un carico di lavoro entra in produzione.
Un Heisenbug è un bug transitorio, il che significa che si verifica solo in condizioni specifiche e non comuni. Queste condizioni sono in genere correlate a fattori come l'hardware (ad esempio, un guasto temporaneo del dispositivo o specifiche dell'implementazione hardware come la dimensione del registro), le ottimizzazioni del compilatore e l'implementazione del linguaggio, le condizioni limite (ad esempio, l'esaurimento temporaneo dello spazio di archiviazione) o le condizioni di gara (ad esempio, il mancato utilizzo di un semaforo per operazioni multithread).
Gli Heisenbug costituiscono la maggior parte dei bug in produzione e sono difficili da trovare perché sono sfuggenti e sembrano cambiare comportamento o scomparire quando si tenta di osservarli o eseguirne il debug. Tuttavia, se si riavvia il programma, è probabile che l'operazione fallita abbia successo perché l'ambiente operativo è leggermente diverso, eliminando le condizioni che hanno introdotto l'Heisenbug.
Pertanto, la maggior parte degli errori di produzione sono transitori e quando l'operazione viene ritentata, è improbabile che si verifichi nuovamente un errore. Per essere resilienti, i sistemi distribuiti devono essere tolleranti ai guasti nei confronti di Heisenbugs. [Scopriremo come raggiungere questo obiettivo nella sezione Incrementare l'MTBF dei sistemi distribuiti.](increasing-mtbf.md#increasing-mtbf.title)
# Disponibilità con dipendenze
Nella sezione precedente, abbiamo detto che l'hardware, il software e potenzialmente altri sistemi distribuiti sono tutti componenti del carico di lavoro. Questi componenti si chiamano *dipendenze, ossia* gli elementi da cui dipende il carico di lavoro per fornire le proprie funzionalità. Esistono dipendenze *rigide*, ovvero quelle cose senza le quali il carico di lavoro non può funzionare, e dipendenze *morbide* la cui indisponibilità può passare inosservata o tollerata per un certo periodo di tempo. Le dipendenze rigide hanno un impatto diretto sulla disponibilità del carico di lavoro.
Potremmo provare a calcolare la disponibilità massima teorica di un carico di lavoro. Questo è il prodotto della disponibilità di tutte le dipendenze, incluso il software stesso, (*α* *n* è la disponibilità di un singolo sottosistema) perché ognuna deve essere operativa.
![\[Immagine dell'equazione. A = α 1 X α 2 X... Soggetto X n α>\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation4.png)
I numeri di disponibilità utilizzati in questi calcoli sono generalmente associati a elementi come SLA o Service-Level Objectives (SLO). Gli SLA definiscono il livello di servizio previsto che i clienti riceveranno, le metriche in base alle quali viene misurato il servizio e le misure correttive o le penalità (generalmente pecuniarie) in caso di mancato raggiungimento dei livelli di servizio.
Utilizzando la formula precedente, possiamo concludere che, puramente matematicamente, un carico di lavoro non può essere più disponibile di nessuna delle sue dipendenze. Ma in realtà, ciò che di solito vediamo è che non è così. Un carico di lavoro creato utilizzando due o tre dipendenze con SLA di disponibilità del 99,99% può comunque raggiungere da solo una disponibilità del 99,99% o superiore.
Questo perché, come indicato nella sezione precedente, questi numeri di disponibilità sono stime. Stimano o prevedono la frequenza con cui si verifica un guasto e la rapidità con cui può essere riparato. Non sono una garanzia di tempi di inattività. Le dipendenze spesso superano lo SLA o lo SLO di disponibilità dichiarati.
Le dipendenze possono inoltre avere obiettivi di disponibilità interna più elevati rispetto ai quali mirare alle prestazioni rispetto ai numeri forniti negli SLA pubblici. Ciò fornisce un livello di mitigazione del rischio nel rispetto degli SLA quando accade l'ignoto o l'inconoscibile.
Infine, il carico di lavoro potrebbe avere dipendenze i cui SLA non sono noti o non offrono uno SLA o uno SLO. Ad esempio, il routing Internet a livello mondiale è una dipendenza comune per molti carichi di lavoro, ma è difficile sapere quali provider di servizi Internet utilizza il traffico globale, se hanno degli SLA e quanto siano coerenti tra i provider.
Tutto ciò ci dice che il calcolo di una disponibilità teorica massima probabilmente produce solo un calcolo approssimativo dell'ordine di grandezza, ma di per sé è probabile che non sia accurato o non fornisca informazioni significative. Ciò che la matematica ci dice è che il minor numero di elementi su cui si basa il carico di lavoro riduce la probabilità complessiva di fallimento. Minore è il numero di numeri moltiplicati tra loro, maggiore è il risultato.
**Regola 3**
La riduzione delle dipendenze può avere un impatto positivo sulla disponibilità.
La matematica aiuta anche a orientare il processo di selezione delle dipendenze. Il processo di selezione influisce sul modo in cui si progetta il carico di lavoro, su come si sfrutta la ridondanza delle dipendenze per migliorarne la disponibilità e sul fatto che tali dipendenze vengano considerate deboli o rigide. Le dipendenze che possono avere un impatto sul carico di lavoro devono essere scelte con attenzione. La regola successiva fornisce indicazioni su come farlo.
**Regola 4**
In generale, seleziona le dipendenze i cui obiettivi di disponibilità sono uguali o superiori agli obiettivi del tuo carico di lavoro.
# Disponibilità con ridondanza
Quando un carico di lavoro utilizza sottosistemi multipli, indipendenti e ridondanti, può raggiungere un livello di disponibilità teorica più elevato rispetto all'utilizzo di un singolo sottosistema. Ad esempio, si consideri un carico di lavoro composto da due sottosistemi identici. Può essere completamente operativo se è operativo il sottosistema uno o il sottosistema due. Affinché l'intero sistema sia inattivo, entrambi i sottosistemi devono essere disattivati contemporaneamente.
*Se la probabilità di guasto di un sottosistema è 1 − *α*, allora la probabilità che due sottosistemi ridondanti siano inattivi contemporaneamente è il prodotto della probabilità di guasto di ciascun sottosistema, *F* = (1− *α) × (1− α*1).* 2 *Per un carico di lavoro con due sottosistemi ridondanti, utilizzando l'equazione (3), si ottiene una disponibilità definita come:*
![\[Immagine di tre equazioni\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation5.png)
Quindi, per due sottosistemi la cui disponibilità è del 99%, la probabilità che uno fallisca è dell'1% e la probabilità che entrambi falliscano è (1− 99%) × (1− 99%) = 0,01%. Ciò rende la disponibilità utilizzando due sottosistemi ridondanti del 99,99%.
**Questo può essere generalizzato per incorporare anche ricambi ridondanti aggiuntivi.** Nell'Equazione *(5)* abbiamo ipotizzato solo un singolo pezzo di riserva, ma un carico di lavoro potrebbe avere due, tre o più pezzi di riserva in modo da poter sopravvivere alla perdita simultanea di più sottosistemi senza influire sulla disponibilità. Se un carico di lavoro ha tre sottosistemi e due sono di riserva, la probabilità che tutti e tre i sottosistemi falliscano contemporaneamente è (1− *α*) × (1− *α*) × (1− *α*) o (1− *α*) 3. *In generale, un carico di lavoro con *s unità di riserva avrà esito negativo solo se i sottosistemi* s\$11 falliscono.*
*Per un carico di lavoro con *n* sottosistemi e *s* parti di riserva, *f* è il numero di modalità di errore o i modi in cui *i* sottosistemi s\$11 possono fallire su n.*
******Questo è in effetti il teorema binomiale, la matematica combinatoria che consiste nello scegliere *k elementi da un insieme di n, o «n sceglie k*».****** **In questo caso, k è s \$1 1.**
![\[Immagine di quattro equazioni\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation6.png)
Possiamo quindi produrre un'approssimazione della disponibilità generalizzata che incorpori il numero di modalità di guasto e il risparmio. (Per capire il motivo, in forma approssimativa, fate riferimento all'Appendice 2 di Highleyman, et al. [Rompere la barriera](https://www.amazon.com/Breaking-Availability-Barrier-Survivable-Enterprise/dp/1410792331) della disponibilità.)
![\[Immagine di quattro equazioni\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/availability-and-beyond-improving-resilience/images/equation7.png)
Lo sparing può essere applicato a qualsiasi dipendenza che fornisca risorse che falliscono indipendentemente. Ne sono un esempio le istanze Amazon EC2 in diverse AZ o i bucket Amazon S3 in diverse aree. Regioni AWS L'utilizzo delle risorse di riserva aiuta tale dipendenza a raggiungere una maggiore disponibilità totale per supportare gli obiettivi di disponibilità del carico di lavoro.
**Regola 5**
Usa sparing per aumentare la disponibilità delle dipendenze in un carico di lavoro.
Tuttavia, il risparmio ha un costo. Ogni pezzo di ricambio aggiuntivo ha lo stesso costo del modulo originale, con un costo almeno lineare. La creazione di un carico di lavoro in grado di utilizzare parti di ricambio ne aumenta anche la complessità. Deve saper identificare i fallimenti legati alla dipendenza, assegnare un peso al lavoro e dedicarlo a una risorsa sana e gestire la capacità complessiva del carico di lavoro.
La ridondanza è un problema di ottimizzazione. Troppi pezzi di ricambio e il carico di lavoro può fallire più frequentemente del desiderato, troppe parti di ricambio e l'esecuzione del carico di lavoro costa troppo. Esiste una soglia oltre la quale l'aggiunta di ulteriori ricambi costerà più della disponibilità aggiuntiva garantita.
Utilizzando la nostra formula di disponibilità generale con ricambi, Equation *(7)*, per un sottosistema con una disponibilità del 99,5%, con due unità di riserva la disponibilità del carico di lavoro è *A* ≈ 1 − (1) (1−.995) 3 = 99,9999875% (circa 3,94 secondi di inattività all'anno) e con 10 ricambi otteniamo *A* ≈ 1 − (1) (1−.995) = 11 25,5 9 ′ *s* (il tempo di inattività approssimativo sarebbe di 1,26252 × 10 −15 *m* *s* all'anno, in effetti 0). Confrontando questi due carichi di lavoro, abbiamo registrato un aumento di 5 volte del costo dello risparmio per ottenere quattro secondi di inattività in meno all'anno. Per la maggior parte dei carichi di lavoro, l'aumento dei costi sarebbe ingiustificato per questo aumento della disponibilità. La figura seguente mostra questa relazione.
![\[Diagramma che mostra la diminuzione dei rendimenti derivanti da un maggiore risparmio\]](http://docs.aws.amazon.com/it_it/whitepapers/latest/availability-and-beyond-improving-resilience/images/effect-of-sparing.png)
Con tre ricambi di riserva e oltre, il risultato è una frazione di secondo dei tempi di inattività previsti all'anno, il che significa che dopo questo punto si raggiunge l'area dei rendimenti decrescenti. Potrebbe essere necessario «aggiungere altro» per raggiungere livelli di disponibilità più elevati, ma in realtà i vantaggi in termini di costi scompaiono molto rapidamente. L'utilizzo di più di tre pezzi di ricambio non offre un guadagno sostanziale e notevole per quasi tutti i carichi di lavoro quando il sottosistema stesso ha una disponibilità almeno del 99%.
**Regola 6**
Esiste un limite massimo all'efficienza in termini di costi del risparmio. Utilizzate il minor numero di ricambi necessario per ottenere la disponibilità richiesta.
È necessario considerare l'unità di guasto quando si seleziona il numero corretto di ricambi. Ad esempio, esaminiamo un carico di lavoro che richiede 10 istanze EC2 per gestire la capacità di picco e che vengono distribuite in un'unica AZ.
Poiché le AZ sono progettate per fungere da limiti di isolamento dei guasti, l'unità di errore non è solo una singola istanza EC2, poiché un'intera istanza EC2 può fallire insieme. In questo caso, ti consigliamo di [aggiungere ridondanza con un'altra AZ](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html), implementando 10 istanze EC2 aggiuntive per gestire il carico in caso di errore AZ, per un totale di 20 istanze EC2 (seguendo lo schema di stabilità statica).
Anche se sembrano essere 10 istanze EC2 di riserva, in realtà si tratta solo di una singola istanza AZ di riserva, quindi non abbiamo superato il limite di rendimenti decrescenti. Tuttavia, puoi essere ancora più efficiente in termini di costi e allo stesso tempo aumentare la disponibilità utilizzando tre AZ e implementando cinque istanze EC2 per AZ.
Ciò fornisce una zona di emergenza con un totale di 15 istanze EC2 (rispetto a due AZ con 20 istanze), fornendo comunque le 10 istanze totali necessarie per soddisfare la massima capacità durante un evento che ha un impatto su una singola AZ. Pertanto, è necessario incorporare sparing per garantire la tolleranza agli errori in tutti i limiti di isolamento dei guasti utilizzati dal carico di lavoro (istanza, cella, AZ e regione).
# Teorema CAP
Un altro modo in cui potremmo pensare alla disponibilità è in relazione al teorema CAP. Il teorema afferma che un sistema distribuito, costituito da più nodi che memorizzano dati, non può fornire contemporaneamente più di due delle tre garanzie seguenti:
+ **Coerenza: ogni richiesta di lettura riceve la scrittura più recente o un errore quando la coerenza non può essere garantita.**
+ Disponibilità: ogni richiesta riceve **una** risposta priva di errori, anche quando i nodi sono inattivi o non disponibili.
+ **Tolleranza di partizione: il sistema continua a funzionare nonostante la perdita di un numero arbitrario di messaggi tra i nodi.**
(Per maggiori dettagli, vedere Seth Gilbert e Nancy Lynch, La [http://dl.acm.org/citation.cfm?id=564601&CFID=609557487&CFTOKEN=15997970](http://dl.acm.org/citation.cfm?id=564601&CFID=609557487&CFTOKEN=15997970) (2002), pag. 51-59.)
La maggior parte dei sistemi distribuiti deve tollerare i guasti di rete e, pertanto, deve essere consentito il partizionamento della rete. Ciò significa che questi carichi di lavoro devono scegliere tra coerenza e disponibilità quando si verifica una partizione di rete. Se il carico di lavoro sceglie la disponibilità, restituisce sempre una risposta, ma con dati potenzialmente incoerenti. Se sceglie la coerenza, durante una partizione di rete restituirà un errore poiché il carico di lavoro non può essere sicuro della coerenza dei dati.
Per i carichi di lavoro il cui obiettivo è fornire livelli di disponibilità più elevati, potrebbero scegliere Availability and Partition Tolerance (AP) per evitare che vengano restituiti errori (non essere disponibili) durante una partizione di rete. Ciò comporta la necessità di un [modello di coerenza più rilassato, come la coerenza](https://en.wikipedia.org/wiki/Consistency_model) finale o la coerenza monotona.
# Tolleranza e isolamento dei guasti
Questi sono due concetti importanti quando pensiamo alla disponibilità. La tolleranza ai guasti è la capacità di [resistere ai guasti del sottosistema](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-withstand-component-failures.html) e di mantenere la disponibilità (facendo la cosa giusta entro uno SLA stabilito). Per implementare la tolleranza agli errori, i carichi di lavoro utilizzano sottosistemi di riserva (o ridondanti). Quando uno dei sottosistemi di un set ridondante si guasta, un altro riprende il lavoro, in genere quasi senza interruzioni. In questo caso, i pezzi di ricambio rappresentano una vera e propria capacità inutilizzata, in quanto sono in grado di assorbire il 100% del lavoro del sottosistema guasto. Con True Spares, sono necessari diversi guasti del sottosistema per avere un impatto negativo sul carico di lavoro.
L'isolamento dei guasti riduce al minimo la portata dell'impatto in caso di guasto. Questo viene in genere implementato con la modularizzazione. I carichi di lavoro sono suddivisi in piccoli sottosistemi che si guastano indipendentemente e possono essere riparati in modo isolato. L'errore di un modulo [non si propaga](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-interactions-in-a-distributed-system-to-mitigate-or-withstand-failures.html) oltre il modulo. Questa idea si estende sia verticalmente, attraverso funzionalità diverse in un carico di lavoro, sia orizzontalmente, su più sottosistemi che forniscono le stesse funzionalità. Questi moduli fungono da contenitori di guasti che limitano l'ambito dell'impatto durante un evento.
I modelli architettonici dei piani di controllo, dei piani dati e della stabilità statica supportano direttamente l'implementazione della tolleranza e dell'isolamento dei guasti. L'articolo della Amazon Builders' Library [Stability using Availability Zones](https://aws.amazon.com/builders-library/static-stability-using-availability-zones) fornisce buone definizioni per questi termini e per come si applicano alla creazione di carichi di lavoro resilienti e ad alta disponibilità. Questo white paper utilizza questi modelli nella sezione [Progettazione di sistemi distribuiti ad alta disponibilità suAWS,](designing-highly-available-distributed-systems-on-aws.md#designing-highly-available-distributed-systems-on-aws.title) e qui riassumiamo anche le relative definizioni.
+ **Piano di controllo**: la parte del carico di lavoro coinvolta nell'apportare modifiche: aggiunta di risorse, eliminazione di risorse, modifica delle risorse e propagazione di tali modifiche dove sono necessarie. I piani di controllo sono in genere più complessi e hanno più parti mobili rispetto ai piani dati, quindi statisticamente hanno maggiori probabilità di guasti e hanno una disponibilità inferiore.
+ **Piano dati**: la parte del carico di lavoro che fornisce le day-to-day funzionalità aziendali. I piani dati tendono ad essere più semplici e funzionano a volumi più elevati rispetto ai piani di controllo, con conseguente maggiore disponibilità.
+ **Stabilità statica**: la capacità di un carico di lavoro di continuare a funzionare correttamente nonostante la riduzione della dipendenza. Un metodo di implementazione consiste nel rimuovere le dipendenze dei piani di controllo dai piani dati. Un altro metodo consiste nell'accoppiare liberamente le dipendenze del carico di lavoro. Forse il carico di lavoro non vede alcuna informazione aggiornata (come elementi nuovi, elementi eliminati o elementi modificati) che la sua dipendenza avrebbe dovuto fornire. Tuttavia, tutto ciò che faceva prima che la dipendenza diventasse compromessa continua a funzionare.
Quando pensiamo alla riduzione del carico di lavoro, ci sono due approcci di alto livello che possiamo prendere in considerazione per il recupero. Il primo metodo consiste nel reagire a tale deterioramento dopo che si è verificato, magari aggiungendo nuova capacità. AWS Auto Scaling Il secondo metodo consiste nel prepararsi a tali problemi prima che si verifichino, magari sovradimensionando l'infrastruttura di un carico di lavoro in modo che possa continuare a funzionare correttamente senza la necessità di risorse aggiuntive.
Un sistema staticamente stabile utilizza quest'ultimo approccio. Predispone la capacità inutilizzata per renderla disponibile in caso di guasto. Questo metodo evita di creare una dipendenza da un piano di controllo nel percorso di ripristino del carico di lavoro per fornire nuova capacità di ripristino in caso di guasto. Inoltre, il provisioning di nuova capacità per varie risorse richiede tempo. In attesa di una nuova capacità, il carico di lavoro può essere sovraccaricato dalla domanda esistente e subire un ulteriore degrado, con conseguente «esaurimento» o completa perdita di disponibilità. Tuttavia, è necessario considerare anche le implicazioni in termini di costi dell'utilizzo della capacità preimpostata rispetto agli obiettivi di disponibilità.
La stabilità statica fornisce le due regole successive per i carichi di lavoro ad alta disponibilità.
**Regola 7**
Non fatevi dipendere dai piani di controllo del vostro piano dati, specialmente durante il ripristino.
**Regola 8**
Associa liberamente le dipendenze in modo che il carico di lavoro possa funzionare correttamente nonostante la riduzione della dipendenza, ove possibile.