Antwort.

In der Geschichte der Entwicklung verteilter IT-Systeme haben Fragen zur Fehlerbehandlung und zu Ausfallszenarien lange Zeit eine untergeordnete Rolle gespielt und der Geschäftslogik Platz gemacht. Der steigende Umfang und die Komplexität der Infrastruktur haben jedoch im Laufe der Zeit gezeigt, dass unzureichend ausgearbeitete Fehlerbehandlungszenarien zu großangelegten Ausfällen und Datenverlusten führen.

Das Problem besteht darin, dass komplexe Systeme unter vielen verschiedenen Arten von Ausfällen leiden: von der Nichterreichbarkeit einzelner Dienste bis hin zur Inkonsistenz der Daten oder Teil-Ausfällen der Kommunikationskanäle. Oft verstehen Auftraggeber unter "Ausfällen" nur offensichtliche Fehler (zum Beispiel, der Server ist nicht erreichbar), während sie Ketten von Servicefehlern oder die Degradierung der Benutzererfahrung ignorieren.

Eine effektive Lösung basiert auf einem systematischen Ansatz:

Erkennung aller potenziellen Ausfallpunkte.
Entwicklung umfassender Szenarien für deren Auftreten in Zusammenarbeit mit Architekten, QA, Designern und Betriebstechnikern.
Abstimmung des Verhaltens des Systems mit dem Geschäft (zum Beispiel, ob Aufträge verschoben werden können oder ob Operationen zwischengespeichert werden müssen).
Klare Dokumentation aller Arten von Fehlermeldungen und Verarbeitungswegen.

Wesentliche Merkmale:

Behandlung nicht nur fataler, sondern auch weicher/schleichender Ausfälle (zum Beispiel, vorübergehende Nichterreichbarkeit eines externen Dienstes).
Einbeziehung von Szenarien zur Degradierung der UI und Funktionalität.
Abgrenzung von Geschäftsfehlern und technischen Ausfällen in allen Phasen der Anforderungserarbeitung.

Fangfragen.

Was ist der Unterschied zwischen Ausnahmen auf Anwendungsebene und auf Infrastruktur-Ebene?

Sehr häufig verwechseln Kandidaten Geschäftsfehler (zum Beispiel, "Benutzer nicht gefunden") mit echten Ausfällen (zum Beispiel, "Datenbank nicht erreichbar"). Die Anwendung sollte immer klar zwischen zwei Arten von Ausnahmen unterscheiden und unterschiedliche Behandlungsstrategien bereitstellen (Rollback, Benachrichtigungen, Alerts).

Welche Ausfallszenarien sollten für eine interne API modelliert werden, wenn sie nicht öffentlich ist?

Ausfallszenarien sind für jede API relevant: Auch wenn die API intern ist, sind Ausfälle jederzeit möglich (sogar innerhalb eines Automatisierungs-Workflows), und sie müssen explizit modelliert werden, um effektiv mit ungültigen/fehlenden Daten zu arbeiten.

Sollte ein System alle Fehler vor dem Benutzer verbergen, um das beste UX zu gewährleisten?

Nein, das absolute Verbergen von Fehlern führt zu Fehlinformationen für den Benutzer. Es ist wichtig, ein Gleichgewicht zwischen Informationsgehalt (damit der Benutzer versteht, was als nächstes zu tun ist) und Sicherheit (ohne die Implementierungsdetails offenzulegen) zu finden.

Typische Fehler und Anti-Patterns

Unformalisierte Fehlerbehandlung (auf "Standard" belassene Catch-Blöcke).
Fehlende Degradationsszenarien bei Teil-Ausfällen (zum Beispiel bei Mikrodiensten — ein nicht funktionierender Warenkorb blockiert den gesamten Bestellprozess).
Ignorieren des Anstiegs von "stillen" Ausfällen (keine Alerts/Monitoring für außergewöhnliche Situationen).

Beispiel aus dem Leben

Negativer Fall: In einem großen E-Commerce-Projekt hat der Systemanalytiker die Behandlung aller Netzwerkfehler der Architektur überlassen. Bei Notfall-Updates und dem Ausfall des E-Mail-Dienstes hat das System keine Benachrichtigungen über Bestellungen gesendet, und die Benutzer konnten nicht verstehen, ob ihre Bestellungen erstellt wurden.

Vorteile:

Vereinfachung der Anforderungserstellung.

Nachteile:

Datenverlust (es ist unmöglich zu beweisen, dass eine Bestellung erstellt wurde).
Die Supportkosten stiegen nach dem Produktstart.

Positiver Fall: Der Systemanalytiker hat zusammen mit dem Architekten separate Szenarien für jeden kritischen Dienst modelliert: Nichterreichbarkeit der E-Mail-Warteschlange, Ausfälle von Zahlungs-Gateways, Degradierung des Suchdienstes. Benutzerfreundliche Nachrichten für Kunden wurden formuliert.