Disponibilità - Pilastro dell'affidabilità

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à:

$\text{Availability} = \ \frac{\text{Available}\ \text{for}\ \text{Use}\ \text{Time}}{\text{Total}\ \text{Time}}$
  • 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:

$\text{Availability} = \ \frac{\text{Successful}\ \text{Responses}\}{\text{Valid}\ \text{Requests}}$

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 × Availdep1 × Availdep2 = 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%:

Availeffective = AvailMAX − ((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:

$$\text{Avail}_{\text{EST}} = \frac{\text{MTBF}}{MTBF + MTTR}$$

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, 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.