Antwort.

Geschichte der Frage

Mit dem Übergang zu Mikrodiensten und verteilten Systemen hat die Wahrscheinlichkeit von Fehlern, die bei der Interaktion zwischen Diensten auftreten, sowie die Komplexität ihrer Behandlung stark zugenommen. Frühere Ansätze berücksichtigten oft nicht die Instabilität der Netzwerkinteraktionen, was zu massiven Vorfällen in der Produktion führte.

Problem

Das Hauptproblem besteht darin, dass komplexe Ausfallszenarien, die Degradierung von Diensten und Integrationsfehler in den Anforderungen nicht ausreichend formalisiert sind. Dadurch müssen Entwickler Entscheidungen zur Fehlerbehandlung nach eigenem Ermessen treffen, was zu einer Heterogenität der Fälle und Schwierigkeiten bei deren Testung führt.

Lösungsansatz

Eine effektive Beschreibung der Fehlerbehandlung sollte Folgendes umfassen:

• Abgrenzung von Fehlerarten (Netzwerkausfälle, Timeout, Ausfall dritter Dienste, Fehler in der Geschäftslogik, Inkonsistenz der Daten).
• Aufschreiben von Reaktionsmöglichkeiten für jede Fehlerart: erneute Versuche, Rückrollungen von Transaktionen, Degradierung der Funktionalität, Alarme, Benutzermeldungen.
• Einführung klarer Szenarien zur Testung von Ausfällen (Fail-Over, Graceful Degradation), einschließlich unspezifischer und kaskadierender Vorfälle.
• Dokumentation von Verträgen und Fehlerformaten (z.B. standardisierter JSON-Fehlerantwortvertrag).

Wesentliche Merkmale:

• Standardisierung von Fehlerbehandlungsmustern zwischen Diensten.
• Validierung der Degradierungsszenarien und deren Abstimmung mit dem Geschäft.
• Sicherstellung der Nachverfolgbarkeit von Fehlern und Protokollierung für eine spätere Analyse von Vorfällen.

Fangfragen.

Ist es notwendig, die Behandlung technischer Fehler in den Anforderungen zu beschreiben – ist das nicht die Aufgabe des Entwicklers?

Unbedingt. Eine nicht reflektierte Fehlerbehandlungsstrategie führt oft zu Fehlern in der Funktionsweise und Missverständnissen. Der Systemanalytiker muss das Verhalten bei Fehlern besprechen.

Sollten auch sehr seltene Fälle beschrieben werden (z.B. partielle Verbindungsverluste zwischen Diensten)?

Ja, weil selten auftretende Fehler zu den komplexesten Vorfällen führen. Ihre Auswirkungen können geschäftskritisch sein.

Muss man mit dem Geschäft die Nachrichten abstimmen, die den Benutzern bei Fehlern angezeigt werden?

Ja. Korrekte, informative, aber nicht übermäßige oder beängstigende Nachrichten müssen mit dem Geschäft abgestimmt werden, da sonst die Benutzererfahrung und Loyalität leiden.

Typische Fehler und Anti-Pattern

• Nur den Happy Path beschreiben und Ausfallszenarien ignorieren.
• Die Degradierung des Systems nicht berücksichtigen (Notfallszenarien sind nicht beschrieben).
• Unkoordinierte oder technisch komplexe Fehlermeldungen für den Benutzer.

Beispiel aus dem Leben

Negativer Fall: Im Projekt wurden Szenarien zur Behandlung von Timeouts zwischen Diensten nicht beschrieben. Infolgedessen „hängten“ die Dienste aufgrund eines instabilen Netzwerks ohne Antwort. Vorteile: Schnelle Ausführung der Hauptszenarien. Nachteile: Massive Ausfälle in der Produktion, negative Rückmeldungen von Kunden, „manuelles“ Schließen von Vorfällen.

Positiver Fall: Der Analyst hat Szenarien für Degradierungen und Neustarts, erneute Versuche und korrekte Nachrichten niedergeschrieben. Vorteile: Hohe Stabilität des Dienstes bei Ausfällen, reduzierte Anzahl von Notfällen. Nachteile: Mehr Zeit für die Ausarbeitung der Architekturszenarien.