# Affidabilità
Il pilastro dell’affidabilità comprende la capacità di un carico di lavoro di eseguire la funzione attesa in modo corretto e coerente quando previsto. Ciò comprende la possibilità di utilizzare e testare il carico di lavoro per tutto il ciclo di vita. Il presente documento fornisce linee guida dettagliate sulle best practice per l’implementazione di carichi di lavoro affidabili in AWS.
**Topics**
+ [Modello di responsabilità condivisa per la resilienza](shared-responsibility-model-for-resiliency.md)
+ [Principi di progettazione](design-principles.md)
+ [Definizioni](definitions.md)
+ [Approfondimento sulle esigenze in termini di disponibilità](understanding-availability-needs.md)
# Modello di responsabilità condivisa per la resilienza
La resilienza è una responsabilità condivisa tra te e AWS. È importante comprendere, nell’ambito della resilienza, il funzionamento del disaster recovery (DR) e della disponibilità in questo modello condiviso.
**Responsabilità AWS: resilienza del cloud**
AWS è responsabile della protezione dell’infrastruttura di esecuzione di tutti i servizi offerti nel Cloud AWS. Questa infrastruttura comprende l’hardware, il software, la rete e le strutture che gestiscono i servizi Cloud AWS. AWS compie sforzi commercialmente ragionevoli per rendere disponibili tali servizi Cloud AWS, garantendo che la loro disponibilità soddisfi o superi gli [accordi sul livello di servizio (SLA) di AWS](https://aws.amazon.com/legal/service-level-agreements/).
L’[infrastruttura cloud globale di AWS](https://aws.amazon.com/about-aws/global-infrastructure/) è progettata per consentire ai clienti di creare architetture di carichi di lavoro altamente resilienti. Ogni Regione AWS è completamente isolata e comprende diverse [zone di disponibilità](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/#Availability_Zones), ossia partizioni completamente isolate della nostra infrastruttura. Le zone di disponibilità isolano gli errori che potrebbero influire sulla resilienza del carico di lavoro, impedendo loro di interessare altre zone nella regione. Allo stesso tempo, tutte le zone in una Regione AWS sono interconnesse con reti a larghezza di banda elevata e a bassa latenza, su una fibra ottica metropolitana dedicata e completamente ridondante che fornisce una rete ad alto throughput e bassa latenza tra le zone. Tutto il traffico tra zone è crittografato. Le prestazioni di rete sono adeguate per l’esecuzione della replica sincrona tra zone. In caso di partizione di un’applicazione tra zone di disponibilità, le aziende sono isolate e protette meglio da problemi come interruzioni dell’alimentazione, fulmini, tornado, uragani e altro ancora.
**Responsabilità del cliente: resilienza del cloud**
La tua responsabilità è determinata dai servizi Cloud AWS che scegli. La scelta definisce l’entità delle attività di configurazione che devi eseguire nell’ambito delle tue responsabilità nell’ambito della resilienza. Ad esempio, un servizio come Amazon Elastic Compute Cloud (Amazon EC2) richiede che il cliente esegua tutte le attività di configurazione e gestione della resilienza necessarie. I clienti che implementano istanze Amazon EC2 sono responsabili dell’[implementazione delle istanze Amazon EC2 in più sedi](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/use-fault-isolation-to-protect-your-workload.html) (come le zone di disponibilità AWS), dell’[implementazione della riparazione automatica](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-withstand-component-failures.html) tramite servizi come Auto Scaling e dell’utilizzo delle [best practice per un’architettura resiliente per carichi di lavoro](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/workload-architecture.html) per le applicazioni installate sulle istanze. Per i servizi gestiti, come Amazon S3 e Amazon DynamoDB, AWS si occupa del livello dell’infrastruttura, del sistema operativo e delle piattaforme, mentre i clienti accedono agli endpoint per archiviare e recuperare i dati. Tu hai la responsabilità della gestione della resilienza dei dati, incluse le strategie di backup, controllo delle versioni e replica.
L’implementazione del carico di lavoro in più zone di disponibilità in una Regione AWS è parte di una strategia di disponibilità elevata progettata per proteggere i carichi di lavoro isolando i problemi in una zona di disponibilità, usando la ridondanza delle altre zone di disponibilità per continuare a gestire le richieste. Un’architettura multi-AZ è parte anche di una strategia di disaster recovery progettata per isolare e proteggere meglio i carichi di lavoro da problemi come le interruzioni dell’alimentazione, i fulmini, i tornado, i terremoti e altri ancora. Le strategie di disaster recovery possono usare anche più Regioni AWS. Ad esempio, in una configurazione con approccio attivo/passivo, il servizio per il carico di lavoro esegue il failover dalla regione attiva alla regione di disaster recovery se la regione attiva non può più gestire le richieste.
![\[Grafico che mostra il modello di resilienza condiviso.\]](http://docs.aws.amazon.com/it_it/wellarchitected/latest/reliability-pillar/images/shared-model-resiliency.png)
Puoi usare servizi AWS per realizzare gli obiettivi di resilienza. Come cliente, sei responsabile della gestione degli aspetti seguenti del sistema per realizzare la resilienza nel cloud. Per maggiori dettagli su ciascun servizio in particolare, consulta la [ documentazione AWS](https://docs.aws.amazon.com/index.html).
**Reti, quote e vincoli**
+ La sezione [Fondamenti](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/foundations.html) illustra le best practice per quest’area del modello di responsabilità condivisa.
+ Pianifica la tua architettura con un margine di scalabilità adeguato e analizza le [quote di servizio](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/manage-service-quotas-and-constraints.html), nonché i vincoli dei servizi inclusi, in base agli aumenti previsti delle richieste di carico, laddove applicabile.
+ Progetta la [topologia di rete](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-your-network-topology.html) in modo che sia altamente disponibile, ridondante e scalabile.
**Gestione delle modifiche e resilienza operativa**
+ La [gestione delle modifiche](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/change-management.html) comprende le modalità di introduzione e gestione delle modifiche nell’ambiente. L’[implementazione delle modifiche](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/implement-change.html) richiede la creazione e l’aggiornamento di runbook e strategie di implementazione per l’applicazione e l’infrastruttura.
+ Una strategia resiliente per il [monitoraggio delle risorse del carico di lavoro](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/monitor-workload-resources.html) tiene conto di tutti i componenti, ivi comprese metriche tecniche e aziendali, notifiche, automazione e analisi.
+ I carichi di lavoro nel cloud devono [adattarsi ai cambiamenti nella domanda](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-adapt-to-changes-in-demand.html) in senso di riduzione orizzontale in risposta a riduzioni o fluttuazioni nell’utilizzo.
**Osservabilità e gestione dei guasti**
+ L’osservazione dei guasti attraverso il monitoraggio è necessaria per automatizzare la correzione in modo che i carichi di lavoro possano [resistere ai guasti dei componenti](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/design-your-workload-to-withstand-component-failures.html).
+ La [gestione dei guasti](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/failure-management.html) richiede il [backup dei dati](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/back-up-data.html), l’applicazione delle best practice per consentire al carico di lavoro di resistere ai guasti dei componenti e la [pianificazione del disaster recovery](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html).
**Architettura del carico di lavoro**
+ L’[architettura del carico di lavoro](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/workload-architecture.html) include la progettazione di servizi in base ai domini aziendali, l’applicazione della SOA e la progettazione di sistemi distribuiti per prevenire i guasti e l’integrazione di funzionalità come limitazione (della larghezza di banda della rete), nuovi tentativi, gestione delle code, timeout e leve di emergenza.
+ Affidati a [soluzioni AWS](https://aws.amazon.com/solutions/) comprovate, ad [Amazon Builders’ Library](https://aws.amazon.com/builders-library/) e a [modelli serverless](https://serverlessland.com/patterns) per allinearti alle best practice e avviare subito le implementazioni.
+ Apporta miglioramenti continui per scomporre il sistema in servizi distribuiti per una scalabilità e un’innovazione più rapide. Utilizza le indicazioni relative ai [microservizi AWS](https://aws.amazon.com/microservices/) e le opzioni di servizio gestito per semplificare e accelerare la tua capacità di introdurre modifiche e innovazioni.
**Esecuzione continua di test dell’infrastruttura critica**
+ [Testare l’affidabilità](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/test-reliability.html) significa eseguire test a livello funzionale, prestazionale e di caos, nonché adottare l’analisi degli incidenti e le pratiche delle giornate di gioco per acquisire competenze nella risoluzione di problemi non ben compresi.
+ Per applicazioni interamente nel cloud e ibride, la conoscenza del loro comportamento quando si verificano problemi o in caso di arresto dei componenti permette di recuperare rapidamente e in modo affidabile dalle interruzioni.
+ Crea e documenta esperimenti ripetibili per identificare il comportamento del sistema in situazioni impreviste. Questi test dimostreranno l’efficacia della resilienza complessiva e forniranno un ciclo di feedback per le procedure operative prima di affrontare scenari di errore reali.
# Principi di progettazione
Nel cloud, sono presenti una serie di principi utili per aumentare l’affidabilità. Tieni presente quanto segue quando si discute delle best practice:
+ **Ripristino automatico in caso di guasto:** monitorando un carico di lavoro per gli indicatori chiave di prestazioni (KPI), puoi avviare l’automazione in caso di violazione di una soglia. Questi KPI dovrebbero essere una misura del valore aziendale, non degli aspetti tecnici del funzionamento del servizio. Ciò consente la notifica e il tracciamento automatici degli errori e i processi di recupero automatizzati che aggirano o riparano l’errore. Con un’automazione più sofisticata, è possibile anticipare e correggere gli errori prima che si verifichino.
+ **Test delle procedure di ripristino:** in un ambiente on-premises, spesso vengono eseguiti test per dimostrare che il carico di lavoro funziona in uno scenario specifico. I test non vengono in genere utilizzati per convalidare le strategie di ripristino. Nel cloud, puoi testare il modo in cui il carico di lavoro incorre nell’errore e convalidare le procedure di ripristino. Puoi utilizzare l’automazione per simulare diversi errori o ricreare scenari che in precedenza hanno portato a errori. Questo approccio presenta percorsi di errore che è possibile testare e correggere *prima* che si verifichi uno scenario di errore reale, riducendo così il rischio.
+ **Scalare a livello orizzontale per aumentare la disponibilità dei carichi di lavoro aggregati:** sostituisci una risorsa grande con più risorse piccole per ridurre l’impatto di un singolo guasto sul carico di lavoro complessivo. Distribuisci le richieste tra più risorse di dimensioni inferiori per garantire che non condividano un punto di errore comune.
+ **Smetti di fare ipotesi sulla capacità:** una causa comune di guasti nei carichi di lavoro on-premises è la saturazione delle risorse, quando le richieste assegnate a un carico di lavoro superano la capacità di quel carico di lavoro (questo è spesso l’obiettivo di attacchi di tipo Denial of Service). Nel cloud, è possibile monitorare la domanda e l’utilizzo dei carichi di lavoro, nonché automatizzare l’aggiunta o la rimozione di risorse per mantenere il livello ottimale, al fine di soddisfare la domanda senza un provisioning eccessivo o inferiore. Esistono ancora limiti, ma alcune quote possono essere controllate e altre possono essere gestite (consulta [Gestione di Service Quotas e vincoli](manage-service-quotas-and-constraints.md)).
+ **Gestione del cambiamento tramite l’’automazione**: le modifiche all’infrastruttura andrebbero apportate utilizzando l’automazione. Le modifiche da gestire includono quelle all’automazione, che possono quindi essere monitorate e revisionate.
# Definizioni
Il presente whitepaper si occupa dell’affidabilità nel cloud, illustrando le best practice per queste quattro aree:
+ Fondamenti
+ Architettura del carico di lavoro
+ Gestione delle modifiche
+ Gestione dei guasti
Per garantire l’affidabilità, è necessario iniziare dalle basi: un ambiente in cui le quote di servizio e la topologia di rete sono in grado di supportare il carico di lavoro. L’architettura del carico di lavoro del sistema distribuito deve essere progettata per prevenire e mitigare i guasti. Il carico di lavoro deve gestire le variazioni nella domanda o nei requisiti e deve essere progettato per rilevare il guasto e applicare autonomamente le correzioni in automatico.
**Topics**
+ [Resilienza e componenti dell’affidabilità](resiliency-and-the-components-of-reliability.md)
+ [Disponibilità](availability.md)
+ [Obiettivi di disaster recovery (DR)](disaster-recovery-dr-objectives.md)
# Resilienza e componenti dell’affidabilità
L’affidabilità di un carico di lavoro nel cloud dipende da diversi fattori, il principale dei quali è la *resilienza*:
+ La **resilienza** è la capacità di un carico di lavoro di ripristinarsi a seguito di interruzioni dell’infrastruttura o del servizio, acquisire in modo dinamico le risorse di calcolo per soddisfare la domanda e mitigare le interruzioni, quali configurazioni errate o problemi di rete transitori.
Gli altri fattori che influiscono sull’affidabilità del carico di lavoro sono:
+ Eccellenza operativa, che include l’automazione delle modifiche, l’uso di playbook per rispondere ai guasti e le revisioni sulla prontezza operativa (ORR) per confermare che le applicazioni sono pronte per le operazioni di produzione.
+ Sicurezza, che include la prevenzione di danni ai dati o all’infrastruttura da parte di malintenzionati, che comprometterebbero la disponibilità. Ad esempio, crittografare i backup per garantire la sicurezza dei dati.
+ Efficienza delle prestazioni, che include la progettazione di tassi massimi di richiesta e la riduzione al minimo delle latenze per il carico di lavoro.
+ Ottimizzazione dei costi, che include compromessi quali spendere di più sulle istanze EC2 per ottenere stabilità statica oppure fare affidamento sulla scalabilità automatica quando è necessaria una maggiore capacità.
La resilienza è l’obiettivo principale di questo whitepaper.
Anche gli altri quattro aspetti sono importanti e sono illustrati nei rispettivi pilastri del [Framework AWS Well-Architected](https://aws.amazon.com/architecture/well-architected/). Molte delle best practice qui presenti affrontano anche gli aspetti relativi all’affidabilità, ma l’attenzione è focalizzata sulla resilienza.
# Disponibilità
La *disponibilità* (nota anche come *disponibilità del servizio*) è una metrica usata comunemente sia per misurare in termini quantitativi la resilienza sia come obiettivo target della resilienza.
+ La **disponibilità** è la percentuale di tempo per cui un carico di lavoro è disponibile per l’uso.
*Disponibile per l’uso* significa che la funzione concordata viene eseguita correttamente quando occorre.
Questa percentuale si calcola su un periodo di tempo, ad esempio un mese, un anno o tre anni consecutivi. Applicando l’interpretazione più rigida possibile, la disponibilità viene ridotta ogni volta che l’applicazione non funziona normalmente, incluse le interruzioni pianificate e non pianificate. Ecco la definizione di *disponibilità*:
![\[\]](http://docs.aws.amazon.com/it_it/wellarchitected/latest/reliability-pillar/images/availability-formula.png)
+ la disponibilità è una percentuale del tempo di attività (come il 99,9%) per un periodo di tempo (di norma un mese o un anno)
+ Un modo di dire comune si riferisce solo al "numero di nove", ad esempio "cinque nove" significa una disponibilità del 99,999%
+ Alcuni clienti scelgono di escludere i tempi di inattività del servizio pianificati (ad esempio, manutenzione pianificata) dal tempo totale nella formula del *tempo totale*. Tuttavia, questo approccio non è consigliato, poiché gli utenti probabilmente vorranno usare il tuo servizio in quei momenti.
Ecco una tabella relativa agli obiettivi di progettazione di disponibilità delle applicazioni comuni e il periodo di tempo massimo durante il quale le interruzioni possono verificarsi entro un anno pur raggiungendo l’obiettivo. La tabella presenta esempi dei tipi di applicazioni che di solito vediamo a ogni livello di disponibilità. In questo documento, ci riferiamo a questi valori.
| Disponibilità | Indisponibilità massima (per anno) | Categorie dell’applicazione |
| --- | --- | --- |
| 99% | 3 giorni 15 ore | Elaborazione batch, estrazione dati, trasferimento e caricamento di lavori |
| 99,9% | 8 ore 45 minuti | Strumenti interni come knowledge management, monitoraggio dei progetti |
| 99,95% | 4 ore 22 minuti | Commercio online, POS |
| 99,99% | 52 minuti | Carichi di lavoro di video e trasmissione |
| 99,999% | 5 minuti | Transazioni bancomat, carichi di lavoro di telecomunicazione |
**Misurazione della disponibilità in base alle richieste.** Per il tuo servizio, potrebbe essere più facile conteggiare le richieste non andate a buon fine e quelle andate a buon fine, invece del "tempo disponibile per l’utilizzo". In questo caso, è possibile usare il seguente calcolo:
![\[Mathematical formula for calculating availability using successful responses divided by valid requests.\]](http://docs.aws.amazon.com/it_it/wellarchitected/latest/reliability-pillar/images/availability-formula-requests.png)
Questo viene spesso misurato per periodi di un minuto o di cinque minuti. Quindi, è possibile calcolare una percentuale di tempo di attività mensile (misurazione della disponibilità in base al tempo) dalla media di tali periodi. In caso di assenza di richieste in un dato periodo, viene conteggiato come disponibile al 100% per il periodo in questione.
**Calcolo della disponibilità con forti dipendenze.** Molti sistemi presentano forti dipendenze con altri sistemi, nei quali un’interruzione in un sistema dipendente si traduce direttamente in un’interruzione del sistema di richiamo. Ciò si contrappone a una dipendenza leggera, in cui l’applicazione compensa un guasto del sistema dipendente. In presenza di tali forti dipendenze, la disponibilità del sistema di richiamo è il prodotto delle disponibilità dei sistemi dipendenti. Ad esempio, se disponi di un sistema progettato per una disponibilità del 99,99% con una forte dipendenza da due altri sistemi indipendenti, ciascuno progettato per una disponibilità del 99,99%, il carico di lavoro può teoricamente raggiungere il 99,97% di disponibilità:
Availinvok × Avail*dep1* × Avail*dep2* = Availworkload
99,99% × 99,99% × 99,99% = 99,97%
Pertanto, è importante conoscere le tue dipendenze e i loro obiettivi di progettazione in termini di disponibilità mentre calcoli i tuoi.
**Calcolo della disponibilità con componenti ridondanti.** Quando un sistema prevede l’uso di componenti indipendenti e ridondanti (ad esempio, risorse ridondanti in diverse zone di disponibilità), la disponibilità teorica si calcola come 100% meno il prodotto delle percentuali di guasto dei componenti. Ad esempio, se un sistema utilizza due componenti indipendenti, ciascuno con una disponibilità del 99,9%, la disponibilità effettiva di tale dipendenza è del 99,9999%:
![\[Diagram showing calculation of availability with redundant components in a system.\]](http://docs.aws.amazon.com/it_it/wellarchitected/latest/reliability-pillar/images/image2.png)
Availeffective = *Avail*MAX − ((100%−Availdependency)×(100%−Availdependency))
99,9999% = 100% − (0,1%×0,1%)
*Calcolo abbreviato*: se le disponibilità di tutti i componenti nel tuo calcolo consistono solamente di nove, allora puoi sommare il numero di nove per ottenere una risposta. Nell’esempio precedente, due componenti indipendenti ridondanti con disponibilità a tre nove totalizzano sei nove.
**Calcolo della disponibilità delle dipendenze.** Alcune dipendenze forniscono linee guida sulla loro disponibilità, inclusi gli obiettivi di progettazione in termini di disponibilità per molti servizi AWS. Tuttavia, nei casi in cui esse non siano disponibili (ad esempio, un componente in cui il produttore non pubblica informazioni sulla disponibilità), un modo per effettuare una stima è determinare il **tempo medio tra guasti (MTBF)** e il **tempo medio di ripristino (MTTR)**. È possibile stabilire una stima della disponibilità mediante:
![\[\]](http://docs.aws.amazon.com/it_it/wellarchitected/latest/reliability-pillar/images/avail-est-formula.png)
Ad esempio, se l’MTBF è di 150 giorni e l’MTTR è di 1 ora, la stima della disponibilità è pari al 99,97%.
Per ulteriori dettagli, consulta [Availability and Beyond: Understanding and improving the resilience of distributed systems on AWS](https://docs.aws.amazon.com/whitepapers/latest/availability-and-beyond-improving-resilience/availability-and-beyond-improving-resilience.html), utile per calcolare la tua disponibilità.
**Costi per la disponibilità.** La progettazione di applicazioni per livelli più elevati di disponibilità comporta in genere un aumento dei costi, quindi è opportuno identificare le reali esigenze in termini di disponibilità prima di iniziare la progettazione dell’applicazione. Elevati livelli di disponibilità impongono requisiti più severi per test e convalida in scenari di guasto completo. Questi richiedono l’automazione per il ripristino da tutti i tipi di guasti, oltre alla realizzazione e al test di tutti gli aspetti delle operazioni di sistema in modo simile, secondo gli stessi standard. Ad esempio, l’aggiunta o la rimozione di capacità, l’implementazione o il rollback del software aggiornato o le modifiche alla configurazione o la migrazione dei dati di sistema devono essere condotti nel rispetto dell’obiettivo di disponibilità desiderato. Oltre ai costi per lo sviluppo del software, con livelli di disponibilità molto elevati, l’innovazione ne risente a causa della necessità di procedere più lentamente nell’implementazione dei sistemi. Il suggerimento, pertanto, è di essere rigorosi nell’applicazione degli standard e nel considerare l’obiettivo di disponibilità adeguato per l’intero ciclo di vita del funzionamento del sistema.
Un altro modo in cui i costi aumentano nei sistemi che operano con obiettivi di progettazione ad alta disponibilità riguarda la selezione delle dipendenze. A questi obiettivi più elevati, il set di software o servizi che è possibile scegliere come dipendenze diminuisce in base a quali di questi servizi hanno beneficiato di ingenti investimenti discussi in precedenza. Man mano che l’obiettivo di progettazione della disponibilità aumenta, è tipico trovare meno servizi multiuso (ad esempio un database relazionale) e più servizi dedicati. Questo poiché questi ultimi sono più facili da valutare, testare e automatizzare e presentano un potenziale ridotto di interazioni imprevedibili con funzionalità incluse, ma inutilizzate.
# Obiettivi di disaster recovery (DR)
Oltre agli obiettivi di disponibilità, la strategia di resilienza deve includere obiettivi di disaster recovery (DR) basati su strategie per ripristinare il carico di lavoro in caso di un evento di emergenza. Il disaster recovery è incentrato su obiettivi di ripristino una tantum in risposta a disastri naturali, errori tecnici su larga scala o minacce umane, come attacchi o errori. Si tratta di un parametro diverso rispetto alla disponibilità che misura la resilienza su un periodo di tempo in risposta a guasti di componenti, picchi di carico e bug di software.
**Obiettivo del tempo di ripristino (RTO)** definito dall’organizzazione. L’RTO è il ritardo massimo accettabile tra l’interruzione del servizio e il relativo ripristino. Questo determina ciò che viene considerato un intervallo di tempo accettabile in caso di indisponibilità del servizio.
**Obiettivo del punto di ripristino (RPO)** definito dall’organizzazione. L’RPO è il periodo di tempo massimo accettabile dall’ultimo punto di ripristino dei dati. Questo determina ciò che si considera una perdita di dati accettabile tra l’ultimo punto di ripristino e l’interruzione del servizio.
![\[Business continuity timeline showing RPO, disaster event, and RTO with data loss and downtime periods.\]](http://docs.aws.amazon.com/it_it/wellarchitected/latest/reliability-pillar/images/business-continuity.png)
*Relazione tra RPO, RTO ed evento di emergenza.*
L’RTO è simile all’MTTR (tempo medio di ripristino), in quanto entrambi misurano il tempo tra l’inizio di un’interruzione e il ripristino del carico di lavoro. Tuttavia, l’MTTR è un valore medio acquisito su diversi eventi che influiscono sulla disponibilità in un periodo di tempo, mentre l’RTO è un obiettivo, o un valore massimo consentito, per un *singolo* evento che influisce sulla disponibilità.
# Approfondimento sulle esigenze in termini di disponibilità
Di solito si pensa alla disponibilità di un’applicazione come a un singolo obiettivo per l’applicazione nel suo insieme. Tuttavia, a un’analisi più attenta, spesso scopriamo che alcuni aspetti di un’applicazione o di un servizio presentano requisiti di disponibilità diversi. Ad esempio, alcuni sistemi potrebbero dare priorità alla capacità di ricevere e archiviare nuovi dati prima del recupero dei dati esistenti. Altri sistemi danno la priorità alle operazioni in tempo reale rispetto a quelle che modificano la configurazione o l’ambiente di un sistema. I servizi potrebbero avere requisiti di disponibilità molto elevati durante determinate ore del giorno, ma possono tollerare periodi di interruzione molto più lunghi al di fuori di questi orari. Questi sono alcuni dei modi in cui è possibile scomporre una singola applicazione in parti costitutive e valutarne i requisiti in termini di disponibilità. Il vantaggio di questo approccio è concentrare gli sforzi (e le spese) sulla disponibilità in base alle esigenze specifiche, piuttosto che progettare l’intero sistema in base ai requisiti più rigidi.
| Raccomandazione |
| --- |
| Valuta in modo critico gli aspetti unici delle tue applicazioni e, dove necessario, differenzia gli obiettivi di progettazione della disponibilità e del disaster recovery per riflettere le esigenze della tua azienda. |
All’interno di AWS, dividiamo di solito i servizi in "piano dati" e "piano di controllo (control-plane)". Il piano dati è responsabile della fornitura del servizio in tempo reale mentre i piani di controllo (control-plane) consentono di configurare l’ambiente. Ad esempio, le istanze Amazon EC2, i database Amazon RDS e le operazioni di lettura/scrittura su tabelle di Amazon DynamoDB sono tutte operazioni sul piano dati. Al contrario, l’avvio di nuove istanze EC2 o database RDS o l’aggiunta o la modifica di metadati delle tabelle di DynamoDB sono tutte considerate operazioni sul piano di controllo (control-plane). Sebbene elevati livelli di disponibilità siano importanti per tutte queste funzionalità, i piani dati hanno in genere obiettivi di progettazione di disponibilità più elevati rispetto ai piani di controllo (control-plane). Pertanto, i carichi di lavoro con requisiti di alta disponibilità dovrebbero evitare dipendenze di runtime su operazioni sul piano di controllo (control-plane).
Molti clienti AWS adottano un approccio analogo alla valutazione critica delle loro applicazioni e all’identificazione di componenti secondari con diverse esigenze di disponibilità. Gli obiettivi di progettazione della disponibilità vengono quindi adattati ai diversi aspetti e si adottano le opportune iniziative di lavoro per progettare il sistema. AWS vanta una grande un’esperienza nella progettazione di applicazioni con una serie di obiettivi di progettazione della disponibilità, inclusi servizi con una disponibilità del 99,999% o superiore. AWS I Solution Architects (SA) possono aiutarti a effettuare una progettazione adeguata ai tuoi obiettivi di disponibilità. Il coinvolgimento di AWS nelle prime fasi del processo di progettazione migliora la nostra capacità di aiutarti a raggiungere i tuoi obiettivi di disponibilità. La pianificazione della disponibilità non viene eseguita solo prima dell’avvio del carico di lavoro, ma in modo continuo per perfezionare la progettazione man mano che acquisisci esperienza operativa, impari da eventi reali e superi guasti di diversi tipi. È quindi possibile applicare l’iniziativa di lavoro opportuna per migliorare l’implementazione.
Le esigenze di disponibilità necessarie per un carico di lavoro devono essere allineate a esigenze e criticità aziendali. Definendo innanzitutto il framework di criticità aziendale con RTO, RPO e disponibilità definiti, è possibile valutare ciascun carico di lavoro. Tale approccio richiede che le persone coinvolte nell’implementazione del carico di lavoro conoscano framework e impatto del loro carico di lavoro sulle esigenze aziendali.