Graceful Degradation
Bei einem Teilausfall eingeschränkt weiterarbeiten
Die Idee und ihr Nutzen
Nach einem schweren Sturm melden Tausende Kunden gleichzeitig Schäden im Schadenportal ihrer Versicherung. Das Portal ist stark belastet, und der Werkstattdienst, der passende Werkstätten empfiehlt, fällt aus. Trotzdem sollen Kunden ihren Schaden melden, Fotos hochladen und ihre Schadenakte sehen können. Das Portal schaltet deshalb nur die Werkstattempfehlungen ab, zeigt dort den Hinweis „Werkstatt vorübergehend nicht verfügbar“ und hält die wichtigen Funktionen weiter in Betrieb. Der Ausfall des Werkstattdienstes verhindert so keine einzige Schadenmeldung. Dieses Verhalten heißt Graceful Degradation, auf Deutsch etwa geordnete Einschränkung. Der Name meint: Das Portal verliert bei einer Störung nur die verzichtbaren Funktionen, statt ganz auszufallen.
Wie funktioniert es?
Nach dem Sturm meldet ein Kunde einen Schaden an seinem Dach und lädt vier Fotos hoch, während das Portal an seiner Belastungsgrenze läuft. Das Portal speichert Meldung und Fotos zuerst dauerhaft in der Schadenakte, dem Dienst, der die Meldungen und Fotos jedes Schadens aufbewahrt. Das geschieht unabhängig davon, ob die übrigen Dienste antworten. Danach fragt das Portal den Werkstattdienst nach Werkstätten in der Nähe. Der Werkstattdienst ist um 10 Uhr ausgefallen, und das Portal bricht die Anfrage nach Ablauf einer festen Zeitgrenze ab. Die Fotoauswertung prüft Schadenfotos automatisch. Das Team, das das Portal betreibt, hat die Fotoauswertung wegen der hohen Last per Betriebsschalter abgeschaltet. Das Portal merkt die Fotos deshalb zur späteren Auswertung vor. Ein Betriebsschalter ist eine Einstellung, mit der sich eine Funktion während des Betriebs ein- und ausschalten lässt. Betriebsschalter gehören zu den Feature Toggles. Der Kunde sieht sofort seine Schadenakte. Im Bereich „Werkstatt in Ihrer Nähe“ steht der Hinweis „Werkstatt vorübergehend nicht verfügbar“, und bei den Fotos steht „Auswertung folgt in Kürze“. Am Abend sinkt die Last. Das Team schaltet die Fotoauswertung wieder ein, und die Fotoauswertung wertet die vorgemerkten Fotos nachträglich aus.
Das Portal setzt jede Seite aus Angaben mehrerer Dienste zusammen: aus der Schadenakte, dem Werkstattdienst und der Fotoauswertung. Den Ausfall eines dieser Dienste kann das Portal nicht verhindern. Den Werkstattdienst etwa betreibt ein Partnerunternehmen. Grundlage für den eingeschränkten Betrieb ist eine Einstufung, die das Team zusammen mit der Fachabteilung festlegt: Die Funktionen „Schaden melden“, „Fotos hochladen“ und „Schadenakte ansehen“ sind unverzichtbar; Werkstattempfehlungen und Fotoauswertung sind verzichtbar. Unverzichtbare Funktionen dürfen nicht davon abhängen, dass verzichtbare funktionieren. Die Schadenmeldung wird also auch gespeichert, wenn die Fotoauswertung nicht läuft. Das Portal setzt jede Seite so zusammen, dass ein gescheiterter verzichtbarer Teil durch einen Hinweis ersetzt wird, statt die ganze Seite abzubrechen. Das Abschalten verzichtbarer Funktionen hilft auch bei Überlast, wenn gar nichts ausgefallen ist. Die Rechenleistung reicht dann für die unverzichtbaren Funktionen. Dass ein Dienst gestört ist, melden diese Hilfsmittel:
- Zeitgrenzen beenden eine Anfrage, auf die zu lange keine Antwort kommt.
- Schutzschalter, englisch Circuit Breaker, erkennen einen gestörten Dienst und rufen ihn vorübergehend nicht mehr auf.
- Regelmäßige Prüfungen fragen ab, ob jeder Dienst antwortet.
Scheitert das Speichern in der Schadenakte, muss das Portal eine Fehlermeldung zeigen und darf dem Kunden nicht anzeigen, die Schadenmeldung sei gespeichert. Fällt die Schadenakte ganz aus, kann das Portal keine Schadenmeldungen mehr speichern, und das Abschalten verzichtbarer Funktionen hilft nicht. Graceful Degradation garantiert auch nicht, dass die unverzichtbaren Funktionen unter jeder Last schnell genug bleiben. Ob die unverzichtbaren Funktionen während der Lastspitze schnell genug geblieben sind, prüft das Team anhand der gemessenen Antwortzeiten.
Graceful Degradation: melden geht, Empfehlungen und Auswertung warten
Wann ist es sinnvoll und wann nicht?
Graceful Degradation lohnt sich
- Eine Anwendung hat viele Funktionen unterschiedlicher Wichtigkeit. Im Portal ist „Schaden melden“ nach einem Sturm unverzichtbar, die Werkstattempfehlung darf dagegen einige Stunden fehlen. Ohne diese Einstufung behandelt das Portal alle Funktionen gleich, und eine Störung der Werkstattempfehlung kann auch das Melden eines Schadens verhindern.
- Die Anwendung hängt von vielen anderen Diensten ab, deren Ausfall sie nicht verhindern kann. Lädt das Portal für jede Seite alle Teile gemeinsam und bricht ab, sobald einer davon scheitert, sehen Kunden bei einem Ausfall des Werkstattdienstes auch bei der Schadenmeldung nur eine Fehlerseite. Dabei braucht die Schadenmeldung den Werkstattdienst gar nicht. Ein kleiner Ausfall wird so zu einem großen, ausgerechnet nach einem Sturm, wenn am meisten Kunden auf das Portal angewiesen sind.
- Die Last schwankt stark, und bei Spitzen reicht die Rechenleistung nicht für alle Funktionen gleichzeitig. An gewöhnlichen Tagen reicht die Rechenleistung für alle Funktionen, nach einem Sturm kommen in wenigen Stunden Zehntausende Meldungen. Ohne Abschalten teilen sich alle Funktionen die knappe Rechenleistung, und auch „Schaden melden“ wird langsam. Durch das Abschalten der Fotoauswertung bleibt Rechenleistung für diese Meldungen.
- Arbeit, die viel Rechenleistung braucht, lässt sich verschieben. Ohne Aufschieben müsste das Portal die Fotos sofort auswerten lassen oder ganz auf die Auswertung verzichten. Die Fotoauswertung entfällt nicht, sondern die vorgemerkten Fotos werden am Abend nachträglich ausgewertet. Durch den Hinweis weiß der Kunde, dass die Auswertung seiner Fotos noch folgt.
Graceful Degradation ist nicht das Richtige
- Eine Funktion ist nur vollständig oder gar nicht sinnvoll. Eine halbe Zahlung oder eine teilweise gespeicherte Vertragsänderung gibt es nicht. An einer solchen Funktion gibt es keinen Teil, der sich abschalten ließe, ohne dass das Ergebnis falsch wird. Fehlt für eine solche Funktion ein Dienst, bricht das Programm den ganzen Vorgang ab und zeigt eine Fehlermeldung. So wird keine halbe Zahlung ausgeführt.
- Eine Anwendung hat praktisch nur eine Funktion. Ein Beispiel ist die Schadenakte, die nur Meldungen und Fotos aufbewahrt. Es gibt dann nichts Verzichtbares, das abgeschaltet werden könnte. Stattdessen betreibt das Team nach dem Ansatz Redundancy and Failover ein zweites Exemplar der Schadenakte, das Meldungen und Fotos speichert, wenn das erste ausfällt. Eine Einstufung der Funktionen und Betriebsschalter braucht die Schadenakte nicht.
- Eine eingeschränkte Antwort würde zu falschen Entscheidungen führen. Ein Beispiel ist ein Erstattungsbetrag, der ohne Abzug der Selbstbeteiligung berechnet wurde. Das Programm zeigt dann statt des Betrags eine Fehlermeldung und berechnet den Betrag erst, wenn alle nötigen Angaben vorliegen. So zahlt die Versicherung keinen zu hohen Betrag aus.
- Einschränkungen wären nur wegen Überlast nötig, nicht wegen ausgefallener Dienste. Dann kommen nach dem Ansatz Autoscaling bei steigender Last automatisch weitere Exemplare desselben Portals auf zusätzlichen Servern hinzu, und alle Funktionen bleiben auch nach einem Sturm verfügbar. Das Team muss keine eingeschränkten Zustände bauen und testen; dafür bezahlt die Versicherung die zusätzlichen Server, solange die Last hoch ist. Das geht nur, wenn die zusätzlichen Server bereitstehen, bevor die vorhandenen überlastet sind.
- Es geht nur um einen einzelnen unzuverlässigen Aufruf, etwa die Anfrage des Portals an den Werkstattdienst. Dann legt das Team mit einem Fallback nur für diesen Aufruf eine Ersatzreaktion fest, etwa einen hinterlegten Standardwert. Eine Einstufung aller Funktionen und Betriebsschalter braucht es dann nicht.
Nachteile und typische Fehler
Jeder eingeschränkte Zustand ist ein eigener Zustand der Anwendung, der gebaut und getestet werden muss. Beim Portal sind das schon vier Fälle: alles verfügbar, Werkstattdienst aus, Fotoauswertung aus und beides aus. Die Einstufung, was verzichtbar ist, muss vorher feststehen, braucht fachliche Abstimmung und muss überprüft werden, wenn neue Funktionen hinzukommen. Für Betriebsschalter braucht das Team eine Möglichkeit, Funktionen während des Betriebs umzuschalten, und eine Festlegung, wer wann schalten darf, etwa nur die Person im Bereitschaftsdienst des Teams und nur bei Überlast. Aufgeschobene Arbeit wie die vorgemerkten Fotos muss gespeichert und später nachgeholt werden. Dafür braucht es Speicherplatz und einen Ablauf, der das Nachholen anstößt.
Typische Fehler und woran man sie erkennt:
- Versteckte Abhängigkeit: Das Portal wartet mit dem Speichern der Meldung auf das Ergebnis der Fotoauswertung. Erst dann schickt das Portal Meldung und Ergebnis in einer gemeinsamen Anfrage an die Schadenakte. Fällt die Fotoauswertung aus, speichert das Portal auch die Meldung nicht. Erkennbar ist das an Fehlerseiten bei der Schadenmeldung zur selben Zeit wie Störungen eines verzichtbaren Dienstes.
- Vergessener Betriebsschalter: Das Team schaltet die Fotoauswertung nach der Lastspitze nicht wieder ein. Die Fotoauswertung fehlt dann wochenlang, ohne dass es jemand merkt. Erkennbar ist das an Betriebsschaltern, die seit langer Zeit auf „aus“ stehen, obwohl die Last längst gesunken ist.
- Stilles Verschwinden: Das Portal lässt den Bereich eines ausgefallenen Dienstes weg, statt einen Hinweis zu zeigen. Kunden suchen den Bereich vergeblich und rufen beim Kundenservice an. Erkennbar ist das an steigenden Anrufzahlen mit Fragen nach fehlenden Funktionen.
- Ungetesteter Notbetrieb: Das Team hat nie ausprobiert, was das Portal bei einem Ausfall des Werkstattdienstes tut. Ein Programmfehler beim Ersetzen durch den Hinweis fällt deshalb erst beim ersten echten Ausfall auf: Das Portal bricht die ganze Seite ab. Erkennbar ist das erst im Ernstfall, wenn statt des Hinweises eine Fehlerseite erscheint.
- Verlorene Nacharbeit: Das Team schaltet die Fotoauswertung wieder ein, aber niemand stößt die Auswertung der vorgemerkten Fotos an. Die Fotoauswertung wertet dann nur neu hochgeladene Fotos aus. Erkennbar ist das an Schadenakten, deren Fotoauswertung auch Tage nach dem Sturm fehlt.
Weiterführend
Verwandte Ansätze
- Bulkhead: teilt die Verbindungen und die Rechenleistung eines Programms fest auf, sodass wartende Aufrufe an einen gestörten Dienst nicht alles davon belegen. Aufrufe an den ausgefallenen Werkstattdienst belegen dann höchstens einen festen Teil der Verbindungen des Portals, und für die Schadenmeldung bleiben Verbindungen frei.
- Throttling: begrenzt die Zahl eingehender Anfragen, damit die verbleibenden Funktionen unter Last weiterarbeiten können.
Werkzeuge und Umsetzungen
Graceful Degradation ist eine Art, Anwendungen zu entwerfen, und kein Produkt. Diese Werkzeuge liefern Bausteine dafür:
- Resilience4j: Schutzschalter, Zeitgrenzen und Ersatzreaktionen für Java-Anwendungen.
- Polly: dieselben Bausteine für die Plattform .NET.
- Unleash: Dienst für Funktionsschalter, mit dem sich auch Betriebsschalter einrichten lassen.
- Envoy: ein Programm, das Verbindungen stellvertretend annimmt und weiterleitet. Envoy kann gestörte Ziele automatisch meiden und Anfragen an Ersatzziele leiten.
Quellen
- AWS Well-Architected Framework: REL05-BP01 Implement graceful degradation to transform applicable hard dependencies into soft dependencies: beschreibt, wie eine Anwendung bei ausgefallenen Abhängigkeiten ihre wichtigste Funktion weiter erbringt, warum die Auswahl auch eine fachliche Entscheidung ist und dass eingeschränkte Abläufe getestet werden müssen.
- Microsoft Azure Well-Architected Framework: Architecture strategies for self-healing and self-preservation: behandelt im Abschnitt zum eingeschränkten Betrieb das automatische Erkennen von Ausfällen, Hinweise an Nutzer und Ersatzabläufe für unverzichtbare Funktionen.