Condividi tramite

Raccomandazioni per la progettazione di una strategia di risposta di emergenza

  • Articolo

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

OE:08 Sviluppare una pratica efficace per le operazioni di emergenza. Assicurarsi che il carico di lavoro genera segnali di integrità significativi nell'infrastruttura e nel codice. Raccogliere i dati risultanti e usarli per generare avvisi interattivi che applicano risposte di emergenza tramite dashboard e query. Definire chiaramente le responsabilità umane, ad esempio rotazioni su chiamata, gestione degli eventi imprevisti, accesso alle risorse di emergenza ed esecuzione di postmortem.

Questa guida descrive le raccomandazioni per la progettazione di una strategia di risposta di emergenza. Alcuni problemi che si verificano nel corso del ciclo di vita di un carico di lavoro sono sufficientemente critici da giustificare la dichiarazione delle emergenze. È possibile implementare processi e procedure strettamente controllati e incentrati che il 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 team non è ben preparato. Per ridurre al minimo lo stress e la confusione, progettare una strategia di risposta, condividere la strategia di risposta con l'organizzazione ed eseguire una formazione regolare sulle risposte di emergenza.

Strategie di progettazione chiave

Una strategia di risposta di emergenza deve essere un insieme ordinato e ben definito di processi e procedure. Ogni processo e procedura deve disporre di script per garantire che ogni passaggio progredisca il team verso una risoluzione rapida e sicura di un problema. Per sviluppare una strategia di risposta alle emergenze, prendere in considerazione la panoramica seguente:

  • Prerequisiti
    • Sviluppare una piattaforma di osservabilità
    • Creare un piano di risposta agli eventi imprevisti
  • Fasi degli eventi imprevisti
    • Rilevamento
    • Containment
    • Valutazione
  • Fasi post-evento imprevisto
    • Analisi della causa radice (RCA)
    • Analisi a posteriori
  • Attività in corso
    • Esercitazioni sulle risposte di emergenza

Le sezioni seguenti forniscono raccomandazioni per ognuna di queste fasi.

Per avere una solida strategia di risposta alle emergenze, è necessario disporre di una solida piattaforma di osservabilità. La piattaforma di osservabilità deve avere le caratteristiche seguenti:

  • Monitoraggio olistico: assicurarsi di monitorare accuratamente il carico di lavoro dal punto di vista dell'infrastruttura e dell'applicazione.

  • Registrazione dettagliata: abilitare la registrazione dettagliata per i componenti per facilitare le indagini quando si valuta un problema. Strutturare i log in modo che siano facili da gestire. Inviare automaticamente i log ai sink di dati da preparare per l'analisi.

  • Dashboard utili: creare dashboard basati su modelli di integrità personalizzati per ogni team dell'organizzazione. I diversi team sono responsabili di diversi aspetti dell'integrità del carico di lavoro.

  • Avvisi interattivi: creare avvisi utili per i team del carico di lavoro. Evitare avvisi che non richiedono azioni da parte dei team. Troppi avvisi di questo tipo possono portare a persone che ignorano o bloccano le notifiche di avviso.

  • Notifiche automatiche: assicurarsi che i team appropriati ricevano automaticamente avvisi che richiedono un'azione da essi. Ad esempio, il team di supporto di livello 1 deve ricevere notifiche per tutti gli avvisi, mentre i tecnici della sicurezza devono ricevere avvisi solo per gli eventi di sicurezza.

Per altre informazioni, vedere Raccomandazioni per la progettazione e la creazione di un framework di osservabilità.

Creare un piano di risposta agli eventi imprevisti

La base di una strategia di risposta alle emergenze è un piano di risposta agli eventi imprevisti. Come un piano di ripristino di emergenza, definire chiaramente e accuratamente ruoli, responsabilità e procedure per un piano di risposta agli eventi imprevisti. Il piano deve essere un documento controllato dalla versione soggetto a revisioni regolari che assicurano che siano aggiornate.

Definire chiaramente i componenti seguenti nel piano.

Ruoli

Identificare un gestore di risposta agli eventi imprevisti. Questa persona è proprietaria dell'evento imprevisto dall'avvio alla correzione all'analisi della causa radice. Un responsabile della risposta agli eventi imprevisti garantisce che i processi vengano seguiti e che le parti appropriate vengano informate quando il team di risposta esegue il proprio lavoro.

Identificare un leader postmortem. Questo individuo garantisce che i postmortems vengano eseguiti subito dopo la risoluzione dell'evento imprevisto. Producono un report, che consente di applicare i risultati che escono dall'evento imprevisto.

Processi e procedure

Il team del carico di lavoro deve definire e comprendere i criteri di emergenza. Quando il team determina che un caso è grave, è possibile dichiarare un'emergenza e avviare il piano di ripristino di emergenza. In casi meno gravi, il problema potrebbe non soddisfare i criteri di un'emergenza. Tuttavia, è comunque consigliabile considerare il problema di emergenza, che richiede l'avvio del piano di risposta di emergenza. Le emergenze possono essere problemi interni al carico di lavoro oppure possono essere il risultato di un problema con una dipendenza del carico di lavoro. Il team di supporto deve essere in grado di determinare se un problema segnalato dagli utenti esterni soddisfa i criteri di emergenza, anche se non ha visibilità sul problema sottostante.

Definire con precisione piani di comunicazione e escalation. In base al tipo di notifica di avviso ricevuta, assicurarsi che il supporto di livello 1 possa contattare facilmente i team appropriati per inoltrare i problemi. Assicurarsi che sappiano quale tipo di comunicazione è appropriato per le parti interne ed esterne. Nei piani di comunicazione e escalation, includere un elenco della pianificazione delle chiamate e del personale.

Nel piano generale, includere script di contenimento e valutazione. I team seguono queste procedure dettagliate quando eseguono le funzioni di contenimento e valutazione. Includere una descrizione di ciò che definisce una chiusura degli eventi imprevisti.

Altri elementi da includere

Documentare tutti gli strumenti standard che verranno usati durante gli eventi imprevisti per la comunicazione interna, ad esempio Microsoft Teams, e per tenere traccia delle attività nel corso dell'evento imprevisto, ad esempio gli strumenti di creazione di ticket o gli strumenti di pianificazione del backlog.

Documentare le credenziali di emergenza, altrimenti note come account break-glass. Includere una guida dettagliata che descrive come devono essere usate.

Creare istruzioni di drill di risposta di emergenza e tenere traccia di quando sono state eseguite esercitazioni.

Documentare eventuali misure legali o normative necessarie, ad esempio per comunicare violazioni dei dati.

Agire sui trigger di osservabilità

Quando si dispone di una piattaforma di osservabilità ben progettata che monitora le anomalie e li avvisa automaticamente, è possibile rilevare rapidamente i problemi e determinarne la gravità. Se il problema viene considerato un'emergenza, il piano può essere avviato. In alcuni casi, il team di supporto non riceve una notifica tramite la piattaforma di osservabilità. I clienti potrebbero segnalare problemi di supporto tramite le vie di comunicazione del team di supporto. Oppure possono contattare le persone con cui lavorano regolarmente, ad esempio dirigenti di account o VP. Indipendentemente dal modo in cui il team di supporto riceve una notifica, deve sempre seguire gli stessi passaggi per convalidare il problema e determinare la gravità. La deviazione dal piano di risposta può aggiungere stress e confusione.

Definire le procedure di contenimento

Il primo passaggio della correzione dei problemi consiste nel contenere il problema per proteggere il resto del carico di lavoro. Una strategia di contenimento dipende dal tipo di problema, ma in genere comporta la rimozione del componente interessato dai percorsi di flusso del carico di lavoro. Ad esempio, è possibile arrestare una risorsa o rimuoverla dai percorsi di routing di rete. Gli amministratori di sistema, i tecnici e gli sviluppatori senior devono collaborare per progettare strategie di contenimento. Il contenimento deve limitare il raggio di esplosione dei problemi e mantenere le funzionalità del carico di lavoro in uno stato degradato fino a quando il problema non viene risolto. Se un componente interessato deve essere accessibile per eseguire la valutazione, è fondamentale che l'accesso al resto del carico di lavoro venga bloccato. Il più possibile, è consigliabile accedere al componente solo tramite un percorso separato dal carico di lavoro e dal resto dei sistemi.

Definire le procedure di valutazione

Dopo aver contenuto correttamente il problema, è possibile iniziare a valutare il lavoro. I passaggi da seguire durante la valutazione dipendono dal tipo di problema. Il team per una determinata area di supporto del carico di lavoro deve creare procedure per gli eventi imprevisti correlati al team. Ad esempio, i team di sicurezza devono valutare i problemi di sicurezza e devono seguire gli script che sviluppano. È importante che i team seguano script ben definiti durante l'esecuzione delle attività di valutazione. Questi script devono essere processi step-by-step che includono processi di rollback per annullare modifiche inefficaci o che possono causare altri problemi. Usare gli strumenti di analisi e aggregazione dei log non disponibili per analizzare in modo efficiente i problemi che richiedono un'analisi approfondita. Dopo aver risolto il problema, seguire i processi ben definiti per riportare il componente interessato in modo sicuro nei percorsi di flusso del carico di lavoro.

Generare report sugli eventi imprevisti RCA

I contratti di servizio ai clienti potrebbero determinare che è necessario emettere report RCA entro un determinato periodo di tempo dopo la risoluzione dell'evento imprevisto. Il proprietario dell'evento imprevisto deve creare i report RCA. In caso di impossibilità, un'altra persona che ha lavorato a stretto contatto con il proprietario dell'evento imprevisto può creare i report RCA. Tale strategia garantisce una contabilità accurata dell'evento imprevisto. In genere, le organizzazioni hanno un modello RCA definito con linee guida su come vengono presentate le informazioni e quali tipi di informazioni possono o non possono essere condivisi. Se è necessario creare modelli e linee guida personalizzati, assicurarsi che vengano esaminati e approvati dagli stakeholder.

Conservare i postmortem degli eventi imprevisti

Un individuo imparziale dovrebbe condurre postmorte senza colpa. Nelle sessioni postmortem tutti condividono i risultati di un evento imprevisto. Ogni team coinvolto nella risposta agli eventi imprevisti deve essere rappresentato da singoli utenti che hanno lavorato all'evento imprevisto. Tali persone dovrebbero venire alla sessione preparata con esempi delle aree che hanno avuto successo e aree che possono essere migliorate. La sessione non è un forum per l'assegnazione della colpa per l'evento imprevisto o i problemi che potrebbero essersi verificati durante la risposta. Il leader postmortem deve lasciare la sessione con un elenco chiaro di elementi di azione che si concentrano sul miglioramento, ad esempio:

  • Miglioramenti al piano di risposta. I processi o le procedure potrebbero dover essere rivalutati e riscritti per acquisire meglio le azioni appropriate.

  • Miglioramenti alla piattaforma di osservabilità. Potrebbe essere necessario rivalutare le soglie per rilevare il tipo specifico di evento imprevisto in precedenza oppure potrebbe essere necessario implementare un nuovo monitoraggio per rilevare il comportamento non tenuto conto.

  • Miglioramenti al carico di lavoro. L'evento imprevisto potrebbe esporre una vulnerabilità nel carico di lavoro che deve essere risolto come correzione permanente.

Considerazioni

Una strategia di risposta eccessivamente aggressiva può causare falsi allarmi o escalation non necessarie.

Analogamente, l'implementazione aggressiva del ridimensionamento automatico o altre azioni di riparazione automatica per rispondere alle violazioni delle soglie può portare a spese e oneri di gestione non necessari. È possibile che non si conoscano le soglie esatte da impostare per gli avvisi e le azioni automatiche, ad esempio il ridimensionamento. Eseguire test in ambienti inferiori e nell'ambiente di produzione per determinare le soglie corrette per i requisiti.

Facilitazione di Azure

Monitoraggio di Azure è una soluzione completa per la raccolta, l'analisi e la risposta ai dati di monitoraggio da ambienti cloud e locali. Include una solida piattaforma di avvisi che è possibile configurare per le notifiche automatiche e altre azioni, ad esempio il ridimensionamento automatico e altri meccanismi di riparazione automatica.

Usare Monitoraggio per integrare Machine Learning. Automatizzare e ottimizzare la valutazione degli eventi imprevisti e le misure proattive. Per altre informazioni, vedere AIOps e Machine Learning in Monitoraggio.

Log Analytics è uno strumento di analisi affidabile integrato in Monitoraggio. È possibile usare Log Analytics per eseguire query su log aggregati e ottenere informazioni dettagliate sul carico di lavoro.

Microsoft offre formazione sulla conformità agli eventi imprevisti correlati ad Azure. Per altre informazioni, vedere Introduzione all'idoneità agli eventi imprevisti di Azure e Idoneità agli eventi imprevisti.

Elenco di controllo per l'eccellenza operativa

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo per l'eccellenza operativa