Condividi tramite

Raccomandazioni per la progettazione di una strategia di mitigazione degli errori di distribuzione

  • Articolo

Si applica a questa raccomandazione per l'eccellenza operativa di Azure Well-Architected Framework:

OE:12 Implementare una strategia di mitigazione degli errori di distribuzione che risolve problemi imprevisti di implementazione mid-rollout con ripristino rapido. Combinare più approcci, ad esempio il rollback, la disabilitazione delle funzionalità o l'uso delle funzionalità native del modello di distribuzione.

Questa guida descrive le raccomandazioni per progettare una strategia standardizzata per gestire efficacemente gli errori di distribuzione. Analogamente ad altri problemi del carico di lavoro, gli errori di distribuzione sono una parte inevitabile di un ciclo di vita del carico di lavoro. Con questa mentalità, è possibile essere proattivi avendo una strategia ben progettata e intenzionale per gestire gli errori di distribuzione. Tale strategia consente al team del carico di lavoro di ridurre in modo efficiente gli errori con il minor impatto possibile sugli utenti finali.

L'assenza di tale piano può portare a risposte caotiche e potenzialmente dannose ai problemi, che possono influire significativamente sulla coesione del team e dell'organizzazione, sulla fiducia dei clienti e sulle finanze.

Strategie di progettazione chiave

In alcuni casi, nonostante la maturità delle procedure di sviluppo, si verificano problemi di distribuzione. L'uso di procedure di distribuzione sicure e la gestione di una catena di fornitura di carichi di lavoro affidabile consentono di ridurre al minimo la frequenza delle distribuzioni non riuscite. Ma è anche necessario progettare una strategia standardizzata per gestire le distribuzioni non riuscite quando si verificano.

Quando si usa un modello di distribuzione di esposizione progressiva come procedura standard:

  • Si ha la giusta base per ridurre al minimo gli effetti sui clienti o sugli utenti interni quando le distribuzioni hanno esito negativo.
  • È possibile attenuare i problemi in modo efficiente.

Una strategia di mitigazione degli errori di distribuzione è costituita da cinque fasi generali:

  1. Rilevamento: per rispondere a una distribuzione non riuscita, è prima necessario rilevare l'errore. Il rilevamento può assumere diverse forme, ad esempio test di fumo non riusciti, problemi segnalati dall'utente o avvisi generati dalla piattaforma di monitoraggio.

  2. Decisione: è necessario decidere qual è la strategia di mitigazione migliore per il tipo di errore specifico.

  3. Mitigazione: si esegue l'azione di mitigazione identificata. La mitigazione può assumere la forma di fallback, rollback, roll forward o uso di una configurazione di runtime per ignorare la funzione che causa l'errore.

  4. Comunicazione: gli stakeholder e gli utenti finali interessati devono essere informati dello stato durante il rilevamento e il funzionamento del problema in base alle esigenze del piano di risposta di emergenza.

  5. Postmortem: postmortems senza colpa offrono opportunità al team del carico di lavoro di identificare le aree per il miglioramento e creare piani per applicare le lezioni.

Le sezioni seguenti forniscono raccomandazioni dettagliate per queste fasi. Queste sezioni presuppongono che venga rilevato un problema dopo la distribuzione delle modifiche in uno o più gruppi di utenti o sistemi, ma prima di aggiornare tutti i gruppi nel piano di implementazione.

Progettare meccanismi di rilevamento degli errori

Per identificare rapidamente i problemi relativi alle distribuzioni, sono necessari test affidabili e procedure di osservabilità in relazione alle distribuzioni. Per rilevare rapidamente le anomalie, è possibile integrare il monitoraggio e gli avvisi del carico di lavoro seguendo questa procedura:

  • Usare uno strumento di gestione delle prestazioni dell'applicazione.
  • Abilitare la registrazione tramite strumentazione.

I test di fumo e altri test di qualità devono essere eseguiti in ogni fase dell'implementazione. I test riusciti in un gruppo di distribuzione non devono influenzare le decisioni da testare nei gruppi successivi.

È possibile implementare i dati di telemetria che correlano i problemi degli utenti con una fase di distribuzione. È quindi possibile identificare rapidamente il gruppo di implementazione a cui è associato un determinato utente. Questo approccio è particolarmente importante per le distribuzioni di esposizione progressiva, perché potrebbero essere presenti più configurazioni in esecuzione nella base utente in un determinato punto della distribuzione.

Si dovrebbe essere pronti per rispondere immediatamente ai problemi segnalati dall'utente. Ogni volta che è pratica, distribuire la fase di implementazione durante l'orario di lavoro, quando è disponibile un team di supporto completo. Assicurarsi che il personale di supporto sia addestrato su come inoltrare i problemi di distribuzione per il routing corretto. Le escalation devono essere allineate al piano di risposta di emergenza del carico di lavoro.

Decidere la strategia di mitigazione

La scelta di una strategia di mitigazione appropriata per un determinato problema di distribuzione comporta la considerazione di molti fattori, tra cui:

  • Tipo di modello di esposizione progressiva usato. Ad esempio, è possibile usare un modello blu-verde o un modello canary.

    Se si usa un modello blu-verde, il fallback è più pratico del rollback. È possibile spostare facilmente il traffico nello stack che esegue la configurazione non aggiornata. È quindi possibile risolvere il problema nell'ambiente problematico e riprovare la distribuzione in un momento appropriato.

  • I metodi disponibili per ignorare il problema. Gli esempi includono l'uso di flag di funzionalità, variabili di ambiente o qualsiasi altro tipo di proprietà di configurazione di runtime che è possibile attivare e disattivare.

    A volte è possibile ignorare facilmente un problema disattivando un flag di funzionalità o attivando un'impostazione. In questo caso, potrebbe essere possibile:

    • Procedere con l'implementazione.
    • Evitare il fallback.
    • Eseguire il rollback durante la correzione del codice che causa l'errore.

  • Livello di impegno necessario per implementare una correzione nel codice.

    Se il livello di impegno per correggere il codice è basso, il roll forward implementando una correzione rapida è la scelta giusta per determinati scenari.

  • Livello di criticità per il carico di lavoro interessato.

    I carichi di lavoro business critical devono essere sempre distribuiti in modo side-by-side, ad esempio in un modello blu-verde, per ottenere distribuzioni senza tempi di inattività. Di conseguenza, il fallback è la strategia di mitigazione preferibile per questi tipi di carichi di lavoro.

  • Tipo di infrastruttura usata dal carico di lavoro, modificabile o non modificabile.

    Se il carico di lavoro è progettato per l'uso dell'infrastruttura modificabile, il roll forward può avere senso, perché comporta l'aggiornamento dell'infrastruttura sul posto. Viceversa, il rollback o il fallback può essere utile quando si usa un'infrastruttura non modificabile.

Indipendentemente da quali scelte effettuate, è necessario includere le approvazioni appropriate nel processo decisionale e codificarle nell'albero delle decisioni.

Implementare la strategia di mitigazione

  • Rollback: in uno scenario di rollback i sistemi aggiornati vengono ripristinati all'ultimo stato di configurazione valido noto.

    È importante che l'intero team del carico di lavoro accetti il significato dell'ultimo bene noto. Questa espressione si riferisce all'ultimo stato del carico di lavoro integro prima dell'avvio della distribuzione, che non è necessariamente la versione precedente dell'applicazione.

    Il rollback può essere complesso, soprattutto in relazione alle modifiche ai dati. Le modifiche dello schema possono apportare il rollback rischioso. Implementarli in modo sicuro può richiedere una pianificazione considerevole. Come raccomandazione generale, gli aggiornamenti dello schema devono essere additivi. Non devono essere modifiche sostitutive. I record non devono essere sostituiti con nuovi record. I record meno recenti devono invece essere deprecati e devono coesistere con nuovi record fino a quando non è sicuro rimuovere i record deprecati.

  • Fallback: in uno scenario di fallback, i sistemi aggiornati vengono rimossi dal routing del traffico di produzione. Tutto il traffico viene indirizzato allo stack che non viene aggiornato. Questa strategia a basso rischio consente di risolvere i problemi nel codice senza introdurre ulteriori interruzioni.

    Con le distribuzioni canary, il fallback potrebbe non essere semplice o anche possibile, a seconda dell'infrastruttura e della progettazione dell'app. Se è necessario eseguire il ridimensionamento per gestire il carico nei sistemi che non vengono aggiornati, eseguire tale ridimensionamento prima di eseguire il fallback.

  • Ignorare la funzione che causa l'errore: se è possibile ignorare il problema usando flag di funzionalità o un altro tipo di proprietà di configurazione di runtime, è possibile decidere che continuare con l'implementazione è la strategia giusta per un determinato problema.

    È necessario comprendere chiaramente il compromesso di ignorare la funzione e si dovrebbe essere in grado di comunicare tale compromesso con gli stakeholder. Gli stakeholder devono approvare il piano di avanzamento. Gli stakeholder devono determinare l'intervallo di tempo che è tollerabile per il funzionamento in uno stato degradato. Devono anche valutare tale determinazione in base alla stima del tempo necessario per correggere il codice che causa l'errore e distribuirlo.

  • Distribuzione di emergenza (correzione rapida): se è possibile risolvere il problema a metà implementazione, una correzione rapida potrebbe essere la strategia di mitigazione più pratica.

    Come qualsiasi altro codice, le correzioni ad accesso frequente devono seguire le procedure di distribuzione sicure. Ma con una correzione a caldo, la sequenza temporale è notevolmente accelerata. È necessario usare una strategia di promozione del codice in tutti gli ambienti. È anche necessario controllare il codice di correzione ad accesso frequente a tutti i controlli di qualità. Ma potrebbe essere necessario ridurre notevolmente i tempi di bake e potrebbe essere necessario modificare i test per accelerarli. Assicurarsi di poter eseguire test completi sul codice aggiornato il prima possibile dopo la distribuzione. L'automazione dei test di controllo qualità ad alto livello consente di rendere i test efficienti in questi scenari.

Compromessi:

  • La possibilità di eseguire il fallback significa in genere che è necessaria una capacità di infrastruttura sufficiente per gestire due versioni della configurazione del carico di lavoro contemporaneamente. I team del carico di lavoro devono anche essere in grado di supportare due versioni nell'ambiente di produzione contemporaneamente.
  • La possibilità di eseguire il rollback in modo efficace potrebbe comportare il refactoring degli elementi del carico di lavoro. Ad esempio, potrebbe essere necessario separare le funzioni o modificare il modello di dati.

Standardizzare gli aggiornamenti dello stato durante un evento imprevisto

È importante avere chiaramente definite responsabilità di comunicazione per ridurre al minimo il caos durante gli eventi imprevisti. Queste responsabilità devono stabilire in che modo il team del carico di lavoro interagisce con team di supporto, stakeholder e personale del team di risposta alle emergenze, come il responsabile della risposta di emergenza.

Standardizzare la cadenza che il team del carico di lavoro segue per fornire gli aggiornamenti dello stato. Assicurarsi che gli stakeholder siano consapevoli di questo standard in modo che sappiano quando aspettarsi gli aggiornamenti.

Se il team del carico di lavoro deve comunicare direttamente con gli utenti finali, chiarire il tipo di informazioni e il livello di dettaglio appropriati per la condivisione con gli utenti. Comunicare anche con il team del carico di lavoro qualsiasi altro requisito che si applica a questi casi.

Eseguire postmortems degli eventi imprevisti

I postmortems devono seguire tutte le distribuzioni non riuscite, senza eccezione. Ogni distribuzione non riuscita è un'opportunità di apprendimento. I postmortems consentono di identificare i punti deboli nei processi di distribuzione e sviluppo. È anche possibile identificare errori di configurazione nell'infrastruttura, tra le altre possibilità.

I postmortemi devono sempre essere incolpevoli in modo che gli individui coinvolti nell'incidente si sentano sicuri quando condividono le loro prospettive su ciò che può essere migliorato. I leader postmortem devono seguire i piani per implementare i miglioramenti identificati e aggiungere questi piani al backlog del carico di lavoro.

Rendere operativi i processi di mitigazione

Assicurarsi che la pipeline di distribuzione possa accettare versioni distinte come parametri in modo che sia possibile distribuire facilmente le ultime configurazioni valide.

Mantenere la coerenza con i piani di gestione e dati durante il rollback o il rollforward. Chiavi, segreti, dati sullo stato del database e configurazioni specifici per le risorse e i criteri devono essere tutti inclusi nell'ambito e per i quali è necessario tenere conto. Ad esempio, prestare attenzione alla progettazione del ridimensionamento dell'infrastruttura nell'ultima distribuzione valida nota. Determinare se è necessario modificare la configurazione quando si ridistribuisce il codice.

Preferisce modifiche frequenti e piccole rispetto a modifiche frequenti e frequenti, in modo che il delta tra le distribuzioni nuove e le ultime distribuzioni note sia di piccole dimensioni.

Eseguire un'analisi della modalità di errore (FMA) nelle pipeline di integrazione continua e recapito continuo (CI/CD) per identificare i problemi che possono complicare le mitigazioni. Analogamente al carico di lavoro nel suo complesso, le pipeline possono essere analizzate per identificare le aree che potrebbero essere problematiche quando si tenta un determinato tipo di mitigazione.

Usare le funzionalità di rollback automatizzato in modo corretto:

  • Alcuni strumenti CI/CD come Azure DevOps hanno funzionalità di rollback automatico integrate. Prendere in considerazione l'uso di questa funzionalità se fornisce valore tangibile.
  • È consigliabile adottare la funzionalità di rollback automatico solo dopo aver testato accuratamente e regolarmente la pipeline. Assicurarsi che la pipeline sia abbastanza matura per introdurre problemi aggiuntivi se viene attivato un rollback automatico.
  • È necessario considerare attendibile che l'automazione distribuisca solo le modifiche necessarie e che venga attivata solo quando necessario. Progettare i trigger con attenzione per soddisfare questi requisiti.

Usare le funzionalità fornite dalla piattaforma durante il rollback. Ad esempio, i backup e i ripristini temporizzato possono essere utili per l'archiviazione e il rollback dei dati. In alternativa, se si usano macchine virtuali per ospitare l'applicazione, può essere utile ripristinare l'ambiente in un checkpoint immediatamente prima di un evento imprevisto.

Testare frequentemente l'intera strategia di mitigazione degli errori di distribuzione. Analogamente ai piani di risposta di emergenza e ai piani di ripristino di emergenza, il piano di errore di distribuzione ha esito positivo solo se il team è addestrato e lo esegue regolarmente. La progettazione di Chaos e i test di inserimento degli errori possono essere tecniche efficaci per testare la strategia di mitigazione della distribuzione.

Compromesso: i membri del team di supporto devono poter svolgere le normali mansioni e supportare anche le emergenze. Potrebbe essere necessario aumentare il numero di head per garantire che il team di supporto sia adeguatamente staffato e in grado di svolgere tutti i compiti necessari. Testare accuratamente le distribuzioni quando si esegue la distribuzione in ambienti di sviluppo inferiori. Questa procedura consente di rilevare bug e configurazioni errate prima di passare all'ambiente di produzione.

Facilitazione di Azure

  • Azure Pipelines offre servizi di compilazione e rilascio per supportare CI/CD delle applicazioni.

  • Piani di test di Azure è una soluzione di gestione dei test basata su browser facile da usare. Questa soluzione offre funzionalità necessarie per i test manuali pianificati, i test di accettazione degli utenti e i test esplorativi. I piani di test di Azure offrono anche un modo per raccogliere feedback dagli stakeholder.

  • Monitoraggio di Azure è una soluzione di monitoraggio completa per la raccolta, l'analisi e la risposta ai dati di monitoraggio dagli ambienti cloud e locali. Il monitoraggio include una piattaforma di avvisi affidabile. È possibile configurare il sistema per le notifiche automatiche e altre azioni, ad esempio la scalabilità automatica e altri meccanismi di riparazione automatica.

  • Application Insights è un'estensione di Monitoraggio che fornisce funzionalità di monitoraggio delle prestazioni dell'applicazione (APM).

  • App per la logica di Azure è una piattaforma basata sul cloud per l'esecuzione di flussi di lavoro automatizzati che integrano app, dati, servizi e sistemi. È possibile usare App per la logica per creare una nuova versione dell'applicazione ogni volta che viene eseguito un aggiornamento. Azure gestisce una cronologia delle versioni e può ripristinare o alzare di livello qualsiasi versione precedente.

  • Molti servizi di database di Azure offrono funzionalità di ripristino temporizzato che consentono di eseguire il rollback:

  • Azure Chaos Studio Preview è un servizio gestito che usa la progettazione chaos per misurare, comprendere e migliorare la resilienza dell'applicazione cloud e del servizio.

Elenco di controllo per l'eccellenza operativa

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo per l'eccellenza operativa