Scenario a due 9 (99%)

Questi carichi di lavoro sono utili per l'azienda, ma la loro indisponibilità costituisce solo un inconveniente. Questo tipo di carico di lavoro può corrispondere a strumentazione interna, gestione interna delle conoscenze o monitoraggio dei progetti. Oppure può trattarsi di carichi di lavoro effettivi rivolti al cliente ma serviti da un servizio sperimentale, con un interruttore di funzionalità in grado di nascondere il servizio, se necessario.

Questi carichi di lavoro possono essere distribuiti con una regione e una zona di disponibilità.

Monitoraggio delle risorse

Avremo un monitoraggio semplice, indicando se la home page del servizio sta restituendo uno stato HTTP 200 (OK). In caso di problemi, il nostro playbook indicherà che il log dall'istanza verrà utilizzato per stabilire la causa principale.

Adattarsi alle modifiche nella domanda

Avremo playbook per i guasti hardware comuni, gli aggiornamenti software urgenti e altre modifiche che causano interruzioni.

Implementazione delle modifiche

Utilizzeremo AWS CloudFormation per definire il nostro modello Infrastructure as code e in particolare per accelerare la ricostruzione in caso di guasto.

Gli aggiornamenti software avverranno in manuale, utilizzando un runbook, con tempi di inattività richiesti per l'installazione e il riavvio del servizio. In caso di problemi durante l'implementazione, il runbook illustra come ripristinare la versione precedente.

Eventuali correzioni dell'errore avvengono utilizzando l'analisi dei log da parte dei team operativi e di sviluppo e la correzione viene implementata dopo aver completato e stabilito la priorità della soluzione.

Esecuzione del backup dei dati

Utilizzeremo un fornitore o una soluzione di backup appositamente creata per inviare dati di backup crittografati ad Amazon S3 utilizzando un runbook. Verificheremo il funzionamento dei backup ripristinando i dati e garantendo la possibilità di usarli su base regolare mediante un runbook. Configuriamo il controllo delle versioni sui nostri oggetti Amazon S3 e rimuoveremo le autorizzazioni per l'eliminazione dei backup. Usiamo una policy del ciclo di vita del bucket Amazon S3 per archiviare o eliminare definitivamente i dati in base ai nostri requisiti.

Architettura mirata alla resilienza

I carichi di lavoro vengono implementati con una regione e una zona di disponibilità. Implementiamo l'applicazione, incluso il database, in un'unica istanza.

Testare la resilienza

È prevista una pipeline di implementazione del nuovo software, con alcuni test di unità, ma si tratta principalmente di test white-box/black-box del carico di lavoro assemblato.

Pianificazione per il ripristino di emergenza

In caso di guasto, attendiamo il completamento dell'errore, con la possibilità di instradare le richieste a un sito Web statico utilizzando la modifica DNS tramite un runbook. Il tempo di ripristino sarà determinato dalla velocità di implementazione dell'infrastruttura e da quella di ripristino del database al backup più recente. Questa implementazione può trovarsi nella stessa zona di disponibilità o in una diversa in caso di guasto della zona di disponibilità mediante un runbook.

Obiettivo di progettazione della disponibilità

Servono 30 minuti per comprendere e decidere di richiamare il ripristino, 10 minuti per distribuire l'intero stack in AWS CloudFormation, presupponendo di implementare in una nuova zona di disponibilità e che il database possa essere ripristinato in 30 minuti. Questo implica che occorrono circa 70 minuti per ripristinare un guasto. Supponendo un guasto per trimestre, il nostro tempo di impatto stimato per l'anno è di 280 minuti, ossia quattro ore e 40 minuti.

Ciò significa che il limite massimo di disponibilità è del 99,9%. La disponibilità effettiva dipenderà anche dal tasso reale di guasto, dalla durata dello stesso e dalla relativa rapidità di ripristino. Per questa architettura, prevediamo che l'applicazione sia offline durante gli aggiornamenti (stima di 24 ore all'anno: quattro ore per aggiornamento, sei volte all'anno), oltre agli eventi reali. Quindi, facendo riferimento alla tabella sulla disponibilità delle applicazioni più sopra nel whitepaper, vediamo che il nostro obiettivo di progettazione della disponibilità è del 99%.

Riepilogo

Argomento	Implementazione
Monitoraggio delle risorse	Solo controllo dell'integrità del sito; nessun avviso.
Adattarsi alle modifiche nella domanda	Scalabilità verticale tramite nuova implementazione.
Implementazione delle modifiche	Runbook per implementazione e rollback.
Esecuzione del backup dei dati	Runbook per backup e ripristino.
Architettura mirata alla resilienza	Ricostruzione completa; ripristino tramite backup.
Testare la resilienza	Ricostruzione completa; ripristino tramite backup.
Pianificazione per il ripristino di emergenza	Backup crittografati, ripristino in una zona di disponibilità diversa, se necessario.