La pipeline è di nuovo in funzione. Ci si può fidare dei dati?

Dopo un errore o un'interruzione della replica, un riavvio riuscito dimostra solo una cosa: la replica è di nuovo in esecuzione. Non dimostra che tutte le modifiche siano state recapitate. Non dimostra che le eliminazioni siano state elaborate. Non dimostra che i valori siano aggiornati. E non dimostra che i team a valle possano fidarsi dei dati.

Ecco perché la convalida post-recupero è importante.

Le linee guida del NIST sull'integrità dei dati considerano il ripristino come qualcosa di più del semplice recupero della disponibilità. Sottolineano l'importanza del rilevamento e della risposta tempestivi alle perdite di integrità e il ruolo della preparazione, della registrazione e degli strumenti appropriati per ridurre al minimo i tempi di inattività e le perdite in caso di danneggiamento o modifica dei dati.

Prima di dichiarare completato il recupero, i team hanno bisogno di prove sufficienti per rispondere a una semplice domanda: su cosa ci basiamo quando diciamo alle persone che i dati sono di nuovo sicuri da utilizzare?

Risposta rapida: Come si convalidano i dati dopo il ripristino del CDC?

La validazione deve rispondere a due domande diverse ma ugualmente importanti

• La replica è stata ripristinata correttamente?
  Questa è la questione operativa. Il processo è stato riavviato. Il ritardo è tornato ai livelli previsti. L'arretrato è stato smaltito.
• I dati recuperati sono affidabili?
  Si tratta di una questione relativa all'integrità dei dati. Il risultato finale riflette le modifiche previste. Sono presenti record importanti. Le eliminazioni sono state elaborate. Non rimangono discrepanze inspiegabili.

Un processo efficace contribuisce a stabilire che il recupero è avvenuto. La validazione contribuisce a stabilire che il recupero ha prodotto dati affidabili. Un processo di validazione post-recupero pratico si articola in cinque fasi:

• Definire la finestra di ripristino.
• Identificare i dati e i sistemi a valle che sono stati esposti.
• Utilizzare le prove disponibili dalla fonte, dalla piattaforma di replica e dal target.
• Verifica nello specifico le modalità di guasto rilevanti.
• Documentare ciò che è stato convalidato, ciò che è stato riscontrato e ciò che rimane incerto.

Non fare affidamento su un solo segnale.

Un processo in esecuzione indica che la replica è attiva. Il conteggio delle righe fornisce informazioni sul set di dati risultante. Un confronto tra origine e destinazione identifica le differenze entro l'ambito supportato. I log e la diagnostica della piattaforma indicano cosa è successo a livello operativo. I controlli a livello aziendale indicano se il risultato a valle è coerente.

Nel loro insieme, questi segnali possono supportare una conclusione difendibile. Analizziamoli nel dettaglio.

La convalida è un processo in cinque fasi

Le sezioni seguenti approfondiscono questi cinque ambiti. Alcuni passaggi richiedono verifiche multiple. Ad esempio, il confronto tra dati di origine e di destinazione può comportare la convalida dei conteggi, l'identificazione di modifiche mancanti, la verifica della presenza di duplicati, la conferma delle eliminazioni e l'analisi di valori obsoleti.

L'obiettivo non è completare tredici compiti scollegati tra loro, bensì raccogliere prove sufficienti per rispondere a un'unica domanda: possiamo fidarci dei dati recuperati?

Definire la finestra di recupero

Prima di effettuare qualsiasi confronto, è necessario stabilire quale periodo si intende effettivamente analizzare. Si deve partire dall'ultimo punto precedente all'incidente in cui la replica funzionava come previsto. Successivamente, si deve identificare il momento in cui il ripristino e il recupero hanno raggiunto il punto oggetto di valutazione.

Questo ti offre una finestra di recupero: dall'ultimo stato noto e funzionante → attraverso l'interruzione → attraverso il recupero → allo stato di cui ora vuoi fidarti. A seconda della fonte e della piattaforma, i riferimenti utili possono includere:

• timestamp
• riavvio o stato del processo
• posti di controllo
• segnalibri
• posizioni del registro sorgente
• coordinate di ripristino specifiche della piattaforma

Negli ambienti Db2 per z/OS, i team possono anche utilizzare concetti specifici della sorgente, come RBA o LRSN, ove appropriato. La terminologia esatta varia. L'importante è che tutti coloro che valutano il ripristino facciano riferimento allo stesso periodo e allo stesso limite logico.

Come le posizioni dei log di origine, incluso Db2 per z/OS RBA/LRSN, possono contribuire a definire la convalida post-ripristino

Le posizioni dei log di origine possono aiutare i team a identificare il periodo di elaborazione che stanno cercando di valutare. Negli ambienti Db2 per z/OS, RBA o LRSN possono essere rilevanti per comprendere la posizione del log di origine, a seconda della configurazione e dell'ambiente.

Queste coordinate possono essere utili per orientare l'indagine. Non devono però essere considerate una prova universale del completamento dell'obiettivo. Il team deve comunque collegare lo stato sorgente pertinente, le prove provenienti dalla piattaforma di replica e lo stato target risultante.

Chiedere:

Quando è iniziato effettivamente il problema?

Qual è stato l'ultimo Stato di cui ci siamo fidati?

Quando è iniziato il recupero?

Quando l'obiettivo è tornato allo stato che stiamo valutando ora?

Quali transazioni, set di dati, tabelle, file o processi a valle rientrano in tale intervallo?

Perché è importante

Se la finestra di validazione è vaga, anche la conclusione sarà vaga, quindi non si può rispondere con sicurezza alla domanda: "Ci siamo persi qualcosa?" finché non si concorda su: "Tra quali due punti?"

Identificare cosa è stato effettivamente esposto

Non convalidare automaticamente tutto con lo stesso livello di impegno. Prima di tutto, cerca di capire cosa è cambiato durante la finestra di ripristino e quali sistemi a valle si basavano su quei dati.

Chiedere:

• Quali fonti e obiettivi sono stati colpiti?
• Quali tabelle, file, set di dati o domini di dati sono stati modificati durante l'intervallo di tempo considerato?
• Quali applicazioni a valle, report, analisi, API o processi operativi dipendono da essi?
• Sono stati utilizzati dati di destinazione obsoleti durante il ritardo nella replica?
• Quali dati sono sufficientemente critici per l'attività aziendale da richiedere una validazione più approfondita?
• Sono previsti utilizzi relativi a clienti, reportistica, finanza, operazioni, regolamentazione o altri utilizzi ad alto impatto?

Questo aiuta a determinare il livello di validazione richiesto. Una breve interruzione che interessa dati a basso rischio può giustificare un approccio di validazione diverso rispetto a un'interruzione prolungata che coinvolge liquidazioni, richieste di risarcimento, rendicontazione normativa o altri processi critici.

La questione pratica: "Cosa conta davvero in questo vuoto?"

Questo è un punto di partenza più utile rispetto all'applicare ciecamente la stessa lista di controllo a ogni tavolo.

Fai un inventario delle prove che hai effettivamente

La validazione post-recupero dovrebbe attingere a tre fonti:

A. La fonte

Cosa ti dice la fonte autorevole riguardo al periodo in questione? Le prove rilevanti possono includere:

• Documenti di origine
• Cronologia delle transazioni/modifiche
• Indicazioni temporali
• Chiavi
• Informazioni di registro o di sequenza specifiche della fonte
• Totali aziendali
• Altre prove provenienti dal sistema sorgente

B. La piattaforma di replica

Cosa può mostrare la piattaforma in merito all'accaduto? A seconda del prodotto e della configurazione, ciò può includere:

• Stato di riavvio/processo salvato
• Informazioni sullo stato e sul monitoraggio
• Errori e diagnostica
• Informazioni sul ritardo o sul recupero
• Funzionalità di confronto o convalida supportate
• Altre prove operative specifiche della piattaforma

C. L'obiettivo

Cosa contiene effettivamente il target ora? A seconda dei dati e del caso d'uso, potrebbe essere necessario esaminare:

• Registri
• chiavi aziendali
• conti
• Valori
• Indicazioni temporali
• Eccezioni di destinazione
• Risultati a valle
• Comportamento a livello di applicazione

La validazione più solida deriva solitamente dal collegare le prove provenienti da questi diversi livelli, anziché considerare lo stato di "successo" di un sistema come la risposta definitiva.

Inizia con un approccio ampio, ma non fermarti al conteggio delle righe.

Il conteggio delle righe è utile. Tuttavia, è anche una delle prime cose che gli esperti sconsigliano di considerare sufficienti. Due set di dati possono avere lo stesso numero di righe ed essere comunque errati.
Avresti potuto:

• una riga mancante e una riga inattesa
• la chiave corretta con un valore errato
• un record che avrebbe dovuto essere cancellato ma che esiste ancora
• un aggiornamento successivo senza uno stato previsto precedente
• differenze che si annullano a vicenda nel conteggio totale

Pertanto, utilizzate controlli generali per individuare i punti in cui approfondire la ricerca. Alcuni controlli generali utili possono includere:

• numero previsto di righe o record
• volumi di variazione previsti
• intervalli chiave
• totali aziendali di alto livello
• timestamp
• eccezioni inattese
• stato segnalato dalla piattaforma

Una discrepanza indica immediatamente che qualcosa richiede un'indagine. Una corrispondenza indica che quel particolare controllo è andato a buon fine. Ciò non significa che tutto sia stato dimostrato corretto.

Il numero di righe è un segnale, non una garanzia di buono stato di salute.

Confronta la fonte e la destinazione dove conta.

Una volta definiti il ​​periodo di ripristino e l'ambito interessato, confrontate l'origine e la destinazione in un punto logicamente appropriato. A seconda del vostro ambiente, la convalida potrebbe utilizzare:

• chiavi aziendali
• Confronto a livello di record
• Colonne selezionate
• Hash o checksum, ove appropriato
• Totali di controllo
• Indicazioni temporali
• Valori di origine e di destinazione
• Funzionalità di confronto supportate dalla piattaforma

Lo scopo non è necessariamente confrontare ogni byte di ogni dataset. È piuttosto quello di verificare se i dati che dovrebbero essere rappresentati nel target sono rappresentati in modo sufficientemente corretto da supportare la conclusione richiesta.

Fai attenzione ai tempi

Origine e destinazione devono essere confrontate in stati significativi e logicamente compatibili. Se l'origine continua a cambiare mentre la destinazione si sta ancora aggiornando, una differenza non significa automaticamente che il ripristino sia fallito. Potrebbe semplicemente significare che le due parti vengono misurate in momenti diversi.

Ecco perché la finestra di recupero e il confine di confronto sono importanti.

Come convalidare la completezza della replica CDC da mainframe a cloud dopo il ripristino: checksum, posizioni dei log e riconciliazione

Non esiste una ricetta universale per la convalida. Tuttavia, i team solitamente combinano diverse forme di evidenza quando convalidano i dati dopo un ripristino del CDC su mainframe.

Conteggi e totali di controllo: utili per identificare differenze evidenti nei volumi previsti o negli aggregati aziendali.

• Ideale per: rilevamento di anomalie su vasta scala.
• Non dimostra: che i singoli record o i valori siano presenti correttamente.

Chiavi e confronti a livello di record: utili per identificare record mancanti, imprevisti o non corrispondenti all'interno di un ambito definito.

• Ideale per: individuare differenze specifiche.
• Non dimostra automaticamente: la sequenza delle transazioni o ogni forma di correttezza storica.

Hash o checksum: laddove appropriato, gli hash o i checksum possono aiutare a confrontare insiemi di valori in modo efficiente.

• Utile per: rilevare differenze tra i valori di origine e di destinazione.
• Non ti dice automaticamente: perché differiscono o se il comportamento specifico della sequenza era corretto.

Timestamp, stato di riavvio e posizioni nel registro sorgente: questi elementi possono aiutare a stabilire il periodo o lo stato di elaborazione in esame. Per le sorgenti mainframe, la terminologia specifica relativa alle posizioni dipende dalla piattaforma sottostante.

• Utile per: dare un punto di riferimento all'indagine di recupero.
• Non dimostra automaticamente che i dati di destinazione finali siano corretti.

Funzionalità di diagnostica e confronto della piattaforma La piattaforma di replica può fornire prove operative o funzionalità di confronto supportate tra origine e destinazione.

• Ideale per: aggiungere dati specifici della piattaforma al processo di validazione.
• Importante: è fondamentale comprendere esattamente cosa copre la funzionalità per la piattaforma di origine e quella di destinazione. Non dare per scontato che una funzionalità di confronto tra piattaforme dimostri la correttezza di ogni aspetto.

Validazione a livello aziendale: per i flussi di lavoro critici, verificare che i record aziendali importanti, i totali, gli eventi o i risultati siano coerenti dopo il ripristino.

• Utile per: determinare se i dati sono utilizzabili nel contesto rilevante.
• Non sostituisce: la convalida tecnica laddove sia richiesta una prova tecnica.

L'approccio più difendibile è spesso la validazione a livelli: diversi controlli che rispondono a domande diverse, piuttosto che un unico controllo che pretende di rispondere a tutto.

Come individuare transazioni mancanti o modifiche dopo il ripristino da parte del CDC

La domanda che gli utenti si pongono è semplice: "Come facciamo a sapere che non ci è sfuggito nulla?"

Iniziate con la finestra di ripristino. Quindi confrontate ciò che avrebbe dovuto raggiungere la destinazione con ciò che è effettivamente avvenuto. A seconda dell'ambiente, ciò potrebbe significare esaminare:

• Documenti sorgente interessati
• chiavi aziendali di alto valore
• Cambiare attività durante l'intervallo
• Record di destinazione
• Diagnostica della piattaforma
• Risultati del confronto sorgente-destinazione supportati
• Risultati a valle

Presta particolare attenzione ai dati che sono cambiati durante l'interruzione della replica o la fase di recupero.

Segnali d'allarme

• I dati previsti sono assenti
• Gli aggiornamenti previsti non sono stati visualizzati
• I totali a valle non sono più riconciliati
• Le eccezioni relative alla piattaforma o alla destinazione rimangono inspiegate.

Non è possibile contabilizzare transazioni specifiche di alto valore

Non estendere le conclusioni oltre le prove disponibili. Se hai convalidato un sottoinsieme definito di tabelle o una finestra di ripristino specifica, specificalo. Un'affermazione difendibile è: "Abbiamo convalidato i dataset interessati e la finestra di ripristino utilizzando questi controlli e non abbiamo riscontrato discrepanze inspiegabili".

È una posizione più forte rispetto a un'affermazione categorica non supportata dalle prove.

Come identificare modifiche duplicate o rielaborate dopo il riavvio della pipeline

Un riavvio o un ripristino possono generare dubbi sul fatto che il lavoro sia stato elaborato più di una volta. Il comportamento esatto in termini di tentativi e duplicazione dipende dalla piattaforma di replica, dall'origine, dalla destinazione e dalla configurazione.

Non date per scontata una garanzia di consegna universale. Identificate invece dove potrebbero essere visibili applicazioni duplicate o ripetute nel vostro ambiente. I potenziali indicatori includono:

• Record aggiuntivi inattesi
• Duplicare le chiavi aziendali
• Errori di vincolo target
• Conteggi incoerenti
• Eventi aziendali ripetuti
• Errori o diagnostica della piattaforma
• Anomalie a livello di applicazione

Nei set di dati privi di vincoli di unicità naturali, l'individuazione dei duplicati può risultare più complessa.

Per questo motivo, i team dovrebbero comprendere quali chiavi o regole aziendali rendono visibile la duplicazione prima che si verifichi l'incidente.

Come individuare gli elementi eliminati mancanti dopo il ripristino del CDC

Le eliminazioni meritano una verifica a parte perché è facile non notarle. Un database di destinazione può contenere tutti i record previsti eppure risultare errato perché include record che non dovrebbero più esistere. In termini pratici, questo problema viene descritto in modo molto diretto: "I record eliminati dal database di origine sono ancora presenti nel database di destinazione".

Quando si verificano eliminazioni durante la finestra di ripristino, verificare che lo stato di destinazione pertinente le rifletta correttamente. A seconda del modello dati, ciò può comportare:

• Verifica delle chiavi aziendali interessate
• Confronto della presenza nella sorgente e nella destinazione
• Analisi dei risultati del confronto tra piattaforme supportate
• Convalidare il comportamento a valle laddove i record eliminati siano rilevanti

Non dare per scontato che un confronto di conteggio riuscito riveli sempre le cancellazioni mancanti.

Come identificare valori obsoleti o errati

A volte il record è presente su entrambi i lati. Il problema è che il destinatario ha la versione sbagliata. Cerca:

• Valori che non corrispondono alla fonte nel punto di confronto previsto
• Aggiornamenti dalla finestra di ripristino che non vengono visualizzati
• Risultati a valle utilizzando un valore precedente
• Differenze che non possono essere spiegate dalla normale tempistica o trasformazione

Questo è importante perché un semplice controllo di esistenza può avere esito positivo anche se il target è ancora obsoleto.

La domanda non è solo: "Il documento è presente?", ma: "Il documento è nello stato in cui ci aspettiamo che sia?".

Come identificare i cambiamenti fuori sequenza dopo il ripristino del CDC

L'ordine di esecuzione è più importante in alcuni carichi di lavoro che in altri. Se il risultato aziendale dipende dalla sequenza, il confronto dello stato finale potrebbe non rispondere a tutte le domande. In questi scenari, i team potrebbero aver bisogno di ulteriori prove appropriate per:

• La fonte
• L'obiettivo
• L'architettura di replica
• Il modello di transazione interessato
• Il requisito specifico per l'ordinazione

Non dare per scontato che un checksum o la corrispondenza dello stato finale di una riga dimostrino l'ordine storico. Allo stesso modo, non dare per scontato che ogni carico di lavoro richieda la convalida della sequenza transazione per transazione.

Lo standard corretto è: convalidare il comportamento di ordinamento che è effettivamente rilevante per il processo aziendale e l'architettura interessati.

Indaga sulle discrepanze, non limitarti a farle passare per medie.

Se un controllo di validazione rileva una differenza, considerala come una prova da approfondire.

Chiedere:

• Si tratta di una differenza di tempistica prevista?
• È coinvolta una trasformazione?
• Il confronto ha utilizzato stati di origine e di destinazione equivalenti?
• Il bersaglio sta ancora recuperando terreno?
• C'è una registrazione mancante di cui non si conosce la spiegazione?
• È presente qualcosa che avrebbe dovuto essere eliminato?
• La modifica è stata elaborata più di una volta?
• Un valore è obsoleto?
• La discrepanza è un caso isolato o fa parte di un modello più ampio?

Successivamente, si determinerà l'intervento di bonifica appropriato. A seconda dell'ambiente, questo potrebbe includere:

• Correzione di un record o di un set di dati identificato
• Ripetere una fase di convalida
• Risincronizzazione dei dati interessati
• Eseguire una risincronizzazione più ampia
• Mantenere limitato l'utilizzo a valle fino a quando il problema non sarà compreso.

Non permettete che un elevato numero di controlli andati a buon fine nasconda una discrepanza inspiegabile in dati cruciali per l'attività aziendale.

Creare una documentazione probatoria post-guarigione

Il team che ha gestito l'incidente potrebbe sapere esattamente cosa è successo oggi. Tre mesi dopo, qualcun altro potrebbe chiedere: "Come abbiamo fatto a sapere che i dati erano di nuovo sicuri da utilizzare?"

Non costringeteli a ricostruire la risposta a memoria. Create un registro conciso delle prove post-recupero che includa:

Finestra temporale dell'incidente: quando si è verificato l'incidente di replica?

Punto di ripristino: dove è ripresa l'elaborazione, utilizzando la terminologia appropriata alla fonte e alla piattaforma?

Ambito interessato: Quali fonti, destinazioni, set di dati, tabelle, file o processi a valle sono stati coinvolti?

Metodo di ripristino: Quale percorso di ripristino è stato utilizzato? Ad esempio:

• Riavvia dallo stato salvato
• Aumento
• Risincronizzazione mirata
• Risincronizzazione o ricaricamento più ampio

Validazione eseguita: Quali controlli sono stati completati? Per ogni controllo importante, registrare:

• Cosa è stato esaminato
• Quale periodo o ambito è stato trattato?
• Che cosa si intendeva accertare l'assegno

Risultati: Cosa ha osservato il team? Sono state riscontrate delle discrepanze?

Rimedi: Cosa è stato corretto, rielaborato o risincronizzato?

Eccezioni: cosa rimane irrisolto o al di fuori dell'ambito convalidato?

Conclusione: Quali prove supportano la decisione che i dati a valle pertinenti siano pronti per l'uso?

Tale record può supportare:

• Revisione dell'incidente
• Passaggio di consegne delle operazioni
• Comunicazione a valle
• Governance  
• Valutazione
• Risoluzione dei problemi futuri
• Miglioramento del manuale operativo di ripristino

Chi dà il via libera?

Si tratta di una questione operativa che i team spesso lasciano irrisolta fino a quando la pressione non è massima. Qualcuno deve decidere se i dati sono pronti per essere riutilizzati. Tale decisione potrebbe coinvolgere più persone oltre a quella che ha riavviato la pipeline. A seconda dell'incidente, potrebbe essere necessario il contributo di:

• Il team di replica o di ingegneria dei dati
• Il proprietario del sistema sorgente
• Il proprietario della piattaforma o dell'applicazione a valle
• operazioni sui dati
• Un imprenditore
• Governance, rischio o altra funzione di controllo

La procedura di approvazione precisa dovrebbe rispecchiare l'importanza dei dati interessati.

Il principio chiave: il team tecnico deve essere in grado di spiegare:

• Cosa è stato influenzato?
• Cosa è stato convalidato
• Cosa hanno stabilito i controlli
• Ciò che resta incerto
• Quali eccezioni esistono ancora?

In questo modo, i responsabili dell'utilizzo a valle potranno prendere una decisione consapevole.

Come si comunica ai team a valle che i dati sono di nuovo pronti?

Evitate entrambi gli estremi. Non affermate che va tutto bene se le prove a vostra disposizione non lo confermano.

Ma non riversate un registro degli incidenti tecnici su un responsabile aziendale. Comunicate chiaramente quattro cose:

• Cosa è successo: la replica è stata interrotta o ha subito dei ritardi durante un periodo definito.
• Cosa è stato interessato: identificare i dati o i sistemi a valle pertinenti.
• Cosa è stato convalidato: Descrivere l'ambito dei controlli effettuati.
• Cosa resta da fare: Indicare eventuali eccezioni, limitazioni o lavori di approfondimento ancora aperti.

Il messaggio più utile suona così:

"La replicazione è stata completata. Abbiamo convalidato i dati interessati per il periodo di tempo in cui si è verificato l'incidente utilizzando i controlli descritti qui. Non abbiamo riscontrato [differenze inspiegabili / abbiamo identificato queste differenze, che sono state corrette]. Questi set di dati a valle sono stati dichiarati utilizzabili. Le eccezioni, se presenti, rimangono aperte."

Il linguaggio utilizzato deve corrispondere esattamente alle prove. È così che si ricostruisce la fiducia senza fingere che l'incertezza non esista.

Una conduttura verde non è una strategia di validazione

L'errore ricorrente dopo un ripristino è quello di fermarsi allo stato operativo: il processo è in esecuzione. La latenza è tornata alla normalità. La dashboard è verde.

Tutti vogliono chiudere la chiamata di bridge. Ma nessuno di questi segnali, di per sé, stabilisce che i dati target interessati siano corretti.

La domanda cruciale a cui rispondere è: "Su quali prove ci basiamo quando diciamo alle persone che possono di nuovo fidarsi di questi dati?"

Se la risposta non è chiara, l'incidente non è concluso.

Come valutare le capacità di convalida post-recupero

Non tutte le piattaforme del CDC forniscono lo stesso livello di prove dopo un'interruzione. Alcune funzionalità sono considerate standard, mentre altre possono ridurre significativamente lo sforzo, l'incertezza e il rischio connessi alla dimostrazione dell'avvenuto ripristino.

Stacchi da tavolo

Tutte le piattaforme CDC aziendali dovrebbero fornire:

• Riavviare o informazioni sullo stato del processo
• Stato operativo e monitoraggio
• Informazioni di errore e diagnostiche
• Visibilità sull'attività di recupero
• Procedure di ripristino di base per gli ambienti supportati

Queste funzionalità aiutano i team a rispondere alla domanda: la replica è stata ripristinata e l'elaborazione è ripresa?

La questione più difficile è: possiamo dimostrare che i dati recuperati sono affidabili?

Funzionalità importanti che non sono sempre incluse

• Funzionalità di confronto tra origine e destinazione
• Visibilità della posizione di recupero e della cronologia delle procedure
• Sostegno al recupero del patrimonio storico laddove sia disponibile materiale storico conservato.
• Diagnosi significative a supporto dell'indagine sulle cause profonde.
• Prove di ispezione e convalida dello stato di recupero
• Visibilità sulle discrepanze rilevate durante la riconciliazione
• Supporto per la convalida efficiente di grandi set di dati
• Documentazione e reportistica a supporto dei requisiti di audit, governance o approvazione a valle.

Queste funzionalità determinano quanta indagine manuale è necessaria prima che i team possano dichiarare con certezza il completamento del ripristino. Nessuna singola funzionalità dovrebbe essere considerata una prova universale del successo del ripristino. La domanda cruciale è: "Quali prove fornirà questa piattaforma al nostro team dopo un evento di ripristino e di quale ulteriore convalida avremo ancora bisogno?"

Domande da porre a ogni fornitore del CDC

Chiedi al fornitore di fare una dimostrazione:

• Quale stato di riavvio o di processo è visibile dopo un'interruzione?
• Quali informazioni di monitoraggio e diagnostica possono esaminare gli operatori?
• In che modo la piattaforma supporta il recupero dopo un'interruzione?
• Quali funzionalità di confronto tra origine e destinazione sono disponibili?
• Quali differenze possono effettivamente individuare queste funzionalità di confronto?
• Quali sono i limiti di queste capacità?
• In che modo queste capacità si inseriscono in un processo di validazione più ampio?
• Quali prove possono conservare le squadre a supporto di una decisione di via libera?

Lo standard dovrebbe essere lo stesso per ogni piattaforma CDC: non accettare "il processo è stato riavviato" come prova. Chiedete agli operatori cosa possono ispezionare, confrontare, testare e difendere in seguito.

Come Rocket Data Replicate & Sync si integra

Rocket Data Replicate & Sync (RDRS) include funzionalità che possono contribuire all'analisi e alla convalida post-ripristino per le configurazioni supportate.

Le funzionalità RDRS documentate includono:

• Stato del processo salvato e del riavvio
• Informazioni di monitoraggio e diagnostica
• Funzionalità di confronto batch per le fonti supportate
• Supporto per l'elaborazione dei log archiviati per gli ambienti basati su log supportati, laddove la cronologia richiesta rimanga disponibile.

Queste funzionalità possono fornire prove operative e di convalida durante un'indagine di ripristino. Come per qualsiasi piattaforma CDC, le organizzazioni dovrebbero valutare RDRS in base alle proprie fonti, destinazioni, configurazioni, requisiti di ripristino e procedure operative specifiche. La domanda più importante è: "Quali prove può fornire RDRS negli scenari di ripristino che il nostro ambiente è più probabilmente in grado di affrontare?"

Lista di controllo per la convalida post-recupero

Prima di comunicare agli utenti a valle che i dati sono di nuovo pronti, confermare:

• La finestra di recupero è chiaramente definita.
• Sono note le fonti, i bersagli e i consumatori a valle interessati.
• L'arretrato è stato smaltito oppure lo stato rimanente è chiaro.
• Sono state esaminate le prove pertinenti relative alla fonte, alla piattaforma di replica e al bersaglio.
• La validazione è andata oltre il semplice stato del processo.
• Verifiche generiche come conteggi o totali non erano considerate prove universali.
• Ove opportuno, sono stati confrontati dati importanti, valori o elementi chiave per l'attività aziendale.
• Sono state prese in considerazione le modifiche mancanti.
• Le modifiche duplicate o ripetute sono state prese in considerazione ove pertinenti.
• Sono state prese in considerazione le eliminazioni avvenute durante la finestra di ripristino.
• Sono stati presi in considerazione i valori obsoleti o errati.
• L'ordine è stato valutato laddove la sequenza è importante.
• Sono state esaminate le discrepanze inspiegabili.
• Qualsiasi intervento di correzione o risincronizzazione è stato documentato.
• Le restanti eccezioni sono esplicite.
• I proprietari a valle sanno cosa è sicuro utilizzare.
• Le prove a sostegno del verdetto di assoluzione sono state registrate.

In conclusione

Rimettere in funzione la pipeline è solo metà del lavoro di recupero. La domanda più difficile è: "Come possiamo dimostrare che i dati sono corretti?"

Inizia definendo la finestra di ripristino. Comprendi cosa è stato interessato. Utilizza le prove provenienti dalla sorgente, dalla piattaforma di replica, dalla destinazione e dall'ambiente a valle. Cerca deliberatamente modifiche mancanti, duplicati, eliminazioni mancanti, valori obsoleti e problemi di ordinamento laddove siano rilevanti. Indaga sulle discrepanze invece di presumere che siano innocue. E lascia sufficienti prove affinché chiunque non abbia partecipato alla riunione sull'incidente possa capire perché la destinazione è stata dichiarata utilizzabile.

Perché:

Ricominciare a correre non è la stessa cosa che essere guariti.
E un gasdotto verde non significa che i dati siano affidabili.

Il recupero è completo quando il processo è stabile e l'organizzazione dispone di prove sufficienti per poter nuovamente fidarsi dei dati.

*NIST SP 1800-26: Integrità dei dati, rilevamento e risposta agli eventi distruttivi

Prossimo argomento: La tua piattaforma attuale è sufficientemente valida per il ripristino?

Se il ripristino dipende ripetutamente da convalide manuali, conoscenze informali, indagini tra team diversi o incertezza su cosa sia successo durante l'intervallo, la domanda successiva potrebbe essere più complessa dell'incidente stesso.

Come valutare le capacità di ripristino del CDC aziendale quando la perdita di dati non è accettabile

Utilizza il framework di valutazione per definire cosa la tua piattaforma dovrebbe rendere visibile, testabile e dimostrabile prima che si verifichi il prossimo errore.