Die Cloud ist wieder erreichbar. Wo sind die Aufträge aus der Ausfallzeit?

Die Statusseite ist wieder grün. Die Datenbank antwortet, die Anwendung lädt und die Fehlerrate sinkt. Trotzdem fehlen im Kundenservice mehrere Auftragsbestätigungen. Andere Kunden haben zwei Nachrichten erhalten. Der technische Ausfall ist beendet, aber die betroffenen Geschäftsvorgänge sind noch nicht geklärt.

Unternehmen, die Cloud-Betrieb oder eine Modernisierung ihrer Anwendung beauftragen, sollten deshalb den Wiederanlauf ausdrücklich in den Leistungsumfang aufnehmen. Gemeint ist die nachvollziehbare Bearbeitung aller offenen Aufträge nach einer Störung. Eine wieder erreichbare Infrastruktur ist dafür eine Voraussetzung, aber noch kein vollständiger Nachweis.

Beginnen Sie mit einer Liste erwarteter Ergebnisse

Die Anwendung sollte wissen, welche Geschäftsvorgänge sie angenommen hat. Für jeden Vorgang muss erkennbar sein, ob er noch wartet, bearbeitet wird, abgeschlossen ist oder eine verantwortete Ausnahme darstellt. Diese Sicht darf nicht ausschließlich von der aktuellen Länge einer technischen Warteschlange abhängen.

Bei einem fiktiven B2B-System führt eine Kundenbestellung zu einer Reservierung, einem ERP-Auftrag und einer Bestätigung. Nach einer Störung kann jeder dieser Schritte einen anderen Stand haben. Ein Gesamtstatus „Fehler“ reicht nicht, um sicher zu entscheiden, was wiederholt werden darf.

Halten Sie die fachliche Kennung über alle Schritte hinweg stabil. Technische Nachrichten können mehrfach entstehen oder anders gruppiert werden. Der ursprüngliche Geschäftsvorgang muss trotzdem derselbe bleiben, damit das Team seine Ergebnisse zusammenführen kann.

Verstehen Sie die Zusagen des Nachrichtendienstes

Die AWS-Dokumentation zur mindestens einmaligen Zustellung bei SQS erklärt, dass Standardwarteschlangen Nachrichten erneut zustellen können und Anwendungen entsprechend gestaltet werden müssen. Eine erneute Nachricht darf also nicht automatisch eine zweite geschäftliche Wirkung auslösen.

Die AWS-Beschreibung von Dead-Letter Queues behandelt die separate Aufbewahrung nicht erfolgreich verarbeiteter Nachrichten. Eine solche Warteschlange ist hilfreich für Untersuchung und erneute Verarbeitung. Sie ist jedoch kein automatischer Ersatz für eine fachliche Fehlerbearbeitung.

Lassen Sie den Dienstleister die tatsächlichen Zusagen der eingesetzten Produkte erklären. Begriffe wie „genau einmal“ müssen auf den jeweiligen technischen Umfang bezogen werden. Eine Zusage innerhalb eines Nachrichtendienstes beweist nicht ohne Weiteres, dass ein externes ERP eine Aktion genau einmal ausgeführt hat.

Prüfen Sie den Zeitpunkt nach der Geschäftswirkung

Der schwierige Fall entsteht oft, wenn eine externe Aktion erfolgreich war, ihre Bestätigung aber verloren geht. Die Anwendung weiß dann nicht sicher, ob sie wiederholen oder abschließen soll. Ein pauschaler Neustart kann in dieser Situation doppelte Aufträge oder Benachrichtigungen erzeugen.

Entwickeln Sie für jede relevante Aktion eine Möglichkeit zur Abstimmung. Kann das Zielsystem anhand einer stabilen Referenz Auskunft geben? Unterstützt es eine Wiederholung ohne zusätzliche Wirkung? Muss ein Mensch einen unklaren Zustand prüfen? Diese Fragen gehören vor dem Produktivstart beantwortet.

Bewahren Sie den bisherigen Verlauf, statt einen fehlgeschlagenen Datensatz zu löschen und neu anzulegen. Der Verlauf enthält möglicherweise genau die Information, die eine sichere Wiederaufnahme ermöglicht. Auch manuelle Eingriffe sollten nachvollziehbar mit dem ursprünglichen Auftrag verbunden bleiben.

Begrenzen Sie den Wiederanlauf

Nach einem längeren Ausfall können viele Vorgänge gleichzeitig warten. Werden alle sofort erneut verarbeitet, kann der Rückstau das gerade erholte System oder einen Partnerdienst erneut überlasten. Planen Sie daher eine kontrollierte Reihenfolge und Geschwindigkeit.

Berücksichtigen Sie fachliche Abhängigkeiten. Ein Änderungsauftrag sollte nicht vor dem zugehörigen Grundauftrag verarbeitet werden, wenn das Zielsystem diesen Zusammenhang benötigt. Ältere, inzwischen überholte Nachrichten müssen passend zur Geschäftsregel behandelt werden, statt blind den aktuellen Stand zu überschreiben.

Zeigen Sie dem Betrieb, welche Gruppe gerade wieder aufgenommen wird und welche Ergebnisse entstehen. Eine Pause sollte möglich sein, ohne die bereits erreichten Zustände unklar zu machen. Definieren Sie, wer den Wiederanlauf startet, überwacht und gegebenenfalls unterbricht.

Machen Sie Fehler für die richtige Person lesbar

Ein technischer Fehlercode kann die Ursache beschreiben, sagt aber selten, wer den betroffenen Kundenauftrag übernimmt. Ergänzen Sie eine verständliche Kategorie, den betroffenen Vorgang und eine nächste Aktion. Trennen Sie vorübergehende Verbindungsprobleme von ungültigen Geschäftsdaten.

Die Arbeitsoberfläche sollte ausreichend Kontext bieten, ohne unnötige sensible Inhalte in Protokolle zu kopieren. Ein Mitarbeiter muss beispielsweise erkennen, welche Bestellung betroffen ist. Dafür benötigt er nicht automatisch vollständige Zahlungsdaten oder sämtliche Anhänge des Kunden.

Behalten Sie auch Vorgänge im Blick, für die nie eine technische Nachricht erzeugt wurde. Eine Abstimmung zwischen angenommenen Aufträgen und erzeugten Verarbeitungsschritten findet Fehler an dieser Grenze. Allein die Überwachung des Nachrichtendienstes kann sie nicht erkennen.

Beauftragen Sie eine Wiederanlaufprobe

Ein brauchbarer Test unterbricht die Anwendung vor der Verarbeitung, während einer externen Anfrage und nach einer bereits erfolgten Wirkung. Anschließend muss das Team für jeden Testauftrag zeigen können, was geschehen ist und welche Schritte noch fehlen.

Prüfen Sie außerdem eine doppelte Nachricht, ungültige Daten und einen verspäteten Verarbeitungsschritt. Der erwartete Endzustand ist entweder ein nachvollziehbar abgeschlossenes Ergebnis oder eine sichtbare Ausnahme mit Verantwortlichem. Eine verschwundene Fehlermeldung ist kein ausreichendes Erfolgskriterium.

Zum Übergabepaket gehören Betriebsanleitung, Berechtigungen, Abstimmungsansichten und eine geübte Wiederaufnahme. Klären Sie, wer diese Probe nach wesentlichen Änderungen wiederholt. So bleibt der Wiederanlauf ein gepflegter Bestandteil des Systems und keine einmalige Präsentation.

Unsere Beiträge zu ereignisgesteuerter Architektur und RTO und RPO ergänzen die Planung. Innovation T unterstützt mit Cloud- und Softwareleistungen. Besprechen Sie den Wiederanlauf Ihrer Anwendung anhand eines Geschäftsvorgangs, dessen Ergebnis nach einer Störung heute nur mühsam feststellbar ist.

Ein praktisches Übergabeformat ist eine kurze Auftragsliste mit erwartetem Ergebnis, zuletzt bestätigtem Schritt und erlaubter nächster Aktion. Diese Liste sollte der Betrieb aus dem System erzeugen können. Sie ermöglicht auch eine verständliche Abstimmung mit dem Kundenservice: Welche Kunden warten noch, welche Zusagen sind bereits erfüllt und bei welchen Vorgängen muss zuerst eine externe Rückmeldung geprüft werden? So bekommt die technische Wiederaufnahme einen überprüfbaren geschäftlichen Abschluss.

Häufige Fragen

Ist eine leere Warteschlange ein Beleg für vollständige Verarbeitung?

Nein. Nachrichten können verarbeitet, verworfen, verschoben oder vor dem Einreihen verloren gegangen sein. Entscheidend ist die Abstimmung mit den erwarteten Geschäftsvorgängen und ihren Ergebnissen.

Dürfen fehlerhafte Nachrichten einfach erneut eingespielt werden?

Erst nach Prüfung der Ursache und möglicher bereits eingetretener Geschäftswirkungen. Der Wiederanlauf braucht eine kontrollierte Auswahl, begrenzte Geschwindigkeit und nachvollziehbare Ergebnisse.

Was gehört in einen Wiederanlauftest?

Unterbrechen Sie die Verarbeitung an unterschiedlichen Stellen, einschließlich nach einer externen Aktion. Prüfen Sie anschließend, ob jeder Auftrag vollständig erledigt oder als verantwortete Ausnahme sichtbar ist.