Die Pipeline läuft wieder. Kann man den Daten trauen?

Nach einem Replikationsfehler oder einer Unterbrechung beweist ein erfolgreicher Neustart lediglich eines: Die Replikation läuft wieder. Er beweist nicht, dass alle Änderungen übernommen wurden. Er beweist nicht, dass Löschvorgänge verarbeitet wurden. Er beweist nicht, dass die Werte aktuell sind. Und er beweist auch nicht, dass nachgelagerte Teams den Daten vertrauen können.

Deshalb ist die Validierung nach der Wiederherstellung so wichtig.

Die NIST-Richtlinien zur Datenintegrität betrachten die Wiederherstellung als mehr als nur die Wiederherstellung der Verfügbarkeit. Sie betonen die rechtzeitige Erkennung und Reaktion auf Integritätsverluste sowie die Bedeutung von Vorbereitung, Protokollierung und geeigneten Tools zur Minimierung von Ausfallzeiten und Datenverlusten, wenn Daten beschädigt oder verändert wurden.

Bevor die Wiederherstellung als abgeschlossen erklärt werden kann, benötigen die Teams genügend Beweise, um eine einfache Frage zu beantworten: Worauf stützen wir uns, wenn wir den Menschen sagen, dass die Daten wieder sicher verwendet werden können?

Kurzantwort: Wie validiert man Daten nach der CDC-Wiederherstellung?

Die Validierung muss zwei unterschiedliche, aber gleichermaßen wichtige Fragen beantworten.

• Wurde die Replikation erfolgreich wiederhergestellt?
  Dies ist die operative Frage. Der Prozess wurde neu gestartet. Die Verzögerungen haben sich wieder auf das erwartete Niveau eingependelt. Der Rückstand wurde aufgeholt.
• Sind die wiederhergestellten Daten vertrauenswürdig?
  Dies ist die Frage der Datenintegrität. Das Ziel spiegelt die erwarteten Änderungen wider. Wichtige Datensätze sind vorhanden. Löschungen wurden verarbeitet. Es bestehen keine unerklärlichen Diskrepanzen mehr.

Ein ordnungsgemäßer Wiederherstellungsprozess trägt dazu bei, den erfolgreichen Abschluss der Wiederherstellung zu bestätigen. Die Validierung trägt dazu bei, sicherzustellen, dass die wiederhergestellten Daten vertrauenswürdig sind. Ein praktischer Validierungsprozess nach der Wiederherstellung umfasst fünf Teile:

• Definiere das Wiederherstellungsfenster.
• Identifizieren Sie die Daten und nachgelagerten Systeme, die betroffen waren.
• Nutzen Sie die verfügbaren Daten aus der Quelle, der Replikationsplattform und dem Zielsystem.
• Achten Sie insbesondere auf die relevanten Fehlermodi.
• Dokumentieren Sie, was bestätigt, was festgestellt und was noch unklar ist.

Verlassen Sie sich nicht nur auf ein einziges Signal.

Ein laufender Replikationsprozess signalisiert, dass die Replikation aktiv ist. Die Zeilenanzahl gibt Aufschluss über den resultierenden Datensatz. Ein Quell-Ziel-Vergleich identifiziert Unterschiede innerhalb des unterstützten Bereichs. Plattformprotokolle und Diagnosedaten informieren über den Betriebsablauf. Prüfungen auf Geschäftsebene zeigen, ob das Ergebnis plausibel ist.

Zusammengenommen können diese Signale eine vertretbare Schlussfolgerung stützen. Schauen wir uns diese genauer an.

Die Validierung ist ein fünfteiliger Prozess

Die folgenden Abschnitte gehen detaillierter auf diese fünf Bereiche ein. Einige Schritte erfordern mehrere Prüfungen. Beispielsweise kann der Vergleich von Quell- und Zieldaten die Validierung von Zählungen, die Identifizierung fehlender Änderungen, die Suche nach Duplikaten, die Bestätigung von Löschungen und die Untersuchung veralteter Werte umfassen.

Ziel ist es nicht, dreizehn voneinander unabhängige Aufgaben zu erledigen. Es geht darum, genügend Beweise zu sammeln, um eine einzige Frage zu beantworten: Können wir den wiederhergestellten Daten vertrauen?

Wiederherstellungsfenster definieren

Bevor Sie etwas vergleichen, legen Sie fest, welchen Zeitraum Sie eigentlich untersuchen möchten. Beginnen Sie mit dem letzten Zeitpunkt vor dem Vorfall, an dem die Replikation nachweislich wie erwartet funktionierte. Ermitteln Sie dann, wann die Wiederherstellung und der Aufholvorgang den von Ihnen zu bewertenden Punkt erreicht hatten.

Dadurch ergibt sich ein Wiederherstellungsfenster: Vom letzten bekannten fehlerfreien Zustand → über die Unterbrechung → über die Aufholphase → bis zum Zustand, dem Sie nun vertrauen möchten. Je nach Quelle und Plattform können folgende Referenzen hilfreich sein:

• Zeitstempel
• Neustart oder Prozessstatus
• Kontrollpunkte
• Lesezeichen
• Quellprotokollpositionen
• plattformspezifische Wiederherstellungskoordinaten

In Db2 für z/OS-Umgebungen arbeiten Teams gegebenenfalls auch mit quellenspezifischen Konzepten wie RBA oder LRSN. Die genaue Terminologie variiert. Wichtig ist, dass alle an der Bewertung der Wiederherstellung Beteiligten denselben Zeitraum und dieselbe logische Grenze betrachten.

Wie Quellprotokollpositionen, einschließlich Db2 for z/OS RBA/LRSN, zur Verankerung der Validierung nach der Wiederherstellung beitragen können

Die Positionen der Quellprotokolle können Teams dabei helfen, den zu analysierenden Verarbeitungszeitraum zu identifizieren. In Db2 for z/OS-Umgebungen können RBA oder LRSN je nach Konfiguration und Umgebung relevant sein, um die Position der Quellprotokolle zu ermitteln.

Diese Koordinaten können die Untersuchung unterstützen. Sie sollten jedoch nicht als allgemeingültiger Beweis für die Fertigstellung des Zielsystems angesehen werden. Das Team muss weiterhin den relevanten Quellzustand, die Nachweise der Replikationsplattform und den resultierenden Zielzustand miteinander verknüpfen.

Fragen:

Wann genau hat das Problem begonnen?

Welchem ​​Staat haben wir zuletzt vertraut?

Wann begann der Aufholprozess?

Wann ist das Ziel in den Zustand zurückgekehrt, den wir jetzt auswerten?

Welche Transaktionen, Datensätze, Tabellen, Dateien oder nachgelagerten Prozesse fallen in diesen Zeitraum?

Warum es wichtig ist

Ist der Validierungszeitraum unklar, so ist auch das Ergebnis unklar. Daher kann man die Frage „Haben wir etwas übersehen?“ nicht sicher beantworten, bis man sich über die Frage „Zwischen welchen beiden Punkten?“ geeinigt hat.

Ermitteln Sie, was tatsächlich freigelegt wurde.

Validieren Sie nicht automatisch alles mit dem gleichen Aufwand. Verstehen Sie zunächst, was sich während des Wiederherstellungszeitraums geändert hat und welche nachgelagerten Systeme auf diese Daten angewiesen waren.

Fragen:

• Welche Quellen und Ziele waren betroffen?
• Welche Tabellen, Dateien, Datensätze oder Datendomänen haben sich während des betrachteten Zeitraums geändert?
• Welche nachgelagerten Anwendungen, Berichte, Analysen, APIs oder operativen Prozesse hängen davon ab?
• Wurden veraltete Zieldaten verwendet, während die Replikation hinterherhinkte?
• Welche Daten sind geschäftskritisch genug, um eine eingehendere Validierung zu erfordern?
• Gibt es kundenbezogene, Berichts-, Finanz-, Betriebs-, Regulierungs- oder andere wichtige Anwendungsfälle, die in den Geltungsbereich fallen?

Dies hilft dabei, den erforderlichen Validierungsumfang zu bestimmen. Eine kurze Unterbrechung, die Daten mit geringem Risiko betrifft, kann einen anderen Validierungsansatz rechtfertigen als ein längerer Ausfall, der die Abwicklung von Schadensfällen, die Meldung an Aufsichtsbehörden oder einen anderen kritischen Prozess betrifft.

Die praktische Frage: „Was ist in dieser Lücke eigentlich wichtig?“

Das ist ein sinnvollerer Ausgangspunkt, als blindlings dieselbe Checkliste auf jede Tabelle anzuwenden.

Erstellen Sie eine Liste der Beweise, die Sie tatsächlich haben.

Die Validierung nach der Wiederherstellung sollte auf drei Quellen basieren:

A. Die Quelle

Was sagt die maßgebliche Quelle über den betroffenen Zeitraum aus? Relevante Belege können beispielsweise Folgendes umfassen:

• Quelldatensätze
• Transaktions-/Änderungshistorie
• Zeitstempel
• Schlüssel
• Quellenspezifische Protokoll- oder Sequenzinformationen
• Geschäftssummen
• Weitere Belege für das Quellsystem

B. Die Replikationsplattform

Was kann die Plattform über den Hergang des Geschehens anzeigen? Je nach Produkt und Konfiguration kann dies Folgendes umfassen:

• Gespeicherter Neustart-/Prozessstatus
• Status- und Überwachungsinformationen
• Fehler und Diagnose
• Verzögerungs- oder Aufholinformationen
• Unterstützte Vergleichs- oder Validierungsfunktionen
• Weitere plattformspezifische operative Nachweise

C. Das Ziel

Was enthält das Zielsystem aktuell? Je nach Daten und Anwendungsfall müssen Sie möglicherweise Folgendes überprüfen:

• Aufzeichnungen
• Geschäftsschlüssel
• Zählt
• Werte
• Zeitstempel
• Zielausnahmen
• Nachgelagerte Ergebnisse
• Verhalten auf Anwendungsebene

Die stärkste Bestätigung ergibt sich in der Regel aus der Verknüpfung von Erkenntnissen aus diesen verschiedenen Ebenen, anstatt den „Erfolg“ eines Systems als endgültige Antwort zu betrachten.

Beginnen Sie mit einer breiten Betrachtungsweise – aber beschränken Sie sich nicht nur auf die Reihenanzahl.

Zeilenanzahlen sind nützlich. Sie gehören aber auch zu den ersten Dingen, vor denen erfahrene Anwender warnen, da sie nicht als ausreichend angesehen werden sollten. Zwei Datensätze können die gleiche Anzahl an Zeilen haben und trotzdem fehlerhaft sein.
Sie hätten haben können:

• eine fehlende Zeile und eine unerwartete Zeile
• der richtige Schlüssel mit einem falschen Wert
• ein Datensatz, der hätte gelöscht werden sollen, aber immer noch existiert
• ein späteres Update ohne einen zuvor erwarteten Zustand
• Differenzen, die sich in der Gesamtzahl gegenseitig aufheben.

Nutzen Sie daher allgemeine Prüfverfahren, um festzustellen, wo Sie genauer hinschauen sollten. Nützliche allgemeine Prüfverfahren können beispielsweise Folgendes umfassen:

• erwartete Zeilen- oder Datensatzanzahl
• erwartete Änderungsmengen
• Schlüsselbereiche
• Unternehmensgesamtwerte auf hoher Ebene
• Zeitstempel
• unerwartete Ausnahmen
• von der Plattform gemeldeter Status

Eine Abweichung signalisiert sofort, dass etwas untersucht werden muss. Eine Übereinstimmung bedeutet, dass diese Prüfung erfolgreich war. Das heißt aber nicht, dass alles korrekt ist.

Die Anzahl der Reihen ist ein Indikator, kein Garant für einen einwandfreien Gesundheitszustand.

Vergleichen Sie Quelle und Ziel dort, wo es darauf ankommt.

Sobald Sie das Wiederherstellungsfenster und den betroffenen Bereich definiert haben, vergleichen Sie Quelle und Ziel an einem logisch sinnvollen Zeitpunkt. Je nach Umgebung können zur Validierung folgende Methoden verwendet werden:

• Geschäftsschlüssel
• Vergleich auf Rekordniveau
• Ausgewählte Spalten
• Hashwerte oder Prüfsummen, wo angebracht
• Kontrollsummen
• Zeitstempel
• Quell- und Zielwerte
• Plattformunterstützte Vergleichsfunktionen

Ziel ist es nicht unbedingt, jedes Byte jedes Datensatzes zu vergleichen. Vielmehr geht es darum festzustellen, ob die Daten, die am Zielort dargestellt werden sollen, korrekt genug repräsentiert sind, um die erforderliche Schlussfolgerung zu stützen.

Achten Sie auf den Zeitpunkt.

Quelle und Ziel müssen in sinnvollen, logisch kompatiblen Zuständen verglichen werden. Wenn sich die Quelle weiterhin ändert, während das Ziel noch nachzieht, bedeutet eine Differenz nicht automatisch, dass die Wiederherstellung fehlgeschlagen ist. Es kann lediglich bedeuten, dass die beiden Seiten zu unterschiedlichen Zeitpunkten gemessen werden.

Deshalb sind das Erholungsfenster und die Vergleichsgrenze so wichtig.

Wie man die Vollständigkeit der CDC-Replikation von Mainframe zu Cloud nach der Wiederherstellung überprüft: Prüfsummen, Protokollpositionen und Abgleich

Es gibt kein allgemeingültiges Validierungsrezept. Teams kombinieren jedoch häufig verschiedene Nachweisformen, um Daten nach einer CDC-Wiederherstellung auf einem Mainframe zu validieren.

Zählungen und Kontrollsummen: Nützlich, um offensichtliche Unterschiede bei erwarteten Mengen oder Geschäftsaggregaten zu erkennen.

• Gut geeignet für: umfassende Anomalieerkennung.
• Beweist nicht: dass die korrekten Einzeldatensätze oder -werte vorhanden sind.

Schlüssel und Vergleiche auf Datensatzebene: Nützlich, um fehlende, unerwartete oder nicht übereinstimmende Datensätze innerhalb eines definierten Bereichs zu identifizieren.

• Gut geeignet für: das Aufspüren spezifischer Unterschiede.
• Beweist nicht automatisch: die Reihenfolge der Transaktionen oder jede Form der historischen Korrektheit.

Hashwerte oder Prüfsummen: Wo angebracht, können Hashwerte oder Prüfsummen dabei helfen, Wertemengen effizient zu vergleichen.

• Gut geeignet zum Erkennen von Abweichungen zwischen Quell- und Zielwerten.
• Es wird Ihnen nicht automatisch mitgeteilt, warum sie sich unterscheiden oder ob das sequenzspezifische Verhalten korrekt war.

Zeitstempel, Neustartstatus und Positionen im Quellprotokoll: Diese Angaben können helfen, den Zeitraum oder den Verarbeitungsstatus zu bestimmen, der ausgewertet wird. Bei Mainframe-Quellen hängt die genaue Positionsbezeichnung von der zugrunde liegenden Plattform ab.

• Gut geeignet für: die Verankerung der Ermittlungen zur Wiederherstellung der Sicherheit.
• Beweist nicht automatisch, dass die endgültigen Zieldaten korrekt sind.

Plattformdiagnose- und Vergleichsfunktionen Ihre Replikationsplattform kann operative Nachweise oder unterstützte Quell-Ziel-Vergleichsfunktionen bereitstellen.

• Gut geeignet für: Hinzufügen plattformspezifischer Nachweise zum Validierungsprozess.
• Wichtig: Verstehen Sie genau, was die Funktion für Ihre Quell- und Zielplattform abdeckt. Gehen Sie nicht davon aus, dass eine Plattformvergleichsfunktion die Korrektheit in allen Aspekten garantiert.

Validierung auf Geschäftsebene: Prüfen Sie bei kritischen Arbeitsabläufen, ob wichtige Geschäftsdatensätze, Summen, Ereignisse oder Ergebnisse nach der Wiederherstellung noch plausibel sind.

• Gut geeignet zur Feststellung, ob die Daten im relevanten Kontext verwendbar sind.
• Ersetzt nicht: die technische Validierung, sofern ein technischer Nachweis erforderlich ist.

Der am besten zu verteidigende Ansatz ist oft die mehrstufige Validierung: mehrere Prüfungen, die unterschiedliche Fragen beantworten, anstatt einer einzigen Prüfung, die vorgibt, alles zu beantworten.

So erkennen Sie fehlende Transaktionen oder Änderungen nach der CDC-Wiederherstellung

Die Frage der Nutzer ist einfach: „Woher wissen wir, dass nichts übersehen wurde?“

Beginnen Sie mit dem Wiederherstellungsfenster. Vergleichen Sie dann, was das Ziel hätte erreichen sollen, mit dem, was tatsächlich erreicht wurde. Je nach Umgebung kann dies Folgendes umfassen:

• Betroffene Quelldatensätze
• Hochwertige Geschäftsschlüssel
• Veränderung der Aktivitäten während der Lücke
• Zieldatensätze
• Plattformdiagnose
• Unterstützte Ergebnisse des Quell-Ziel-Vergleichs
• Nachgelagerte Folgen

Achten Sie insbesondere auf Daten, die sich während der Unterbrechung oder des Nachholens der Replikation geändert haben.

Warnsignale

• Die erwarteten Datensätze fehlen.
• Die erwarteten Aktualisierungen werden nicht angezeigt.
• Die Gesamtsummen der nachgelagerten Prozesse stimmen nicht mehr überein.
• Plattform- oder Zielsystemausnahmen bleiben ungeklärt.

Bestimmte Transaktionen mit hohem Wert können nicht nachvollzogen werden

Die Schlussfolgerung sollte nicht über die Beweislage hinausgehen. Wenn Sie eine definierte Teilmenge von Tabellen oder einen bestimmten Wiederherstellungszeitraum validiert haben, geben Sie dies an. Eine nachvollziehbare Aussage lautet: „Wir haben die betroffenen Datensätze und den Wiederherstellungszeitraum mithilfe dieser Prüfungen validiert und keine unerklärlichen Abweichungen festgestellt.“

Das ist aussagekräftiger als eine absolute Behauptung, die durch Beweise nicht gestützt wird.

Wie man doppelte oder erneut verarbeitete Änderungen nach einem Pipeline-Neustart identifiziert

Ein Neustart oder eine Wiederherstellung kann Bedenken hinsichtlich der Frage aufwerfen, ob Vorgänge mehrfach verarbeitet wurden. Das genaue Verhalten bei Wiederholungsversuchen und Duplikaten hängt von der Replikationsplattform, der Quelle, dem Ziel und der Konfiguration ab.

Gehen Sie nicht von einer universellen Liefergarantie aus. Ermitteln Sie stattdessen, wo in Ihrer Umgebung doppelte oder wiederholte Anwendungen sichtbar wären. Mögliche Indikatoren sind:

• Unerwartete zusätzliche Datensätze
• Duplikate Geschäftsschlüssel
• Zielbeschränkungsfehler
• Inkonsistente Zählungen
• Wiederkehrende Geschäftsereignisse
• Plattformfehler oder Diagnose
• Anomalien auf Anwendungsebene

Bei Datensätzen ohne natürliche Eindeutigkeitsbeschränkungen können Duplikate schwieriger zu erkennen sein.

Deshalb sollten Teams verstehen, welche Schlüssel oder Geschäftsregeln Duplikate sichtbar machen, bevor es zu einem solchen Vorfall kommt.

Wie man fehlende Löschvorgänge nach der CDC-Wiederherstellung erkennt

Löschvorgänge erfordern eine gesonderte Prüfung, da sie leicht übersehen werden können. Ein Zielsystem kann alle erwarteten Datensätze enthalten und dennoch fehlerhaft sein, weil es Datensätze enthält, die nicht mehr vorhanden sein sollten. In der Praxis wird dieses Problem sehr direkt formuliert: „Datensätze, die in der Quelle gelöscht wurden, befinden sich noch im Zielsystem.“

Wenn während des Wiederherstellungszeitraums Löschvorgänge aufgetreten sind, überprüfen Sie, ob der entsprechende Zielstatus diese korrekt widerspiegelt. Je nach Datenmodell kann dies Folgendes umfassen:

• Überprüfung der betroffenen Geschäftsschlüssel
• Vergleich der Quellen- und Zielpräsenz
• Überprüfung der Ergebnisse des Plattformvergleichs
• Validierung des nachgelagerten Verhaltens, bei dem gelöschte Datensätze von Bedeutung sind

Gehen Sie nicht davon aus, dass ein erfolgreicher Zählvergleich immer fehlende Löschvorgänge aufdeckt.

Wie man veraltete oder fehlerhafte Werte erkennt

Manchmal ist der Datensatz auf beiden Seiten vorhanden. Das Problem besteht darin, dass das Zielsystem die falsche Version davon hat. Achten Sie auf Folgendes:

• Werte, die an der vorgesehenen Vergleichsstelle nicht mit der Quelle übereinstimmen.
• Aktualisierungen aus dem Wiederherstellungsfenster, die nicht angezeigt werden
• Ergebnisse nachgelagerter Prozesse unter Verwendung eines früheren Wertes
• Unterschiede, die sich nicht durch normale Zeitabläufe oder Transformationen erklären lassen

Dies ist deshalb wichtig, weil eine einfache Existenzprüfung erfolgreich sein kann, während das Ziel noch veraltet ist.

Die Frage lautet nicht nur: „Ist der Rekord vorhanden?“ Sondern: „Befindet sich der Rekord in dem Zustand, in dem wir ihn erwarten?“

Wie man nach der Wiederherstellung durch die CDC fehlerhafte Änderungen erkennt

Die Reihenfolge ist bei manchen Arbeitsabläufen wichtiger als bei anderen. Wenn das Geschäftsergebnis von der Reihenfolge abhängt, beantwortet ein Vergleich des Endzustands möglicherweise nicht alle Fragen. In solchen Fällen benötigen Teams unter Umständen zusätzliche Nachweise, die Folgendes ermöglichen:

• Die Quelle
• Das Ziel
• Die Replikationsarchitektur
• Das betroffene Transaktionsmuster
• Die spezifische Bestellanforderung

Gehen Sie nicht davon aus, dass eine Prüfsumme oder der übereinstimmende letzte Zeilenstatus die historische Reihenfolge beweist. Ebenso wenig sollten Sie annehmen, dass jede Arbeitslast eine transaktionsweise Sequenzvalidierung erfordert.

Der richtige Standard ist: Prüfen Sie das Bestellverhalten, das für den betroffenen Geschäftsprozess und die Architektur tatsächlich relevant ist.

Untersuchen Sie Unstimmigkeiten – mitteln Sie sie nicht einfach weg.

Wenn bei einer Validierungsprüfung ein Unterschied festgestellt wird, behandeln Sie dies als Anhaltspunkt für weitere Untersuchungen.

Fragen:

• Ist diese Zeitdifferenz zu erwarten?
• Ist eine Transformation involviert?
• Wurden für den Vergleich äquivalente Quell- und Zielzustände verwendet?
• Hält das Ziel noch hinterher?
• Gibt es einen unerklärlich fehlenden Datensatz?
• Ist etwas vorhanden, das hätte gelöscht werden sollen?
• Wurde eine Änderung mehr als einmal verarbeitet?
• Ist ein Wert veraltet?
• Handelt es sich bei der Diskrepanz um einen Einzelfall oder ist sie Teil eines größeren Musters?

Anschließend ist die geeignete Sanierungsmaßnahme festzulegen. Je nach Gegebenheiten kann dies Folgendes umfassen:

• Korrektur eines identifizierten Datensatzes
• Wiederholung eines Validierungsschritts
• Resynchronisierung der betroffenen Daten
• Durchführung einer umfassenderen Resynchronisierung
• Die nachgelagerte Nutzung sollte so lange eingeschränkt bleiben, bis das Problem verstanden ist.

Lassen Sie nicht zu, dass eine große Anzahl erfolgreicher Prüfungen eine unerklärliche Diskrepanz in geschäftskritischen Daten verschleiert.

Erstellen Sie einen Nachweisbericht nach der Wiederherstellung

Das Team, das den Vorfall bearbeitet hat, weiß heute vielleicht genau, was passiert ist. Drei Monate später fragt sich vielleicht jemand anderes: „Woher wussten wir, dass die Daten wieder sicher verwendet werden konnten?“

Zwingen Sie sie nicht, die Antwort aus dem Gedächtnis zu rekonstruieren. Erstellen Sie ein prägnantes Protokoll der Beweisführung nach der Wiederherstellung, das Folgendes enthält:

Vorfallzeitraum: Wann war die Replikation beeinträchtigt?

Wiederherstellungspunkt: Wo wurde die Verarbeitung wieder aufgenommen? Verwenden Sie dabei die für die Quelle und Plattform angemessene Terminologie.

Betroffener Umfang: Welche Quellen, Ziele, Datensätze, Tabellen, Dateien oder nachgelagerten Prozesse waren betroffen?

Wiederherstellungsmethode: Welcher Wiederherstellungspfad wurde verwendet? Zum Beispiel:

• Neustart aus dem gespeicherten Zustand
• Aufholen
• Gezielte Resynchronisation
• Umfassendere Resynchronisierung oder Neuladung

Durchgeführte Validierung: Welche Prüfungen wurden durchgeführt? Dokumentieren Sie jede wichtige Prüfung:

• Was wurde untersucht?
• Welcher Zeitraum oder welcher Umfang wurde abgedeckt?
• Wozu diente die Überprüfung?

Ergebnisse: Was hat das Team beobachtet? Wurden Unstimmigkeiten festgestellt?

Korrekturmaßnahmen: Was wurde korrigiert, neu verarbeitet oder neu synchronisiert?

Ausnahmen: Was bleibt ungeklärt oder liegt außerhalb des validierten Bereichs?

Schlussfolgerung: Welche Belege stützen die Entscheidung, dass die relevanten nachgelagerten Daten zur Verwendung bereit sind?

Dieser Datensatz kann Folgendes unterstützen:

• Vorfallsanalyse
• Übergabe der Operationen
• Downstream-Kommunikation
• Governance  
• Prüfung
• Zukünftige Fehlerbehebung
• Verbesserung des Wiederherstellungs-Runbooks

Wer gibt die Entwarnung?

Dies ist eine operative Frage, die Teams oft erst dann beantworten, wenn der Druck am größten ist. Jemand muss entscheiden, ob die Daten wieder einsatzbereit sind. Diese Entscheidung kann mehr als nur die Person betreffen, die die Pipeline neu gestartet hat. Je nach Vorfall kann die Mitwirkung folgender Personen erforderlich sein:

• Das Replikations- oder Datenengineering-Team
• Der Besitzer des Quellsystems
• Der Inhaber der nachgelagerten Plattform oder Anwendung
• Datenoperationen
• Ein Geschäftsinhaber
• Governance-, Risiko- oder eine andere Kontrollfunktion

Der genaue Freigabeprozess sollte die Bedeutung der betroffenen Daten widerspiegeln.

Das Schlüsselprinzip: Das technische Team sollte Folgendes erklären können:

• Was war betroffen?
• Was wurde validiert?
• Was die Kontrollen festgestellt haben
• Was weiterhin ungewiss bleibt
• Welche Ausnahmen gibt es noch?

Dann können die für die nachgelagerte Nutzung Verantwortlichen eine fundierte Entscheidung treffen.

Wie teilt man nachgelagerten Teams mit, dass die Daten wieder verfügbar sind?

Vermeiden Sie beide Extreme. Behaupten Sie nicht, alles sei in Ordnung, wenn Ihre Beweise diese Aussage nicht stützen.

Aber überlassen Sie einem Geschäftspartner auch nicht einfach ein technisches Störungsprotokoll. Kommunizieren Sie vier Dinge klar und deutlich:

• Was geschah: Die Replikation wurde während eines definierten Zeitraums unterbrochen oder blieb hinter den Erwartungen zurück.
• Was war betroffen: Identifizieren Sie die relevanten nachgelagerten Daten oder Systeme.
• Was wurde geprüft? Erläutern Sie den Umfang der durchgeführten Prüfungen.
• Was noch aussteht: Geben Sie alle offenen Ausnahmen, Einschränkungen oder Folgearbeiten an.

Die nützlichste Botschaft lautet etwa so:

Die Replikation wurde abgeschlossen. Wir haben die betroffenen Daten für den Vorfallzeitraum anhand der hier beschriebenen Prüfungen validiert. Wir haben [keine unerklärlichen Unterschiede / die identifizierten Unterschiede wurden behoben]. Diese nachgelagerten Datensätze können nun verwendet werden. Etwaige Ausnahmen bleiben weiterhin offen.

Die Formulierung muss den Beweisen entsprechen. Nur so kann man Vertrauen wiederherstellen, ohne die Existenz von Unsicherheit zu leugnen.

Eine grüne Pipeline ist keine Validierungsstrategie

Ein häufig auftretender Fehler nach einer Wiederherstellung ist, den Status „Betriebsbereit“ beizubehalten: Der Prozess läuft. Die Verzögerung ist wieder normal. Das Dashboard ist grün.

Alle wollen die Brückenverbindung schließen. Doch keines dieser Signale allein beweist, dass die betroffenen Zieldaten korrekt sind.

Die entscheidende Frage lautet: „Auf welche Beweise stützen wir uns, wenn wir den Menschen sagen, dass sie diesen Daten wieder vertrauen können?“

Wenn die Antwort unklar ist, ist der Vorfall noch nicht beendet.

Wie man die Validierungsfähigkeiten nach der Wiederherstellung bewertet

Nicht alle CDC-Plattformen liefern nach einer Unterbrechung den gleichen Nachweisstandard. Einige Funktionen sind Standard. Andere können den Aufwand, die Unsicherheit und das Risiko beim Nachweis einer erfolgreichen Wiederherstellung erheblich reduzieren.

Grundvoraussetzungen

Alle unternehmensweiten CDC-Plattformen sollten Folgendes bieten:

• Informationen zum Neustart oder zum Prozessstatus
• Betriebszustand und Überwachung
• Fehler- und Diagnoseinformationen
• Einblick in die Aufholaktivitäten
• Grundlegende Wiederherstellungsverfahren für unterstützte Umgebungen

Diese Funktionen helfen Teams bei der Beantwortung folgender Fragen: Konnte die Replikation wiederhergestellt und die Verarbeitung fortgesetzt werden?

Die schwierigere Frage lautet: Können wir beweisen, dass die wiederhergestellten Daten vertrauenswürdig sind?

Wichtige Funktionen, die nicht immer enthalten sind

• Vergleichsfunktion zwischen Quelle und Ziel
• Einblick in die Wiederherstellungsposition und den Verarbeitungsverlauf
• Unterstützung für die Aufarbeitung historischer Ereignisse, sofern historische Bestände vorhanden sind
• Aussagekräftige Diagnoseverfahren zur Unterstützung der Ursachenforschung
• Nachweise für die Überprüfung und Validierung im Wiederherstellungszustand
• Einblick in die bei der Abstimmung festgestellten Diskrepanzen
• Unterstützung für die effiziente Validierung großer Datensätze
• Dokumentation und Berichterstattung zur Unterstützung von Prüfungs-, Governance- oder nachgelagerten Genehmigungsanforderungen

Diese Funktionen bestimmen, wie viel manuelle Untersuchung erforderlich ist, bevor Teams die Wiederherstellung mit Sicherheit als abgeschlossen erklären können. Keine einzelne Funktion sollte als universeller Beweis für eine erfolgreiche Wiederherstellung gelten. Die entscheidende Frage lautet: „Welche Nachweise liefert diese Plattform unserem Team nach einem Wiederherstellungsereignis, und welche zusätzliche Validierung benötigen wir noch?“

Fragen, die Sie jedem CDC-Anbieter stellen sollten

Bitten Sie den Anbieter um eine Vorführung:

• Welcher Neustart- oder Prozessstatus ist nach einer Unterbrechung sichtbar?
• Welche Überwachungs- und Diagnoseinformationen können die Bediener einsehen?
• Wie unterstützt die Plattform das Aufholen nach einer Störung?
• Welche Vergleichsmöglichkeiten zwischen Quelle und Ziel stehen zur Verfügung?
• Welche Unterschiede können diese Vergleichsmöglichkeiten tatsächlich aufzeigen?
• Wo liegen die Grenzen dieser Fähigkeiten?
• Wie fügen sich diese Fähigkeiten in einen umfassenderen Validierungsprozess ein?
• Welche Beweise können Teams aufbewahren, um eine Entwarnung zu geben?

Für jede CDC-Plattform sollte derselbe Standard gelten: Die Aussage „Der Prozess wurde neu gestartet“ reicht nicht als Beweis aus. Fragen Sie sich, was die Bediener anschließend überprüfen, vergleichen, testen und begründen können.

Wie Rocket Data Replicate & Sync passt

Rocket Data Replicate & Sync (RDRS) beinhaltet Funktionen, die zur Untersuchung und Validierung nach der Wiederherstellung für unterstützte Konfigurationen beitragen können.

Zu den dokumentierten RDRS-Funktionen gehören:

• Gespeicherter Prozess und Neustartstatus
• Überwachungs- und Diagnoseinformationen
• Stapelvergleichsfunktion für unterstützte Quellen
• Unterstützung der Verarbeitung archivierter Protokolle für unterstützte protokollbasierte Umgebungen, in denen der erforderliche Verlauf erhalten bleibt

Diese Funktionen können im Rahmen einer Wiederherstellungsuntersuchung operative und Validierungsnachweise liefern. Wie bei jeder CDC-Plattform sollten Organisationen RDRS anhand ihrer spezifischen Quellen, Ziele, Konfigurationen, Wiederherstellungsanforderungen und Betriebsabläufe evaluieren. Die wichtigste Frage lautet: „Welche Nachweise kann RDRS in den Wiederherstellungsszenarien liefern, denen unsere Umgebung am ehesten ausgesetzt sein wird?“

Checkliste zur Validierung nach der Wiederherstellung

Bevor Sie nachgelagerten Nutzern mitteilen, dass die Daten wieder verfügbar sind, bestätigen Sie Folgendes:

• Das Wiederherstellungsfenster ist klar definiert.
• Die betroffenen Quellen, Ziele und nachgelagerten Verbraucher sind bekannt.
• Der Bearbeitungsrückstand wurde aufgearbeitet oder der verbleibende Status ist bekannt.
• Relevante Quellen-, Replikationsplattform- und Zielnachweise wurden geprüft.
• Die Validierung ging über den reinen Prozessstatus hinaus.
• Allgemeine Überprüfungen wie Zählungen oder Summen wurden nicht als allgemeingültiger Beweis angesehen.
• Wichtige Aufzeichnungen, Werte oder Geschäftsschlüssel wurden gegebenenfalls verglichen.
• Fehlende Änderungen wurden berücksichtigt.
• Doppelte oder wiederholte Änderungen wurden gegebenenfalls berücksichtigt.
• Es wurden auch Löschungen berücksichtigt, die während des Wiederherstellungszeitraums erfolgten.
• Veraltete oder fehlerhafte Werte wurden berücksichtigt.
• Die Reihenfolge wurde dort bewertet, wo es auf die Abfolge ankommt.
• Ungeklärte Abweichungen wurden untersucht.
• Sämtliche Korrekturmaßnahmen oder Resynchronisierungen wurden dokumentiert.
• Die übrigen Ausnahmen sind explizit aufgeführt.
• Die nachgelagerten Eigentümer wissen, was sicher zu verwenden ist.
• Die Beweise, die die Entwarnung stützen, wurden dokumentiert.

Fazit

Die Wiederherstellung der Pipeline ist nur die halbe Miete. Die schwierigere Frage lautet: „Wie beweisen wir, dass die Daten korrekt sind?“

Definieren Sie zunächst den Wiederherstellungszeitraum. Ermitteln Sie, was betroffen war. Nutzen Sie Beweise aus der Quelle, der Replikationsplattform, dem Zielsystem und der nachgelagerten Umgebung. Suchen Sie gezielt nach fehlenden Änderungen, Duplikaten, fehlenden Löschvorgängen, veralteten Werten und Reihenfolgeproblemen, wo diese relevant sind. Untersuchen Sie Abweichungen, anstatt sie als harmlos abzutun. Hinterlassen Sie ausreichend Beweise, damit auch Personen, die nicht an der Störungsbesprechung teilgenommen haben, nachvollziehen können, warum das Zielsystem wieder freigegeben wurde.

Weil:

Wieder laufen zu können ist nicht dasselbe wie genesen zu sein.
Eine grüne Pipeline bedeutet nicht, dass die Daten vertrauenswürdig sind.

Die Wiederherstellung ist abgeschlossen, wenn der Prozess stabil ist und die Organisation über genügend Beweise verfügt, um den Daten wieder vertrauen zu können.

*NIST SP 1800-26: Datenintegrität, Erkennung und Reaktion auf destruktive Ereignisse

Nächster Schritt: Ist Ihre aktuelle Plattform für die Wiederherstellung ausreichend?

Wenn die Wiederherstellung wiederholt von manueller Validierung, Stammeswissen, teamübergreifenden Untersuchungen oder Unsicherheit darüber, was während der Lücke passiert ist, abhängt, könnte die nächste Frage größer sein als der Vorfall selbst.

Wie man die Wiederherstellungsfunktionen von Enterprise CDC bewertet, wenn Datenverlust nicht akzeptabel ist

Nutzen Sie den Bewertungsrahmen, um festzulegen, was Ihre Plattform sichtbar, testbar und nachweisbar machen sollte, bevor der nächste Fehler auftritt.