Raccomandazioni per la progettazione di una strategia di risposta di emergenza

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

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 assicurarsi 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 set ordinato e ben definito di processi e procedure. Ogni processo e procedura deve avere script per garantire che ogni passaggio progredisca il team verso la risoluzione rapida e sicura di un problema. Per sviluppare una strategia di risposta di emergenza, considerare 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.

Osservabilità

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 all'interno dell'organizzazione. 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 dai team. Troppi avvisi di questo tipo possono portare a persone che ignorano o bloccano le notifiche degli avvisi.

• 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à.

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 sia aggiornato.

Definire chiaramente i componenti seguenti nel piano.

Ruoli

Identificare un responsabile della risposta agli eventi imprevisti. Questa persona possiede l'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 svolge 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. Ma è 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 ed 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 on-call 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 degli elementi che definiscono la chiusura di un evento imprevisto.

Altri elementi da includere

Documentare tutti gli strumenti standard che verranno usati durante gli eventi imprevisti per le comunicazioni interne, 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 le istruzioni di drill della risposta di emergenza e tenere traccia di quando sono state eseguite esercitazioni.

Documentare eventuali misure legali o normative necessarie, ad esempio la comunicazione delle violazioni dei dati.

Rilevamento degli eventi imprevisti

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 da supportare usando le vie di comunicazione del team di supporto. Oppure possono contattare le persone con cui lavorano regolarmente, ad esempio i dirigenti dell'account o i provider di servizi virtuali. 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.

Containment

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 del 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 danneggiato 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.

Valutazione

Dopo aver contenuto correttamente il problema, è possibile iniziare a valutare il lavoro. I passaggi seguiti 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 sviluppati. È 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 i processi di rollback per annullare le modifiche che sono inefficaci o possono causare altri problemi. Usare gli strumenti di aggregazione e analisi dei log off-the-shelf per analizzare in modo efficiente i problemi che richiedono un'analisi approfondita. Dopo aver risolto il problema, seguire processi ben definiti per ripristinare in modo sicuro il componente interessato nei percorsi del flusso del carico di lavoro.

Creazione di report RCA

I contratti di servizio (contratti di servizio) ai clienti potrebbero determinare che è necessario rilasciare report RCA entro un determinato periodo di tempo dopo la risoluzione dell'evento imprevisto. Il proprietario dell'evento imprevisto deve creare i report RCA. Se non è possibile, un'altra persona che ha lavorato strettamente con il proprietario dell'evento imprevisto può creare i report RCA. Questa 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 condivise. Se è necessario creare un modello e linee guida personalizzate, assicurarsi che vengano esaminate e approvate dagli stakeholder.

Postmortems degli eventi imprevisti

Un individuo imparziale deve portare postmorte senza colpa. Nelle sessioni postmortem tutti condividono i risultati di un evento imprevisto. Ogni team coinvolto nella risposta all'evento imprevisto deve essere rappresentato da singoli utenti che hanno lavorato sull'evento imprevisto. Tali individui devono venire alla sessione preparata con esempi delle aree che hanno avuto successo e aree che possono essere migliorate. La sessione non è un forum per assegnare la colpa per l'evento imprevisto o i problemi che potrebbero essere venuti 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 essere rivalutati e riscritti per acquisire meglio le azioni appropriate.

• Miglioramenti alla piattaforma di osservabilità. Le soglie potrebbero essere rivalutate per rilevare il tipo specifico di evento imprevisto precedente o il nuovo monitoraggio potrebbe essere necessario implementare per rilevare il comportamento che non è stato 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 di scalabilità automatica o altre azioni di auto-guarigione per rispondere alle violazioni delle soglie possono causare spese non necessarie e carico di gestione. Potrebbe non essere possibile conoscere le soglie esatte da impostare per l'avviso e le azioni automatiche, ad esempio il ridimensionamento. Eseguire test in ambienti inferiori e in 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 piattaforma di avviso affidabile che è possibile configurare per le notifiche automatiche e altre azioni, ad esempio il ridimensionamento automatico e altri meccanismi di auto-guarigione.

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

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

Microsoft offre training sulla conformità agli eventi imprevisti correlati ad Azure. Per altre informazioni, vedere Introduzione alla conformità agli eventi imprevisti di Azure e conformità agli eventi imprevisti.

Collegamenti correlati

• Raccomandazioni per la progettazione e la creazione di un framework di osservabilità
• Raccomandazioni per la progettazione di una strategia di monitoraggio e avviso affidabile
• Raccomandazioni per la auto-guarigione e la conservazione automatica

Elenco di controllo Di eccellenza operativa

Fare riferimento al set completo di raccomandazioni.