Datensynchronisation zwischen Systemen: Fehlerbilder und Monitoring

Gilt für: Shops, die zwei oder mehr Systeme automatisch Daten austauschen lassen; gesetzliche Aufbewahrungs- und Meldepflichten sind nicht Teil des Artikels

Zwei Systeme laufen nicht von selbst gleich: Eine Übergabe kann ausfallen, halb ankommen oder zweimal ausgeführt werden, ohne dass es im Shop jemand merkt. Ob Sie es erfahren, hängt nicht von der Software ab, sondern davon, was Sie abgleichen, was Sie protokollieren und ab welchem Wert ein Alarm ausgelöst wird. Der Ablauf unten führt in acht Schritten von der Liste der Übergaben zu einem Alarm, der auch abends ankommt.

Was Sie vorab brauchen

eine Liste aller Übergaben: welches System welche Daten in welche Richtung an welches System weitergibt
je Übergabe eine verantwortliche Person
Zugriff auf das Protokoll beider Seiten und auf den Bericht des Dienstes, der die Übergabe ausführt
die Zahl der Datensätze je Übergabe an einem normalen Tag und an einem Aktionstag
ein Alarmziel, das nicht in einem Postfach endet, das abends niemand öffnet
eine Zielgröße dafür, wie lange ein Datensatz unübertragen liegen darf

Schritt für Schritt: Übergaben überwachen

Schritt 1: Übergaben auflisten

Tragen Sie je Übergabe Quelle, Ziel, Richtung, Auslöser (Ereignis oder Zeitplan), Datensatzart (Bestellung, Kunde, Artikel, Preis, Bestand, Sendung, Rechnung) und den Verantwortlichen ein. Nehmen Sie die Umwege mit auf: eine Tabelle, die jemand zusätzlich führt, ein Export, den jemand von Hand anstößt, ein Postfach, aus dem Bestellungen abgelesen werden. Ergebnis: eine Liste, in der jede Zeile eine Übergabe mit Quelle, Ziel und Verantwortlichem nennt.

Schritt 2: Abgleichgröße je Übergabe festlegen

Ein Abgleich zeigt auch ausbleibende Daten, nicht nur gemeldete Fehler: Zählen Sie je Übergabe und Zeitfenster die Datensätze im Quell- und im Zielsystem; bei Geldbeträgen bilden Sie zusätzlich die Summe, und vergleichen Sie die Vorgangsnummern beider Seiten. Anzahl und Summe allein reichen nicht für die Vollständigkeit: Fehlt eine Bestellung über 50 Euro und kommt eine andere über 50 Euro doppelt an, stimmen Anzahl und Summe, obwohl eine Bestellung fehlt und eine doppelt ist; erst der Vergleich der Vorgangsnummern deckt das auf. Beispielrechnung: Zwischen 14:00 und 15:00 Uhr erzeugt der Shop 240 Bestellungen, die Warenwirtschaft empfängt 238. Der Abgleich meldet die Differenz 2; suchen Sie dann die beiden Vorgangsnummern im Protokoll, statt die Zahl nur zu notieren. Ergebnis: eine Zeile je Übergabe mit Zählgröße, Zeitfenster, Vorgangsnummernvergleich und dem Ergebnis „stimmt“ oder „Differenz“.

Schritt 3: Das Fehlerprotokoll mit festen Feldern schreiben

Auswertbar ist ein Protokoll, wenn jeder Eintrag dieselben Felder trägt.

Feld	Inhalt	Wofür es gebraucht wird
Zeitstempel	Zeitpunkt des Versuchs, mit Zeitzone oder in einer einheitlichen Zeit	Ordnet den Fehler dem Abgleich aus Schritt 2 zu
Übergabe	Name, etwa „Shop → Warenwirtschaft, Bestellung“	Trennt die Fehlerquellen voneinander
Quelle und Ziel	System, das gesendet hat, und System, das antworten sollte	Zeigt, welche Seite nicht geantwortet hat
Datensatzart und Nummer	Bestellung 10423, Kunde 8871, Artikelnummer	Macht den betroffenen Fall auffindbar
Vorgangsnummer	dieselbe Kennung bei jedem Versuch desselben Datensatzes	Verbindet Wiederholungen zu einem Fall
Fehlerart und Antwortcode	Zeitüberschreitung, Fehlercode 503, Prüfsummenfehler	Trennt wiederholbare von dauerhaften Fehlern
Versuch und nächster Versuch	„2 von 5, nächster in 120 Sekunden“	Zeigt, ob gewartet oder eingegriffen wird
Status und Verantwortlicher	offen, in Bearbeitung, erledigt, Name	Verhindert Fälle ohne Bearbeitung

Schritt 4: Wiederholungen so bauen, dass keine Doppel entstehen

Geben Sie jedem Datensatz eine eindeutige Kennung mit, die das Zielsystem speichert und gegen die es eine zweite Übermittlung prüft. Nach RFC 9110 Abschnitt 9.2.2 ist eine Anfrage idempotent, wenn die beabsichtigte Wirkung mehrerer gleicher Anfragen dieselbe ist wie die einer einzelnen; PUT, DELETE und die sicheren Methoden sind es deshalb, POST nicht. Nicht-idempotente Anfragen soll ein Client nicht automatisch wiederholen, solange er nicht weiß, dass ihre Semantik doch idempotent ist oder dass die erste Anfrage nie angekommen ist. Antwortet der Zielserver mit 503, darf er im Feld Retry-After eine Wartezeit nennen, als Sekundenzahl oder als Datum (Abschnitte 10.2.3 und 15.6.4); halten Sie sie ein, statt in kurzen Abständen erneut zu senden.

Schritt 5: Schwellenwerte und Alarmstufen festlegen

Ein Alarmwert braucht drei Angaben: gemessene Größe, Zeitfenster und die Zahl, ab der gemeldet wird. Die Tabelle ist eine Arbeitsvorlage; die Beispielwerte gelten für einen Shop mit einigen hundert Vorgängen am Tag und folgen keiner Vorgabe; die für diesen Artikel geöffneten Quellen (BSI, NIST, RFC 9110) nennen keine solchen Zahlen. Setzen Sie sie nach vier Wochen eigener Messwerte neu.

Kennzahl	Messung und Bezugszeitraum	Beispielwert	Stufe	Erste Reaktion
Fehlgeschlagene Übergaben	Anzahl je Übergabe in 15 Minuten, im Normalbetrieb	3 oder mehr	Warnung	Protokoll öffnen, Fehlerart prüfen
Fehlgeschlagene Übergaben	Anteil an allen Datensätzen der Übergabe in 15 Minuten	über 5 Prozent	kritisch	Übergabe anhalten, Wiederholungen stoppen
Datensatzzahl im Abgleich	Differenz je Stunde und Übergabe	1 oder mehr	Warnung	Beide Systeme nach der Nummer durchsuchen
Betragssumme im Abgleich	Differenz der Tagessummen je Übergabe	0,01 Euro oder mehr	kritisch	Zahlungs- und Rechnungsdaten vor dem Tagesabschluss klären
Warteschlange	Alter des ältesten unverarbeiteten Datensatzes in Minuten, im Normalbetrieb	über 120	kritisch	Übergabe anhalten, Fälle in die Klärliste
Stille Quelle	Minuten seit der letzten Protokollmeldung einer Quelle	über 15	kritisch	Dienst und Verbindung der Quelle prüfen
Zeitdifferenz	Sekunden zwischen den Uhren zweier beteiligter Systeme	über 30	kritisch	Zeitdienst prüfen, bevor Protokolle ausgewertet werden
Wiederholungen	Versuche je Datensatz	über 3	Warnung	Fehlerart prüfen: wiederholbar oder dauerhaft
Verworfene Protokolleinträge	Zähler des Protokolldienstes je Tag	1 oder mehr	kritisch	Speicher und Rotation des Protokolls prüfen

Der Alarm soll die Zahlen mitliefern, die ihn ausgelöst haben: Übergabe, Zeitfenster, gemessener Wert, Schwellenwert.

Schritt 6: Alarmweg und Reaktionszeit festlegen

Nennen Sie für jede Stufe einen Empfänger und eine Reaktionszeit und halten Sie beides schriftlich fest. Ein Alarm ist nur so gut wie sein Weg: Endet er in einem Sammelpostfach oder in einem Kanal, den abends niemand liest, bleibt der Fehler liegen. Legen Sie außerdem fest, was der Alarm selbst tun darf, etwa eine Übergabe anzuhalten, und was ein Mensch entscheidet, etwa das Nachziehen eines Datensatzes.

Schritt 7: Fehler erzwingen und den Alarm prüfen

Stellen Sie jede Alarmstufe einmal absichtlich her. Senden Sie einen Datensatz mit einer Nummer, die im Zielsystem schon liegt, und prüfen Sie, ob der Eintrag als Doppel erkannt wird. Schalten Sie die Protokollierung einer Quelle ab und prüfen Sie, ob nach der Heartbeat-Zeit ein Alarm kommt. Der Baustein OPS.1.1.5 Protokollierung des BSI (IT-Grundschutz-Kompendium, Edition 2023, Stand Februar 2023) nennt den Ausfall von Protokollquellen als Gefährdung (Abschnitt 2.7) und sieht in Anforderung A3 vor, in angemessenen Intervallen stichprobenartig zu prüfen, ob die Protokollierung noch funktioniert; die Prüfintervalle gehören in Ihre Protokollierungsrichtlinie. Der Baustein ist eine Empfehlung des BSI und bindet nur, wenn Gesetz oder Vertrag auf ihn verweisen. Ergebnis: ein Protokoll des Tests mit Datum, ausgelöster Stufe und Empfänger.

Schritt 8: Nach jedem Vorfall den Schwellenwert nachziehen

Notieren Sie nach jedem Vorfall, an welcher Stelle Sie ihn zuerst gesehen haben und welche Prüfung ihn früher gezeigt hätte. War der Alarm zu spät, senken Sie den Wert oder verkürzen das Zeitfenster; hatte er keinen Bearbeiter, ändern Sie den Weg. Den Bestellablauf selbst behandelt Bestellabwicklung automatisieren.

So prüfen Sie das Ergebnis

Jede Übergabe aus der Liste hat eine Zählgröße; keine Übergabe läuft ohne Abgleich.
Der Abgleich meldet auch eine Differenz von 1, und die Meldung nennt die betroffene Nummer.
Der Abgleich vergleicht neben Anzahl und Summe die Vorgangsnummern; ein fehlender und ein doppelter Datensatz mit gleicher Anzahl und Summe fallen dadurch auf.
Jeder Protokolleintrag lässt sich über Zeitstempel, Vorgangsnummer und Versuchszähler einem Fall zuordnen.
Jede Alarmstufe hat einen Empfänger und eine Reaktionszeit; der Alarmweg endet nicht in einem Postfach, das abends niemand öffnet.
Sie haben eine Übergabe absichtlich fehlschlagen lassen und Protokolleintrag und Alarm selbst gesehen.
Die Uhren der beteiligten Systeme liegen innerhalb Ihrer festgelegten Abweichung, sodass sich Einträge beider Seiten der Minute nach ordnen lassen.

Wenn etwas nicht klappt

Fehlerbild	Mögliche Ursache	Behebung
Bestellung liegt doppelt in der Warenwirtschaft	Wiederholung nach einem Abbruch; die Kennung fehlt oder wird im Ziel nicht gespeichert	eindeutige Vorgangsnummer je Datensatz einführen und im Ziel speichern
Bestellung fehlt im Zielsystem, im Protokoll steht kein Fehler	Der Lauf ist gelaufen, hat aber kein Ergebnis zurückgemeldet, oder die Quelle schreibt nicht mehr mit	Heartbeat je Quelle einführen, Datensatzzahl und Vorgangsnummern im Abgleich prüfen
Bestand in Shop und Warenwirtschaft weichen ab	Übertragung verzögert oder unvollständig	Zeitstempel je Bestandsänderung zusätzlich zur Menge abgleichen
Protokolleinträge beider Systeme lassen sich nicht zuordnen	Die Systemzeiten laufen auseinander	Zeitdifferenz messen und einen gemeinsamen Zeitdienst einrichten
Kein Alarm, obwohl die Schwelle überschritten war	Der Alarm endet in einem Postfach oder wird durch einen Filter unterdrückt	Zustellung mit einem Testereignis prüfen, zweiten Weg hinterlegen
Am Monatsende fehlen Protokolleinträge	Der Speicher war voll, Einträge wurden verworfen	Rotation und Speicher prüfen, Zähler für verworfene Einträge alarmieren
Eine Preisänderung erreicht den Shop nicht	Die Übergabe überträgt nur einen Teil der Felder oder läuft nur bei Neuanlage	Feldumfang dokumentieren, Änderungsdatum je Feld abgleichen

Der Baustein OPS.1.1.5 nennt zwei dieser Ursachen selbst: den Ausfall einer Protokollquelle (Abschnitt 2.7) und verworfene Einträge bei zu kleinem Speicher (Abschnitt 2.2). Für den Zeitabgleich sieht die Anforderung A4 vor, dass alle protokollierenden Systeme synchron laufen; NIST SP 800-92 empfiehlt dafür in Fußnote 24 einen Zeitdienst wie NTP. Als Faktor für die Priorität von Einträgen nennt derselbe Bericht in Abschnitt 5.2.2 unter anderem die Häufigkeit („x-mal in y Sekunden“); daraus lässt sich ein Schwellenwert bauen; einen Standardwert für Shops nennen die geöffneten Quellen nicht.

Wann Sie Hilfe holen sollten

Holen Sie Unterstützung, wenn zwei Systeme dasselbe Feld unterschiedlich definieren, wenn zwischen Shop und Warenwirtschaft ein weiteres System vermittelt, das Sie nicht selbst betreiben, oder wenn niemand in Ihrem Betrieb den Abgleich warten kann. Für Preise und Stammdaten führt Abgleich der Preise und Stammdaten weiter, für den Aufbau Warenwirtschaft für Onlinehändler, für den Komplettausfall Monitoring und Notfallplan und für bereits hängende Fälle Fehlersuche bei hängenden Bestellungen.