Se qualcosa può andare male, lo farà.

Parte 1: Introduzione (questa)
Parte 2: Ingegneria tradizionale - Schemi architetturali
Parte 3: Ingegneria tradizionale - Schemi di programmazione

Quando si crea qualsiasi tipo di servizio, molte cose possono andare storte durante la sua vita, dai tipici bug degli sviluppatori fino agli eventi del cigno nero, come un data center che va offline.

Osservando la complessità del sistema e gli errori che comporta, nel grafico seguente, da un lato abbiamo la probabilità di fallimento e dall'altro il rango, che è definito nell'ordine dal più probabile al meno probabile.

Andando da sinistra a destra, abbiamo gli errori più probabili che sono cose come errori fuori da 1, bug generici dello sviluppatore, errori transitori, carenza di risorse ecc. Quindi attraversiamo il limite del fallimento in operazioni reattive che sono "probabilmente non dovremmo fare di nuovo" o "chiama questa persona per farlo riparare".

E infine l' ignoto che sono le cose che non ci aspettiamo e le cose che escono dal nulla.

Le 3 categorie di cui sopra possono essere suddivise nelle seguenti (elenco non esaustivo) "correzioni".

1. Ingegneria tradizionale

• Modelli architettonici
• Schemi di programmazione
• Standard di codifica
• Test

• Metriche, registri e avvisi
• Segnalazione delle funzionalità
• Test canarino
• Documentazione
• Rotazione su chiamata
• Autoguarigione
• Post mortem

• Ingegneria del caos
• Tempo di attività inverso

Graziosa degradazione

Correre in uno stato degradato sarà quasi sempre meglio che non correre affatto.

Gran parte della letteratura e del pensiero sulla resilienza si evolve intorno al Grazioso degrado.

Vendemmia ( whitepaper qui )

Harvest è funzione Data available / Total datao, in altre parole, della veridicità di una data query.

Supponiamo di avere un motore di ricerca composto da 100 partizioni di dati.

Se 1 partizione scende, abbiamo un raccolto del 99%, che nella maggior parte dei casi andrà più che bene.

L'esecuzione in uno stato degradato è strettamente correlata al modello di fallback o ai percorsi di fallback come possono anche essere chiamati.

Utilizzando percorsi di fallback intelligenti per le dipendenze in errore e assicurandoti che il tuo servizio non si interrompa di fronte a un errore, potresti comunque servire query ai tuoi utenti/dipendenti a monte.

In breve, l'utente preferirebbe di gran lunga avere un'esperienza piuttosto che nessuna esperienza.

Resilienza del servizio stateful vs stateless

Cos'è lo stato?

Considera una semplice applicazione di conteggio;

O potrebbe mantenere il conteggio corrente in memoria, questa sarebbe considerata un'applicazione con stato.

O

Potrebbe mantenere il conteggio corrente in un database, questa sarebbe un'applicazione senza stato.

Ciò tuttavia non significa che se il tuo servizio salva le cose in un database, è senza stato.

Potresti avere un'applicazione che esegue calcoli in più passaggi a lungo termine, questa sarebbe considerata un'applicazione con stato, poiché lo stato viene gestito dall'applicazione.

Considerando la resilienza per un'applicazione del genere, il peggio che può accadere è che il servizio venga arrestato senza preavviso nel mezzo di un passaggio.

Tenendo traccia delle fasi di calcolo o dei calcoli intermedi e persistendo in questo stato, potrebbe essere un modo per gestire tale scenario.

Domanda da considerare durante la progettazione e lo sviluppo di applicazioni altamente affidabili

• Quali obiettivi e metriche di affidabilità hai definito per la tua applicazione?
• In che modo hai assicurato che l'architettura della tua applicazione sia resiliente ai guasti?
• In che modo avete garantito la disponibilità della capacità e dei servizi richiesti nelle regioni target?
• Come gestisci il ripristino di emergenza per questo carico di lavoro?
• Quali decisioni sono state prese per garantire che la piattaforma applicativa soddisfi i requisiti di affidabilità?
• Quali decisioni sono state prese per garantire che la piattaforma dati soddisfi i requisiti di affidabilità?
• In che modo la logica dell'applicazione gestisce le eccezioni e gli errori?
• Quali decisioni sono state prese per garantire che la rete e la connettività soddisfino i requisiti di affidabilità?
• Quali indennità di affidabilità per la scalabilità e le prestazioni hai fatto?
• Quali indennità di affidabilità per la sicurezza hai fatto?
• Come testare l'applicazione per assicurarsi che sia tollerante ai guasti?
• Come si monitora e si misura l'integrità dell'applicazione?