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:

OE:11	Implementa una strategia di mitigazione degli errori di distribuzione che risolva i problemi imprevisti durante l'implementazione con un ripristino rapido. Combina più approcci, come il rollback, la disabilitazione delle funzionalità o l'utilizzo delle funzionalità native del modello di distribuzione.

Questa guida descrive gli elementi consigliati per progettare una strategia standardizzata per gestire in modo efficace gli errori di distribuzione. Come altri problemi del 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. Tale strategia consente al team del carico di lavoro di mitigare in modo efficiente gli errori con il minor 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, come test di fumo falliti, segnalazioni di utenti o avvisi generati dalla piattaforma di monitoraggio.
2. Decisione: è necessario decidere quale sia la migliore strategia di mitigazione per il tipo di errore specifico.
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 man mano che si rileva e si risolve il problema, come richiesto dal piano di risposta alle emergenze.
5. Postmortem: i post-mortem irreprensibili offrono al team del carico di lavoro l'opportunità di identificare aree di miglioramento e creare piani per applicare quanto appreso.

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

duplicati

Per identificare rapidamente i problemi relativi alle distribuzioni, sono necessarie solide procedure di test e monitoraggio correlate alle distribuzioni. Per rilevare rapidamente le anomalie, è possibile integrare il monitoraggio e gli avvisi del carico di lavoro usando uno strumento di gestione delle prestazioni delle applicazioni e la registrazione tramite la 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. Assicurati che il personale di supporto sia formato su come eseguire l'escalation dei problemi di distribuzione per un routing corretto. Le escalation devono essere in linea con il piano di risposta alle emergenze del carico di lavoro.

Decisione

La decisione di una strategia di mitigazione appropriata per un problema di distribuzione implica la considerazione di 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 per correggere il codice è basso, il rollforward implementando un hotfix è la scelta giusta per 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 del carico di lavoro sia d'accordo sul significato di "ultimo stato conosciuto come valido". Questa espressione si riferisce all'ultimo stato del carico di lavoro 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 devono 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.

• Salta la funzionalità problematica: se puoi ignorare il problema usando flag di funzionalità o un altro tipo di proprietà di configurazione di runtime, potresti decidere che continuare con l'implementazione è la strategia giusta per 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 riesci a risolvere il problema durante l'implementazione, un hotfix potrebbe essere la strategia di mitigazione più pratica.

  Come qualsiasi altro codice, gli hotfix devono essere sottoposti a procedure di distribuzione sicure. Ma con un hotfix, la sequenza temporale è notevolmente accelerata. È necessario utilizzare una strategia di promozione del codice in tutti gli ambienti. È inoltre necessario controllare il codice dell'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 del carico di lavoro deve comunicare direttamente con gli utenti, chiarisci 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

I post-mortem devono seguire tutte le distribuzioni fallite, senza eccezioni. Ogni implementazione fallita è un'opportunità di apprendimento. I post-mortem possono aiutarti a identificare i punti deboli nei processi di distribuzione e sviluppo e 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 post-mortem devono seguire 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 le modifiche piccole e frequenti a quelle grandi e poco frequenti, in modo che la differenza tra le nuove distribuzioni e quelle valide note sia minima.

Esegui un'analisi della modalità di errore sulle pipeline di integrazione continua e distribuzione continua (CI/CD) per identificare i problemi che possono complicare le attività di mitigazione. Come per il 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.

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 temporizzato possono aiutare con i rollback dell'archiviazione e dei dati. Oppure, se utilizzi macchine virtuali per ospitare l'applicazione, può essere utile ripristinare l'ambiente a un checkpoint immediatamente prima di un 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).

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

GitHub Actions per Power Platform consentono agli sviluppatori di creare flussi di lavoro SDLC (Software Development Life Cycle) automatizzati. 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.

Usa il kit Power CAT di Copilot Studio per configurare agenti e test. Eseguendo singoli test sulle API di Copilot Studio (Direct Line) e valuta le risposte agente rispetto ai risultati previsti.

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.

• Configura la telemetria di Power Automate da inviare a Application Insights, ad esempio per monitorare le esecuzioni del flusso cloud e creare avvisi per gli errori di esecuzione del flusso cloud.

• Acquisisci i dati di telemetria dall'Microsoft Copilot Studio agente per usarli in Application Insights di Azure. Puoi usare questi dati di telemetria per monitorare i messaggi e gli eventi registrati inviati a e dal tuo agente, gli argomenti da attivare durante le conversazioni utente e gli eventi di telemetria personalizzati che possono essere inviati dai tuoi argomenti.

Elenco di controllo di Eccellenza operativa

Fai riferimento alla serie completa di elementi consigliati.

Elenco di controllo di Eccellenza operativa