Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Un evento imprevisto è un evento non pianificato che interrompe, degrada o minaccia di interrompere il normale funzionamento di un sistema. Gli eventi imprevisti spesso influiscono negativamente sui clienti o su un'azienda. Esistono in uno spettro, da interruzioni temporanee o localizzate a eventi o emergenze diffuse. Esempi di eventi imprevisti di sicurezza includono violazioni dei dati, violazioni normative, malware o compromissioni dell'identità. Le cause includono errori hardware o infrastruttura, limiti delle risorse, errori umani come distribuzioni non riuscite o errori di configurazione o fattori esterni come gli attacchi alla sicurezza.
La gestione degli eventi imprevisti (IcM) offre un approccio sistematico per il ripristino del servizio durante le interruzioni. Coordina il rilevamento, l'indagine, la mitigazione e la risoluzione mantenendo al contempo comunicazioni chiare e documentando informazioni dettagliate per un miglioramento continuo. La risposta agli eventi imprevisti segue lo stesso playbook indipendentemente dal tipo di evento imprevisto.
Quando crei il tuo piano IcM, non concentrarti solo sui dashboard e sui runbook. In qualità di architetto, progettare operazioni in cui persone, processi e strumenti interagiscono sotto pressione per ripristinare i sistemi in modo efficiente e senza caos. La strategia IcM deve essere ridimensionata in base alla gravità, dalla mitigazione rapida per gli incidenti minori agli sforzi coordinati tra team per gli eventi maggiori. La risposta può anche variare a seconda della causa.
Questo articolo è incentrato sulle fasi di IcM, che includono preparazione, risposta attiva agli eventi imprevisti, revisione post-evento imprevisto e miglioramento continuo. Queste linee guida includono anche un esempio per illustrare le procedure di progettazione. Prima di iniziare, esaminare le strategie chiave e scegliere quelle che hanno senso per l'azienda. Per altre informazioni, vedere Strategie di architettura di OE:08 per la progettazione di un processo IcM.
Questo articolo non illustra le emergenze che richiedono interventi di ripristino specializzati. Per altre informazioni sulla gestione di questi scenari, vedere Sviluppare un piano di ripristino di emergenza per le distribuzioni in più aree.
Terminologia
| Termine | Definition |
|---|---|
| Raggio di esplosione | Ambito dell'impatto o dell'area interessata quando si verifica un evento imprevisto, che mira a limitare le strategie di contenimento. |
| Account di emergenza | Credenziali di emergenza con privilegi elevati usati durante gli eventi imprevisti critici, rigorosamente controllate con linee guida di utilizzo chiare. |
| Bridge team | Il team di valutazione che si riunisce per analizzare un incidente, chiamato anche bridge di ingegneria. È costituito da esperti tecnici e decision maker pertinenti. |
| Contenimento | Primo passaggio della correzione degli eventi imprevisti che isola i componenti interessati per impedire la distribuzione del problema in altre parti del carico di lavoro. |
| Gestione degli eventi imprevisti (IcM) | Processo strutturato di rilevamento, valutazione, mitigazione e risoluzione degli eventi imprevisti durante il coordinamento della comunicazione e l'acquisizione di lezioni apprese. |
| Last-known-good | Ultimo stato integro del carico di lavoro prima dell'inizio di un evento imprevisto, usato come punto di riferimento per le operazioni di rollback. |
| Mitigazione | Azioni per ridurre o rimuovere l'impatto di un evento imprevisto, inclusi il rollback, il fallback, il bypass o le correzioni di emergenza. |
| Retrospettiva | Un processo di revisione post-incidente che non attribuisce colpe e si concentra sull'identificazione delle lezioni apprese e dei miglioramenti attuabili, piuttosto che sull'assegnare la colpa. |
| Analisi della causa radice (RCA) | Processo sistematico di analisi di un evento imprevisto per identificare i fattori sottostanti responsabili del problema e prevenire la ricorrenza. |
| Livello di gravità | Un sistema di classificazione, ad esempio critico, alto, medio e basso, che determina il livello di risposta appropriato in base all'impatto aziendale e agli utenti interessati. |
| Valutazione | Processo di analisi e definizione delle priorità degli eventi imprevisti per determinare gravità, impatto e azioni di risposta appropriate. |
Preparazione
Prima che si verifichi un evento imprevisto, configurare le basi per una risposta efficace progettando l'osservabilità, definendo ruoli e processi chiari e preparando gli strumenti e le risorse necessari ai team. Documentare il piano di risposta agli eventi imprevisti e aggiornarlo ed esaminarlo regolarmente.
Mantenere diagrammi di architettura accurati e aggiornati che mostrano tutti i componenti e le relative interazioni per aiutare i team a identificare rapidamente i colli di bottiglia o i singoli punti di guasto. Questo approccio consente una risoluzione dei problemi più rapida durante situazioni ad alta pressione.
Definire i dati degli eventi imprevisti che lo stack di monitoraggio deve fornire per l'intero carico di lavoro:
Raccogliere dati di telemetria end-to-end, tra cui infrastruttura e applicazioni.
Abilitare la registrazione strutturata per tutti i componenti per supportare la valutazione e l'analisi e inviare i log ai sink di dati per l'analisi. Se necessario, inoltrare anche i log ai sink gestiti centralmente. Assicurarsi che i membri del team dispongano di accesso con privilegi minimi e limitati al tempo durante gli eventi imprevisti.
Creare dashboard basati sul modello di integrità del carico di lavoro. I dashboard mostrano metriche e segnali monitorati dal team.
Configurare avvisi interattivi che attivano le notifiche solo quando vengono superate le soglie e viene rilevato un potenziale evento imprevisto. Ottimizzare gli avvisi per evitare troppi avvisi (rumore) o troppo pochi avvisi. Ad esempio, per gli eventi imprevisti del sito live, gli avvisi devono monitorare metriche critiche come l'unità di elaborazione centrale (CPU), la memoria, i tempi di risposta e le prestazioni del database per rilevare problemi interattivi allineati agli obiettivi di prestazioni.
Instradare gli avvisi automaticamente ai team appropriati. Ad esempio, il supporto di livello 1 ottiene tutti gli avvisi, mentre i tecnici della sicurezza ricevono solo avvisi correlati alla sicurezza.
Per altre informazioni, vedere Raccomandazioni per la progettazione e la creazione di un framework di osservabilità.
Definire i ruoli chiave per garantire la responsabilità, il processo decisionale e un follow-up efficace durante e dopo gli eventi imprevisti. Creare processi di approvazione appropriati e codificarli in un albero delle decisioni chiaro. Definire i livelli di autorizzazione per diversi livelli di gravità, decisioni di mitigazione, percorsi di escalation e altre aree.
Usare gli esempi seguenti come punto di partenza e adattarli in base alla struttura del team.
Ruolo Responsabilità Gestione risposta agli eventi imprevisti È responsabile dell'incidente dal rilevamento alla risoluzione e RCA. Assicura che i processi vengano seguiti, vengano prese decisioni e le persone giuste siano informate. Leader retrospettivo Conduce revisioni post-evento imprevisto, acquisisce lezioni apprese, produce report interattivi e assicura che i risultati vengano applicati. Tecnico on-call Attenua e risolve attivamente gli eventi imprevisti. Segue le responsabilità per diversi tipi di eventi imprevisti e collabora con team specializzati in base alle esigenze per garantire una risoluzione tempestiva dell'evento imprevisto. Definire le procedure per l'analisi:
Definire le categorie per i tipi di eventi imprevisti, ad esempio eventi operativi, di sicurezza, prestazioni e distribuzione, e livelli di gravità, ad esempio critici, alti, medi e bassi, che si applicano al carico di lavoro.
Documentare come valutare la gravità, l'impatto e l'urgenza dell'evento imprevisto. Prendere in considerazione l'impatto dell'utente, i sistemi interessati e le funzioni critiche per l'azienda. In base al livello di gravità, il team attiva il piano di ripristino di emergenza per i casi che soddisfano le soglie a livello di emergenza. Oppure seguono il piano di risposta standard per eventi imprevisti meno gravi.
Definire strategie che isolano o rimuovono il componente interessato dai percorsi del flusso del carico di lavoro, ad esempio arrestare una risorsa o reindirizzare il traffico. Identificare quali ruoli hanno l'autorità di intraprendere un'azione di contenimento.
Impostare i sistemi di monitoraggio per avviare automaticamente il contenimento per gli eventi imprevisti definiti. Questo approccio mantiene gli esseri umani coinvolti nel processo per le decisioni critiche. Gli amministratori di sistema, i tecnici e gli sviluppatori senior devono collaborare per limitare il raggio di esplosione mantenendo al tempo stesso funzionalità ridotte. Se un componente deve rimanere disponibile per la valutazione, isolarne rigorosamente l'accesso dal resto del carico di lavoro.
Creare linee guida per la selezione di strategie di mitigazione in base alla gravità degli eventi imprevisti, ad esempio isolamento, rollback, modifiche alla configurazione e soluzioni alternative.
Specificare quali team o persone gestiscono l'incidente in base al tipo e alla gravità. Includere i percorsi di escalation per quando i risponditori iniziali non possono risolvere il problema.
Descrivere i dati da raccogliere durante la valutazione, ad esempio log, metriche, report utente e avvisi, per supportare l'analisi e il processo decisionale. Includere anche chi deve avere accesso a tali dati.
Importante
Proteggere le credenziali di emergenza, o gli account break-glass, stabilendo regole chiare. Determinare chi può usarli, quando e esattamente come. Abbina queste regole con esercitazioni di emergenza e traccia ogni esercitazione. Definire la frequenza con cui il team deve eseguire le esercitazioni. Durante un incidente, non c'è tempo per capirlo nel momento. Le esercitazioni offrono opportunità di pratica e perfezionamento adeguate.
Configurare l'infrastruttura per supportare la risoluzione:
Parametrizzare le pipeline. Abilitare le pipeline di distribuzione e ripristino per accettare versioni specifiche per il rollback rapido o per correggere la distribuzione.
Assicurare la coerenza del piano dati. Mantenere le chiavi, i segreti, le configurazioni e i dati sullo stato allineati durante le operazioni di ripristino.
Automatizzare il ridimensionamento dell'infrastruttura. Modificare automaticamente le risorse per gestire i turni del traffico o aumentare il carico.
Implementare l'auto-riparazione. Automatizzare in modo sicuro le risposte ai modelli comuni di incidenti, ma includere il monitoraggio adeguato e le opzioni per l'override manuale.
Definire i processi di comunicazione. Documentare piani di comunicazione ed escalation chiari in modo che il supporto di primo livello possa raggiungere rapidamente i team giusti. Specificare i canali di comunicazione appropriati per gli stakeholder interni ed esterni e includere pianificazioni di chiamata e dettagli di contatto.
Definire l'utilizzo di uno strumento IcM e le procedure operative standard da acquisire in un flusso di lavoro semplice. Il flusso di lavoro include quattro passaggi: creare, confermare, attenuare e risolvere. Lo strumento offre visibilità ai team, tiene traccia dello stato di avanzamento, mantiene la responsabilità e garantisce sempre una gestione coerente degli eventi imprevisti. Centralizza tutte le attività per supportare la gestione del sito in diretta e le rotazioni on-call.
Definire i criteri che contrassegnano ufficialmente un evento imprevisto come chiuso:
Includere fattori di risoluzione chiari. In genere, la risoluzione indica che il sistema e i servizi operano all'interno dei contratti di servizio (SLA), le prestazioni e l'affidabilità restituiscono livelli accettabili e le azioni di mitigazione immediate vengono completate correttamente.
Includere i controlli di convalida per confermare la risoluzione completa. Usare gli strumenti di monitoraggio per verificare che l'evento imprevisto non influisca più sul sistema e che gli utenti interessati non subisca più interruzioni.
Includere i requisiti di comunicazione quando si chiude un incidente. Inviare una notifica agli stakeholder pertinenti, inclusi i team interni, il personale di supporto e gli utenti interessati e fornire un riepilogo delle azioni intraprese insieme al lavoro in corso.
Includere una documentazione dettagliata quando si chiude un incidente. Registrare tutti i dettagli nel sistema IcM. Includere il trigger, i passaggi di contenimento, le decisioni di triage e la risoluzione finale. Considerare questa documentazione come la consegna per l'RCA e alla retrospettiva per trarre lezioni apprese.
Importante
Progettare le operazioni in modo che solo l'autorità designata, come Incident Response Manager, possa chiudere un evento imprevisto. Applicare elenchi di controllo rigorosi per bloccare la chiusura prematura. Ignorare i passaggi può lasciare i problemi nascosti irrisolti, il che può trasformare un incidente chiuso in un disastro ripetuto.
Rilevare, analizzare e rispondere
La fase 2 è incentrata sul rilevamento e sulla risposta agli eventi imprevisti in modo rapido ed efficace. Questa fase identifica i problemi in anticipo, ne valuta l'impatto e implementa le strategie di mitigazione corrette, contenendo le interruzioni. Questa fase garantisce inoltre che la valutazione, la risoluzione e la comunicazione siano coordinate, coerenti e responsabili in tutti i team.
Importante
La comunicazione chiara e coerente mantiene il controllo e la chiarezza in situazioni di stress elevato. Definire esattamente chi parla, cosa viene condiviso e con quale frequenza. Standardizzare la cadenza di aggiornamento, i canali e i formati dei messaggi in modo che nessuno si sbatta per informazioni durante la crisi. Assicurarsi che ogni stakeholder, dagli ingegneri ai dirigenti, sappia quando aspettarsi gli aggiornamenti e quando è necessario un intervento.
Agire immediatamente quando gli avvisi o gli utenti segnalano un problema. Usare gli strumenti di osservabilità e prestazioni per correlare le anomalie con le modifiche del sistema. Il destinatario dell'incidente configura un team di valutazione (bridge) con i membri appropriati e concorda la modalità di comunicazione, il monitoraggio dell'avanzamento e l'accesso agli asset dell'incidente.
Mobilizzare il ponte di progettazione per valutare l'impatto e la gravità. Valutare l'impatto dell'evento imprevisto usando le classificazioni di gravità predefinite. Usare i dati per giustificare i criteri descritti nel piano di risposta agli eventi imprevisti, ad esempio il numero di utenti interessati, le funzioni aziendali interrotte, le implicazioni di sicurezza e conformità e il potenziale impatto sulla fiducia e sulla reputazione dei clienti. Questa valutazione determina il livello di risposta appropriato e guida i passaggi successivi per la mitigazione.
La fase di indagine inizia quando i team di progettazione corretti sono coinvolti e avviano un RCA. Questo processo comporta un'analisi tecnica approfondita per individuare la causa e contenere l'impatto. I tecnici usano dati di osservabilità, dashboard di telemetria, log di sistema e cronologie delle modifiche per tracciare le anomalie e identificare i punti di errore. Si concentrano sull'isolamento rapido del problema, sulla convalida delle ipotesi usando i dati in tempo reale e sullo sviluppo di un piano di mitigazione preciso che ripristina la stabilità del servizio senza introdurre nuovi rischi.
Compromesso: Un RCA può richiedere molto tempo. Per correlare i problemi di prestazioni, è necessario raccogliere e archiviare i dati. Il tempo necessario e l'infrastruttura possono aggiungere lavoro aggiuntivo ai team operativi e i costi per il carico di lavoro.
Rischio: Se si esegue un RCA senza protezioni di sicurezza appropriate, è possibile esporre informazioni riservate quando si fornisce l'accesso a log e dati.Seguire le strategie di contenimento per isolare i componenti interessati e limitare il raggio dell'esplosione. È possibile eseguire le azioni seguenti:
Limitare l'accesso ai componenti interessati utilizzando percorsi separati per il triage. Ad esempio, è possibile arrestare una risorsa, limitare il traffico o disabilitare un microservizio con errori.
Limitare la copertura dell'evento imprevisto a utenti, aree o componenti specifici.
Se possibile, mantenere operativa la funzionalità del carico di lavoro in uno stato degradato.
Selezionare una strategia di mitigazione appropriata. Scegliere gli approcci di mitigazione in base allo stato corrente del carico di lavoro, alle risorse disponibili e ai vincoli immediati.
La scelta dipende da fattori come il tipo di infrastruttura, i meccanismi di bypass disponibili, la complessità della correzione, i requisiti di riservatezza e conformità dei dati, le dipendenze di sistema e gli obiettivi del tempo di ripristino (RTO).
Ripristino: Ripristinare i sistemi aggiornati all'ultimo stato di configurazione noto come funzionante. Il team del carico di lavoro deve definire l'ultimo significato valido noto. In genere si riferisce all'ultimo stato integro del carico di lavoro prima dell'inizio della distribuzione, che potrebbe non essere la versione immediatamente precedente dell'applicazione. Il rollback può essere complesso, soprattutto quando sono coinvolte modifiche allo schema o ai dati. Per ridurre i rischi, aggiungere gli aggiornamenti dello schema anziché sostituire i record. I dati vecchi e nuovi possono coesistere fino a quando non è possibile rimuovere in modo sicuro i record deprecati. I rollback potrebbero richiedere un'attenta pianificazione e coordinamento tra più team.
Fallback: Rimuovere i sistemi aggiornati dal routing del traffico di produzione e indirizzare tutto il traffico allo stack stabile. Questa strategia a basso rischio risolve i problemi di distribuzione senza causare ulteriori interruzioni. Il fallback nelle distribuzioni canary può essere complicato a seconda dell'infrastruttura e della progettazione di applicazioni. Assicurarsi una capacità adeguata nello stack stabile prima di tornare al traffico. Il fallback supporta l'operazione continua e isola la distribuzione problematica.
Ignorare la funzione che causa l'errore: Usare flag di funzionalità o proprietà di configurazione di runtime per ignorare la funzionalità problematica. Questo approccio consente all'implementazione di continuare e isolare il problema. Valutare i compromessi e comunicarli agli stakeholder. Includere per quanto tempo è possibile tollerare uno stato danneggiato e il tempo stimato per risolvere completamente il problema. Ottenere l'approvazione degli stakeholder per il piano.
Distribuzione di emergenza (correzione rapida): Distribuire una correzione rapida durante l'implementazione per risolvere rapidamente il problema. Seguire le procedure di distribuzione sicure, inclusa l'innalzamento di codice tramite ambienti e controlli di controllo qualità, ma accelerare le tempistiche. Ridurre o ottimizzare i tempi di prova e i test per velocizzare la distribuzione. Usare test automatizzati per garantire l'affidabilità. Le correzioni a caldo richiedono coordinamento e pianificazione attenta per ridurre al minimo i rischi e risolvere tempestivamente il problema.
Importante
Assicurarsi che le decisioni di mitigazione seguano le regole di autorizzazione predefinite. Il Responsabile degli incidenti dovrebbe gestire tutte le azioni di mitigazione. Richiedere al personale autorizzato di approvare i passaggi ad alto impatto e documentare ogni azione. Mantenere le azioni controllate, sicure e responsabili durante il ripristino del sistema.
Applicare la risoluzione. Questo passaggio è incentrato sul ripristino dello stato operativo completo del sistema, impedendo al tempo stesso la ricorrenza. I team di progettazione applicano correzioni verificate che seguono procedure di script specifiche del team. Usano strumenti di analisi e monitoraggio dei log per guidare l'analisi. I passaggi di rollback annullano modifiche inefficaci per garantire che ogni azione favorisce costantemente il ripristino completo del sistema.
Generare un report RCA. Dopo aver risolto un evento imprevisto, generare il report RCA entro l'intervallo di tempo del contratto di servizio. Il proprietario dell'incidente, o un membro del team strettamente coinvolto, se il proprietario non è disponibile, deve creare il report per garantire l'accuratezza. Seguire un modello RCA definito con linee guida chiare sulle informazioni da includere e condividere oppure creare e approvare un nuovo modello tramite la revisione degli stakeholder.
Attività post-evento imprevisto
Eseguire analisi retrospettive dopo ogni evento imprevisto. Forniscono opportunità di apprendimento critiche, evidenziano i punti deboli in risposta, distribuzione o infrastruttura e informano i miglioramenti. Documentare gli elementi dell'azione e tenerli traccia in un backlog per l'implementazione iterativa.
L'obiettivo non è assegnare la colpa, ma identificare i miglioramenti interattivi. Un facilitatore imparziale dovrebbe condurre questo processo. Le persone che hanno lavorato alla risposta devono rappresentare ogni team coinvolto nell'incidente. Essi devono venire preparati con osservazioni sui successi e le aree per il miglioramento:
Miglioramenti del piano di risposta: Aggiornare processi o procedure per garantire azioni più chiare ed efficaci.
Miglioramenti dell'osservabilità: Modificare le soglie, aggiungere il monitoraggio o implementare avvisi per rilevare eventi imprevisti simili in precedenza.
Correzione del carico di lavoro: Risolvere le vulnerabilità esposte durante l'evento imprevisto per correzioni permanenti.
Esempio: Risposta all'errore di distribuzione
Nell'esempio seguente viene descritto un evento imprevisto correlato alla distribuzione. Anche con un'attenta pianificazione e test, le distribuzioni possono talvolta introdurre problemi che influiscono sulle prestazioni del sistema o sull'esperienza utente.
In questo esempio, un team del carico di lavoro implementa una funzionalità di miglioramento della ricerca che include più componenti:
- Nuovo endpoint dell'API di ricerca con funzionalità di filtro avanzate
- Schema del database aggiornato
- Widget di ricerca dell'interfaccia utente riprogettata
- Nuova logica di memorizzazione nella cache
Il team esegue i passaggi seguenti per rilevare, attenuare e risolvere l'evento imprevisto:
Scoperta: Il team rileva un problema quando i tassi di errore aumentano in uno dei gruppi di implementazione canary. Il team usa immediatamente gli strumenti di osservabilità, ad esempio il monitoraggio delle prestazioni delle applicazioni (APM), la registrazione e la telemetria che collega gli utenti alle fasi di implementazione, per individuare il gruppo interessato.
Il team ha preparato questo scenario creando una forte osservabilità nel processo di distribuzione. Sono stati eseguiti test di fumo e controlli di qualità in ogni fase di implementazione e hanno instrumentato l'applicazione con metriche di registrazione, traccia e prestazioni. I dati di telemetria consentono di collegare gli utenti a specifici gruppi di implementazione, in modo da poter identificare rapidamente la versione interessata dagli utenti. Hanno anche pianificato implementazioni durante l'orario di lavoro quando era disponibile il supporto completo e hanno assicurato che il personale di supporto sapeva come scalare i problemi in base al piano di risposta alle emergenze. Questa preparazione consente loro di rilevare rapidamente il picco delle percentuali di errore e rispondere senza ritardo.
Mitigazione: Il team decide rapidamente una strategia di mitigazione. Considerano se eseguire il rollback all'ultima versione nota valida, eseguire il fallback all'ambiente stabile, ignorare la funzione problematica utilizzando un flag delle funzionalità o distribuire un hotfix. L'albero delle decisioni e il processo di approvazione sono già definiti.
Dopo che il team esamina tutte le strategie disponibili, restringe la scelta al rollback o al fallback e infine decide di optare per il fallback. Determinano che il reindirizzamento del traffico allo stack stabile è più veloce e presenta un rischio inferiore rispetto a un rollback completo, che potrebbe richiedere operazioni complesse su dati e schema. Il team conferma che lo stack stabile ha capacità sufficiente per gestire il carico di produzione completo e può isolare i sistemi aggiornati dal routing del traffico di produzione.
Il team ha raggruppato più modifiche interdipendenti, tra cui l'API, lo schema del database, i componenti dell'interfaccia utente e la logica di memorizzazione nella cache, in modo da identificare il componente specifico che ha causato gli errori è più complesso e dispendioso in termini di tempo rispetto a se fossero state distribuite separatamente ogni modifica.
Risoluzione: Il team implementa la procedura di fallback. Spostano il traffico dall'ambiente aggiornato per isolare l'implementazione problematica. Il team può risolvere il problema sottostante senza influire sulla maggior parte degli utenti.
L'implementazione del fallback rivela lacune operative. Trovano informazioni di contatto obsolete per due membri chiave del team, e un ingegnere nella gerarchia di escalation ha lasciato l'azienda mesi fa. Il team perde tempo per capire l'individuo responsabile. Quando tentano di rimuovere la distribuzione aggiornata dal servizio di bilanciamento del carico, la documentazione fa riferimento a una configurazione del servizio di bilanciamento del carico obsoleta modificata in un aggiornamento recente di Azure. Devono trovare la procedura corretta sotto pressione temporale.
La comunicazione è una parte fondamentale del piano di mitigazione. Il team informa gli stakeholder della decisione e delle relative implicazioni, inclusa la sequenza temporale prevista per risolvere il problema nell'ambiente isolato. Il team ha già standardizzato la cadenza per fornire aggiornamenti dello stato durante gli eventi imprevisti della distribuzione, in modo che gli stakeholder sappiano quando aspettarsi report e aggiornamenti sullo stato. Il team ha anche definito il tipo e il livello di dettaglio da condividere con gli utenti e garantire la conformità con altri requisiti per le comunicazioni degli eventi imprevisti di distribuzione. Questo approccio strutturato riduce al minimo la confusione e contribuisce a mantenere la fiducia nel processo di risposta.
Retrospettiva: Dopo che il team mitiga l'incidente di distribuzione, esegue una retrospettiva per acquisire lezioni apprese e migliorare i processi futuri. La sessione include tutti gli utenti coinvolti nell'implementazione, dagli sviluppatori e dagli operatori al supporto e ai rappresentanti degli stakeholder. Il team esamina la sequenza di eventi, dal rilevamento attraverso la mitigazione, per comprendere cosa è andato bene e dove esistevano gap.
Un aspetto chiave è che raggruppare le modifiche dell'API di ricerca, gli aggiornamenti dello schema del database, la riprogettazione dell'interfaccia utente e le modifiche al livello di cache ha complicato sia la risoluzione dei problemi che il ripristino.
Miglioramenti post-evento imprevisto: Dall'analisi retrospettiva, il team implementa diversi miglioramenti operativi per rendere le distribuzioni future più sicure e le mitigazioni più affidabili:
Modifiche più piccole e frequenti: Il team passa alle distribuzioni incrementali più piccole per ridurre il delta tra le versioni successive e semplificare e ridurre i rischi.
Per il miglioramento della ricerca in modo specifico, il team decide di distribuire ogni componente in modo indipendente. Ora distribuiscono le modifiche dello schema del database con modifiche inizialmente compatibili con le versioni precedenti, quindi aggiornano l'endpoint API e successivamente altre modifiche. Questo approccio consente al team di convalidare ogni livello in modo indipendente prima di aggiungere il livello successivo e isolare più facilmente i problemi a un componente specifico.
Test ed esercitazioni regolari: Il team stabilisce una pratica di test frequenti per la strategia di mitigazione dei guasti di distribuzione completa. Introducono test di progettazione del caos e di inserimento degli errori per simulare gli scenari di errore e convalidare i processi di mitigazione. Queste esercitazioni regolari avrebbero rilevato i problemi riscontrati durante l'evento imprevisto, incluse le informazioni di contatto obsolete e le procedure obsolete del runbook.
Facilitazione di Azure
Microsoft fornisce 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.
Monitoraggio di Azure è una soluzione per la raccolta, l'analisi e la risposta ai dati di monitoraggio da ambienti cloud e locali. Include una piattaforma di avvisi che è possibile configurare per le notifiche automatiche e altre azioni, ad esempio la scalabilità automatica e altri meccanismi di riparazione automatica.
Usare Monitoraggio di Azure per integrare Machine Learning. Automatizzare e ottimizzare la valutazione degli eventi imprevisti e le misure proattive. Per altre informazioni, vedere Operazioni di intelligenza artificiale e Machine Learning in Monitoraggio di Azure.
Log Analytics è uno strumento di analisi in Azure Monitor. È possibile usare Log Analytics per eseguire query su log aggregati e ottenere informazioni dettagliate sul carico di lavoro.
Application Insights è un'estensione di Monitoraggio di Azure che fornisce funzionalità APM.
Microsoft Sentinel è una soluzione SIEM (Security Information and Event Management) e orchestrazione della sicurezza, automazione e risposta (SOAR). Si tratta di una singola soluzione per il rilevamento degli avvisi, la visibilità delle minacce, la ricerca proattiva e la risposta alle minacce.
Azure Pipelines offre servizi di compilazione e rilascio per supportare l'integrazione continua e il recapito continuo (CI/CD) delle applicazioni.
Piani di test di Azure è una soluzione di gestione dei test basata su browser. Questa soluzione offre funzionalità necessarie per i test manuali pianificati, i test di accettazione degli utenti e i test esplorativi. I piani di test di Azure offrono anche un modo per raccogliere feedback dagli stakeholder.
App per la logica di Azure è una piattaforma basata sul cloud per l'esecuzione di flussi di lavoro automatizzati che integrano app, dati, servizi e sistemi. È possibile usare App per la logica per creare una nuova versione dell'applicazione quando ottiene un aggiornamento. Azure gestisce una cronologia delle versioni e può ripristinare o alzare di livello qualsiasi versione precedente.
Molti servizi di database di Azure offrono funzionalità di ripristino a un punto nel tempo che possono aiutarti a eseguire un rollback:
Azure Chaos Studio è un servizio gestito che usa l'ingegneria chaos per aiutare a misurare, comprendere e migliorare la resilienza dell'applicazione cloud e del servizio.