Kontrollierte Degradation in Anwendungen: Was bei einem Ausfall abhängiger Dienste verfügbar bleiben sollte

Wenn eine Anwendung von internen oder externen Diensten abhängt, sollte der Ausfall eines einzelnen Dienstes nicht automatisch alles zum Stillstand bringen. Alle Funktionen unverändert weiterlaufen zu lassen, kann jedoch ebenfalls zu inkonsistenten Daten, doppelten Vorgängen oder Entscheidungen auf Grundlage veralteter Informationen führen. Kontrollierte Degradation bedeutet, im Voraus festzulegen, welche Funktionen verfügbar bleiben, welche eingeschränkt werden und welche blockiert werden müssen, solange eine Abhängigkeit nicht antwortet.

Die Entscheidung sollte den Geschäftsprozess schützen und nicht nur die technische Verfügbarkeit. Für jede Funktion ist zu prüfen, welchen Dienst sie benötigt, was bei dessen Ausfall geschieht, wie lange eine Unterbrechung tolerierbar ist und wie sich die Konsistenz anschließend wiederherstellen lässt. So kann das Team eine sinnvolle Alternative anbieten, ohne das Problem zu verschleiern oder unnötige Risiken einzugehen.

Was kontrollierte Degradation bedeutet

Eine Anwendung befindet sich in kontrollierter Degradation, wenn sie bei einem Ausfall oder einer unzureichenden Antwort einer Abhängigkeit bewusst ausgewählte Funktionen mit klaren Einschränkungen aufrechterhält. Das ist weder eine vollständige Kopie des Dienstes noch das Versprechen, dass alles weiter funktioniert. Es handelt sich um eine Verhaltensrichtlinie für den Umgang mit Teilausfällen.

Sie unterscheidet sich von verwandten Mechanismen:

• Offline-Modus: Bestimmte Funktionen lassen sich ohne Verbindung nutzen und Änderungen gegebenenfalls später synchronisieren. Kontrollierte Degradation kann auch bei bestehender Netzwerkverbindung greifen, wenn ein bestimmter Dienst ausgefallen ist.
• Wiederholungsversuche: Sie senden eine fehlgeschlagene Anfrage erneut, üblicherweise mit Begrenzungen und Wartezeiten. Sie legen aber nicht von selbst fest, was Nutzerinnen und Nutzer sehen oder tun können, solange die Abhängigkeit nicht verfügbar ist.
• Kontrollierte Degradation: Sie definiert das Nutzungserlebnis und die Geschäftsregeln während des Ausfalls. Dazu gehört, welche Vorgänge mit welchen Daten und Einschränkungen zulässig sind.

Fällt beispielsweise ein Empfehlungsdienst aus, kann die Anwendung eine allgemeine Auswahl anzeigen und die Suche weiterhin ermöglichen. Fällt dagegen die für eine Zahlungsbestätigung notwendige Validierung aus, kann eine Zahlung trotzdem zuzulassen riskanter sein, als diese Aktion vorübergehend zu unterbrechen.

Funktionen, Abhängigkeiten und Auswirkungen miteinander verknüpfen

Beginnen Sie mit einer Übersicht der Produktfunktionen und nicht mit einem isolierten Verzeichnis der Dienste. Erfassen Sie für jede sichtbare Funktion, welche Abhängigkeiten sie benötigt und welches Ergebnis sie erzeugt. Eine hilfreiche Dokumentation enthält den Vorgang, den benötigten Dienst, die gelesenen oder geschriebenen Daten, die Auswirkungen auf die Nutzerinnen und Nutzer sowie die Folgen eines fehlerhaften Ergebnisses.

Bewerten Sie anschließend zwei Aspekte: die Auswirkungen, wenn eine Funktion nicht ausgeführt werden kann, und den möglichen Schaden, wenn sie mit unvollständigen oder falschen Informationen ausgeführt wird. Diese Aspekte sind nicht gleichbedeutend. Eine Verzögerung beim Laden von Inhalten kann lästig sein. Eine Transaktion anzunehmen, ohne ihren Status zu prüfen, kann dagegen Verluste oder Probleme beim Abgleich verursachen.

Ordnen Sie die Funktionen zunächst drei Gruppen zu:

• Kann verfügbar bleiben: Funktionen, die unabhängig von der ausgefallenen Abhängigkeit sind, etwa bereits lokal verfügbare Inhalte abzurufen.
• Kann eingeschränkt werden: Nützliche Funktionen, deren Umfang sich begrenzen lässt. Dazu gehört, gespeicherte Daten samt Aktualisierungszeitpunkt anzuzeigen oder einen Entwurf zu speichern, ohne ihn abzusenden.
• Muss angehalten werden: Vorgänge, deren Korrektheit von einer nicht verfügbaren Prüfung abhängt, etwa eine unumkehrbare Aktion zu bestätigen, ohne ihre Voraussetzungen zu validieren.

Die Einordnung sollte Alternativen und Folgen für die betroffenen Bereiche berücksichtigen. Das Produktteam kann festlegen, welches Nutzungserlebnis weiterhin einen Mehrwert bietet. Technologie- und Betriebsteams müssen bestätigen, welche Ausfälle sie erkennen und welche Garantien die Systeme bieten. Prüfen Sie auch indirekte Abhängigkeiten: Eine Funktion kann unabhängig erscheinen und dennoch eine nachgelagerte Validierung benötigen, um den Prozess abzuschließen.

Zwischen eingeschränkter Funktion, Cache und manueller Alternative wählen

Welche Option geeignet ist, hängt davon ab, wie alt Daten sein dürfen, ob ein Vorgang den Systemzustand verändert und ob sich Änderungen später abgleichen lassen. Nicht jeder Cache ist für jede Nutzung sicher: Daten, die bei einer unverbindlichen Abfrage hilfreich sind, eignen sich möglicherweise nicht zur Autorisierung eines Vorgangs.

• Zwischengespeicherte Daten: Nutzen Sie sie, wenn ein Lesezugriff auch ohne vollständige Aktualität sinnvoll bleibt. Geben Sie ihr Alter an und stellen Sie sie nicht als aktuelle Bestätigung dar. Legen Sie fest, ab wann sie nicht mehr akzeptabel sind. Lässt sich diese Grenze nicht anhand der Geschäftsanforderungen bestimmen, sollten die Daten nicht für sensible Entscheidungen verwendet werden.
• Eingeschränkte Funktion: Bieten Sie einen Teil der Funktion an, etwa Informationen abzurufen, aber nicht zu ändern, oder eine Anfrage vorzubereiten, ohne sie abzusenden. Erklären Sie, welcher Schritt noch aussteht und was für den Abschluss erforderlich ist.
• Manuelle Alternative: Sie kann sinnvoll sein, wenn es ein klares Verfahren, benannte Verantwortliche und eine nachträgliche Dokumentation gibt. Ohne diese Kontrollen kann manuelle Arbeit Duplikate erzeugen und zu einer parallelen Datenquelle werden.
• Vorübergehende Sperre: Sie ist vorzuziehen, wenn sich ein Vorgang weder sicher ausführen noch nachträglich überprüfen lässt. Beschränken Sie die betroffene Aktion, nicht zwangsläufig die gesamte Anwendung.

Bevor Sie verzögerte Schreibvorgänge zulassen, legen Sie fest, wie Vorgänge gekennzeichnet, gespeichert und erneut ausgeführt werden, welche Rückmeldung die Person erhält und wie Konflikte gelöst werden. Gibt es für solche Fälle keine sichere Regel, ist es meist weniger riskant, die Absicht als Entwurf zu speichern, als den Vorgang als abgeschlossen darzustellen.

Vorgänge blockieren, die inkonsistente Daten verursachen können

Die entscheidende Frage lautet, ob das System zwischen einer nicht empfangenen Anfrage, einer verarbeiteten Anfrage mit verlorener Antwort und einer noch ausstehenden Anfrage unterscheiden kann. Ist das nicht möglich, könnte ein erneutes Ausführen eines sensiblen Vorgangs ohne geeignete Kontrollen zu einer doppelten Ausführung führen. Wiederholungsversuche müssen begrenzt und an die Art der Anfrage angepasst werden. Bei Aktionen mit Auswirkungen braucht es Mechanismen, mit denen Duplikate erkannt und Ergebnisse vor einer Wiederholung abgefragt werden können.

Stoppen oder beschränken Sie einen Vorgang, wenn:

• er eine ausgefallene Validierung benötigt und keine genehmigte Ausweichregel besteht;
• er unumkehrbare oder nur schwer auszugleichende Folgen haben kann;
• sich nicht feststellen lässt, ob eine vorherige Anfrage bereits abgeschlossen wurde;
• die gespeicherten Daten für die betreffende Entscheidung die zulässige Aktualitätsgrenze überschritten haben.

Gibt es eine Möglichkeit zum Ausgleich, dokumentieren Sie, wer sie einleiten darf und wie sie erfasst wird. Gehen Sie nicht davon aus, dass eine Ausgleichsmaßnahme die ursprüngliche Wirkung einfach rückgängig macht: Sie kann einen betrieblichen Eingriff, eine Prüfung oder eine Mitteilung an die betroffene Person erfordern. Die Richtlinie muss diese Einschränkungen berücksichtigen.

Einschränkungen kommunizieren und den Dienst kontrolliert wiederherstellen

Die Meldung sollte erklären, welche Funktion eingeschränkt ist, was die Person jetzt tun kann und ob ein Schritt wiederholt werden muss. Vermeiden Sie Aussagen wie „abgeschlossen“, wenn lediglich eine ausstehende Anfrage gespeichert wurde. Versprechen Sie auch keine Wiederherstellungszeit, die das Team nicht garantieren kann. Ein klarer Status verringert unbedachte Wiederholungsversuche und vermeidbare Supportanfragen.

Wenn die Abhängigkeit wieder verfügbar ist, sollten Sie ausstehende Vorgänge nicht blind aktivieren. Prüfen Sie den tatsächlichen Status, verarbeiten Sie die Vorgänge in einer festgelegten Reihenfolge, erkennen Sie Duplikate und dokumentieren Sie die Ergebnisse. Bei Konflikten zwischen Änderungen wenden Sie eine vereinbarte Regel an – beispielsweise eine Prüfung, bevor Daten überschrieben werden – und bewahren Sie genügend Nachvollziehbarkeit auf, um Abweichungen untersuchen zu können.

Für die Wiederherstellung müssen überprüfbare Kriterien gelten. Stellen Sie fest, ob die Abhängigkeit stabil antwortet, ihre Ergebnisse gültig sind und die Anwendung den normalen Ablauf abschließen kann. Heben Sie die Einschränkungen anschließend kontrolliert auf. Treten die Symptome erneut auf, muss das System die Funktion wieder einschränken können, statt zwischen Verfügbarkeit und Ausfall hin- und herzuschwanken.

Entscheidungen testen und Ergebnisse messen

Eine Degradationsrichtlinie, die nur in einem Dokument steht, beweist nicht, dass die Anwendung sie korrekt umsetzt. Simulieren Sie den Ausfall, hohe Latenz, Teilfehler und verspätete Antworten jeder wichtigen Abhängigkeit. Prüfen Sie die Benutzeroberfläche ebenso wie Protokolle, ausstehende Vorgänge und das Verhalten bei Duplikaten. Testen Sie auch Wiederherstellung und Abgleich, nicht nur den Wechsel in den eingeschränkten Modus.

Betrachten Sie technische und geschäftliche Kennzahlen gemeinsam. Zu den technischen Signalen gehören Fehler und Antwortzeiten der Abhängigkeit, die Zahl der Wiederholungsversuche und die Dauer der Degradation. Geschäftliche Signale umfassen blockierte Vorgänge, ausstehende Anfragen, erkannte Konflikte und Fälle, die manuelles Eingreifen erfordern. Eine bessere Verfügbarkeit reicht nicht aus, wenn dadurch mehr inkonsistente Transaktionen oder zusätzlicher Supportaufwand entstehen.

Beantworten und überprüfen Sie für jede Funktion vier praktische Fragen: Was bleibt verfügbar, was wird eingeschränkt, was wird blockiert und wie wird die Wiederherstellung bestätigt? Kann das Team diese Fragen nicht beantworten, ist die Strategie noch nicht vollständig. Kontrollierte Degradation macht aus einem unvermeidlichen Ausfall eine bewusste Entscheidung: Der weiterhin sichere Nutzen bleibt erhalten, während das verschoben wird, was von einer vorübergehend nicht verfügbaren Garantie abhängt.