Elementi consigliati per la progettazione di una strategia di mitigazione degli errori di distribuzione

Si applica a questa raccomandazione dell'elenco di controllo di Eccellenza operativa di Power Platform Well-Architected:

Questa guida descrive gli elementi consigliati per progettare una strategia standardizzata per gestire in modo efficace gli errori di distribuzione. Come altri problemi relativi al carico di lavoro, gli errori di distribuzione sono una parte inevitabile del ciclo di vita di un carico di lavoro. Con questa mentalità, puoi essere proattivo adottando una strategia intenzionale e ben progettata per gestire gli errori di distribuzione. Una strategia di questo tipo consente al team addetto al carico di lavoro di mitigare in modo efficiente i guasti con il minimo impatto possibile sugli utenti.

L'assenza di un tale piano può portare a risposte caotiche e potenzialmente dannose ai problemi, che possono influenzare in modo significativo la coesione del team e dell'organizzazione, la fiducia dei clienti e le finanze.

Strategie di progettazione chiave

Occasionalmente, nonostante la maturità delle procedure di sviluppo, si verificano problemi di distribuzione. L'utilizzo di procedure di distribuzione sicure e la gestione di una solida catena di fornitura del carico di lavoro possono aiutarti a ridurre al minimo la frequenza delle distribuzioni non riuscite. È inoltre necessario progettare una strategia standardizzata per gestire le distribuzioni non riuscite quando si verificano.

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

1. Rilevamento: per rispondere a una distribuzione non riuscita, è necessario prima rilevare l'errore. Il rilevamento può assumere diverse forme, ad esempio test di fumo non riusciti, segnalazioni degli utenti o avvisi generati dalla piattaforma di monitoraggio.
2. Decisione: È necessario decidere qual è la migliore strategia di mitigazione per lo specifico tipo di errore.
3. Mitigazione: È necessario eseguire l'azione di mitigazione identificata. La mitigazione può assumere la forma di fallback, rollback o rollforward.
4. Comunicazione: le parti interessate e gli utenti interessati devono essere informati dello stato mentre si rileva e si risolve il problema, come richiesto dal piano di emergenza risposta.
5. Postmortem: i postmortem irreprensibili offrono al team addetto al carico di lavoro l'opportunità di identificare aree di miglioramento e di creare piani per applicare quanto appreso.

Le sezioni seguenti forniscono elementi consigliati dettagliati per ciascuna di queste fasi.

duplicati

Per identificare rapidamente i problemi nelle distribuzioni, è necessario adottare solide pratiche di test e monitoraggio relative alle distribuzioni. Per rilevare rapidamente le anomalie, puoi integrare il monitoraggio e gli avvisi del carico di lavoro utilizzando uno strumento di gestione delle prestazioni delle applicazioni e la registrazione tramite strumentazione.

Gli smoke test e altri test di qualità dovrebbero essere eseguiti in ogni fase dell'implementazione. Il successo dei test in un gruppo di distribuzione non dovrebbe influenzare le decisioni di eseguire test nei gruppi successivi.

È possibile implementare la telemetria che correla i problemi degli utenti con una fase di distribuzione. Quindi puoi identificare rapidamente a quale gruppo di implementazione è associato un particolare utente. Questo approccio è particolarmente importante per le distribuzioni con esposizione progressiva, perché potresti avere più configurazioni in esecuzione nella tua base utenti in un dato punto della distribuzione.

Dovresti essere pronto a rispondere immediatamente ai problemi segnalati dagli utenti. Quando possibile, implementa la fase di implementazione durante l'orario di lavoro, quando hai a disposizione un team di supporto completo. Assicurarsi che il personale di supporto sia formato su come segnalare i problemi di distribuzione per un instradamento corretto. Le escalation devono essere in linea con il piano di risposta alle emergenze del carico di lavoro.

Decisione

Per decidere una strategia di mitigazione appropriata per un problema di distribuzione, è necessario considerare fattori quali:

• Il tipo di modello di esposizione progressiva utilizzato. Ad esempio, potresti utilizzare un modello blu verde o un modello canarino. Se usi un modello blu-verde, ripiegare è più pratico che tornare indietro. Puoi facilmente riportare il traffico allo stack che esegue la configurazione non aggiornata. Potrai quindi risolvere il problema nell'ambiente problematico e riprovare la distribuzione al momento opportuno.

• I metodi che hai a disposizione per aggirare il problema. Gli esempi includono l'uso di flag di funzionalità, variabili ambientali o qualsiasi altro tipo di proprietà di configurazione di esecuzione che è possibile attivare e disattivare. A volte puoi facilmente aggirare un problema disattivando un flag di funzionalità o attivando un'impostazione. In questo caso, sarai essere in grado di:

  • Procedi con il rollout.
  • Evita di ripiegare.
  • Esegui il rollback mentre esegui il codice incriminato.

• Il livello di impegno richiesto per implementare una correzione nel codice. Se il livello di impegno richiesto per correggere il codice è basso, procedere implementando un hotfix è la scelta giusta in determinati scenari.

• Il livello di criticità per il carico di lavoro interessato. I carichi di lavoro business-critical dovrebbero essere sempre distribuiti in modo affiancato, come 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.

Mitigazione

Di seguito sono riportate alcune strategie di mitigazione comuni:

• Rollback: in uno scenario di rollback, si ripristinano i sistemi aggiornati all'ultimo stato di configurazione sicuramente funzionante.

  È importante che l'intero team addetto al carico di lavoro concordi sul significato di "ultimo stato valido noto". Questa espressione si riferisce all'ultimo stato del carico di lavoro che era integro prima dell'inizio della distribuzione, che non è necessariamente la versione precedente dell'applicazione.

  Il rollback può essere complesso, soprattutto se correlato alle modifiche dei dati. Le modifiche allo schema possono rendere rischioso il rollback. La loro attuazione in modo sicuro può richiedere una pianificazione considerevole. Come raccomandazione generale, gli aggiornamenti dello schema dovrebbero essere additivi. I record non dovrebbero essere sostituiti con nuovi record. Invece, i record più vecchi dovrebbero essere deprecati e dovrebbero coesistere con i nuovi record finché non sarà sicuro rimuovere i record deprecati.

• Fallback: in uno scenario di fallback, i sistemi aggiornati vengono rimossi dall'instradamento del traffico di produzione. Tutto il traffico viene indirizzato allo stack non aggiornato. Questa strategia a basso rischio fornisce un modo per risolvere i problemi nel codice senza introdurre ulteriori interruzioni.

  Con le distribuzioni canary, il fallback potrebbe non essere semplice o addirittura possibile, a seconda dell'infrastruttura e della progettazione dell'app. Se è necessario eseguire il ridimensionamento per gestire il carico su sistemi non aggiornati, eseguirlo prima di ricorrere al fallback.

• Ignora la funzione incriminata: se riesci a ignorare il problema utilizzando flag delle funzionalità o un altro tipo di proprietà di configurazione runtime, potresti decidere che continuare con l'implementazione sia la strategia giusta per risolvere un problema.

  Dovresti comprendere chiaramente il compromesso derivante dall'evitare la funzione e dovresti essere in grado di comunicare tale compromesso alle parti interessate. Le parti interessate dovrebbero approvare il piano di avanzamento. Gli stakeholder devono determinare il periodo di tempo tollerabile per operare in uno stato degradato. Devono inoltre valutare tale determinazione rispetto alla stima del tempo necessario per correggere il codice incriminato e distribuirlo.

• Distribuzione di emergenza (hotfix): se è possibile risolvere il problema a metà distribuzione, un hotfix potrebbe essere la strategia di mitigazione più pratica.

  Come qualsiasi altro codice, gli hotfix devono essere sottoposti alle procedure di distribuzione sicura. Ma con un hotfix, i tempi vengono notevolmente accelerati. È necessario utilizzare una strategia di promozione del codice in tutti gli ambienti. È inoltre necessario controllare il codice hotfix in tutti i controlli di qualità. Potrebbe essere necessario ridurre drasticamente i tempi di preparazione e modificare i test per accelerarli. Assicurati di poter eseguire test completi sul codice aggiornato il prima possibile dopo la distribuzione. L'automazione dei test di garanzia della qualità a un livello elevato aiuta a rendere i test efficienti in questi scenari.

Comunicazione

È importante definire chiaramente le responsabilità di comunicazione per ridurre al minimo il caos durante gli incidenti. Queste responsabilità dovrebbero stabilire in che modo il team del carico di lavoro interagisce con i team di supporto, le parti interessate e il personale del team di risposta alle emergenze, come il responsabile della risposta alle emergenze.

Standardizzare la cadenza seguita dal team del carico di lavoro per fornire aggiornamenti di stato. Assicurati che le parti interessate siano a conoscenza di questo standard in modo che sappiano quando aspettarsi aggiornamenti.

Se il team addetto al carico di lavoro deve comunicare direttamente con gli utenti, è opportuno chiarire il tipo di informazioni e il livello di dettaglio appropriati per la condivisione. Comunica inoltre al team del carico di lavoro eventuali altri requisiti applicabili a questi casi.

Post-mortem

Le analisi postmortem dovrebbero seguire per tutte le distribuzioni non riuscite, senza eccezioni. Ogni implementazione fallita è un'opportunità di apprendimento. Le analisi postmortem possono aiutarti a identificare i punti deboli nei tuoi processi di distribuzione e sviluppo, nonché le configurazioni errate nella tua infrastruttura.

I post-mortem dovrebbero essere sempre irreprensibili in modo che le persone coinvolte nell'incidente si sentano sicure quando condividono le loro prospettive su ciò che può essere migliorato. I responsabili del postmortem dovrebbero completamento con i piani per implementare i miglioramenti identificati e per aggiungere tali piani al backlog del carico di lavoro.

Considerazioni ed elementi consigliati generali

Assicurati che la pipeline di distribuzione possa accettare versioni distinte come parametri in modo da poter distribuire facilmente le ultime configurazioni sicuramente valide.

Mantieni la coerenza con la gestione e i piani dati durante il rollback o il rollforward. Chiavi, segreti, dati sullo stato del database e configurazioni specifiche per risorse e criteri devono essere tutti compresi nell'ambito e contabilizzati. Ad esempio, presta attenzione alla progettazione della scalabilità della tua infrastruttura nell'ultima distribuzione funzionante. Determina se è necessario modificare la configurazione quando ridistribuisci il codice.

Preferisci modifiche piccole e frequenti rispetto a modifiche grandi e poco frequenti, in modo che la differenza tra le tue nuove distribuzioni e quelle funzionanti note sia minima.

Eseguire un'analisi delle modalità di errore sulle pipeline di integrazione continua e distribuzione continua (CI/CD) per identificare i problemi che possono complicare gli sforzi di mitigazione. Come per il carico di lavoro nel suo complesso, è possibile analizzare le pipeline per identificare le aree che potrebbero rivelarsi problematiche quando si tenta un determinato tipo di mitigazione.

Utilizza con giudizio la funzionalità di rollback automatizzato:

• Alcuni strumenti CI/CD come Azure DevOps hanno funzionalità di rollback automatico integrate. Considera l'utilizzo di questa funzionalità se ti fornisce un valore tangibile.
• Dovresti adottare la funzionalità di rollback automatico solo dopo aver testato la pipeline in modo approfondito e regolare. Assicurati che la tua pipeline sia sufficientemente matura da introdurre ulteriori problemi se viene attivato un rollback automatico.
• Devi avere fiducia che l'automazione distribuisca solo le modifiche necessarie e che venga attivata solo quando necessario. Progetta attentamente i tuoi trigger per soddisfare questi requisiti.

Utilizza le funzionalità fornite dalla piattaforma durante i rollback. Ad esempio, i backup e il ripristino point-in-time possono facilitare il rollback dell'archiviazione e dei dati. Oppure, se utilizzi macchine virtuali per ospitare la tua applicazione, potrebbe essere utile ripristinare ambiente a un checkpoint immediatamente precedente all'incidente.

Testa frequentemente l'intera strategia di mitigazione degli errori di distribuzione. Come i piani di risposta alle emergenze e i piani di ripristino di emergenza, il piano in caso di fallimento della distribuzione ha successo solo se il tuo team è formato e lo mette in pratica regolarmente. L'ingegneria del caos e il test di inserimento degli errori possono essere tecniche efficaci per testare la strategia di mitigazione della distribuzione.

Facilitazione di Power Platform

Le pipeline in Power Platform mirano a democratizzare la gestione del ciclo di vita delle applicazioni (ALM) per i clienti Power Platform e Dynamics 365 introducendo nel servizio le funzionalità di automazione ALM e di integrazione continua e recapito continuo (CI/CD).

Gli strumenti di creazione di Microsoft Power Platform per Azure DevOps possono essere utilizzati per automatizzare attività comuni di compilazione e distribuzione correlate alle app create in Power Platform.

Le azioni GitHub consentono agli sviluppatori di creare flussi di lavoro automatizzati per il ciclo di vita dello sviluppo software. Power Platform Con GitHub Actions per Microsoft Power Platform puoi creare flussi di lavoro nel tuo repository per creare, testare, creare pacchetti, rilasciare e distribuire app; eseguire l'automazione; e gestire bot e altri componenti basati su Microsoft Power Platform.

Acceleratore ALM è uno strumento open source che include un set di applicazioni, script e pipeline progettati per automatizzare il processo di integrazione/recapito continui.

Automatizzare i test con Azure Pipelines.

Le variabili di ambiente in soluzioni archiviano le chiavi e i valori dei parametri, che servono quindi come input per vari altri oggetti dell'applicazione. La separazione dei parametri dagli oggetti di consumo consente di modificare i valori all'interno dello stesso ambiente o quando si migrano soluzioni ad altri ambienti.

Gli ambienti Power Platform forniscono funzionalità di ripristino temporizzato che possono aiutarti a eseguire il rollback.

Power Platform si integra con Application Insights, che fa parte dell'ecosistema Monitoraggio di Azure. Utilizza l'integrazione per:

• Ricevere telemetria su diagnostica e prestazioni acquisita dalla piattaforma Dataverse in Application Insights. Puoi iscriverti per ricevere la telemetria sulle operazioni che le applicazioni eseguono nel database Dataverse e nelle app basate su modello. Questa telemetria fornisce informazioni che puoi utilizzare per diagnosticare e risolvere i problemi relativi a errori e prestazioni.

• Connettere le tue app canvas a Application Insights. Puoi utilizzare queste analisi per diagnosticare problemi e capire cosa fanno gli utenti con le tue app. Puoi raccogliere informazioni per aiutarti a prendere decisioni aziendali migliori e migliorare la qualità delle tue app.

• Configurare la Power Automate telemetria in modo che fluisca in Application Insights; ad esempio, per monitorare le esecuzioni di flusso cloud e creare avvisi per gli errori di esecuzione di flusso cloud.

Passaggi successivi