Ein Backfill kann fehlende Daten in einem verbundenen System ergänzen. Er kann jedoch auch Aktionen wiederholen, die über das bloße Speichern von Datensätzen hinausgehen. Legen Sie vor dem Start fest, welche Daten erneut verarbeitet werden, welches System maßgeblich ist und welche Nebenwirkungen ausgelöst werden könnten. Ziel ist nicht, einfach alte Daten zu übertragen, sondern eine nachweisbare Abweichung zu beheben, ohne den laufenden Betrieb zu stören.
Backfill, Migration und erneuter Versuch: drei verschiedene Aufgaben
Bei einem Backfill wird eine abgegrenzte Menge historischer Daten erneut verarbeitet, um Informationen in einem verbundenen System zu ergänzen oder zu korrigieren. So können beispielsweise Datensätze übertragen werden, die vor der Aktivierung einer Integration entstanden sind, oder ein Feld ergänzt werden, das zuvor nicht mitgesendet wurde.
Eine Migration hingegen überträgt Daten zwischen Systemen oder ändert deren Struktur, Modell oder Ziel. Sie kann einen Backfill als Teil des Vorhabens einschließen, umfasst aber üblicherweise weitere Entscheidungen zu Transformationen, Feldzuordnungen und dem parallelen Betrieb mehrerer Systeme. Bei einem erneuten Versuch für fehlgeschlagene Ereignisse werden konkrete, nicht abgeschlossene Vorgänge erneut verarbeitet, die normalerweise anhand eines Fehlers oder einer ausstehenden Warteschlange identifiziert werden. Das ist nicht dasselbe, wie den gesamten Datenbestand erneut zu durchlaufen.
Diese Unterscheidung hilft bei der Wahl der passenden Lösung. Fehlen Datensätze, weil sie nie übertragen wurden, kann ein Backfill erforderlich sein. Sind die Daten im empfangenden System vorhanden und muss nur ihre Struktur geändert werden, handelt es sich um eine Migration. Gibt es Ereignisse mit bekannten Fehlern, sollten Sie zunächst diese beheben und die Ereignisse erneut versuchen, anstatt sämtliche historischen Datensätze erneut zu senden.
Entscheiden, ob eine erneute Verarbeitung sinnvoll ist
Beschreiben Sie das Problem zunächst als beobachtbare Abweichung: Welche Daten fehlen, wo sollten sie vorhanden sein und seit wann? Enthält das Quellsystem den richtigen Wert, während er im Zielsystem fehlt, kann ein Backfill sinnvoll sein. Ist der Wert bereits in der Quelle falsch, wird die Übertragung desselben Werts das Problem lediglich kopieren. Korrigieren Sie ihn zuerst in der Quelle oder legen Sie eine ausdrückliche Transformation fest.
Manchmal genügt es auch, den aktuellen Zustand zu synchronisieren. Muss das Zielsystem nur den gegenwärtigen Status kennen und nicht jede historische Änderung speichern, schafft die Übertragung sämtlicher Zwischenstände zusätzliche Komplexität, ohne unbedingt einen Mehrwert zu bieten. Werden Ereignisse dagegen für Audits, Nachverfolgbarkeit oder Berechnungen benötigt, kann es wichtig sein, die historische Reihenfolge und alle Details beizubehalten.
- Ein Backfill ist sinnvoll, wenn es überprüfbare, berechtigte Datensätze gibt, die das Zielsystem nicht erreicht haben, oder wenn eine Integrationsregel Felder unvollständig gelassen hat.
- Die Quelle sollte korrigiert werden, wenn die maßgeblichen Daten schon vor der Übertragung falsch oder unvollständig sind.
- Ereignisse sollten erneut versucht werden, wenn das Problem auf identifizierbare fehlgeschlagene Vorgänge begrenzt ist und sich diese mit dem verfügbaren Verfahren fortsetzen lassen.
- Der aktuelle Zustand sollte synchronisiert werden, wenn das Zielsystem den Änderungsverlauf nicht nachbilden muss.
Berücksichtigen Sie außerdem die betrieblichen Auswirkungen. Ein Datensatz kann eine Benachrichtigung, eine für Nutzer sichtbare Aktualisierung, eine Aufgabenverteilung oder einen finanziellen Vorgang auslösen. Wenn nicht klar ist, welche Aktionen dadurch angestoßen werden, sollten Sie nicht mit dem gesamten historischen Datenbestand beginnen.
Datensätze eingrenzen und die maßgebliche Datenquelle festlegen
Definieren Sie die Datenmenge anhand von Regeln, die eine andere Person nachvollziehen und wiederholen kann. Legen Sie Datumsbereiche und Zeitzone, einbezogene Status, Datensatztypen, Ausschlüsse und Auswahlkriterien fest. Klären Sie, ob die zeitliche Grenze auf dem Erstellungsdatum, dem Änderungsdatum oder dem Zeitpunkt des Ereignisses beruht: Diese Angaben sind nicht unbedingt gleichbedeutend.
Bestimmen Sie außerdem den Schlüssel, der die Datensätze systemübergreifend verknüpft. Mit einem stabilen Schlüssel lässt sich feststellen, ob das Zielsystem das Objekt bereits enthält und ob es erstellt, aktualisiert, übersprungen oder geprüft werden soll. Gehen Sie nicht davon aus, dass zwei Datensätze allein deshalb identisch sind, weil sie denselben Namen oder dieselbe Adresse haben. Verwenden Sie die in der Integration definierten Kennungen und prüfen Sie, wie fehlende oder doppelte Werte behandelt werden.
Legen Sie für jedes Feld ein maßgebliches System fest. Die Quelle kann beispielsweise für die E-Mail-Adresse zuständig sein, während ein anderes Attribut vom Zielsystem verwaltet wird. Ohne diese Entscheidung könnte ein Backfill berechtigte Änderungen überschreiben, die im empfangenden System vorgenommen wurden. Dokumentieren Sie, welche Felder geschrieben und welche beibehalten werden und wie Konflikte zu behandeln sind.
Verfahren auswählen und Nebenwirkungen begrenzen
Ein Stapelimport kann geeignet sein, wenn eine bekannte Datenmenge übertragen werden soll und das Zielsystem kontrollierte Importe unterstützt. Über eine API lassen sich Datensätze mit Validierungen und einzelnen Antworten verarbeiten; dabei müssen jedoch Begrenzungen, Fehler und die Wiederaufnahme berücksichtigt werden. Die Wiedergabe von Ereignissen eignet sich, wenn der Änderungsverlauf wichtig ist und sich bereits verarbeitete Ereignisse sicher erkennen lassen. Keine Option ist automatisch die beste. Entscheidend ist, welche Garantien sie hinsichtlich Reihenfolge, Duplikaten, Fehlern und Beobachtbarkeit bietet.
Prüfen Sie vor dem Senden, ob der Vorgang idempotent ist: Bei einer Wiederholung derselben Anfrage mit demselben Schlüssel sollte kein zweiter unerwünschter Effekt entstehen. Ist das nicht der Fall, legen Sie fest, wie Duplikate erkannt werden und wie sich ein unterbrochener Lauf fortsetzen lässt, ohne von vorn zu beginnen. Verwenden Sie, sofern das System es ermöglicht, Vorgangskennungen oder Fortschrittsmarkierungen und protokollieren Sie, was versucht wurde und welche Antwort einging.
Trennen Sie, wenn möglich, das Schreiben der Daten von den damit verbundenen Effekten. Ein Importmodus ohne Benachrichtigungen oder eine vorübergehende Unterdrückungsregel kann das Risiko senken, sofern diese Möglichkeit verfügbar und genehmigt ist. Gibt es Abbuchungen, Mitteilungen oder irreversible Statusänderungen, müssen vor der Verarbeitung ausdrückliche Kontrollen eingerichtet werden. Gehen Sie nicht davon aus, dass eine historische Aktualisierung wie eine routinemäßige Änderung behandelt wird.
Auch die Reihenfolge kann das Ergebnis beeinflussen. Bestehen Beziehungen zwischen Datensätzen oder aufeinanderfolgende Änderungen, legen Sie fest, ob zuerst übergeordnete Elemente und anschließend ihre Abhängigkeiten verarbeitet werden müssen oder ob jede Änderung ihrer zeitlichen Reihenfolge folgen soll. Ist nur der Endzustand wichtig, halten Sie diese Regel fest und vermeiden Sie die Wiedergabe von Übergängen, die Aktionen auslösen könnten.
Testen, schrittweise ausführen und rechtzeitig stoppen
Führen Sie einen Test mit einer repräsentativen Stichprobe durch. Berücksichtigen Sie dabei verschiedene Status und Datumsangaben, unvollständige Fälle sowie mögliche Duplikate. Vergleichen Sie das erwartete Ergebnis mit dem tatsächlichen Verhalten des Zielsystems und beziehen Sie Nebenwirkungen ein. Eine Stichprobe, die nur einfache Datensätze enthält, kann gerade die risikoreichsten Fälle übersehen.
Vereinbaren Sie vor dem Start Kennzahlen: ausgewählte, verarbeitete, neu angelegte, aktualisierte, übersprungene und fehlgeschlagene Datensätze. Legen Sie auch fest, wie die Abweichung zwischen Quelle und Ziel gemessen wird. Die Zahlen müssen sich auf dieselbe Datenmenge und dieselben Auswahlregeln beziehen. Ein Vergleich der Gesamtsummen kann ausgeschlossene Datensätze fälschlich wie Verluste erscheinen lassen.
Arbeiten Sie in Etappen: zunächst mit einer kleinen Stichprobe, dann mit einem begrenzten Abschnitt und erst dann mit dem Rest, wenn die Ergebnisse akzeptabel sind. Benennen Sie eine verantwortliche Person für die Überwachung und legen Sie Abbruchbedingungen fest. Dazu zählen etwa eine Fehlerrate oberhalb des vereinbarten Grenzwerts, unerwartete Duplikate, mehr Nebenwirkungen oder wachsende Abweichungen. Ein Abbruch sollte von Anfang an vorgesehen und nicht improvisiert sein.
Bewahren Sie für die Wiederaufnahme den Fortschrittsstand auf und unterscheiden Sie behebbare Fehler von Fällen, die einen Eingriff erfordern. Beheben Sie die Ursache vor einem erneuten Versuch, sonst tritt derselbe Fehler wieder auf. Ein Rollback ist nicht immer möglich, insbesondere wenn Mitteilungen versendet oder externe Aktionen ausgeführt wurden. Legen Sie daher im Voraus fest, ob der Plan darin besteht, Daten wiederherzustellen, Auswirkungen auszugleichen oder weitere Schreibvorgänge bis zum Abschluss der Untersuchung auszusetzen.
Abgleichen und den Vorgang abschließen
Vergleichen Sie nach Abschluss die erwarteten Datensätze anhand der vereinbarten Schlüssel mit den Ergebnissen im Zielsystem. Ordnen Sie Abweichungen einer Kategorie zu: nicht berechtigte Datensätze, technische Fehler, Datenkonflikte oder Fälle, die manuell geprüft werden müssen. Erklären Sie den Vorgang nicht allein deshalb für erfolgreich, weil er ohne Unterbrechung beendet wurde. Ein Abgleich muss die Abweichungen nachvollziehbar erklären.
Dokumentieren Sie den ausgeführten Umfang, Ausschlüsse, ausstehende Fehler, Entscheidungen zu Konflikten und beobachtete Nebenwirkungen. Bewahren Sie genügend Informationen auf, damit Support und Betrieb spätere Fragen beantworten können. Wenn sich die zugrunde liegenden Daten weiterhin ändern, legen Sie fest, wie Änderungen während des Backfills erfasst werden, damit keine neue Lücke entsteht.
Checkliste vor dem Produktivbetrieb
- Ist klar, welche Abweichung behoben wird und warum ein erneuter Versuch oder die Synchronisierung des aktuellen Zustands nicht ausreicht?
- Sind Datumsangaben, Status, Ausschlüsse, Kennungen und das maßgebliche System für jedes Feld festgelegt?
- Wurde geprüft, wie Duplikate, wiederholte Anfragen und Teilausfälle behandelt werden?
- Sind Benachrichtigungen, Abbuchungen, Statusänderungen und andere ausgelöste Aktionen bekannt und kontrolliert?
- Deckt die Teststichprobe repräsentative Fälle ab, und wurden die Ergebnisse im Zielsystem überprüft?
- Gibt es Kennzahlen, eine betriebliche verantwortliche Person, Abbruchbedingungen und einen Wiederherstellungsplan?
- Gibt es ein Verfahren für den Abgleich und eine Liste möglicher Abweichungen, die geprüft werden müssen?
Ist eine wichtige Antwort unbekannt, begrenzen Sie den Umfang und klären Sie die Unsicherheit, bevor Sie den Vorgang ausweiten. Bei einem sicheren Backfill kommt es weniger auf eine schnelle Verarbeitung als darauf an, erklären zu können, was gesendet wurde, was sich geändert hat, was noch aussteht und wie sich unerwünschte Wiederholungen vermeiden lassen.