Prima di riavviare, sai cosa ha causato l'errore?

Quando una pipeline CDC si blocca, la pressione è quella di riavviare la replica il prima possibile. Ma prima di scegliere un percorso di ripristino, il team deve capire cosa è cambiato durante il periodo di inattività della pipeline.

La sorgente potrebbe aver continuato l'elaborazione. La destinazione potrebbe essere sempre più obsoleta. Le applicazioni a valle potrebbero aver continuato a funzionare, essersi arrestate completamente o aver intrapreso azioni compensative. La cronologia della sorgente necessaria potrebbe essere ancora disponibile oppure il normale percorso di ripristino potrebbe essere già in fase di modifica.

La domanda non è solo: come ripartiamo?

La domanda è: quali conseguenze ha avuto questo guasto e cosa significa per la ripresa?

Le linee guida di continuità della FEMA descrivono l'analisi dei processi aziendali come la mappatura dei flussi di lavoro, delle attività, delle competenze del personale, dei sistemi, dei dati e delle strutture necessari per svolgere una funzione essenziale. Lo stesso approccio basato sulle dipendenze è utile quando si valuta la portata a valle di un'interruzione del CDC.*

Una valutazione dell'impatto degli incidenti condotta dal CDC aiuta a stabilire:

• Il periodo e lo stato di elaborazione interessati
• I dati che non hanno raggiunto l'obiettivo
• I sistemi a valle e i processi aziendali esposti
• Le condizioni che limitano le opzioni di recupero disponibili
• Le questioni aperte che devono essere risolte o gestite esplicitamente

L'obiettivo non è ritardare la guarigione, bensì evitare di scegliere un percorso di recupero basato su un quadro incompleto.

Cosa devo fare immediatamente dopo l'interruzione di un processo di replica CDC?

Prima di decidere come procedere al ripristino, è necessario determinare cosa è stato colpito. Una valutazione dell'impatto dell'incidente condotta dal CDC aiuta a stabilire la finestra temporale per il ripristino, i dati e i consumatori a valle esposti, l'entità e la rilevanza della conseguente lacuna di dati, le condizioni che limitano i percorsi di ripristino disponibili e le questioni o i rischi che devono essere risolti prima di poter procedere.

Solo allora il team potrà scegliere un percorso di recupero basato su dati concreti anziché su supposizioni.

Risposta rapida: Cosa dovrebbe includere una valutazione dell'impatto di un incidente condotta dal CDC?

Una valutazione pratica dell'impatto di un incidente da parte del CDC dovrebbe rispondere a cinque domande:

1. Qual è il periodo di recupero interessato?
2. Quali dati e consumatori finali sono stati esposti?
3. Quanto è ampio e significativo il divario di dati risultante?
4. Quali condizioni limitano i percorsi di recupero disponibili?
5. Quali interrogativi o rischi irrisolti devono essere affrontati o gestiti prima di procedere con la ripresa?

Le sezioni che seguono descrivono il processo utilizzato per rispondere a queste domande. L'obiettivo non è compilare una lista di attività, bensì raccogliere prove sufficienti per scegliere un percorso di recupero appropriato e stabilire i parametri di riferimento per la validazione post-recupero.

La profondità della valutazione dovrebbe rispecchiare la portata e il rischio dell'incidente. Un'interruzione circoscritta potrebbe richiedere solo una breve analisi, mentre un'interruzione complessa che coinvolga dati critici, interventi manuali o una significativa esposizione a valle richiederà un'indagine più approfondita.

Definire la finestra temporale dell'incidente

Una volta stabilito l'ultimo punto di elaborazione affidabile, definire il periodo che la valutazione deve coprire. La finestra temporale dell'incidente si estende in genere dall'ultimo punto di elaborazione affidabile noto, attraverso l'interruzione, fino allo stato target o di ripristino attuale. A seconda dell'incidente, la finestra temporale può includere:

• Il periodo precedente al rilevamento del problema
• Il momento in cui la replica è stata interrotta o degradata
• Attività della sorgente continua durante l'interruzione
• Elaborazione parziale o tentativi successivi
• Modifiche o interventi sul lato bersaglio
• Attività di riavvio iniziale o di recupero

Non dare per scontato che il momento in cui qualcuno si accorge del guasto coincida con il momento in cui il guasto ha avuto inizio.

Chiedere:

• Quando è stata l'ultima volta che la replica ha funzionato come previsto?
• Quando ha iniziato a rallentare, a presentare problemi o a bloccarsi l'elaborazione?
• Quando è stato rilevato il problema?
• La fonte ha continuato a elaborare le transazioni?
• La cattura, il trasporto o l'applicazione del bersaglio sono proseguiti parzialmente?
• Qualcuno ha provato a riavviare il computer o a modificare la configurazione?
• Il soggetto bersaglio ha ricevuto aggiornamenti diretti o compensativi?
• Quale punto rappresenta lo stato attuale che si sta valutando?

Perché è importante

Un'interruzione di cinque minuti rilevata immediatamente è diversa da un'interruzione di cinque minuti scoperta ore dopo, quando i sistemi a valle hanno continuato a utilizzare dati obsoleti. La finestra temporale dell'incidente stabilisce cosa il team deve indagare. Diventa inoltre il punto di riferimento per la scelta di un percorso di ripristino e per la successiva convalida dei dati.

Mappare i dati interessati

Non tutte le tabelle, i file, i dataset o i domini di dati all'interno di un flusso di replica comportano lo stesso rischio. Inizia identificando cosa era incluso nell'ambito quando la replica ha subito un rallentamento o un arresto. Quindi determina cosa è effettivamente cambiato durante il periodo in cui si è verificato l'incidente. Per ogni oggetto o dominio di dati interessato, considera:

Cambiare attività

• Si sono verificati inserimenti, aggiornamenti o cancellazioni?
• Quanta attività di cambiamento si è accumulata?
• Sono state apportate modifiche allo schema supportate?
• Gli stessi record sono stati modificati più volte?
• Si trattava di transazioni di alto valore o di importanza strategica per l'azienda?

importanza commerciale

• I dati sono utili per la reportistica, la liquidazione, la gestione dei reclami, i pagamenti, l'inventario, il servizio clienti, l'individuazione delle frodi o altri processi critici?
• I dati sono soggetti a requisiti di governance, audit o regolamentazione?
• Quanto deve essere aggiornato il dispositivo di destinazione per l'utilizzo a valle?

Relazioni tra dati

• È necessario che più tabelle o file rimangano sincronizzati?
• È rilevante una relazione di tipo header-detail, padre-figlio o di altro tipo?
• Il recupero parziale dei dati interessati creerebbe uno stato incoerente?

Attività sul lato bersaglio

• Qualche processo ha scritto direttamente sul target?
• I record sono stati corretti manualmente?
• I dati sono stati caricati da un'altra fonte?
• Il team a valle ha tentato una soluzione alternativa?

Laddove gli oggetti correlati devono rimanere coerenti, raggrupparli in base a tali dipendenze. Il ripristino e la convalida dovrebbero riflettere le relazioni rilevanti per l'applicazione o il processo aziendale, non semplicemente l'ordine alfabetico o il conteggio delle righe.

La domanda pratica da porsi in ogni situazione è: "Quali dati sono più importanti in questo incidente e quali relazioni devono essere preservate durante la fase di ripristino?"

Applicare la stessa risposta a tutte le tabelle può comportare una perdita di tempo su dati a basso rischio, trascurando al contempo un piccolo numero di dipendenze critiche.

Valutare l'esposizione a valle

Un errore del CDC non influisce solo sul processo di replica. Se la sorgente continua a funzionare, le applicazioni a valle potrebbero rimanere disponibili, anche se i loro dati diventano sempre più obsoleti. Altri consumatori potrebbero arrestarsi completamente. Alcuni potrebbero continuare a elaborare informazioni parziali o incoerenti. Per ogni consumatore a valle, documentare:

Cosa ha sperimentato il consumatore

• L'applicazione ha smesso di ricevere dati?
• Ha continuato a funzionare con dati obsoleti?
• Ha ricevuto solo una parte delle informazioni previste?
• Gli utenti hanno rilevato un errore, oppure il problema è rimasto nascosto?
• Un evento o un aggiornamento previsto non si è verificato?

Se si sono verificate azioni compensative. Durante un'interruzione prolungata, i team possono:

• Applicare manualmente le patch ai dati di destinazione
• Carica i dati da un backup o da una fonte alternativa
• Interrogare temporaneamente il sistema di registrazione
• Metti in pausa un processo aziendale
• Rielabora le transazioni al di fuori del normale flusso di lavoro
• Annullare una decisione automatizzata

Queste azioni sono importanti perché possono alterare il target o creare conflitti con le modifiche apportate in seguito tramite replica.

Cosa può innescare la riproduzione o il recupero

Alcuni sistemi a valle possono accettare modifiche ritardate senza effetti collaterali. Altri avviano la logica di business al verificarsi di un evento.

A seconda dell'applicazione, la riproduzione delle modifiche accumulate potrebbe attivare:

• Notifiche
• Pagamenti
• Adeguamenti di inventario
• Transizioni del flusso di lavoro
• Richieste di servizio
• Integrazioni a valle
• Azioni duplicate

In molti contesti, si tratta fondamentalmente di una questione di idempotenza: il consumatore può elaborare in modo sicuro un evento riprodotto senza creare conseguenze aziendali indesiderate?

Perché è importante

Una pipeline tecnicamente recuperabile può comunque creare un problema aziendale più ampio. La sorgente potrebbe essere integra. La destinazione potrebbe essere disponibile. Ma gli utenti a valle potrebbero prendere decisioni basandosi su dati obsoleti o incompleti e le attività di ripristino potrebbero innescare conseguenze al di fuori della piattaforma di replica.

Quantificare il divario di dati

Una volta compresi l'intervallo temporale dell'incidente e l'ambito interessato, descrivere la lacuna in termini utili sia per gli interlocutori tecnici che per quelli aziendali.

Le misure tecniche possono includere:

• Tempo trascorso dall'ultimo punto di elaborazione attendibile
• Ritardo di replica attuale
• Modifiche o transazioni in sospeso
• Inserimenti, aggiornamenti ed eliminazioni generati durante l'intervallo
• Posizione della sorgente rispetto alla posizione di elaborazione corrente
• Elaborazione o throughput di applicazione target
• Capacità di recupero disponibile
• Disponibilità di informazioni storiche pertinenti
• Tempo di recupero stimato in base alle prestazioni osservate

Evitate di considerare il tempo di ripristino stimato come una garanzia. Le prestazioni effettive di recupero possono variare in base all'attività della sorgente, alla capacità della rete, alla pressione sui dispositivi target, alla contesa dell'infrastruttura, al volume delle modifiche e ai carichi di lavoro concorrenti.

Le misure aziendali possono includere:

• Transazioni non ancora visibili a un sistema a valle
• Report o dashboard basati su informazioni obsolete
• Processi aziendali ritardati o sospesi
• Decisioni o azioni intraprese utilizzando dati obsoleti
• Scadenze dei clienti o normative in avvicinamento
• Interventi manuali eseguiti durante l'intervallo
• Consumatori che necessitano di un trattamento speciale durante la riproduzione
• rischio finanziario, operativo, di servizio o di conformità

I dati tecnici grezzi aiutano il team operativo a definire l'ambito del ripristino. Le misurazioni dell'impatto aziendale aiutano le parti interessate a comprendere perché l'incidente è rilevante e come dovrebbe essere data priorità al ripristino.

Perché è importante

Un arretrato di 100.000 modifiche può essere considerato di routine in un ambiente e di importanza cruciale per il business in un altro. La dimensione del divario è importante, così come il suo contenuto e chi ne dipende.

Conferma da cosa dipende il recupero

È possibile che si verifichi un divario misurabile, mentre il percorso di ripristino appropriato rimane incerto. Prima di scegliere tra un riavvio, un recupero, una risincronizzazione mirata o un ricaricamento più ampio, è necessario documentare le condizioni che influenzano le opzioni ancora disponibili.

Disponibilità della cronologia della sorgente: determinare da quali informazioni di origine dipende il percorso di ripristino supportato. Tali informazioni potrebbero includere:

• Registri delle transazioni attive
• Registri archiviati
• Riviste
• Cronologia delle modifiche conservata
• Riavvia o elabora lo stato
• posizioni di registro specifiche della sorgente
• Informazioni di ripristino gestite dalla piattaforma

Se la cronologia di origine richiesta non è più immediatamente disponibile, verificare se i log archiviati o altra cronologia conservata possono essere recuperati ed elaborati tramite un percorso di ripristino supportato. Se la cronologia necessaria non è disponibile, le opzioni di ripristino potrebbero risultare più limitate.

Non dare per scontato che la presenza di log archiviati implichi automaticamente il supporto di un particolare percorso di ripristino. Verifica come la piattaforma utilizza tale cronologia per la specifica origine, destinazione e configurazione.

Stato bersaglio

Determinare se l'obiettivo rimane in condizioni tali da consentire la ripresa futura.

Chiedere:

• L'obiettivo era ancora disponibile?
• Sono state effettuate scritture dirette?
• I record sono stati corretti manualmente?
• Le strutture o gli schemi di destinazione sono cambiati?
• Qualche processo ha ricaricato o risincronizzato parzialmente i dati?
• È possibile proteggere il target da ulteriori modifiche durante la fase di ripristino, se necessario?

Comportamento di riproduzione del consumatore: per i consumatori che avviano un'azione all'arrivo dei dati, determinare se gli eventi ritardati o ripetuti possono essere elaborati in modo sicuro.

Chiedere:

• Il consumatore è in grado di riconoscere gli eventi già elaborati?
• La riproduzione potrebbe innescare azioni duplicate?
• Sono disponibili gli identificativi di transazione o le chiavi aziendali?
• È possibile sopprimere temporaneamente notifiche, pagamenti o flussi di lavoro?
• Il team di tutela dei consumatori deve coordinare la ripresa?

Obiettivi di recupero: Confrontare il tempo di recupero o di ripristino stimato con gli obiettivi stabiliti per i sistemi interessati.

Chiedere:

• Per quanto tempo gli utenti a valle possono tollerare dati obsoleti?
• Si avvicina una scadenza aziendale, di rendicontazione, di liquidazione o un impegno con un cliente?
• Il recupero stimato rientra nel periodo di ripresa previsto?
• In caso contrario, quale azione alternativa o decisione delle parti interessate è necessaria?
• Se non esiste un obiettivo di ripristino formale, documentare la tolleranza aziendale per l'incidente in corso anziché inventare una soglia generica.

Perché è importante

Conoscere l'entità del divario non indica al team come recuperare. Il team deve anche comprendere cosa richiede il percorso di recupero supportato, se tali condizioni sussistono ancora e quali rischi il recupero stesso potrebbe comportare.

Documentare le questioni aperte e i vincoli decisionali

Una valutazione d'impatto dovrebbe rendere visibile l'incertezza, non nasconderla. Documentare domande come:

• La posizione di riavvio è affidabile?
• È disponibile tutta la cronologia delle fonti richiesta?
• Il target ha ricevuto scritture dirette?
• Ci sono patch manuali in conflitto con le modifiche al codice sorgente?
• È possibile riprodurre in modo sicuro gli eventi accumulati?
• Quali dati richiedono una validazione più approfondita?
• Quali team a valle devono approvare la ripresa?
• Sono ammissibili delle eccezioni per un recupero controllato?

Le questioni aperte devono essere assegnate e valutate in base al rischio che comportano. Alcune potrebbero impedire il ripristino. Altre possono essere gestite come eccezioni esplicite con responsabili, controlli e azioni di follow-up definiti.

L'obiettivo non è creare una certezza artificiale, bensì garantire che la decisione di recupero rifletta ciò che è noto, ciò che è ancora sconosciuto e le ipotesi su cui si basa il team.

Redigere il riepilogo dell'impatto dell'incidente per il CDC.

La valutazione dovrebbe concludersi con un riassunto scritto conciso che costituisca l'elemento di base per la decisione di recupero e il punto di riferimento per la validazione post-recupero. Includere:

Finestra degli incidenti

• Ultimo punto di elaborazione noto e affidabile
• Inizio dell'incidente confermato o stimato
• Tempo in cui è stato rilevato il problema
• confine di valutazione attuale
• Periodo totale trascorso

Dati interessati

• Fonti e obiettivi coinvolti
• Tabelle, file, set di dati o domini di dati interessati
• Modificare il volume durante l'intervallo
• Dipendenze rilevanti
• Qualsiasi scrittura diretta sul target o modifiche manuali

Esposizione a valle

• Applicazioni, report, API, analisi o processi interessati
• Se i consumatori hanno interrotto l'attività, hanno continuato a utilizzare dati obsoleti o hanno ricevuto informazioni parziali
• Eventuali azioni compensative intraprese
• Rischi di ripetizione o recupero

Valutazione delle lacune nei dati

• Ritardo o arretrato attuale
• Sforzo stimato per il recupero
• Transazioni o eventi aziendali non ancora riflessi a valle
• Scadenze aziendali o conseguenze operative

vincoli di recupero

• disponibilità della storia della fonte
• Riavvio o disponibilità dello stato del processo
• Condizione obiettivo
• Considerazioni sulla riproduzione da parte del consumatore
• Periodo di recupero previsto
• Limitazioni della piattaforma o della configurazione

Domande aperte

• Cosa resta ancora sconosciuto?
• Quali domande influiscono sulla decisione relativa al recupero?
• A chi appartiene ciascuna domanda?
• Quali domande ostacolano la guarigione?
• Quali possono essere gestite come eccezioni documentate?

Decisione successiva consigliata

La valutazione d'impatto non dovrebbe prescrivere automaticamente uno specifico percorso di recupero. Dovrebbe fornire informazioni sufficienti al team per determinare se:

• Riprendi dallo stato salvato
• Processo mantenuto modifiche storiche
• Proseguire il recupero monitorato
• Confronta i dati di origine e di destinazione
• Risincronizza i dati selezionati
• Eseguire una risincronizzazione più ampia o un ricaricamento
• Rimandare l'azione fino a quando non sarà risolta la questione cruciale.
• Riportare la decisione ad altri responsabili tecnici o aziendali.

Come si presenta una valutazione completata

L'esempio seguente è puramente illustrativo. I nomi, i valori, il carico di lavoro e le considerazioni relative al ripristino sono sintetici e non rappresentano una soglia, un'architettura o una procedura di ripristino raccomandate.

Ritardo dell'incidente

Pipeline: flusso di replica degli ordini al magazzino
Ultimo punto di elaborazione attendibile: Checkpoint di destinazione confermato corrispondente alle 2:14
Errore rilevato: 02:17
Valutazione completata: 4:00 del mattino
Intervallo attuale: circa 1 ora e 46 minuti

Dati interessati

Esposizione a valle

vincoli di recupero

• La cronologia delle fonti richiesta rimane disponibile.
• Il target contiene gli aggiornamenti manuali dell'inventario effettuati durante l'interruzione.
• Gli eventi in ritardo potrebbero attivare notifiche ai clienti durante la fase di recupero.
• I dati di intestazione e di dettaglio dell'ordine devono essere recuperati e convalidati insieme.
• I proprietari a valle necessitano di un piano di comunicazione e di riproduzione chiaro.

Domande aperte

• Come si dovrebbero conciliare gli aggiornamenti manuali dei target con le modifiche di origine apportate durante la fase di recupero?
• Le notifiche ai clienti inviate in ritardo devono essere pubblicate, soppresse o gestite separatamente?
• Quale confronto confermerà la coerenza tra intestazione e dettagli dell'ordine dopo il ripristino?

Conclusione della valutazione

Lo stato di riavvio disponibile e la cronologia delle origini conservata supportano un'ulteriore valutazione di un percorso di recupero. Prima di procedere con il ripristino, il team deve concordare le modalità di gestione degli aggiornamenti manuali dei target e delle notifiche ritardate.

La valutazione d'impatto non dimostra che la ripresa avrà successo. Stabilisce le condizioni che la decisione di ripresa deve affrontare.

Errori comuni nella valutazione d'impatto del CDC

Considerare lo stato della pipeline come confine dell'incidente: un processo non riuscito o degradato può segnalare uno stato operativo che non corrisponde all'ultima modifica correttamente riflessa sul target. Utilizzare le prove più affidabili disponibili relative a fonte, piattaforma e target per stabilire il confine della valutazione.

Misurare solo il tempo di inattività trascorso: il solo tempo di inattività non spiega quanto sia cambiato l'obiettivo rispetto alla sorgente, quali dati siano stati interessati o quali sistemi a valle abbiano continuato a funzionare. Misurare sia il ritardo tecnico che l'esposizione a valle.

Ipotizzando che il volume delle modifiche sia uguale al tempo di recupero: il volume delle modifiche è solo uno dei fattori. Anche la velocità di elaborazione osservata, la dimensione dei record, l'attività di origine, la latenza di destinazione, la pressione sull'infrastruttura, la complessità della trasformazione e i carichi di lavoro concorrenti influiscono sulla durata del recupero.

Fermandoci al livello tecnico: una valutazione che documenta il backlog e lo stato di avanzamento ma ignora i consumatori a valle è incompleta. Le conseguenze per il business determinano l'urgenza, la sequenza, la comunicazione e il rischio accettabile.

Ignorare le azioni compensative: patch manuali, caricamenti alternativi, soluzioni temporanee e scritture dirette sul target possono modificare i presupposti di ripristino. Documentateli prima che la replica inizi a distribuire le modifiche accumulate.

Nascondere l'incertezza: le domande senza risposta non scompaiono con l'inizio della ripresa. Documentate ciò che rimane sconosciuto, individuate quali incertezze ostacolano l'azione e gestite il resto come eccezioni esplicite.

Come la valutazione d'impatto si inserisce nel flusso di lavoro di recupero

La valutazione dell'impatto dell'incidente da parte del CDC si colloca tra la fase di rilevamento e quella di attuazione delle misure di recupero.

Supporta:

Decisione di riavvio: la valutazione stabilisce l'ambito del guasto, lo stato di elaborazione disponibile, le dipendenze dalla cronologia di origine, la condizione di destinazione e le considerazioni a valle necessarie per scegliere un percorso di ripristino supportato.

Leggi di più: L'errore più pericoloso nella ripresa del CDC si verifica dopo il fallimento

Monitoraggio del recupero: l'arretrato previsto, l'attività di origine, la tolleranza a valle e le condizioni di recupero documentate nella valutazione aiutano il team a interpretare i progressi del recupero.

Per saperne di più: Il vostro sistema di sviluppo del CDC non è fermo. Siete sicuri che sia in salute?

Validazione post-recupero: la finestra temporale dell'incidente, i dati interessati, le dipendenze e le azioni compensative identificate nella valutazione definiscono cosa deve essere validato dopo il recupero.

Per saperne di più: L'oleodotto è di nuovo in funzione. Ci si può fidare dei dati?

Comunicazione a valle: la mappa dei consumatori e il riepilogo dell'impatto chiariscono chi necessita di aggiornamenti, quali dati rimangono riservati e quali prove supporteranno il definitivo cessato allarme. La valutazione trasforma un guasto non definito in un incidente circoscritto con un ambito noto, vincoli espliciti e un percorso di ripristino più chiaro.

Utilizzare la valutazione dopo l'incidente

La valutazione d'impatto non deve essere accantonata con l'inizio della fase di recupero. Dopo che l'obiettivo è stato validato e rimesso in funzione, è opportuno rivedere la valutazione per individuare eventuali modifiche da apportare prima della successiva interruzione.

• Quali informazioni hanno richiesto troppo tempo per essere reperite?
• Quali dipendenze risultavano mancanti o documentate in modo inadeguato?
• Quali team a valle hanno appreso del problema troppo tardi?
• Quali decisioni dipendevano da un singolo specialista?
• Quali interventi manuali hanno creato un rischio di riconciliazione?
• L'ambiente di monitoraggio ha visualizzato i dati effettivi e l'impatto sul business?
• La piattaforma ha fornito informazioni sufficienti per il riavvio, la diagnostica, il recupero e la convalida?
• È necessario modificare i processi di conservazione o recupero della cronologia delle fonti?
• Quali soglie, manuali operativi, assegnazioni di responsabilità o procedure di comunicazione dovrebbero essere aggiornati?
• Lo stesso guasto potrebbe generare di nuovo la stessa incertezza?

Un singolo episodio può rivelare una lacuna nel processo. Episodi ripetuti possono indicare un problema più ampio relativo al monitoraggio, al modello operativo, alla formazione o alle funzionalità della piattaforma.

L'obiettivo non è solo riprendersi da questa interruzione. È rendere la risposta successiva più rapida, più chiara e più facile da difendere.

Lista di controllo per la valutazione dell'impatto degli incidenti del CDC

Prima di scegliere un percorso di recupero, accertatevi che il team abbia stabilito:

• L'ultimo punto di elaborazione affidabile conosciuto
• La finestra degli incidenti
• Le fonti e gli obiettivi interessati
• I dati sono cambiati durante l'intervallo
• Relazioni e dipendenze importanti
• Sistemi e processi aziendali a valle esposti
• Se sono stati utilizzati dati obsoleti o parziali
• Azioni manuali o compensative intraprese
• Ritardo e arretrati attuali
• Disponibilità della cronologia delle fonti richiesta
• Modifiche o vincoli sul lato bersaglio
• Rischi di ripetizione o duplicazione delle azioni da parte del consumatore
• Recupero previsto e necessità di recupero
• Domande aperte e responsabili assegnati
• Domande che ostacolano la guarigione
• Gestione esplicita delle eccezioni
• La prova che la convalida post-recupero richiederà

La valutazione è pronta per fornire informazioni utili alla decisione di recupero quando il team sarà in grado di spiegare cosa è successo, cosa è stato colpito, da cosa dipende il recupero, cosa rimane incerto e cosa deve essere verificato prima di procedere con l'azione.

In definitiva

Un fallimento del CDC non è definito solo dalla durata dell'indisponibilità della replica. È definito da cosa è cambiato durante l'interruzione, chi è stato colpito, quali opzioni di ripristino rimangono disponibili e quali rischi il ripristino stesso potrebbe comportare.

La questione cruciale non è semplicemente: come facciamo a far ripartire la replicazione?

La domanda è: comprendiamo a sufficienza l'impatto per poter scegliere il percorso di ripresa più adatto?

Una buona valutazione d'impatto fornisce al team una comprensione condivisa di:

• Dove inizia l'incidente
• Cosa ha influito l'incidente
• Quali condizioni limitano il recupero?
• Quali domande restano irrisolte?
• Quali prove saranno necessarie in seguito?

Questa è la differenza tra ripartire basandosi su supposizioni e riprendersi da un problema che il team comprende effettivamente.

FEMA: Analisi dei processi aziendali e analisi dell'impatto aziendale