Consigli per la progettazione di una strategia di risposta alle emergenze

Si applica a questa raccomandazione della checklist di eccellenza operativa ben progettata: Power Platform

OE:07 Sviluppa una pratica efficace delle operazioni di emergenza. Verifica che il tuo carico di lavoro emetta segnali di integrità significativi. Raccogliere i dati risultanti e utilizzarli per generare avvisi attuabili che mettono in atto risposte di emergenza tramite dashboard e query. Definisci chiaramente le responsabilità umane, come le rotazioni delle chiamate, la gestione degli incidenti, l'accesso alle risorse di emergenza e l'esecuzione dei postmortem.

Questa guida descrive i consigli per la progettazione di una strategia di risposta alle emergenze. Alcuni carichi di lavoro potrebbero essere critici per la missione e i problemi che si presentano nel corso del ciclo di vita di un carico di lavoro potrebbero essere abbastanza gravi da giustificarne la dichiarazione di emergenza. Puoi implementare processi e procedure strettamente controllati e mirati che il tuo team può seguire per garantire che un problema venga gestito in modo calmo e ordinato. Le emergenze aumentano naturalmente i livelli di stress di tutti e possono portare a un ambiente caotico se il tuo team non ha un'adeguata preparazione. Per ridurre al minimo lo stress e la confusione, progetta una strategia di risposta, condividila con la tua organizzazione ed esegui regolarmente corsi di formazione sulla risposta alle emergenze.

Strategie di progettazione chiave

Una strategia di risposta alle emergenze dovrebbe essere un insieme ben definito di processi e procedure. Ogni processo e procedura dovrebbe disporre di script per garantire che ogni passaggio consenta al tuo team di risolvere un problema in modo rapido e sicuro. Per sviluppare una strategia di risposta alle emergenze, considera la seguente panoramica:

  • Prerequisiti
    • Sviluppare un sistema di monitoraggio
    • Creare un piano di risposta agli incidenti
  • Fasi dell'incidente
    • Rilevamento e contenimento
    • Valutazione
  • Fasi successive all'incidente
    • Analisi della causa radice
    • Post-mortem
  • Attività in corso
    • Drill down di risposta alle emergenze

Le sezioni seguenti forniscono consigli per ciascuna di queste fasi.

Sistema di monitoraggio

Per avere una strategia di emergenza risposta solida, è necessario disporre di un solido sistema di monitoraggio o di una piattaforma di osservabilità. La tua piattaforma di osservabilità dovrebbe avere le seguenti caratteristiche:

  • Monitoraggio olistico: assicurati di monitorare attentamente il tuo carico di lavoro dal punto di vista della configurazione e dell'applicazione e di includere il monitoraggio dell'infrastruttura se i componenti del tuo carico di lavoro sono ospitati nel cloud o locale. Assicurati che tutti i componenti del tuo carico di lavoro siano coperti dalla tua strategia di monitoraggio. Ad esempio, se il carico di lavoro interagisce con risorse di Azure o con un sistema locale, includi tali componenti nel monitoraggio.

  • Registrazione dettagliata: abilita la registrazione dettagliata per i tuoi componenti per agevolare le indagini quando classifichi un problema. Struttura i log in modo che siano facili da gestire. Invia automaticamente i log ai sink di dati per essere preparato per l'analisi.

  • Dashboard utili: crea dashboard basate sul tuo modello sanitario, personalizzate per ogni team della tua organizzazione. Team diversi sono responsabili di aspetti diversi dell'integrità del carico di lavoro.

  • Avvisi attuabili: crea avvisi utili per i tuoi team addetti al carico di lavoro. Evita gli avvisi che non richiedono l'intervento dei tuoi team. Troppi avvisi di questo tipo possono portare le persone a ignorare o bloccare le notifiche di avviso.

  • Notifiche automatiche: assicurati che i team appropriati ricevano automaticamente gli avvisi che richiedono un intervento da parte loro. Ad esempio, il team di supporto di Livello 1 dovrebbe ricevere notifiche per tutti gli avvisi, mentre i tecnici della sicurezza dovrebbero ricevere avvisi solo per gli eventi di sicurezza.

Per ulteriori informazioni, consultare Raccomandazioni per la progettazione e la creazione di un quadro di monitoraggio.

Piano di risposta agli incidenti

La base di una strategia di risposta alle emergenze è un piano di risposta agli incidenti. Come per un piano di ripristino in caso di disastro, definire in modo chiaro e approfondito ruoli, responsabilità e procedure per rispondere a un incidente. Il piano dovrebbe essere un documento con controllo della versione soggetto a revisioni regolari che ne garantiscano l'aggiornamento.

Definisci chiaramente i seguenti componenti nel tuo piano.

Ruoli

Identificare un responsabile della risposta agli incidenti. Questa persona è proprietaria dell'incidente dall'inizio alla riparazione fino all'analisi della causa principale. Un responsabile degli incidenti risposta garantisce che i processi vengano seguiti e che le parti interessate vengano informate mentre il team risposta svolge il proprio lavoro.

Identifica un leader del post-mortem. Questa persona garantisce che i post-mortem vengano eseguiti subito dopo la risoluzione dell'incidente. Producono un report che ti aiuta ad applicare i risultati emersi dall'incidente.

Processi e procedure

Il team del carico di lavoro dovrebbe definire e comprendere i criteri di emergenza. Quando il tuo team determina che un caso è grave, puoi dichiarare un disastro e avviare il piano di ripristino di emergenza. Nei casi meno gravi, il problema potrebbe non soddisfare i criteri di un disastro, ma dovresti comunque considerarlo un'emergenza, che richiede l'avvio del piano di emergenza risposta. Le emergenze possono essere interne al carico di lavoro, come bug nel codice dell'applicazione, o derivanti da un problema con una dipendenza del carico di lavoro, come la non disponibilità di un'API o di un database. Un'emergenza potrebbe anche essere causata da un'interruzione del servizio del tuo fornitore (ad esempio un problema con il Microsoft Entra ID o Power Platform). Il team di supporto deve essere in grado di determinare se un problema soddisfa i criteri di emergenza, anche se non ha visibilità sul problema sottostante.

Definisci con precisione i piani di comunicazione ed escalation. In base al tipo di notifica di avviso ricevuta, assicurati che i membri del team di supporto di Livello 1 possano contattare facilmente i team appropriati per segnalare i problemi.

Altri elementi da includere

Documentare tutti gli strumenti standard utilizzati durante gli incidenti per la comunicazione interna, come Microsoft Teams, e per monitorare le attività nel corso dell'incidente, come gli strumenti di ticketing o gli strumenti di pianificazione degli arretrati.

Documenta le tue credenziali di emergenza, altrimenti note come account break-glass. Includi una guida dettagliata che descrive come dovrebbero essere utilizzati.

Crea istruzioni di emergenza risposta eseguire il drill-down e tieni traccia di quando vengono eseguite le esercitazioni.

Documentare tutte le misure legali o normative necessarie, come la comunicazione delle violazioni dei dati.

Rilevamento e contenimento degli incidenti

Quando disponi di un sistema di monitoraggio ben progettato che monitora le anomalie e avvisa automaticamente, è possibile rilevare rapidamente i problemi e determinarne la gravità. Se il problema è considerato un’emergenza, il piano può essere avviato. In alcuni casi, il team di supporto non viene avvisato tramite il sistema di monitoraggio. Gli utenti potrebbero segnalare problemi al supporto utilizzando le vie di comunicazione del team di supporto. Oppure potrebbero contattare persone con cui lavorano regolarmente o con cui sanno che lavorano, come gli amministratori del tuo servizio o il team del Centro di eccellenza. Power Platform Power Platform Indipendentemente da come viene informato il team di supporto, questo deve sempre seguire gli stessi passaggi per convalidare il problema e determinarne la gravità. La deviazione dal piano di risposta può aggiungere stress e confusione.

Valutazione

Il primo passaggio nella risoluzione dei problemi consiste nell'identificare il componente del carico di lavoro che causa il problema. I passaggi da seguire durante la valutazione dipendono dal tipo di problema. Il team addetto a una determinata area di supporto del carico di lavoro dovrebbe creare procedure per gli incidenti correlati al proprio lavoro. Ad esempio, i team di sicurezza dovrebbero valutare i problemi di sicurezza e seguire gli script da loro sviluppati. È importante che i team seguano script ben definiti mentre svolgono le loro attività di valutazione. Questi script dovrebbero contenere istruzioni dettagliate che includano processi di rollback per annullare le modifiche inefficaci o che possono causare altri problemi. Una volta risolto il problema, segui processi ben definiti per riportare in sicurezza il componente interessato nei percorsi di flusso del carico di lavoro.

Creazione dei report di analisi della causa radice

I report di analisi delle cause profonde (RCA) devono essere redatti dal responsabile dell'incidente o da qualcuno che ha lavorato a stretto contatto con lui. Questa strategia garantisce una registrazione accurata dell’incidente. In genere, le organizzazioni dispongono di un modello RCA definito con linee guida su come vengono presentate le informazioni e su quali tipi di informazioni possono o non possono essere condivise. Se hai bisogno di creare un tuo modello e delle tue linee guida, assicurati che le parti interessate li esaminino e approvino.

Post-mortem dell'incidente

Una persona imparziale dovrebbe realizzare post-mortem obiettivi. Nelle sessioni post-mortem, tutti condividono i risultati di un incidente. Ogni team coinvolto nell'incidente risposta dovrebbe essere rappresentato dalle persone che hanno lavorato all'incidente. Tali soggetti dovrebbero presentarsi alla sessione preparati con esempi di azioni che hanno avuto successo e di aree che possono essere migliorate. La sessione non è un forum in cui attribuire la colpa dell'incidente o dei problemi che potrebbero sorgere durante risposta. Il leader del post-mortem dovrebbe lasciare la sessione con un chiaro elenco di azioni incentrate sul miglioramento, come ad esempio:

  • Miglioramenti al piano di risposta. Potrebbe essere necessario rivalutare e riscrivere processi o procedure per acquisire meglio le azioni appropriate.
  • Miglioramenti al sistema di monitoraggio. Potrebbe essere necessario rivalutare le soglie per individuare in anticipo il tipo specifico di incidente oppure potrebbe essere necessario implementare un nuovo monitoraggio per individuare comportamenti di cui non si è tenuto conto.
  • Miglioramenti al carico di lavoro. L'incidente potrebbe esporre una vulnerabilità nel carico di lavoro che deve essere risolta come soluzione permanente.

Considerazioni

La tua strategia di risposta alle emergenze dovrebbe essere strettamente allineata alla tua strategia di supporto Power Platform generale. Collabora con i tuoi amministratori e con il team del Centro di eccellenza per discutere le opzioni e i processi di supporto e di emergenza risposta che potrebbero essere già definiti. Power Platform

È importante definire il processo di supporto e il percorso di escalation classificare le soluzioni costruito in base alla criticità. Questa pratica consente di stabilire processi che garantiscono che le applicazioni critiche abbiano le protezioni necessarie per supportarle, senza soffocare l'innovazione degli scenari di produttività o sopraffare i team risposta addetti agli incidenti. Mentre definisci i tuoi modelli di supporto, pensa anche a un percorso di crescita. Una soluzione potrebbe inizialmente richiedere solo un supporto a livello di produttività, ma poi crescere in funzionalità o base di utenti fino a richiedere un livello di supporto più elevato. Definisci in che modo gli autori possono richiedere un supporto più formale e trasferire una soluzione agli ambienti supportati.

Facilitazione di Power Platform

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.

  • Acquisisci dati di telemetria dal tuo Microsoft Copilot Studio copilota per utilizzarli in Azure Application Insights. Puoi utilizzare questa telemetria per monitorare i messaggi registrati e gli eventi inviati e ricevuti dal tuo copilota, gli argomenti da attivare durante le conversazioni degli utenti e gli eventi di telemetria personalizzati che possono essere inviati dai tuoi argomenti.

Application Insights è una soluzione completa per raccogliere, analizzare e rispondere al monitoraggio dei dati da ambienti cloud e locali. Include una solida piattaforma di avvisi che puoi configurare per le notifiche automatiche e altre azioni.

Il kit di automazione di Power Platform è un set di strumenti che accelera l'uso e il supporto di Power Automate per desktop nei progetti di automazione. Il kit fornisce gli strumenti che consentono di gestire i progetti di automazione e di monitorarli per stimare il risparmio e il ritorno sull'investimento (ROI). Parte del kit di automazione è il centro di controllo, che integra la funzionalità di esecuzione flusso desktop di Monitor. L'obiettivo principale del centro di controllo è una vista dell'orchestratore che consente agli analisti e alle organizzazioni di supporto di monitorare, agire e avvisare quando necessario.

Passaggi successivi