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 la funzionalità prevista. Deve essere resiliente in modo che possa rilevare, resistere e ripristinare da errori entro un periodo di tempo accettabile. Deve essere disponibile anche 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 interessata, 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 compromesse significative.
I principi di progettazione sono destinati a fornire indicazioni per gli aspetti dell'affidabilità da considerare durante il ciclo di vita dello sviluppo. Iniziare con gli approcci consigliati e giustificare i vantaggi per un set di requisiti. Dopo aver impostato la strategia, guidare le azioni usando l'elenco di controllo Affidabilità.
Se non si applicano questi principi alla progettazione, il carico di lavoro più probabilmente non sarà preparato per prevedere o gestire i problemi nell'ambiente di produzione. Il risultato potrebbe essere un'interruzione del servizio che comporta una perdita finanziaria. Nel caso dei carichi di lavoro critici, la mancata applicazione di questi principi potrebbe compromettere la sicurezza.
Progettazione per i requisiti aziendali
Raccogliere i requisiti aziendali con un'attenzione all'utilità prevista del carico di lavoro. |
---|
I requisiti devono coprire l'esperienza utente, i dati, i flussi di lavoro e le caratteristiche univoci per il carico di lavoro. Il risultato del processo dei requisiti deve chiaramente dichiarare le aspettative. Gli obiettivi devono essere raggiungibili e negoziati con il team, dato un investimento specificato. Devono essere documentati per guidare scelte tecnologiche, implementazioni e operazioni.
Approccio | Vantaggi |
---|---|
Quantificare l'esito positivo impostando obiettivi sugli indicatori per singoli componenti, flussi di sistema e il sistema nel suo complesso. Queste destinazioni rendono i flussi utente più affidabili? | Le metriche quantificano le aspettative. Consentono di comprendere le complessità e determinare se i costi downstream di tali complessità sono entro il limite di investimento. I valori di destinazione indicano uno stato ideale. È possibile usare i valori come soglie di test che consentono di rilevare le deviazioni da tale stato e il tempo necessario per tornare allo stato di destinazione. I requisiti di conformità devono avere anche risultati prevedibili per i flussi nell'ambito. La priorità di questi flussi porta l'attenzione alle aree più sensibili. |
Comprendere gli impegni della piattaforma. Prendere in considerazione i limiti, le quote, le aree e i vincoli di capacità per i servizi. | I contratti di servizio variano in base al servizio. Non tutti i servizi e le funzionalità sono trattati ugualmente. Non tutti i servizi o le funzionalità sono disponibili in tutte le aree. La maggior parte dei limiti delle risorse della sottoscrizione è per area. Avere una buona comprensione delle copertura e dei limiti può aiutare a rilevare la deriva e creare meccanismi di resilienza e ripristino. |
Determinare le dipendenze e l'effetto sulla resilienza. | Tenere traccia dell'infrastruttura dipendente, dei servizi, delle API e delle funzioni sviluppate da altri team o terze parti consente di determinare se il carico di lavoro può funzionare in assenza di tali dipendenze. Consente inoltre di comprendere gli errori a catena e migliorare le operazioni downstream. Gli sviluppatori possono implementare modelli di progettazione resilienti per gestire potenziali errori quando si usano servizi esterni che potrebbero essere soggetti a errori. |
Progettare la resilienza
Il carico di lavoro deve continuare a funzionare con funzionalità complete o ridotte. |
---|
È consigliabile prevedere che i componenti non funzionano, le interruzioni della piattaforma, i degradi delle prestazioni, la disponibilità limitata delle risorse e altri errori si verificheranno. Creare resilienza nel sistema in modo che sia a tolleranza di errore e possa degradare in modo normale.
Approccio | Vantaggi |
---|---|
Distinguere i componenti che si trovano nel percorso critico da quelli che possono funzionare in uno stato degradato. | Non tutti i componenti del carico di lavoro devono essere altrettanto affidabili. La determinazione della criticità consente di progettare in base alla criticità di ogni componente.
Non si sovraprogetterà la resilienza per i componenti che potrebbero peggiorare leggermente l'esperienza utente, anziché i componenti che possono causare problemi end-to-end se hanno esito negativo. La progettazione può essere efficiente nell'allocazione delle risorse ai componenti critici. È anche possibile implementare strategie di isolamento degli errori in modo che, se un componente non critico ha esito negativo o entra in uno stato degradato, può essere isolato per evitare errori a catena. |
Identificare i potenziali punti di errore nel sistema, soprattutto 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 evitare che un problema influisca sui componenti downstream. Il sistema sarà in grado di mitigare errori temporanei e permanenti, colli di bottiglia delle prestazioni e altri problemi che potrebbero influire sull'affidabilità. Sarà anche possibile ridurre al minimo il raggio di esplosione. |
Aggiungere la funzionalità per aumentare la scalabilità dei componenti critici (applicazione e infrastruttura) considerando i vincoli di capacità dei servizi nelle aree 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 aumentare la scalabilità in più aree, può anche superare potenziali vincoli di capacità delle risorse temporanee o altri problemi che influisce su una singola area. |
Creare ridondanza in livelli e resilienza in vari livelli di applicazione. Obiettivo della ridondanza nelle utilità fisiche e nella replica immediata dei dati. Mirano anche alla ridondanza nel livello funzionale che copre i servizi, le operazioni e il 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 active-active o active-passive) consente di soddisfare le destinazioni di tempo di attività. L'aggiunta di intermediari impedisce la dipendenza diretta tra componenti e migliora il buffering. Entrambi questi vantaggi consentono di rafforzare la resilienza del sistema. |
Overprovision per attenuare immediatamente l'errore individuale delle istanze ridondanti e per eseguire il buffer rispetto al consumo di risorse runaway. | Un maggiore investimento nel overprovisioning aumenta la resilienza. Il sistema continuerà a funzionare con 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 utilizzo imprevisto delle risorse runaway che richiede il buffer pianificato, ottenendo tempo di valutazione critico, prima che si verifichino errori di sistema o scalabilità aggressiva. |
Progettazione 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 richiedono approcci di preparazione alle emergenze, sia nella progettazione dell'architettura che nelle operazioni del carico di lavoro. Nel livello dati è necessario avere strategie che possono ripristinare lo stato del carico di lavoro in caso di danneggiamento.
Approccio | Vantaggi |
---|---|
Sono stati strutturati, testati e documentati piani di ripristino allineati alle destinazioni di ripristino negoziate. I piani devono coprire tutti i componenti oltre al sistema nel suo complesso. | Un processo ben definito porta a un recupero rapido che può impedire un impatto negativo sulle finanze e sulla reputazione dell'azienda. L'esecuzione di regolari drill-end di ripristino verifica il processo di ripristino dei componenti di sistema, dei dati e del failover e dei passaggi di failover e failback per evitare confusione quando l'integrità dei dati e il tempo sono misure chiave di esito positivo. |
Assicurarsi di poter ripristinare i dati di tutti i componenti con stato nelle destinazioni di ripristino. | I backup sono essenziali per ripristinare lo stato di lavoro del sistema usando un punto di ripristino attendibile, come l'ultimo stato valido noto. I backup non modificabili e coerenti con la transazione garantiscono che i dati non possano essere modificati e che i dati ripristinati non siano danneggiati. |
Implementare funzionalità di auto-guarigione automatizzate nella progettazione. | Questa automazione riduce i rischi da fattori esterni, ad esempio l'intervento umano, e riduce il ciclo di correzione delle interruzioni. |
Sostituire componenti senza stato con unità temporanee non modificabili. | La creazione di unità temporanee che è possibile generare e distruggere su richiesta offre la ripetibilità e la coerenza. Usare modelli di distribuzione side-by-side per effettuare la transizione alle nuove unità incrementali, riducendo al minimo le interruzioni. |
Progettare per le operazioni
Spostarsi a sinistra nelle operazioni per prevedere le condizioni di errore. |
---|
Gli errori di test vengono adottati in anticipo e spesso nel ciclo di vita dello sviluppo e determinano l'impatto delle prestazioni sull'affidabilità. Per motivi di analisi della causa radice e postmortems, è necessario avere visibilità condivisa, tra i team, dello stato delle dipendenze e degli errori in corso. Informazioni dettagliate, diagnostica e avvisi provenienti da sistemi osservabili sono fondamentali per una gestione efficace degli eventi imprevisti e un miglioramento continuo.
Approccio | Vantaggi |
---|---|
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 priorità ai propri sforzi per la correzione. |
Prevedere potenziali malfunzionamenti e comportamenti anomali. Rendere visibili gli errori di affidabilità attivi usando avvisi prioritari e interattivi. Investire in processi e infrastrutture affidabili che portano a una valutazione più rapida. |
I tecnici dell'affidabilità del sito possono ricevere immediatamente una notifica in modo che possano mitigare gli eventi imprevisti del sito live in corso e attenuare in modo proattivo i potenziali errori identificati dagli avvisi predittivi prima che diventino eventi imprevisti in tempo reale. |
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 normalmente agli errori. Consente inoltre di testare le soglie impostate per le metriche aziendali. |
Creare componenti tenendo conto dell'automazione e automatizzare il più possibile. | L'automazione riduce al minimo il potenziale di errore umano, portando la coerenza a test, distribuzione e operazioni. |
Fattori nelle operazioni di routine e il 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. L'esame 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. In definitiva, sarà possibile migliorare in base agli eventi imprevisti reali. |
Scegli la semplicità
Evitare l'overengineering della progettazione dell'architettura, del codice dell'applicazione e delle operazioni. |
---|
Spesso è ciò che si rimuove invece di quello che si aggiunge che porta alle soluzioni più affidabili. Semplicità riduce la superficie di attacco per il controllo, riducendo al minimo le inefficienze e le potenziali configurazioni errate o interazioni impreviste. D'altra parte, la sovrasmplificazione può introdurre singoli punti di guasto. Mantenere un approccio bilanciato.
Approccio | Vantaggi |
---|---|
Aggiungere componenti all'architettura solo se consentono di ottenere valori aziendali di destinazione. Mantenere il percorso critico snello. | 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 è 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. Approcci come convenzioni di denominazione standard e 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 di utente o flusso di dati e i bug del 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 le risorse predefinite 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. |