Woran erkennt man, dass die Erstattungsansprüche eines CDC-Anbieters Bestand haben?

Testen Sie Neustartstatus, Aufholfunktionen, Validierung, Wiedergabeverhalten, Diagnosefunktionen und Wiederherstellungsgrenzen, bevor Sie sich für eine CDC-Plattform entscheiden.

Die meisten CDC-Demonstrationen zeigen, dass der Prozess wie geplant funktioniert. Daten werden übertragen. Das Zielsystem wird aktualisiert. Das Dashboard bleibt grün. Eine Wiederherstellungsbewertung der CDC muss jedoch eine andere Frage klären:

Was passiert, wenn der Weg abbricht?

Die AWS-Richtlinien für gut strukturierte Architekturen empfehlen, die Ausfallsicherheit unter widrigen Bedingungen in Umgebungen zu testen, die der Produktionsumgebung so nahe wie möglich kommen. Sie warnen davor, Ausfallsicherheit zu implementieren, ohne vorher zu überprüfen, wie sich die Arbeitslast bei Fehlern und unerwarteter Last verhält.*

Ein Plattform-Proof-of-Concept (POC) gibt Ihrem Team die Möglichkeit zu beobachten, wie sich das System verhält, wenn die Replikation hinterherhinkt, während der aktiven Verarbeitung stoppt, den unmittelbaren Zugriff auf die erforderliche Quellhistorie verliert oder nachgewiesen werden muss, dass das wiederhergestellte Ziel korrekt ist.

Ziel ist es nicht, einen künstlichen Fehler zu erzeugen, der in der Produktion niemals auftreten würde. Vielmehr geht es darum zu bewerten, ob die Plattform die Wiederherstellung unter Bedingungen ermöglicht, die Ihrer Umgebung entsprechen und somit sichtbar, testbar und nachvollziehbar sind.

Kurzantwort: Wie sollte man die CDC-Wiederherstellung während eines POC testen?

Ein praxisorientierter CDC-Wiederherstellungs-POC sollte acht Bereiche testen:

1. Transparenz von Verzögerungen und Rückständen
2. Sichtbarkeit von Neustart und Wiederherstellungszustand
3. Historischer Aufholprozess
4. Aufholprozesse und stockende Erholung
5. Diagnose und Nachweis von Leistungsversagen
6. Validierung nach der Wiederherstellung
7. Auswirkungen der Wiedergabe und der nachgelagerten Verbraucher
8. Wiederherstellungsgrenzen und Resynchronisierungsgrenzen

Für jeden Test sollte geprüft werden, welche Bedingungen eingeführt wurden, was die Bediener beobachten konnten, welchen Zustand die Plattform beibehalten hat, was während der Wiederherstellung geschah, welche Spuren anschließend zurückblieben und was die Plattform nicht feststellen konnte. Jede Schlussfolgerung sollte mit der Quelle, dem Ziel, der Topologie, der Version, der Konfiguration und dem getesteten Fehlerszenario verknüpft sein.

Der Standard ist einfach: Zeigen Sie uns, was passiert, wenn der Pfad abbricht. Zeigen Sie uns dann, woran wir erkennen können, dass die Wiederherstellung erfolgreich war.

Vor dem Proof of Concept: Beginnen Sie mit den Lücken, die Sie testen müssen.

Das Erreichen dieser Phase bedeutet wahrscheinlich, dass Sie bereits festgestellt haben, dass die Wiederherstellung einer genaueren Prüfung bedarf. Wiederholen Sie nicht die gesamte Bereitschaftsanalyse innerhalb des Proof of Concept (POC). Übertragen Sie stattdessen die dokumentierten Schwachstellen der aktuellen Umgebung in den Testplan.

Falls diese Lücken noch nicht dokumentiert wurden, beginnen Sie mit der Frage: Wann wird ein CDC-Wiederherstellungsproblem zu einem Plattformproblem ? Dokumentieren Sie die Wiederherstellungslücken in der aktuellen Umgebung, bevor Sie den POC definieren.

Definieren Sie anschließend die Umgebung, die der Proof of Concept (POC) repräsentieren soll. Dokumentieren Sie mindestens Folgendes:

• Quell- und Zieltechnologien und -versionen
• Methoden erfassen und anwenden
• Replikationstopologie
• Normale und Spitzen-Transaktionsraten
• Richtlinien für Quellprotokollierung, Journal oder Aufbewahrungshistorie
• Netzwerk- und Zielbedingungen
• Anforderungen an Transformation und unterstützte Schemaänderungen
• Wiederherstellungsziele und inakzeptable Szenarien für Neuladen oder Resynchronisierung
• Nachgelagerte Verbraucher, Wiedergabeempfindlichkeit und geschäftliche Abhängigkeiten

Eine allgemeine Demonstration liefert nur begrenzte Beweise.

Die entscheidende Frage lautet nicht: Unterstützt die Plattform die Wiederherstellung? Sondern: Wie funktioniert die Wiederherstellung für unsere Quell-, Ziel-, Konfigurations-, Arbeitslast- und Betriebsanforderungen?

Von Fähigkeiten zu Beweisen

Funktionsbezeichnungen sind kein Beweis. Die folgenden Tests verlagern die Diskussion von „Unterstützen Sie das?“ hin zu „Zeigen Sie uns, wie es funktioniert, wenn eine Wiederherstellung erforderlich ist.“

POC-Test 1: Replikation hinterherhinken lassen

Es soll eine kontrollierte Umgebung geschaffen werden, in der die Replikation zwar aktiv bleibt, aber nicht mit der Quellaktivität Schritt halten kann. Ziel ist es, festzustellen, ob die Bediener zwischen normalem Betrieb, zunehmender Verzögerung, fortschreitender Aufholung und stockender Aufholung unterscheiden können.

Bitten Sie den Anbieter, das Ausmaß der Verzögerung, die Größe und Richtung des Rückstands, den Ort der Verzögerung, den Fortschritt der Verarbeitung und die Auswirkungen auf die Offenlegung der Quellhistorie bei zunehmender Verzögerung aufzuzeigen.

Was für eine starke Demonstration zeigt

Sowohl das Ausmaß als auch die Richtung des Problems sind sichtbar. Die Bediener müssen den Fortschritt der Wiederherstellung nicht anhand einer grünen Statusanzeige ableiten. Sie können erkennen, wie weit der Fortschritt hinter dem Ziel zurückliegt, wo die Verzögerung auftritt und ob sich die Bedingungen verbessern.

POC-Test 2: Replikation während der aktiven Verarbeitung stoppen

Führen Sie eine sichere, unterstützte Unterbrechung ein, während Transaktionen aktiv ausgeführt werden. Ein ordnungsgemäßes Herunterfahren mag zwar das normale Neustartverhalten demonstrieren, zeigt aber möglicherweise nicht, was bei einer abrupten Beendigung, einer Netzwerkunterbrechung, einem Zielsystemausfall oder einem anderen realistischen Ereignis geschieht.

Bitten Sie den Anbieter, Ihnen zu zeigen, welcher Neustart- oder Prozessstatus beibehalten wurde, was die einzelnen Markierungen bedeuten, wo die Verarbeitung voraussichtlich wieder aufgenommen wird, welche Transaktionsgrenze gilt und ob die Arbeit wiederholt oder neu verarbeitet werden kann.

Was für eine starke Demonstration zeigt

Die Bediener können den relevanten Status vor dem Neustart überprüfen und nachvollziehen, wie die Plattform vorgehen wird. Der Anbieter kann die Status „Quellerfassung“, „Verarbeitung“, „Transport“ und „Zielanwendung“ unterscheiden, sofern diese Unterscheidungen relevant sind.

POC-Test 3: Test der Unterstützung für die historische Wiederherstellung

Bei protokollbasierter CDC können die akkumulierten Änderungen von aktiven Protokollen, archivierten Protokollen, Journalen oder anderen gespeicherten Quellhistorien abhängen. Testen Sie die Abhängigkeitskette unter dem Aufbewahrungsmodell, das in Ihrer Produktionsumgebung verwendet wird.

Bitten Sie den Anbieter um eine Erläuterung, welche Historie benötigt wird, wo sie gespeichert ist, wer die Aufbewahrung kontrolliert, wie sie abgerufen wird, ob die Plattform sie direkt verarbeiten kann und wo die unterstützte Wiederherstellungsgrenze endet.

Was für eine starke Demonstration zeigt

Der Anbieter demonstriert, wie die Plattform die benötigten Verlaufsdaten findet und verarbeitet und welche Bereiche die Bediener überwachen können. Die Antwort ist spezifisch für die Quelle und Konfiguration und keine allgemeine Aussage darüber, dass die Wiederherstellung archivierter Protokolle unterstützt wird.

POC-Test 4: Einen ins Stocken geratenen Aufholprozess erzeugen

Beginnen Sie mit dem Aufholprozess und schränken Sie anschließend die Quell-, Netzwerk-, Anwendungs- oder Zielbedingungen so ein, dass die bestehende Lücke nicht weiter schrumpft oder sich vergrößert. Dies testet, ob die Plattform zwischen Aktivität und tatsächlichem Fortschritt unterscheidet.

Bitten Sie den Anbieter, die Richtung des Auftragsrückstands, die aktuellen Bearbeitungs- und Anwendungsraten, den Fortschritt der Positionen, Wiederholungsversuche oder Drosselungen, die Auswirkungen auf Quelle und Ziel sowie die Grundlage für jede Fertigstellungsschätzung darzulegen.

Was für eine starke Demonstration zeigt

Fortschritte und Stillstand bei der Aufholjagd unterscheiden sich deutlich. Die Bediener können erkennen, ob sich die Lücke schließt, gleich bleibt oder sich vergrößert, und die Fertigstellungsprognosen basieren auf den beobachteten Bedingungen und nicht auf dem theoretischen Durchsatz.

POC-Test 5: Nachweise für Fehlfunktionen sichern und untersuchen

Lösen Sie einen repräsentativen Quell-, Netzwerk-, Replikations- oder Zielausfall aus und bewerten Sie, welche Beweise vor und nach dem Neustart noch verfügbar sind.

Bitten Sie den Anbieter, Ihnen zu demonstrieren, wie die Bediener den Fehler untersuchen, wie Verarbeitungskontext und Fehler korreliert werden, wie lange Beweismittel aufbewahrt werden, was exportiert werden kann und welche zusätzlichen Quell-, Netzwerk- oder Zielnachweise noch benötigt werden.

Was für eine starke Demonstration zeigt

Die Bediener können nachvollziehen, welche Daten die Pipeline verarbeitet hat, wie sich Verzögerung oder Durchsatz verändert haben, welche Komponente den Fehler verursacht hat, welcher Zustand danach bestand und welche Wiederherstellungsmaßnahmen ergriffen wurden. Wichtige Informationen gehen beim Neustart des Prozesses nicht einfach verloren.

POC-Test 6: Validieren Sie das wiederhergestellte Ziel

Ein erfolgreicher Neustart beweist, dass die Replikation wiederaufgenommen wurde. Er beweist jedoch nicht, dass das Ziel vollständig, aktuell und korrekt ist. Bekannte Diskrepanzen sollten, wo immer möglich und sicher, berücksichtigt werden, beispielsweise fehlende Einfügungen oder Aktualisierungen, unerwartete Datensätze, Duplikate, fehlende Löschvorgänge, veraltete Werte, Unterschiede in Transformationen oder Reihenfolgeprobleme, bei denen die Reihenfolge wichtig ist.

Bitten Sie den Anbieter, Ihnen zu demonstrieren, wie Unterschiede zwischen Quelle und Ziel identifiziert werden, welche Objekte oder Vorfallfenster erfasst werden können, welche Schlüssel und Werte verglichen werden, wie Abweichungen dargestellt werden und welche zusätzliche Validierung weiterhin in der Verantwortung des Betriebsteams liegt.

Was für eine starke Demonstration zeigt

Die Plattform identifiziert spezifische Unterschiede und erläutert klar, was der Vergleich beweist und was nicht. Eine übereinstimmende Zeilenanzahl oder ein abgeschlossener Prozess werden nicht als allgemeingültiger Beweis für Integrität dargestellt.

POC-Test 7: Testwiederholung und Auswirkungen auf nachgelagerte Verbraucher

Änderungen während einer Unterbrechung sammeln und im Anschluss verarbeiten. Wiederholempfindliche Ereignistypen einbeziehen, sofern dies sicher ist. Wiederholvorgänge sind nicht per se problematisch, wohl aber unsichtbare oder schlecht verstandene.

Bitten Sie den Anbieter, das Wiedergabefenster, die betroffenen Datensätze oder Ereignistypen, das erwartete Volumen und die Rate, das Wiederholungs- oder wiederholte Verarbeitungsverhalten, die Reihenfolgeüberlegungen und die nach dem Aufholen verbleibenden Beweise anzuzeigen.

Warum Idempotenz wichtig ist

Eine Replikationsplattform kann eine Zahlungs-, Benachrichtigungs-, Inventar- oder Workflow-Anwendung nicht idempotent machen. Sie kann jedoch genügend Informationen bereitstellen, damit nachgelagerte Teams entscheiden können, ob Unterdrückung, Deduplizierung, Sequenzierung oder koordinierte Aktivierung erforderlich ist.

Was für eine starke Demonstration zeigt

Die Wiedergabe ist sichtbar und nachvollziehbar. Nachgelagerte Teams können abschätzen, was wann eintrifft, erkennen, ob wiederholte Verarbeitungsvorgänge auftreten können, und beurteilen, ob verbraucherseitige Schutzmaßnahmen erforderlich sind.

POC-Test 8: Nachweis der Wiederherstellungsgrenze

Jede CDC-Plattform kennt Situationen, in denen ein Neustart oder das Aufholen nicht zielführend ist. Eine gezielte oder umfassendere Resynchronisierung oder ein vollständiger Neustart kann erforderlich sein, wenn der Wiederherstellungsstatus nicht verfügbar ist, der notwendige Quellverlauf nicht verarbeitet werden kann, das Ziel inkonsistent ist, nicht unterstützte Änderungen aufgetreten sind oder die Validierung erhebliche Diskrepanzen aufdeckt.

Bitten Sie den Anbieter, zu erläutern, welche Szenarien einen Neustart, das Aufholen historischer Daten, eine gezielte Resynchronisierung, eine umfassendere Resynchronisierung oder ein Neuladen unterstützen und welche Anzeichen den Betreibern zeigen, dass der normale Wiederherstellungspfad nicht mehr anwendbar ist.

Was für eine starke Demonstration zeigt

Die Antwort ist präzise, ​​qualifiziert und auf die vorgeschlagene Umgebung abgestimmt. Eine ehrliche Festlegung einer Wiederherstellungsgrenze ist ein Zeichen von Reife, nicht von Schwäche.

Dokumentieren Sie, was der POC tatsächlich bewiesen hat.

Ein sorgfältig durchgeführter Proof of Concept (POC) sollte mehr als Screenshots, Besprechungsnotizen und die Bestätigung des erfolgreichen Tests dokumentieren. Für jedes Szenario sollten die Testbedingungen, die beobachteten Ergebnisse, das Wiederherstellungsergebnis, die Bewertung, die Einschränkungen und die erforderlichen Folgemaßnahmen erfasst werden.

Ziel ist es nicht, eine allgemeine Wiederherstellungsbewertung zu vergeben. Vielmehr geht es darum festzustellen, ob die Plattform unter den von Ihnen getesteten Bedingungen die für Ihre Umgebung erforderlichen Fähigkeiten unter Beweis gestellt hat.

Verwenden Sie das CDC Recovery POC-Evaluierungsarbeitsblatt . Das Arbeitsblatt dient als Dokumentation für die Evaluierung. Verwenden Sie es, um:

• Definieren Sie Quelle, Ziel, Topologie, Arbeitslast, Aufbewahrungsmodell und Wiederherstellungsziele.
• Planen Sie die acht Wiederherstellungsszenarien
• Erfassen Sie beobachtbares Verhalten und gespeicherte Beweise
• Bewerten Sie die Fähigkeiten wie folgt: Nachgewiesen, Teilweise nachgewiesen, Nicht nachgewiesen oder Nicht zutreffend
• Dokumentbeschränkungen, Abhängigkeiten und offene Fragen
• Vergleichen Sie Anbieter nur unter gleichwertigen Bedingungen.
• Untermauern Sie die abschließende Empfehlung mit Belegen.

Eine Funktion sollte nicht allein aufgrund von Produktdokumentation, Präsentationsmaterial oder mündlicher Erklärung als „nachgewiesen“ gekennzeichnet werden. Die Bewertung sollte vielmehr das beobachtbare Verhalten und die aus der getesteten Konfiguration gewonnenen Erkenntnisse widerspiegeln.

Könnte unser reguläres Betriebsteam die hier vorgelegten Beweise nutzen, um den Fehler zu verstehen, die Wiederherstellung zu steuern und die Entwarnung zu verteidigen, ohne sich vollständig auf den Anbieter oder einen einzelnen internen Spezialisten zu verlassen?

Häufige Fehler der CDC-Erholungsbeauftragten

Es genügt, nur den Normalfall zu testen: Ein erfolgreicher initialer Lasttest und ein stabiler Replikationstest stellen die grundlegende Funktionalität sicher. Sie geben jedoch keinen Aufschluss über das Wiederherstellungsverhalten. Daher sollten auch Szenarien mit kontrollierter Verzögerung, Unterbrechung, Aufholprozess, Validierung und Wiederherstellungsgrenzen berücksichtigt werden.

Ausschließlich saubere Herunterfahrvorgänge verwenden: Saubere Herunterfahrvorgänge zeigen möglicherweise nicht dasselbe Neustartverhalten, Transaktionsverhalten, Diagnoseverhalten oder Wiederholungsverhalten wie abrupte Unterbrechungen. Untersucht werden unterstützte Fehlerbedingungen, die ein realistisches Produktionsrisiko widerspiegeln.

Die Verwendung von Bezeichnungen ohne Definitionen ist problematisch: Begriffe wie „genau einmal“, „kein Datenverlust“, „Selbstheilung“, „automatische Wiederherstellung“, „nahtloses Aufholen“ und „integrierte Validierung“ können plattformübergreifend unterschiedliche Verhaltensweisen beschreiben. Eine Definition, die mit der getesteten Konfiguration und dem Fehlerszenario verknüpft ist, ist erforderlich.

Der Status eines Prozesses wird nicht als Beweis für die Wiederherstellung gewertet: Ein laufender Prozess bedeutet nicht, dass der Fehler behoben ist. Ein behobener Fehler bedeutet nicht, dass der Prozess validiert ist. Eine Validierung innerhalb eines bestimmten Bereichs beweist nicht die Korrektheit in allen Dimensionen.

Keine bekannten Diskrepanzen einbeziehen: Wenn jeder Test mit korrekten Daten beginnt und endet, zeigt der Proof of Concept nicht, was die Plattform bei Fehlern erkennen kann. Fehlende, unerwartete, gelöschte, veraltete oder doppelte Daten sollten nach Möglichkeit einbezogen werden.

Ignorieren des nachgelagerten Verhaltens: Die Wiederherstellung endet nicht an der Zieltabelle. Verzögerte und wiederholte Änderungen können nachgelagerte Anwendungen, Ereignisse, Benachrichtigungen, Zahlungen, Workflows oder Entscheidungen auslösen.

Nicht dokumentiert, was nicht demonstriert wurde: Eine unbeantwortete Frage sollte nicht stillschweigend als vorausgesetzte Fähigkeit gelten. Dokumentieren Sie dies wie folgt:

Die Erstattungsansprüche auf den Prüfstand stellen

Ein CDC-POC sollte mehr als nur die erfolgreiche Replikation unter normalen Bedingungen demonstrieren. Er sollte aufzeigen, was die Bediener sehen, wenn die Pipeline in Verzug gerät, welcher Wiederherstellungszustand nach einem Fehler verbleibt, wo die Verarbeitung fortgesetzt werden kann, wovon die bisherige Wiederherstellung abhängt, wie der Aufholfortschritt gemessen wird, welche Diagnosedaten erhalten bleiben, wie das Ziel validiert wird, welche Bedeutung die Wiedergabe für nachgelagerte Verbraucher hat und wo der unterstützte Wiederherstellungspfad endet.

Führen Sie dieselben Tests auf jeder Plattform durch, auch auf derjenigen, die bereits in Ihrer Umgebung im Einsatz ist. Die Wiederherstellungsfähigkeit sollte nicht allein aufgrund eines Funktionsnamens oder einer gelungenen Demonstration angenommen werden. Sie muss durch beobachtbares Verhalten und dokumentierte Nachweise belegt werden.

Zeigen Sie uns, was passiert, wenn der Pfad abbricht. Zeigen Sie uns dann, woran wir erkennen können, dass die Wiederherstellung erfolgreich war.
 

*AWS Well-Architected: Test der Ausfallsicherheit mittels Chaos Engineering November 2024