NOTA / 02.A.01
Il problema
Una piattaforma può avere più server e conservare un singolo punto di interruzione: database, identità amministrativa, storage, rete o provider. Il progetto parte dal valore del servizio e dalle conseguenze della sua indisponibilità.
NOTA / 02.A.02
Gli obiettivi di continuità
RTO — Recovery Time Objective — esprime il tempo di ripristino richiesto. RPO — Recovery Point Objective — definisce la perdita di dati recenti tollerabile. Gli obiettivi vengono concordati sulle funzioni applicative da recuperare, non soltanto sull’avvio dei server.
NOTA / 02.A.03
L’architettura e i domini di guasto
HA — High Availability —, load balancing e replica vengono valutati rispetto ai failure domain effettivi. Il progetto considera consistenza del database, dipendenze comuni e comportamento durante una partizione di rete. Una replica non sostituisce il recupero da un errore logico propagato.
NOTA / 02.A.04
Dalla progettazione al servizio
L’implementazione può comprendere bilanciamento, database HA, copie segregate e procedure di promozione e ripristino. Compute, storage e rete possono essere erogati da provider terzi; responsabilità e dipendenze restano esplicite.
NOTA / 02.A.05
Come si verifica
Le prove concordate osservano il comportamento in caso di guasto e il ritorno delle funzioni applicative. Tempi misurati e punto dei dati recuperato vengono confrontati con RTO e RPO. Il restore viene verificato attraverso l’utilizzabilità del servizio.
NOTA / 02.A.06
Gestione e impegni operativi
SLA — Service Level Agreement —, tempi di intervento, monitoring ed escalation vengono definiti quando previsti dall’incarico. I risultati di una prova descrivono le condizioni osservate e non costituiscono da soli una garanzia per ogni guasto possibile.