Wenn eine Schnittstelle ausfällt: stille Störungen erkennen

Erkennung ist keine Frage teurer Werkzeuge, sondern eine Frage der richtigen Frage. Eine Schnittstelle kann auf drei grundsätzlich verschiedene Arten scheitern: Die Verbindung selbst ist tot, die Verbindung lebt, aber es kommt nichts, oder es kommt etwas, aber unvollständig. Für jede dieser Arten gibt es ein eigenes Prüfmuster. Wer nur eines davon einsetzt, deckt nur einen Teil der möglichen Störungen ab.

Diese drei Muster ergänzen sich und lassen sich in nahezu jeder Umgebung umsetzen — auch dann, wenn die beteiligten Systeme selbst keine Überwachungsfunktion mitbringen. Entscheidend ist nicht die Technik, sondern dass die Prüfung außerhalb der Schnittstelle stattfindet. Eine Komponente, die ihren eigenen Ausfall melden soll, kann das nicht mehr, sobald sie ausgefallen ist.

Der Aufwand für diese drei Prüfungen ist gering, wenn er beim Bau der Schnittstelle mitgedacht wird. Wird er nachträglich ergänzt, ist der Mengenabgleich meist der teuerste Teil, weil beide Systeme eine belastbare Zählung liefern müssen. Ein pragmatischer Zwischenschritt: Zunächst nur Herzschlag und Zeitfenster einführen, den Mengenabgleich zunächst als tägliche Auswertung mit manueller Sichtprüfung fahren und ihn erst automatisieren, wenn klar ist, welche Abweichungen im Normalbetrieb ohnehin auftreten.

Der zweite große Unterschied zwischen einer robusten und einer improvisierten Schnittstelle liegt darin, was mit den Daten passiert, während die Gegenseite nicht erreichbar ist. Eine einfach gebaute Verbindung versucht die Übergabe genau einmal. Klappt sie nicht, ist der Datensatz weg — nicht gelöscht, aber eben auch nicht übertragen, und niemand weiß, welche es betroffen hat. Die Nacharbeit besteht dann darin, aus zwei Systemen Listen zu ziehen und sie gegeneinander zu halten.

Eine Warteschlange dreht das um. Jeder zu übertragende Vorgang wird zuerst in einen Zwischenspeicher geschrieben und erst nach erfolgreicher Bestätigung der Gegenseite als erledigt markiert. Schlägt die Übergabe fehl, bleibt der Eintrag mit Zeitstempel, Fehlergrund und Versuchszähler liegen. Wiederholte Versuche erfolgen mit wachsendem Abstand, damit ein überlastetes Zielsystem nicht zusätzlich belastet wird. Nach einer festgelegten Anzahl von Versuchen wandert der Eintrag in einen Bereich für Fälle, die menschliche Entscheidung brauchen.

Wichtig ist dabei der Umgang mit Wiederholungen. Wenn das Zielsystem einen Vorgang bereits angenommen hat und nur die Empfangsbestätigung verloren ging, würde ein erneuter Versuch eine Doppelbuchung erzeugen. Verhindert wird das durch eine eindeutige Kennung je Vorgang, die das Zielsystem prüft, bevor es verarbeitet. Fachlich heißt das: Ein zweiter Aufruf mit derselben Kennung ändert nichts mehr. Diese Eigenschaft ist bei der Übertragung von Rechnungen, Zahlungen und Lagerbewegungen keine Feinheit, sondern die Voraussetzung dafür, dass ein Wiederanlauf überhaupt gefahrlos möglich ist.

Mit dem technischen Wiederanlauf ist der Vorfall selten erledigt. Während der Störung sind fachliche Entscheidungen unter falschen Voraussetzungen getroffen worden: Es wurde etwas verkauft, das im anderen System längst reserviert war, eine Mahnung ging an eine Kundin, deren Zahlung nur nicht übertragen worden war, ein Auftrag wurde zweimal angelegt, weil der erste im anderen System nicht auftauchte. Diese Fälle löst kein Wiederanlauf, sie brauchen eine fachliche Durchsicht.

Praktikabel ist eine kurze Nachlaufliste: Welche Vorgänge sind im Störungszeitraum entstanden, welche davon wurden nach außen kommuniziert, und wo ist eine Korrektur nötig? Zuständig ist die Fachabteilung, nicht die Technik — die Technik liefert die Liste, die Bewertung findet im Fach statt. Zwei bis drei Kategorien reichen: unkritisch, intern zu korrigieren, mit dem Kunden zu klären.

Der Ablauf gehört in die Verfahrensbeschreibung der Schnittstelle: was übertragen wird, in welcher Richtung, in welchem Takt, wer im Störungsfall handelt und wie der Wiederanlauf abläuft. Bei buchungsrelevanten Übertragungen berührt das auch die Anforderungen an eine Verfahrensdokumentation; die Beurteilung des Einzelfalls gehört in die Hände der steuerlichen Beratung. Wie eine solche Beschreibung aufgebaut wird, ohne zum Aktenordner zu werden, zeigen wir unter Prozessdokumentation.

Alle fünf Bausteine gleichzeitig einzuführen, überfordert die meisten Betriebe — und ist auch nicht nötig. Der Nutzen ist ungleich verteilt: Die ersten Schritte kosten wenig und decken den größten Teil der Fälle ab, die späteren sind aufwendiger und zahlen sich erst bei kritischen Verbindungen aus. Wer priorisieren muss, geht nach Schadenshöhe vor: Welche Verbindung würde bei einem dreitägigen Ausfall den größten Rückstand erzeugen?

Die folgende Reihenfolge hat sich bewährt. Sie lässt sich schrittweise abarbeiten, jeder Schritt bringt für sich genommen einen Nutzen, und man kann nach jedem Schritt aufhören, ohne einen halbfertigen Zustand zu hinterlassen.

Der Aufwand hält sich in Grenzen, wenn die Punkte eins bis drei zuerst kommen: Sie sind überwiegend Organisation, nicht Programmierung. Erst ab Punkt vier entsteht echter Umsetzungsaufwand. Eine unbeobachtete Schnittstelle ist kein technisches Risiko, sondern ein kaufmännisches — der Schaden entsteht nicht in der Technik, sondern in der Nacharbeit und im Vertrauen der Kunden. Wie sich Prüfung, Nachrüstung und laufende Betreuung abrechnen, steht unter Preise.