Principi di progettazione dell'affidabilità

Interruzioni e malfunzionamenti sono gravi preoccupazioni per tutti i carichi di lavoro. Un carico di lavoro affidabile deve sopravvivere a tali eventi e continuare a fornire in modo coerente le funzionalità desiderate. Deve essere resiliente in modo che possa rilevare e resistere agli errori continuando a funzionare. Deve essere recuperabile in modo che, se un'interruzione supera le misure di resilienza, il carico di lavoro può essere ripristinato entro gli obiettivi di ripristino concordati. Deve anche essere disponibile in modo che gli utenti possano accedere al carico di lavoro durante il periodo di tempo promesso a livello di qualità promesso.

Non è realistico presupporre che gli errori non si verifichino, soprattutto quando il carico di lavoro viene compilato per l'esecuzione nei sistemi distribuiti. Alcuni componenti potrebbero non riuscire mentre altri continuano a funzionare. A un certo punto, l'esperienza utente potrebbe essere influenzata, che compromette gli obiettivi aziendali.

Le architetture dei carichi di lavoro devono avere garanzie di affidabilità nel codice dell'applicazione, nell'infrastruttura e nelle operazioni. Le scelte di progettazione non devono modificare la finalità specificata dai requisiti aziendali. Tali modifiche devono essere considerate compromessi significativi.

I principi di progettazione sono progettati per fornire indicazioni sugli aspetti dell'affidabilità da considerare durante tutto il ciclo di vita di sviluppo. Iniziare con gli approcci consigliati e giustificare i vantaggi per un set di requisiti. Dopo aver impostato la strategia, guida le azioni usando l'elenco di controllo della affidabilità.

Se questi principi non vengono applicati alla progettazione, è probabile che il carico di lavoro non sia pronto a prevedere o gestire i problemi nell'ambiente di produzione. Il risultato potrebbe essere un'interruzione del servizio che comporta una perdita finanziaria. Nel caso di carichi di lavoro critici, la mancata applicazione di questi principi potrebbe compromettere la sicurezza.

Progettare in base ai requisiti aziendali

Ottenere chiarezza sull'ambito del carico di lavoro, sulla crescita degli utenti e, soprattutto, sulle promesse che il team ha fatto ai clienti esterni e agli stakeholder interni.

La progettazione non è un'ipotesi basata su risultati non definiti o vaghi. L'affidabilità richiede un'attività intenzionale che raggiunga l'allineamento su un'esperienza utente accettabile, vincoli di progettazione e su cosa significa avere successo e su come viene misurato.

Definire obiettivi chiari, raggiungibili e documentati, negoziati con gli stakeholder aziendali e fondati su un investimento realistico e una previsione. Questi requisiti informeranno direttamente le scelte dell'architettura, dalle strategie di resilienza agli strumenti di osservabilità e ai piani di ridimensionamento.

Avvicinarsi	Beneficio
Concentrarsi sulla raccolta di informazioni necessarie per definire l'ambito e la profondità della soluzione. Chiarire i vincoli che influenzano gli obiettivi aziendali. Iniziare con domande di alto livello, ad esempio: - Quale livello di resilienza, ripristino, osservabilità e semplicità è necessario? - Esistono vincoli definiti correlati a costi, conformità, geografia o latenza? In base a queste informazioni, documentare ciò che è abbastanza buono e semplice da raggiungere.	La comprensione degli obiettivi e dei limiti impedirà di indovinare. In caso contrario, si potrebbe rimanere bloccati in un ciclo di progettazione iterativo, con conseguente spreco di sforzi e costi non necessari.
Guida al processo decisionale traducendo gli obiettivi aziendali in una comprensione condivisa dei compromessi architetturali all'interno di vincoli reali. Opzioni presenti che influiscono: - Costo finanziario - Complessità dell'ingegneria - Considerazioni sulla sicurezza - Overhead operativo	Questo aiuterà gli stakeholder a comprendere i costi, la complessità e le implicazioni operative delle loro richieste e guidarli verso risultati realistici e allineati.
Definire in ordine di priorità i risultati di affidabilità per ogni flusso utente critico sulle misurazioni generiche, ad esempio il tempo di attività. Identificare le funzionalità e i flussi degli utenti attraverso il sistema e, per ognuno, valutare il valore aziendale, i modelli di utilizzo e i requisiti di resilienza. Favorire il consenso a livello di flusso per garantire che le decisioni di progettazione rimangano allineate agli obiettivi aziendali.	Questa conversazione consente agli stakeholder di allontanarsi da dichiarazioni insostenibili, ad esempio "il sito deve sempre essere attivo", ad aspettative pratiche e raggiungibili legate a funzionalità e risultati reali. Questi risultati consentono di stabilire cosa viene risolto con la tecnologia e cosa può essere affrontato con piani di continuità aziendale aggiuntivi.
Ancorare le scelte di progettazione agli orizzonti temporali. Definire le aspettative di utilizzo con previsioni realistiche. Ad esempio, qual è il carico utente previsto all'avvio? Si prevede che la crescita degli utenti sia lineare, esponenziale o incerta.	Queste informazioni consentiranno di progettare un'architettura che risolverà le esigenze di affidabilità a breve termine evitando decisioni di progettazione che richiederanno una rielaborazione significativa per gestire gli orizzonti futuri. Questo approccio influisce su come considerare l'elasticità, i flussi di lavoro basati sugli eventi e consente di effettuare scelte strategiche relative al debito tecnico da incorrere o evitare.
Fattore delle dipendenze che potrebbero limitare l'autonomia della progettazione, ad esempio i vincoli dell'organizzazione. Tenere presente l'infrastruttura centralizzata, i requisiti di sicurezza, i criteri di routing di rete o le decisioni della piattaforma che influisce direttamente su ciò che è possibile promettere in termini di resilienza, disponibilità e ripristino.	Comprendere la dipendenza dai servizi al di fuori del controllo consente di progettare con aspettative realistiche per l'affidabilità. Garantisce che gli obiettivi RTO/RPO e gli SLO siano raggiungibili e chiaramente comunicati, evitando promesse eccessive e riducendo le sorprese.

Progettare per la resilienza

Il carico di lavoro deve continuare a funzionare con funzionalità complete o ridotte.

È consigliabile prevedere che si verifichino malfunzionamenti del componente, interruzioni della piattaforma, riduzione delle prestazioni, disponibilità limitata delle risorse e altri errori. Creare resilienza nel sistema in modo che sia a prova di errore e possa degradarsi gradualmente.

Avvicinarsi	Beneficio
Distinguere i componenti presenti nel percorso critico da quelli che possono funzionare in uno stato danneggiato.	Non tutti i componenti del carico di lavoro devono essere ugualmente affidabili. La determinazione della criticità consente di progettare in base alla criticità di ogni componente. Non si esagererà nel progettare la resilienza per i componenti che potrebbero causare un leggero deterioramento dell'esperienza utente, a differenza dei componenti che possono causare problemi end-to-end se falliscono. La progettazione può essere efficiente nell'allocazione di risorse ai componenti critici. È anche possibile implementare strategie di isolamento degli errori in modo che, se un componente non critico non riesce o entra in uno stato danneggiato, può essere isolato per evitare errori a catena.
Identificare i potenziali punti di errore nel sistema, in particolare per i componenti critici e determinare l'effetto sui flussi utente.	È possibile analizzare i casi di errore, il raggio di esplosione e l'intensità dell'errore: interruzione completa o parziale. Questa analisi influenza la progettazione delle funzionalità di gestione degli errori a livello di componente.
Creare funzionalità di auto-conservazione usando modelli di progettazione correttamente e modularizzando la progettazione per isolare gli errori.	Il sistema sarà in grado di impedire a un problema di influire sui componenti downstream. Il sistema sarà in grado di attenuare errori temporanei e permanenti, colli di bottiglia delle prestazioni e altri problemi che potrebbero influire sull'affidabilità. Potrai anche ridurre al minimo il raggio dell'esplosione.
Aggiungere la funzionalità per scalare i componenti critici (applicazione e infrastruttura) considerando i vincoli di capacità dei servizi nelle regioni supportate.	Il carico di lavoro sarà in grado di gestire picchi di capacità variabile e fluttuazioni. Questa funzionalità è fondamentale quando si verifica un carico imprevisto nel sistema, ad esempio un aumento dell'utilizzo valido. Se il carico di lavoro è progettato per espandersi in più regioni, può anche superare i potenziali vincoli di capacità temporanea delle risorse o altri problemi che influiscono su una singola area.
Creare ridondanza a più livelli e resilienza nei vari livelli applicativi. Puntare alla ridondanza nelle funzioni fisiche e alla replica immediata dei dati. Mirare anche alla ridondanza nel livello funzionale che copre servizi, operazioni e personale.	La ridondanza consente di ridurre al minimo i singoli punti di errore. Ad esempio, se è presente un componente, un'interruzione zonale o regionale, la distribuzione ridondante (in attivo-attivo o attivo-passivo) consente di soddisfare gli obiettivi di uptime. L'aggiunta di intermediari impedisce la dipendenza diretta tra i componenti e migliora il buffering. Entrambi questi vantaggi rafforzano la resilienza del sistema.
Overprovisioning per mitigare immediatamente il guasto individuale delle istanze ridondanti e bufferizzare contro il consumo eccessivo delle risorse.	Un maggiore investimento nel provisioning eccessivo aumenta la resilienza. Il sistema continuerà a funzionare con l'utilità completa durante un errore attivo anche prima che le operazioni di ridimensionamento possano iniziare a correggere l'errore. Analogamente, è possibile ridurre il rischio di un consumo imprevisto e incontrollato di risorse che utilizza il buffer pianificato, ottenendo un tempo critico per il triage, prima che si verifichino guasti di sistema o scaling aggressivo.

Progettare per il ripristino

Il carico di lavoro deve essere in grado di prevedere e recuperare dalla maggior parte degli errori, di tutte le dimensioni, con un'interruzione minima dell'esperienza utente e degli obiettivi aziendali.

Anche i sistemi altamente resilienti necessitano di approcci di preparazione alle emergenze, sia nella progettazione dell'architettura che nelle operazioni del carico di lavoro. Nello strato dati, è necessario avere strategie in grado di ripristinare lo stato del carico di lavoro in caso di danneggiamento.

Avvicinarsi	Beneficio
I piani di ripristino strutturati, testati e documentati sono allineati agli obiettivi di ripristino negoziati. I piani devono coprire tutti i componenti, oltre al sistema nel suo complesso.	Un processo ben definito comporta un rapido ripristino che può impedire un impatto negativo sulle finanze e sulla reputazione dell'azienda. L'esecuzione di esercitazioni di ripristino regolari verifica il processo di ripristino dei componenti di sistema, dei dati e dei passaggi di failover e failback per evitare confusione quando il tempo e l'integrità dei dati sono misure chiave di successo.
Assicurarsi di poter ripristinare i dati di tutti i componenti con stato all'interno delle destinazioni di ripristino.	I backup sono essenziali per ripristinare lo stato di funzionamento del sistema usando un punto di ripristino attendibile, ad esempio l'ultimo stato valido noto. I backup non modificabili e coerenti in modo transazionale assicurano che i dati non possano essere modificati e che i dati ripristinati non siano danneggiati.
Implementare funzionalità di riparazione automatica nella progettazione.	Questa automazione riduce i rischi derivanti da fattori esterni, come l'intervento umano, e riduce il ciclo di correzione delle interruzioni.
Sostituire i componenti senza stato con unità temporanee non modificabili.	La creazione di unità temporanee che è possibile creare e distruggere su richiesta offre ripetibilità e coerenza. Usare modelli di distribuzione side-by-side per eseguire la transizione alle nuove unità incrementali, riducendo al minimo le interruzioni.

Progettazione per le operazioni

Spostarsi a sinistra nelle operazioni per prevedere le condizioni di errore.

Gli errori di test in anticipo e spesso nel ciclo di vita di sviluppo e determinano l'impatto delle prestazioni sull'affidabilità. A scopo di analisi e post-mortem delle cause principali, è necessario avere visibilità condivisa, tra team, dello stato delle dipendenze e degli errori in corso. Le informazioni dettagliate, la diagnostica e gli avvisi dei sistemi osservabili sono fondamentali per una gestione efficace degli eventi imprevisti e un miglioramento continuo.

Avvicinarsi	Beneficio
Creare sistemi osservabili in grado di correlare i dati di telemetria.	Il monitoraggio e la diagnostica sono operazioni cruciali. Se si verifica un errore, è necessario sapere che non è riuscito, quando non è riuscito e perché non è riuscito. L'osservabilità a livello di componente è fondamentale, ma l'osservabilità aggregata dei componenti e dei flussi utente correlati offre una visualizzazione olistica dello stato di integrità. Questi dati sono necessari per consentire ai tecnici dell'affidabilità del sito di assegnare le priorità ai propri sforzi per la correzione.
Prevedere potenziali malfunzionamenti e comportamenti anomali. Rendere visibili gli errori di affidabilità attivi usando avvisi con priorità e interattivi. Investire in processi e infrastrutture affidabili che conducono a una valutazione più rapida.	I tecnici dell'affidabilità del sito possono ricevere immediatamente una notifica in modo che possano attenuare gli eventi imprevisti in corso del sito live e attenuare in modo proattivo i potenziali errori identificati dagli avvisi predittivi prima che diventino eventi imprevisti live.
Simulare gli errori ed eseguire test in ambienti di produzione e pre-produzione.	È utile riscontrare errori nell'ambiente di produzione in modo da poter impostare aspettative realistiche per il ripristino. In questo modo è possibile effettuare scelte di progettazione che rispondono in modo appropriato agli errori. Consente inoltre di testare le soglie impostate per le metriche aziendali.
Creare componenti tenendo presente l'automazione e automatizzare il più possibile.	L'automazione riduce al minimo il potenziale di errore umano, portando la coerenza ai test, alla distribuzione e alle operazioni.
Tenere conto delle operazioni di routine e del loro impatto sulla stabilità del sistema.	Il carico di lavoro potrebbe essere soggetto a operazioni in corso, ad esempio revisioni delle applicazioni, controlli di sicurezza e conformità, aggiornamenti dei componenti e processi di backup. Il controllo di tali modifiche garantisce la stabilità del sistema.
Imparare continuamente dagli eventi imprevisti nell'ambiente di produzione.	In base agli eventi imprevisti, è possibile determinare l'impatto e le supervisione nella progettazione e nelle operazioni che potrebbero non essere rilevate nella preproduzione. Alla fine, sarà possibile guidare miglioramenti basati su incidenti reali.

Mantieni semplice

Evitare di sovradimensionare la progettazione dell'architettura, il codice applicativo e le operazioni.

Spesso si tratta di ciò che si rimuove invece di quello che si aggiunge che porta alle soluzioni più affidabili. La semplicità riduce la superficie per il controllo, riducendo al minimo le inefficienze e potenziali configurazioni o interazioni impreviste. D'altra parte, la sovrasmplificazione può introdurre singoli punti di guasto. Mantenere un approccio bilanciato.

Avvicinarsi	Beneficio
Aggiungere componenti all'architettura solo se consentono di raggiungere i valori aziendali di destinazione. Mantenere snello il percorso critico.	La progettazione per i requisiti aziendali può portare a una soluzione semplice da implementare e gestire. Evitare di dover avere troppi componenti critici, perché ognuno di essi è un punto di errore significativo.
Stabilire standard nell'implementazione del codice, nella distribuzione e nei processi e documentarli. Identificare le opportunità per applicare tali standard usando le convalide automatizzate.	Gli standard forniscono coerenza e riducono al minimo gli errori umani. Gli approcci come le convenzioni di denominazione standard e le guide di stile del codice consentono di mantenere la qualità e semplificare l'identificazione degli asset durante la risoluzione dei problemi.
Valutare se gli approcci teorici si traducono in una progettazione pragmatica applicabile ai casi d'uso.	Il codice dell'applicazione troppo granulare può portare a interdipendenze non necessarie, operazioni aggiuntive e manutenzione complessa.
Sviluppare codice sufficiente.	Sarà possibile evitare problemi che sono il risultato di implementazioni inefficienti, ad esempio l'utilizzo imprevisto delle risorse, gli errori del flusso di dati o dell'utente e i bug di codice. Al contrario, i problemi di affidabilità devono portare a revisioni del codice per garantire che il codice sia abbastanza resiliente per gestire i problemi.
Sfruttare le funzionalità fornite dalla piattaforma e gli asset predefiniti che consentono di soddisfare in modo efficace gli obiettivi aziendali.	Questo approccio riduce al minimo il tempo di sviluppo. Consente inoltre di basarsi su procedure collaudate e testate usate con carichi di lavoro simili.

Passaggi successivi

Elenco di controllo per l'affidabilità