Le pipeline fonctionne à nouveau. Peut-on se fier aux données ?

Après une panne ou une interruption de la réplication, un redémarrage réussi ne prouve qu'une chose: la réplication est de nouveau en cours. Cela ne prouve pas que toutes les modifications ont été prises en compte, ni que les suppressions ont été traitées, ni que les valeurs sont à jour, ni que les équipes en aval peuvent faire confiance aux données.

C'est pourquoi la validation post-récupération est importante.

Les recommandations du NIST en matière d'intégrité des données considèrent la récupération comme allant au-delà du simple rétablissement de la disponibilité. Elles insistent sur la détection et la réponse rapides aux atteintes à l'intégrité des données, ainsi que sur le rôle de la préparation, de la journalisation et des outils appropriés pour minimiser les interruptions de service et les pertes de données en cas de corruption ou d'altération.

Avant de déclarer la récupération terminée, les équipes ont besoin de suffisamment de preuves pour répondre à une question simple: sur quoi nous basons-nous lorsque nous disons aux gens que les données sont à nouveau utilisables en toute sécurité ?

Réponse rapide: Comment valider les données après une récupération CDC ?

La validation doit répondre à deux questions différentes mais tout aussi importantes

• La réplication a-t-elle réussi à se rétablir ?
  Il s'agit de la question opérationnelle. Le processus a redémarré. Le délai est revenu aux niveaux prévus. Le retard a été résorbé.
• Les données récupérées sont-elles fiables ?
  Il s'agit d'une question d'intégrité des données. La cible reflète les changements attendus. Les enregistrements importants sont présents. Les suppressions ont été traitées. Aucune anomalie inexpliquée ne subsiste.

Un processus sain permet de confirmer que la récupération a eu lieu. La validation permet de s'assurer que la récupération a produit des données fiables. Un processus pratique de validation post-récupération comporte cinq étapes:

• Définir la fenêtre de récupération.
• Identifiez les données et les systèmes en aval qui ont été exposés.
• Utilisez les preuves disponibles provenant de la source, de la plateforme de réplication et de la cible.
• Vérifiez en particulier les modes de défaillance importants.
• Documentez ce qui a été validé, ce qui a été trouvé et ce qui reste incertain.

Ne vous fiez pas à un seul signal.

Un processus en cours d'exécution indique que la réplication est active. Le nombre de lignes fournit des informations sur l'ensemble de données résultant. Une comparaison source-cible identifie les différences dans le cadre de sa définition. Les journaux et les diagnostics de la plateforme détaillent le déroulement des opérations. Des contrôles métier permettent de vérifier la cohérence du résultat obtenu.

Ensemble, ces signaux permettent de tirer une conclusion plausible. Analysons-les.

La validation est un processus en cinq étapes

Les sections suivantes développent ces cinq domaines plus en détail. Certaines étapes nécessitent plusieurs vérifications. Par exemple, la comparaison des données source et cible peut impliquer la validation des décomptes, l'identification des modifications manquantes, la recherche de doublons, la confirmation des suppressions et l'analyse des valeurs obsolètes.

L'objectif n'est pas d'accomplir treize tâches sans lien entre elles. Il s'agit de rassembler suffisamment de preuves pour répondre à une seule question: peut-on faire confiance aux données récupérées ?

Définir la fenêtre de récupération

Avant toute comparaison, définissez précisément la période que vous cherchez à évaluer. Commencez par le dernier point avant l'incident où la réplication fonctionnait comme prévu. Identifiez ensuite le moment où la récupération et le rattrapage ont atteint le niveau que vous souhaitez analyser.

Cela vous offre une fenêtre de récupération: du dernier état stable connu → en passant par l’interruption → en passant par la reprise du système → jusqu’à l’état auquel vous souhaitez désormais faire confiance. Selon la source et la plateforme, des références utiles peuvent inclure:

• horodatages
• redémarrage ou état du processus
• points de contrôle
• signets
• positions du journal source
• coordonnées de récupération spécifiques à la plateforme

Pour les environnements Db2 pour z/OS, les équipes peuvent également utiliser des concepts spécifiques à la source, tels que RBA ou LRSN, le cas échéant. La terminologie exacte varie. L'important est que tous les intervenants dans l'évaluation de la récupération se réfèrent à la même période et à la même limite logique.

Comment les positions des journaux sources, notamment Db2 pour z/OS RBA/LRSN, peuvent contribuer à ancrer la validation post-récupération

La position du journal source peut aider les équipes à identifier la période de traitement qu'elles cherchent à évaluer. Dans les environnements Db2 pour z/OS, RBA ou LRSN peuvent être pertinents pour comprendre la position du journal source, selon la configuration et l'environnement.

Ces coordonnées peuvent servir de point d'ancrage à l'enquête. Elles ne constituent pas une preuve absolue que la cible est complète. L'équipe doit encore établir le lien entre l'état source pertinent, les données de la plateforme de réplication et l'état cible obtenu.

Demander:

Quand le problème a-t-il réellement commencé ?

Quel était le dernier État auquel nous faisions confiance ?

Quand le rattrapage a-t-il commencé ?

Quand la cible est-elle revenue à l'état que nous sommes en train d'évaluer ?

Quelles transactions, ensembles de données, tables, fichiers ou processus en aval se trouvent dans cette fenêtre ?

Pourquoi c'est important

Si la fenêtre de validation est vague, la conclusion le sera aussi. Par conséquent, vous ne pouvez pas répondre avec certitude à la question: « Avons-nous oublié quelque chose ? » tant que vous ne vous êtes pas mis d’accord sur: « Entre quels deux points ? »

Identifiez ce qui a été réellement exposé

Ne validez pas systématiquement toutes les données avec le même niveau d'effort. Commencez par comprendre ce qui a changé pendant la période de récupération et quels systèmes en aval dépendaient de ces données.

Demander:

• Quelles sources et cibles ont été touchées ?
• Quels tableaux, fichiers, ensembles de données ou domaines de données ont été modifiés pendant cette période ?
• Quelles applications, rapports, analyses, API ou processus opérationnels en aval en dépendent ?
• Des données cibles obsolètes ont-elles été utilisées pendant que la réplication était en retard ?
• Quelles sont les données suffisamment critiques pour l'entreprise pour nécessiter une validation plus approfondie ?
• Existe-t-il des utilisations à fort impact, notamment en matière de clients, de reporting, de finances, d'opérations, de réglementation ou autres ?

Cela permet de déterminer le niveau de validation requis. Une brève interruption affectant des données à faible risque peut justifier une approche de validation différente de celle nécessaire pour une panne prolongée impliquant un règlement, des réclamations, des déclarations réglementaires ou tout autre processus critique.

La question pratique: « Qu’est-ce qui compte réellement dans cet intervalle ? »

C'est un point de départ plus utile que d'appliquer aveuglément la même liste de contrôle à chaque table.

Faites l'inventaire des preuves dont vous disposez réellement.

La validation post-récupération devrait s'appuyer sur trois sources:

A. La source

Que vous apprend la source faisant autorité sur la période concernée ? Les éléments de preuve pertinents peuvent inclure:

• Enregistrements sources
• Historique des transactions/modifications
• Horodatage
• Clés
• Informations de journalisation ou de séquence spécifiques à la source
• Total des activités
• Autres preuves du système source

B. La plateforme de réplication

Que peut indiquer la plateforme concernant l'événement ? Selon le produit et sa configuration, cela peut inclure:

• État de redémarrage/processus enregistré
• Informations sur l'état et le suivi
• Erreurs et diagnostics
• Informations de retard ou de rattrapage
• Fonctionnalités de comparaison ou de validation prises en charge
• Autres preuves opérationnelles propres à la plateforme

C. La cible

Que contient réellement la cible actuellement ? Selon les données et le cas d’utilisation, il peut être nécessaire d’inspecter:

• Archives
• Clés d'affaires
• Comptes
• Valeurs
• Horodatage
• Exceptions cibles
• Résultats en aval
• Comportement au niveau de l'application

La validation la plus solide provient généralement de la mise en relation des preuves à travers ces différents niveaux, et non de la prise en compte du statut de « succès » d'un système comme réponse finale.

Commencez par une vue d'ensemble, mais ne vous arrêtez pas au nombre de lignes.

Le nombre de lignes est utile. C'est aussi l'un des premiers points sur lesquels les praticiens expérimentés mettent en garde: il ne faut pas le considérer comme suffisant. Deux ensembles de données peuvent avoir le même nombre de lignes et pourtant être erronés.
Vous auriez pu:

• une ligne manquante et une ligne inattendue
• la clé correcte avec une valeur incorrecte
• un enregistrement qui aurait dû être supprimé mais qui existe toujours
• une mise à jour ultérieure sans état attendu antérieur
• les différences s'annulent mutuellement dans le nombre total

Utilisez donc des vérifications générales pour identifier les points à approfondir. Voici quelques exemples de vérifications générales utiles:

• Nombre de lignes ou d'enregistrements attendu
• volumes de changement attendus
• plages clés
• chiffres d'affaires de haut niveau
• horodatages
• exceptions inattendues
• statut signalé par la plateforme

Une incohérence indique immédiatement qu'une investigation est nécessaire. Une correspondance signifie que ce contrôle particulier a été réussi. Cela ne signifie pas pour autant que tout est correct.

Le nombre de lignes est un indicateur, pas une preuve irréfutable de bonne santé.

Comparez la source et la cible là où c'est important.

Une fois la fenêtre de récupération et le périmètre affecté définis, comparez la source et la cible à un point logiquement approprié. Selon votre environnement, la validation peut utiliser:

• Clés d'affaires
• Comparaison au niveau des records
• Colonnes sélectionnées
• Hachages ou sommes de contrôle, le cas échéant
• Totaux de contrôle
• Horodatage
• valeurs source et cible
• Fonctionnalités de comparaison prises en charge par la plateforme

L'objectif n'est pas nécessairement de comparer chaque octet de chaque ensemble de données. Il s'agit de déterminer si les données qui devraient être représentées à la cible le sont suffisamment correctement pour étayer la conclusion attendue.

Faites attention au timing

La source et la cible doivent être comparées dans des états pertinents et logiquement compatibles. Si la source continue d'évoluer tandis que la cible est encore en phase de synchronisation, une différence n'indique pas automatiquement un échec de la récupération. Cela peut simplement signifier que les deux éléments sont mesurés à des moments différents.

C'est pourquoi la fenêtre de récupération et la limite de comparaison sont importantes.

Comment valider l'intégrité de la réplication CDC mainframe-cloud après une restauration: sommes de contrôle, positions des journaux et réconciliation

Il n'existe pas de méthode de validation universelle. Cependant, les équipes combinent généralement plusieurs types de preuves lors de la validation des données après une restauration d'un système CDC sur mainframe.

Comptages et totaux de contrôle: utiles pour identifier les différences évidentes dans les volumes attendus ou les agrégats commerciaux.

• Idéal pour: la détection d'anomalies à grande échelle.
• Ne prouve pas que les enregistrements ou valeurs individuels corrects sont présents.

Clés et comparaisons au niveau des enregistrements: utiles pour identifier les enregistrements manquants, inattendus ou non concordants dans un périmètre défini.

• Idéal pour: trouver des différences spécifiques.
• Cela ne prouve pas automatiquement: la séquence des transactions ou toute forme d'exactitude historique.

Hachages ou sommes de contrôle: le cas échéant, les hachages ou les sommes de contrôle peuvent aider à comparer efficacement des ensembles de valeurs.

• Idéal pour: détecter les différences entre les valeurs source et cible.
• Cela ne vous indique pas automatiquement: pourquoi elles diffèrent ou si le comportement spécifique à une séquence était correct.

Horodatage, état de redémarrage et positions dans le journal source: ces éléments permettent de déterminer la période ou l’état de traitement évalué. Pour les sources mainframe, la terminologie de position spécifique dépend de la plateforme sous-jacente.

• Idéal pour: ancrer l'enquête de récupération.
• Cela ne prouve pas automatiquement que les données cibles finales sont correctes.

Capacités de diagnostic et de comparaison de la plateforme: Votre plateforme de réplication peut fournir des preuves opérationnelles ou des fonctionnalités de comparaison source-cible prises en charge.

• Idéal pour: ajouter des preuves spécifiques à la plateforme au processus de validation.
• Important: comprenez précisément ce que couvre cette fonctionnalité pour votre source et votre cible. Ne présumez pas qu’une fonction de comparaison de plateformes prouve l’exactitude de tous les aspects.

Validation au niveau métier: Pour les flux de travail critiques, vérifiez si les enregistrements, totaux, événements ou résultats importants restent cohérents après la récupération.

• Utile pour: déterminer si les données sont utilisables dans le contexte pertinent.
• Ne remplace pas: la validation technique lorsque des preuves techniques sont requises.

L'approche la plus défendable est souvent la validation par couches: plusieurs contrôles répondant à différentes questions plutôt qu'un seul contrôle prétendant tout résoudre.

Comment détecter les transactions ou modifications manquantes après une récupération CDC

La question que se posent les utilisateurs est simple: « Comment savoir si rien n'a été oublié ? »

Commencez par analyser la fenêtre de récupération. Comparez ensuite ce qui aurait dû atteindre la cible avec ce qui l'a réellement atteinte. Selon l'environnement, cela peut impliquer d'examiner:

• Enregistrements sources concernés
• Clés commerciales à forte valeur ajoutée
• Activité de changement pendant l'intervalle
• Enregistrements cibles
• Diagnostics de la plateforme
• Résultats de comparaison source-cible pris en charge
• Résultats en aval

Examinez en particulier les données qui ont changé pendant l'interruption ou la reprise de la réplication.

Signaux d'alarme

• Les enregistrements attendus sont absents.
• Les mises à jour attendues ne sont pas reflétées
• Les totaux en aval ne concordent plus.
• Les exceptions concernant la plateforme ou la cible restent inexpliquées.

Certaines transactions de grande valeur ne peuvent être comptabilisées.

N'étendez pas vos conclusions au-delà des preuves. Si vous avez validé un sous-ensemble défini de tables ou une fenêtre de récupération spécifique, indiquez-le. Une déclaration acceptable serait: « Nous avons validé les ensembles de données concernés et la fenêtre de récupération à l'aide de ces contrôles et n'avons constaté aucune anomalie inexpliquée. »

C'est plus convaincant que d'affirmer catégoriquement quelque chose que les preuves ne peuvent étayer.

Comment identifier les modifications dupliquées ou retraitées après le redémarrage du pipeline

Un redémarrage ou une récupération peut soulever des questions quant à un éventuel traitement multiple des données. Le comportement exact en matière de nouvelles tentatives et de doublons dépend de la plateforme de réplication, de la source, de la cible et de la configuration.

Ne présumez pas d'une garantie de livraison universelle. Identifiez plutôt les endroits où une application dupliquée ou répétée pourrait être visible dans votre environnement. Voici quelques indicateurs potentiels:

• Enregistrements supplémentaires inattendus
• Clés commerciales en double
• Erreurs de contrainte cible
• Des décomptes incohérents
• Événements commerciaux répétés
• Erreurs ou diagnostics de la plateforme
• Anomalies au niveau de l'application

Pour les ensembles de données sans contraintes d'unicité naturelles, les doublons peuvent être plus difficiles à détecter.

C’est pourquoi les équipes doivent comprendre quelles clés ou règles métier rendent la duplication visible avant que l’incident ne survienne.

Comment détecter les suppressions manquantes après une récupération CDC

Les suppressions méritent une vérification spécifique car elles sont faciles à manquer. Une cible peut contenir tous les enregistrements attendus et pourtant être erronée car elle renferme des enregistrements qui ne devraient plus exister. Le langage courant pour décrire ce problème est très clair: « Des enregistrements supprimés de la source sont toujours présents dans la cible. »

En cas de suppressions survenues pendant la période de récupération, vérifiez que l'état cible correspondant les reflète correctement. Selon le modèle de données, cela peut impliquer:

• Vérification des clés métier concernées
• Comparaison de la présence de la source et de la cible
• Analyse comparative des plateformes prises en charge
• Valider le comportement en aval lorsque les enregistrements supprimés sont importants

Ne partez pas du principe qu'une comparaison de comptage réussie permettra toujours de déceler les suppressions manquantes.

Comment identifier les valeurs obsolètes ou incorrectes

Il arrive que le document soit présent des deux côtés. Le problème est que le destinataire possède la mauvaise version. Recherchez:

• Valeurs qui ne correspondent pas à la source au point de comparaison prévu
• Mises à jour de la fenêtre de récupération qui ne sont pas reflétées
• Résultats en aval utilisant une valeur antérieure
• Des différences qui ne peuvent s'expliquer par le calendrier normal ou la transformation

C'est important car une simple vérification d'existence peut réussir alors que la cible est encore obsolète.

La question n'est pas simplement: « Le disque existe-t-il ? » C'est: « Le disque est-il dans l'état où nous nous attendons à le trouver ? »

Comment identifier les changements anormaux après la récupération du CDC

L'ordre des tâches est plus important pour certaines charges de travail que pour d'autres. Si le résultat commercial dépend de la séquence, la comparaison des états finaux peut ne pas répondre à toutes les questions. Dans ces cas, les équipes peuvent avoir besoin d'éléments de preuve supplémentaires pertinents pour:

• La source
• La cible
• L'architecture de réplication
• Modèle de transaction affecté
• Les exigences spécifiques en matière de commande

Ne présumez pas qu'une somme de contrôle ou la correspondance de l'état final d'une ligne prouve l'ordre historique. De même, ne présumez pas que chaque charge de travail nécessite une validation de séquence transaction par transaction.

La norme appropriée consiste à valider le comportement de commande qui importe réellement pour le processus métier et l'architecture concernés.

Examinez les anomalies — ne les ignorez pas par la moyenne

Si un contrôle de validation révèle une différence, considérez-la comme un élément à examiner.

Demander:

• S'agit-il d'un décalage temporel normal ?
• Une transformation est-elle impliquée ?
• La comparaison a-t-elle utilisé des états source et cible équivalents ?
• L'objectif est-il toujours en train de rattraper son retard ?
• Existe-t-il un enregistrement manquant inexpliqué ?
• Y a-t-il un élément présent qui aurait dû être supprimé ?
• Une modification a-t-elle été traitée plusieurs fois ?
• Une valeur est-elle obsolète ?
• Cette anomalie est-elle isolée ou fait-elle partie d'une tendance plus générale ?

Déterminez ensuite la mesure corrective appropriée. Selon l'environnement, cela pourrait impliquer:

• Correction d'un enregistrement ou d'un ensemble de données identifié
• Répéter une étape de validation
• Resynchronisation des données affectées
• Effectuer une resynchronisation plus large
• Restreindre l'utilisation en aval jusqu'à ce que le problème soit compris.

Ne laissez pas un grand nombre de vérifications réussies masquer une anomalie inexpliquée dans des données critiques pour l'entreprise.

Créer un dossier de preuves post-récupération

L'équipe qui a géré l'incident sait peut-être exactement ce qui s'est passé aujourd'hui. Trois mois plus tard, quelqu'un d'autre pourrait se demander: « Comment pouvions-nous être sûrs que les données pouvaient être réutilisées en toute sécurité ? »

Ne les obligez pas à reconstituer la réponse de mémoire. Créez un dossier de preuves post-récupération concis qui comprend:

Fenêtre d'incident: Quand la réplication a-t-elle été affectée ?

Point de reprise: Où le traitement a-t-il repris, en utilisant la terminologie appropriée à la source et à la plateforme ?

Périmètre concerné: Quelles sources, cibles, ensembles de données, tables, fichiers ou processus en aval étaient concernés ?

Méthode de récupération: Quel chemin de récupération a été utilisé ? Par exemple:

• Redémarrer à partir de l'état enregistré
• Rattraper
• Resynchronisation ciblée
• Resynchronisation ou rechargement plus large

Validation effectuée: Quels contrôles ont été réalisés ? Pour chaque contrôle important, veuillez indiquer:

• Ce qui a été examiné
• Quelle période ou quelle étendue a été couverte ?
• Ce que le chèque était censé établir

Résultats: Qu’a observé l’équipe ? Des anomalies ont-elles été constatées ?

Remédiation: Qu’est-ce qui a été corrigé, retraité ou resynchronisé ?

Exceptions: Qu’est-ce qui reste non résolu ou en dehors du périmètre validé ?

Conclusion: Quels éléments de preuve étayent la décision selon laquelle les données en aval pertinentes sont prêtes à être utilisées ?

Ce document peut étayer:

• Examen des incidents
• Transfert des opérations
• Communication en aval
• Gouvernance
• Audit  
• Dépannage futur
• Amélioration du manuel de reprise d'activité

Qui donne le feu vert ?

Il s'agit d'une question opérationnelle que les équipes laissent souvent sans réponse jusqu'à ce que la situation devienne critique. Il faut bien que quelqu'un décide si les données sont de nouveau utilisables. Cette décision peut impliquer plus que la seule personne ayant relancé le processus. Selon l'incident, elle peut nécessiter l'avis de:

• L'équipe de réplication ou d'ingénierie des données
• Le propriétaire du système source
• Le propriétaire de la plateforme ou de l'application en aval
• opérations de données
• Un propriétaire d'entreprise
• Gouvernance, risque ou autre fonction de contrôle

La procédure de validation exacte doit refléter l'importance des données concernées.

Principe clé: L’équipe technique doit être en mesure d’expliquer:

• Qu'est-ce qui a été affecté
• Ce qui a été validé
• Ce que les contrôles ont établi
• Ce qui reste incertain
• Quelles exceptions subsistent ?

Les personnes responsables de l'utilisation en aval pourront alors prendre une décision éclairée.

Comment informer les équipes en aval que les données sont à nouveau disponibles ?

Évitez les deux extrêmes. Ne dites pas que tout va bien si vos preuves ne le confirment pas.

Mais n'inondez pas non plus un responsable métier d'un rapport d'incidents techniques. Communiquez clairement quatre points:

• Que s'est-il passé ? La réplication a été interrompue ou a pris du retard pendant une période définie.
• Éléments affectés: Identifier les données ou systèmes en aval concernés.
• Ce qui a été validé: Expliquez la portée des contrôles effectués.
• Ce qui reste à faire: Indiquer toute exception, limitation ou travail de suivi en cours.

Le message le plus utile ressemble à ceci:

« La réplication a rattrapé son retard. Nous avons validé les données affectées pour la période concernée par l'incident à l'aide des contrôles décrits ici. Nous n'avons constaté aucune différence inexpliquée. Les différences identifiées ont été corrigées. Ces jeux de données en aval sont prêts à être utilisés. Les exceptions éventuelles restent ouvertes. »

Les termes employés doivent correspondre exactement aux faits. C'est ainsi que l'on rétablit la confiance sans faire comme si l'incertitude n'existait pas.

Un pipeline vert n'est pas une stratégie de validation

L'erreur fréquente après une reprise est de s'arrêter à l'état opérationnel: le processus est en cours d'exécution, la latence est revenue à la normale et le tableau de bord est vert.

Tout le monde souhaite clore la communication. Mais aucun de ces signaux, à lui seul, ne permet d'établir que les données cibles concernées sont correctes.

La question cruciale à laquelle il faut répondre est la suivante: « Sur quelles preuves nous appuyons-nous lorsque nous disons aux gens qu’ils peuvent à nouveau faire confiance à ces données ? »

Si la réponse n'est pas claire, l'incident n'est pas terminé.

Comment évaluer les capacités de validation post-récupération

Les plateformes CDC ne fournissent pas toutes le même niveau de preuve après une interruption. Certaines fonctionnalités correspondent aux exigences de base. D'autres peuvent réduire considérablement les efforts, l'incertitude et les risques liés à la démonstration de la réussite d'une reprise.

Enjeux de table

Toutes les plateformes CDC d'entreprise doivent fournir:

• Informations sur le redémarrage ou l'état du processus
• État opérationnel et surveillance
• Informations sur les erreurs et les diagnostics
• Visibilité sur les activités de rattrapage
• Procédures de récupération de base pour les environnements pris en charge

Ces fonctionnalités aident les équipes à répondre à la question suivante: La réplication a-t-elle été rétablie et le traitement a-t-il repris ?

La question plus difficile est la suivante: pouvons-nous prouver que les données récupérées sont fiables ?

Des fonctionnalités importantes qui ne sont pas toujours incluses

• Fonctionnalité de comparaison source-cible
• Visibilité de la position de récupération et de l'historique de traitement
• Soutien à la mise à jour des données historiques lorsque des données historiques sont conservées
• Des diagnostics pertinents qui soutiennent l'analyse des causes profondes
• Preuves d'inspection et de validation de l'état de rétablissement
• Visibilité des écarts découverts lors de la réconciliation
• Prise en charge de la validation efficace des grands ensembles de données
• Documentation et rapports à l'appui des exigences d'audit, de gouvernance ou de validation en aval

Ces fonctionnalités déterminent le niveau d'investigation manuelle nécessaire avant que les équipes puissent déclarer la récupération terminée avec certitude. Aucune fonctionnalité ne doit être considérée à elle seule comme une preuve absolue de la réussite de la récupération. La question essentielle est: « Quelles preuves cette plateforme fournira-t-elle à notre équipe après un incident de récupération, et de quelles validations supplémentaires aurons-nous encore besoin ? »

Questions à poser à chaque fournisseur du CDC

Demandez au vendeur de faire une démonstration:

• Quel état de redémarrage ou de processus est visible après une interruption ?
• Quelles informations de surveillance et de diagnostic les opérateurs peuvent-ils consulter ?
• Comment la plateforme permet-elle de rattraper le retard après une interruption ?
• Quelles sont les fonctionnalités de comparaison source-cible disponibles ?
• Quelles différences ces capacités de comparaison permettent-elles réellement d'identifier ?
• Quelles sont les limites de ces capacités ?
• Comment ces capacités s'intègrent-elles dans un processus de validation plus large ?
• Quelles preuves les équipes peuvent-elles conserver pour étayer une décision sans équivoque ?

La norme devrait être la même pour toutes les plateformes CDC: ne pas se contenter d’un simple redémarrage du processus. Il faut se demander ce que les opérateurs peuvent inspecter, comparer, tester et justifier par la suite.

Comment Rocket Data Replicate & Sync s'intègre

Rocket Data Replicate & Sync (RDRS) inclut des fonctionnalités qui peuvent contribuer à l'investigation et à la validation post-récupération pour les configurations prises en charge.

Les capacités documentées de RDRS comprennent:

• État du processus enregistré et du redémarrage
• Informations de surveillance et de diagnostic
• Fonctionnalité de comparaison par lots pour les sources prises en charge
• Prise en charge du traitement des journaux archivés pour les environnements basés sur les journaux pris en charge où l'historique requis reste disponible

Ces fonctionnalités peuvent fournir des preuves opérationnelles et de validation lors d'une enquête de reprise d'activité. Comme pour toute plateforme CDC, les organisations doivent évaluer RDRS en fonction de leurs sources, cibles, configurations, exigences de reprise d'activité et procédures opérationnelles spécifiques. La question essentielle est: « Quelles preuves RDRS peut-elle fournir dans les scénarios de reprise d'activité les plus susceptibles de se produire dans notre environnement ? »

Liste de contrôle de validation post-récupération

Avant d'informer les utilisateurs en aval que les données sont de nouveau disponibles, veuillez vérifier:

• La fenêtre de récupération est clairement définie.
• Les sources, les cibles et les consommateurs en aval concernés sont identifiés.
• L'arriéré a été résorbé ou l'état restant est compris.
• Les preuves pertinentes relatives à la source, à la plateforme de réplication et à la cible ont été examinées.
• La validation allait au-delà du simple état du processus.
• Les vérifications générales telles que les décomptes ou les totaux n'étaient pas considérées comme une preuve universelle.
• Les enregistrements, valeurs ou clés commerciales importants ont été comparés le cas échéant.
• Les modifications manquantes ont été prises en compte.
• Les modifications en double ou répétées ont été prises en compte le cas échéant.
• Les suppressions survenues pendant la période de récupération ont été prises en compte.
• Les valeurs obsolètes ou incorrectes ont été prises en compte.
• L'ordre a été évalué là où la séquence importait.
• Des anomalies inexpliquées ont fait l'objet d'une enquête.
• Toute mesure corrective ou de resynchronisation a été documentée.
• Les exceptions restantes sont explicites.
• Les propriétaires situés en aval savent ce qui est sûr à utiliser.
• Les preuves confirmant la levée de l'alerte ont été enregistrées.

En résumé

Remettre en marche la chaîne de production ne représente que la moitié du chemin vers la guérison. La question la plus difficile est: « Comment prouver que les données sont exactes ? »

Commencez par définir la fenêtre de récupération. Identifiez les éléments affectés. Utilisez les preuves provenant de la source, de la plateforme de réplication, de la cible et de l'environnement en aval. Recherchez systématiquement les modifications manquantes, les doublons, les suppressions manquantes, les valeurs obsolètes et les problèmes d'ordre, là où ils sont significatifs. Analysez les anomalies au lieu de les considérer comme anodines. Enfin, conservez suffisamment d'éléments de preuve pour qu'une personne n'ayant pas participé à la réunion d'incident puisse comprendre pourquoi la cible a été remise en service.

Parce que:

Courir à nouveau ne signifie pas être guéri.
Et un pipeline vert ne signifie pas que les données sont fiables.

Le rétablissement est complet lorsque le processus est stable et que l'organisation dispose de suffisamment de preuves pour faire à nouveau confiance aux données.

*NIST SP 1800-26: Intégrité des données, détection et réponse aux événements destructeurs

Prochaine étape: Votre plateforme actuelle est-elle suffisamment performante en matière de reprise d’activité ?

Si la récupération dépend systématiquement d'une validation manuelle, de connaissances tacites, d'une enquête inter-équipes ou d'une incertitude quant à ce qui s'est passé pendant l'interruption, la question suivante pourrait être plus importante que l'incident lui-même.

Comment évaluer les capacités de récupération des données d'entreprise lorsque la perte de données est inacceptable ?

Utilisez le cadre d'évaluation pour définir ce que votre plateforme doit rendre visible, testable et prouvable avant la prochaine défaillance.