Der lange und steinige Weg zur Resilienz – Teil 5

Der lange und steinige Weg zur Resilienz – Teil 5

Im vorherigen Beitrag haben wir die 100-%-Verfügbarkeitsfalle diskutiert und das Thema Verfügbarkeit erneut betrachtet. Wir haben auch die beiden Erkenntnisse besprochen, die notwendig sind, um unsere Reise zum zweiten Plateau fortzusetzen.

In diesem Beitrag werden wir diskutieren, was wir am zweiten Plateau finden, dem Plateau der Robustheit.

Das Plateau der Robustheit

Das Plateau der Robustheit¹ ist die zweite Zwischenstation, die Unternehmen auf ihrem Weg zur Resilienz typischerweise erreichen.

Nicht so viele Unternehmen sind dort zu finden, weil es einen Wandel der Denkweise erfordert, der typischerweise schwierig ist und Zeit braucht. Der erforderliche Wandel besteht darin, zu akzeptieren, dass Ausfälle nicht vermieden werden können:

Wir können Ausfälle nicht vermeiden. Daher sollten wir sie uns zu eigen machen.

Das bedeutet nicht, dass die Vermeidung von Ausfällen irrelevant wird. Es ist in Bezug auf Verfügbarkeit immer noch besser, einen Ausfall einmal pro Woche zu erleben als einmal pro Stunde. Wir verlassen uns jedoch nicht ausschließlich auf die Vermeidung von Ausfällen, d.h. wir nehmen nicht an, dass wir MTTF (Mean Time To Failure) so weit schieben können, dass wir nur einmal pro Jahrhundert einen Ausfall erleben.

Ausfälle zu eigen machen bedeutet zu akzeptieren, dass die Möglichkeiten zur Vermeidung von Ausfällen begrenzt sind. Wir können ihre Häufigkeit reduzieren, aber wir können sie nicht vollständig vermeiden. Daher müssen wir uns zusätzlich darauf konzentrieren, wie wir effektiv mit Ausfällen umgehen, um uns schnell von ihnen zu erholen oder ihre Wirkung zumindest abzumildern.

Bewertung des Plateaus der Robustheit

Nach diesen einleitenden Gedanken wollen wir das Plateau der Robustheit mit dem bereits bekannten Bewertungsschema genauer erkunden.

Kerntreiber

Der Kerntreiber ist es, sich Ausfälle zu eigen zu machen.

Der Gedankengang ist: Wir wollen die Verfügbarkeit maximieren. Wir können Ausfälle nicht vollständig vermeiden. Daher lasst uns einen Teil unseres Fokus darauf legen, MTTF zu erhöhen, jedoch zu akzeptieren, dass wir MTTF nicht beliebig weit erhöhen können. Wichtiger ist, Wege zu finden, MTTR (Mean Time To Recovery) zu reduzieren, d.h. Ausfälle schnell zu erkennen und sich zügig von ihnen zu erholen oder ihre Auswirkungen zumindest abzumildern, indem wir den Betrieb auf einem definierten reduzierten Service-Level fortsetzen.²

Leitfragen

Typische Leitfragen sind:

• Was kann schief gehen und wie kann ich darauf reagieren?
• Was kann ich tun, wenn ein Remote-Service nicht verfügbar ist?
• Wie kann ich ungültige Anfragen (wenn ich aufgerufen werde) und Antworten (bei eigenen Aufrufen) erkennen und handhaben?
• Wie kann ich Bugs und andere Defekte schnell beheben?

Die erste Frage ist die allgemeine, übergreifende Frage. Die anderen Fragen sind Beispiele für spezifischere Fehlertypen.

Typische Maßnahmen

Die Leitfragen führen zu einem anderen Satz typischer Maßnahmen:

• Die wahrscheinlich wichtigste zusätzliche Maßnahme ist die Implementierung von Fallbacks, d. h. sinnvolle alternative Reaktionen auf Geschäftsebene, die ausgeführt werden, wenn der reguläre Anfrageverarbeitungspfad aufgrund eines technischen Fehlers nicht abgeschlossen werden kann. Damit erweitert sich der Maßnahmen-Scope bis auf die Geschäftsebene – im Gegensatz zum Plateau der Stabilität, wo der Fokus nur auf technischen Maßnahmen lag (siehe auch die Diskussion unten).
• Anwendung vollständiger Parameterprüfung für eingehende Anfragen sowie für Antworten von aufgerufenen Systemen. Auch wenn diese Maßnahme selbstverständlich erscheint, ist sie überraschend selten gut implementiert.³
• Rigorose Deployment-Automatisierung mit CI/CD, IaC/IfC, etcetera. Hier geht es nicht so sehr um Wiederholbarkeit als um Geschwindigkeit. Je schneller neue Software-Releases ohne Qualitätskompromisse deployed werden können, desto kürzer wird MTTR im Fall eines Software-Bugs.
• Minimierung der Startzeit von Systemkomponenten. Kurze Startzeiten können MTTR erheblich verbessern, ohne ausschließlich von Redundanz und Failover abhängig zu sein.
• Anwendung gründlichen Monitorings auf Anwendungs- und Geschäftsebene, um Fehler früh zu erkennen und sie idealerweise zu beseitigen, bevor sie zu Ausfällen werden.

Anmerkung: Für das Plateau der Robustheit ist Monitoring noch ausreichend. Vollständige Observability ist noch nicht erforderlich, weil es ausreicht, erwartete Fehlerarten schnell zu erkennen und auf sie zu reagieren.⁴

Ich versuche in der Regel, die verschiedenen Abstufungen von Fehlern gemäß der üblichen Unterscheidungen in der Fehlertoleranz-Literatur zu machen (siehe z. B. „Patterns for fault tolerant software" von Robert S. Hanmer):

• Ein Fault (Defekt) ist ein Defekt, der in einem System lauert und einen Error verursachen kann, z. B. ein Software-Bug oder ein schwacher Festplattensektor.
• Ein Error (Fehler) ist ein inkorrektes Systemverhalten, das von innerhalb des Systems beobachtet werden kann und einen Ausfall verursachen kann. Ein Fehler kann jedoch (noch) nicht von außerhalb des Systems beobachtet werden. Von außen verhält sich das System noch entsprechend seiner Spezifikation.
• Ein Failure (Ausfall) ist ein inkorrektes Systemverhalten, das von außerhalb des Systems beobachtet werden kann, d. h. das wahrgenommene Verhalten des Systems weicht von seiner Spezifikation ab. Wichtig ist dabei, dass ein Ausfall nicht unbedingt ein Absturzfehler sein muss. Auch von außen wahrnehmbare Fehlermuster wie z.B. hohe Latenzen oder fehlerhafte Antworten zählen als Ausfälle.

Im Deutschen ist die Unterscheidung manchmal schwierig, weil sich alle drei englischen Fachbegriffe im Deutschen auch mit „Fehler” übersetzen lassen. Damit ergeben sich schnell schwer nachvollziehbare Aussagen wie: Ein Fehler kann zu einem Fehler führen, der zu einem Fehler wird, wenn man ihn von außen beobachten kann. Häh?

Deshalb versuche ich im Deutschen, „Fault” mit „Defekt”, „Error” mit „Fehler” und „Failure” mit „Ausfall” zu übersetzen, auch wenn das im Falle von Failure (Ausfall) zu Stirnrunzeln führen kann, weil man üblicherweise z. B. eine hohe Latenz oder eine falsche Antwort nicht mit einem Ausfall gleichsetzt. Das als ergänzende Begriffserläuterung.

Die Idee ist, Fehler (Errors) zu erkennen und zu handhaben, bevor sie von außen sichtbar werden, d. h. zu Ausfällen (Failures) werden. Die Behandlung von Fehlern geschieht typischerweise auf zwei Arten:

• Fehlerbehebung (Error Recovery) – Die Ursache beheben und sich von der Fehlersituation erholen. Fehlerbehebung ist nur möglich, wenn das System genug Informationen, Zeit und Ressourcen hat, um das Problem sofort zu beheben.
• Fehlermilderung (Error Mitigation) – Zurückfallen auf einen definierten reduzierten Service-Level (auch bekannt als graceful degradation of service). Wenn das System nicht die Informationen, Zeit oder Ressourcen hat, um das Problem sofort zu beheben, fällt es auf einen definierten reduzierten Service-Level zurück, bis entweder das Problem verschwindet (z. B. im Fall einer temporären Überlastsituation) oder das System genug Informationen, Zeit und Ressourcen hat, um das Problem zu beheben (z. B. durch Nutzung eines Supervisors, einer Control Plane oder eines Wartungsjobs, welche die Voraussetzungen erfüllen).

Wenn möglich, wird der Fehler sofort behoben und der normale Betrieb wird fortgesetzt, ohne dass jemand von außen ein Problem beobachten kann. Das ist der beste Fall.

Manchmal fehlen dem System jedoch

• die erforderlichen Informationen (das System weiß nicht, wie das Problem zu beheben ist, z. B. wenn ein aufgerufenes System nicht antwortet) und/oder
• die Zeit (die Wiederherstellung würde zu lange dauern und das SLA des Systems verletzen) und/oder
• die Ressourcen (das System hat keinen Zugang zu den erforderlichen Ressourcen, z. B. zusätzliche Rechen-Knoten zur Behandlung einer Überlastsituation)

um sich sofort von dem Fehler zu erholen.

In einer solchen Situation muss es seinen Service-Level „würdevoll” (graceful) reduzieren. Z. B. kann es in einer Überlastsituation einige Anfragen ablehnen (load shedding). Oder wenn es seine Datenbank nicht erreichen kann, kann es immer noch auf Anfragen mit gecachten Daten antworten, aber es akzeptiert keine Schreibanfragen. Aber egal wie das System seinen Service-Level reduziert, es muss eine definierte Reduktion des Service-Levels sein, d. h. der reduzierte Service-Level muss in der Spezifikation des Systemverhaltens beschrieben sein. Andernfalls wäre es eine Abweichung vom spezifizierten Verhalten, d. h. ein Ausfall.

Wenn das System in einem reduzierten Service-Level läuft, wird es versuchen, so schnell wie möglich zum normalen Service-Level zurückzukehren. Typischerweise wird ein externer Supervisor, Fehlerbehandler (Error Handler), Control Plane oder Wartungsjob, der Zugang zu mehr Zeit, Informationen und Ressourcen hat, versuchen, das Problem zu lösen und den vollumfänglichen Service-Level wieder herzustellen.

Graceful degradation of service ist eine Variante des Fallback-Patterns, das zuvor als erste typische Maßnahme erwähnt wurde. Das Fallback-Pattern stellt grundsätzlich die Frage, was zu tun ist, wenn etwas nicht wie beabsichtigt funktioniert, also: „Was ist der Plan B, wenn Plan A fehlschlägt?”.

Die Fallback-Aktion ist oft eine Aktion, die aus Nutzungssicht einen reduzierten Service-Level bietet. Je nach Kritikalität des Systems und seinem fachlichen Design bedeutet ein Fallback jedoch nicht notwendigerweise einen reduzierten Service-Level. Es bedeutet einfach, einen anderen Pfad auszuführen, wenn der primäre Pfad aufgrund eines technischen Fehlers nicht funktioniert.

Der Hauptaspekt des Fallback-Patterns ist, dass die alternative Aktion ein anderes Verhalten in Bezug auf die Geschäftslogik bedeutet. Das bedeutet, die Entscheidung, was zu tun ist, falls Plan A fehlschlägt, kann nicht einer Software-Entwicklerin überlassen werden, die gerade den Code für einen Remote-Aufruf schreibt und sich verzweifelt fragt, wie sie denn eine potenzielle IOException oder ähnliches handhaben soll, die der Remote-Aufruf zurückgeben kann. Die arme Entwicklerin kann nicht wissen, was in einer solchen Situation zu tun ist, welche alternative Logik zu implementieren ist.

Daher ist die typische Fehlerbehandlung, wenn sie einfach dem/r Entwickler/in überlassen wird, die gefangene Exception erneut zu werfen, meist verpackt in eine Runtime-Exception (oder welchen Mechanismus auch immer deine Programmiersprache bietet, um eine Exception zu erstellen, die nicht explizit auf jeder Call-Stack-Ebene behandelt werden muss, die sie durchläuft).

Die Exception wird dann schließlich vom generischen Exception-Handler abgefangen, der Teil der primären Anfrageverarbeitungsschleife auf der obersten Ebene ist. Dort wird die Exception meistens schlicht in das Log geschrieben, weil auch auf dieser Ebene nicht bekannt ist, wie die Exception zu behandeln ist. Schließlich wird die Verarbeitung mit der nächsten externen Anfrage fortgesetzt, weil das Terminieren des Services keine Option ist. Und die Benutzer/innen fragen sich dann, warum das System ihre Anfragen stillschweigend „verschluckt", ohne etwas zu tun.⁵

Daher bedeutet die Implementierung eines Fallbacks immer, die fachlichen Experten einzubeziehen. Die Leitfrage ist: Wie soll das System reagieren, wenn X nicht funktioniert (wobei X eine Aktion ist, die aufgrund eines technischen Fehlers fehlschlagen kann, z. B. ein fehlschlagender Remote-Aufruf)? Basierend auf der Kritikalität und Wichtigkeit der fehlschlagenden Aktion werden die Antworten sehr unterschiedlich sein. Z. B. kann eine fehlschlagende Anfrage an eine Recommendation-Engine stillschweigend ignoriert werden (aber ohne den Rest des Verarbeitungspfads zu überspringen, wie oben skizziert), während ein stillschweigendes Fehlschlagen des Checkout-Prozesses in einem E-Commerce-System keine Option ist wird, weil das Unternehmen an der Stelle normalerweise sein Geld verdient.

Es bedeutet auch sehr unterschiedliche Entwicklungs- und Laufzeit-Budgets, die für den Fallback ausgegeben werden können, von keinem bis zu sehr großen Budgets. All das kann die IT-Abteilung nicht allein entscheiden – und sollte es auch nicht. Die Fachbereiche müssen in den Entscheidungsprozess einbezogen werden, wie ein Ausfall am besten zu handhaben ist.

Das ist einer der großen Unterschiede zwischen dem Plateau der Stabilität und dem Plateau der Robustheit. Auf dem Plateau der Stabilität war die Idee, dass Ausfälle mit rein technischen Mitteln vollständig vermieden werden können. Daher mussten sich die Fachbereiche nicht um Ausfälle kümmern. Auf dem Plateau der Robustheit ist klar, dass Ausfälle unvermeidlich sind und sich zu eigen gemacht werden müssen. Das schließt die Entscheidung auf fachlicher Ebene ein, wie potenzielle Ausfälle zu handhaben sind, d. h. die Fachbereiche sind Teil des Spiels.

Trade-offs

Der Ansatz des Plateaus der Robustheit hat mehrere Trade-offs:

• Es erfordert mehr Aufwand, das Plateau zu erreichen, insbesondere auch im Vergleich zum Aufwand, der erforderlich ist, um das Plateau der Stabilität vom Tal aus zu erreichen.
• Ein Wandel der Denkweise von der Vermeidung von Ausfällen hin zum „Umarmen” von Ausfällen (englisch: Embrace; sich zu eigen machen) ist erforderlich, was typischerweise der schwierigste Teil ist. Ein Wandel der Denkweise ist nie einfach und erfordert Zeit und Aufwand.
• Der Wirkungsradius wächst von reinen IT-Systemen zu IT-Systemen und teilweise Prozessen (aufgrund rigoroser Automatisierung und des zusätzlichen Fokus auf die Reduzierung von MTTR).
• Der Wirkungsradius dehnt sich von der IT-Abteilung allein zu sowohl der IT-Abteilung als auch den Fachbereichen aus, die beide in den Entscheidungsprozess einbezogen werden, wie Ausfälle am besten zu handhaben sind.
• Eine sehr enge Ops-Dev-Zusammenarbeit ist erforderlich, um zu verstehen, ob die implementierten Maßnahmen die gewünschte Wirkung erzielen und um Ausfälle, die Code-Änderungen erfordern, schnell zu bearbeiten.
  Der Ansatz funktioniert gut mit einem „Economies of Speed"-Geschäftsmodell, d. h. in Unternehmen, die sich auf Markt-Feedback-Zykluszeiten konzentrieren, weil es die Notwendigkeit unterstützt, schnell auf externe Kräfte zu reagieren. Dieselben technischen und prozessualen Maßnahmen, die eine schnelle Fehlerbehandlung ermöglichen, können auch genutzt werden, um IT-seitig schnell auf sich ändernde Marktbedürfnisse und -anforderungen zu reagieren.
• Es ist möglich, mit diesem Ansatz sehr hohe Verfügbarkeit zu erreichen. Als Faustregel können mehrere Neunen (höher als 99,9 %) für eine einzelne Laufzeitkomponente erreicht werden und auch mehr als 99,9 % sind für eine Gruppe zusammenarbeitender Services erreichbar.
• Resilienz wird teilweise erreicht – bekannte widrige Ereignisse und Situationen können erfolgreich gehandhabt werden.

Wann ist es sinnvoll

Ein solches Setup ist gut, wenn deine Verfügbarkeitsanforderungen hoch sind – als Faustregel 99,9 % und mehr.

Es ist auch geeignet, wenn ein System intern verteilt ist, z. B. mit einem Microservice-Ansatz oder wenn viele andere Systeme aufgerufen werden müssen, um eine externe Anfrage abzuarbeiten. Da sehr hohe Verfügbarkeiten der einzelnen Laufzeitkomponenten erreicht werden können, ist die Gesamtverfügbarkeit der Gruppe von Komponenten, die an der Beantwortung einer externen Anfrage beteiligt sind, normalerweise immer noch ausreichend, ohne dass zusätzliche Verfügbarkeitsmaßnahmen auf der Komponentengruppenebene implementiert werden müssen.

Wann ist es zu vermeiden

Ein solches Setup ist nicht ausreichend für sicherheitskritische (safety critical) Kontexte.

Es neigt auch dazu, unzureichend zu sein, wenn die Verfügbarkeitsanforderungen sehr hoch sind, aber die technische Umgebung sehr ungewisse Verfügbarkeitseigenschaften aufweist.

Es neigt auch dazu, unzureichend zu sein, wenn hohe Innovationsgeschwindigkeit in hochgradig ungewissen Geschäftsumgebungen erforderlich ist.⁶

Der Kernaspekt in allen drei Fällen ist das Maß an Ungewissheit. Ungewissheit führt zu Überraschungen, d. h. zu nicht vorhergesehenen Situationen. Das Plateau der Robustheit behandelt jedoch nur erwartete Ausfallmodi. Überraschungen sind nicht abgedeckt (siehe auch den blinden Fleck unten). Wir werden dies im nächsten Beitrag ausführlicher diskutieren.

Wirkungsradius

Der Wirkungsradius umfasst die IT-Systeme, die IT-Abteilung, die Fachabteilungen und berührt die Prozesse (bezüglich Automatisierung und Reduzierung von MTTR).

Blinder Fleck

Der blinde Fleck dieses Setups sind die Grenzen der Wahrnehmung. Es funktioniert gut für erwartete Ausfallmodi. Es kann jedoch nicht mit unerwarteten Ausfällen, also Überraschungen umgehen.

Zusammenfassung

Das Plateau der Robustheit ist die zweite Zwischenstation auf unserer Reise zur Resilienz. Es akzeptiert, dass Ausfälle unvermeidlich und vielfältig sind. Daher ändert es die Einstellung von der Vermeidung von Ausfällen hin zum „Umarmen” (sich zu eigen machen) von Ausfällen.

Es braucht einigen Aufwand, das Plateau zu erreichen: Ein Wandel der Denkweise ist nötig. Mehr Parteien sind beteiligt. Prozesse sind teilweise betroffen. Mehr Ausfallmodi werden berücksichtigt. Maßnahmen müssen oft auf Anwendungsebene implementiert werden und können nicht einfach Infrastruktur- und Middleware-Mittel nutzen. Daher haben noch nicht so viele Unternehmen dieses Plateau erreicht.

Es ermöglicht sehr gute Verfügbarkeit, auch wenn das zugrunde liegende System intern verteilt ist. Es ist jedoch nicht geeignet für sicherheitskritische Systeme.

Im nächsten Beitrag werden wir diskutieren, was es bedeutet, sich auch auf Überraschungen vorzubereiten, die Erkenntnisse, die nötig sind, um uns zum nächsten Plateau zu leiten, und das wahrscheinlich größte Hindernis, dem wir auf unserer Reise begegnen werden. Bleibt dran … ;)

¹ Ich verwende den Begriff „Stabilität" hauptsächlich, um diesen Ansatz vom Robustheitsansatz zu unterscheiden. Je nach Argumentation kannst du beide Begriffe austauschbar verwenden. Ich verbinde jedoch einen gewissen Grad an Starrheit mit „Stabilität", während ich „Robustheit" mit einem gewissen Grad an Flexibilität verbinde. Z. B. ist ein Betonpfeiler in diesem Sinne stabil, während ein Baum robust ist. Der Betonpfeiler wird bis zu einem bestimmten Stresslevel ohne wahrnehmbare Verformung standhalten und dann zerbrechen, während der Baum unter Stress eher nachgeben und nach Ende des Stresses zu seiner ursprünglichen Form zurückkehren wird (natürlich wird auch ein Baum schließlich brechen, wenn das Stresslevel zu hoch wird, aber normalerweise kann er Stress viel besser absorbieren und sich davon erholen als ein Betonpfeiler vergleichbarer Größe).

² Ich betone immer, dass der reduzierte Service-Level, auf den eine Anwendung als Teil einer Fehlermilderungsmaßnahme zurückfallen kann, definiert werden muss. Wenn ein Fehler auftritt und die Anwendung weiterarbeitet (anstatt einfach abzustürzen oder nicht mehr zu antworten), wird sie automatisch auf eine Art reduzierten Service-Level zurückfallen (z. B. erst nach ein paar Sekunden antworten, anstatt nach weniger als einer halben Sekunde zu antworten). Wenn dieser reduzierte Service-Level jedoch nicht als Teil der möglichen Systemverhaltensspezifikation definiert ist, wird er dennoch als Ausfall betrachtet, denn: Das Verhalten des Systems weicht von seiner Spezifikation ab. So einfach ist das. In solchen Situationen wenden Menschen oft ein, dass ihre Systeme keine definierte Spezifikation ihres Verhaltens hätten. Meine typische Antwort dann ist (etwas flapsig): Viel Glück! Wenn du keine Spezifikation des erwarteten Verhaltens deiner Systems bereitstellst (zumindest als SLA), werden deine Kunden und Benutzer*innen eine implizite Erwartungshaltung entwickeln, die grundsätzlich sein wird: 100 % verfügbar. Immer. Keine Bugs. Keine Ausfälle. Nie. Niemals. Und wenn du einmal nicht sauber abgeklärt haben solltest, wie eine umzusetzende Anforderung eigentlich gemeint war, erwarten deine Kunden und Benutzer*innen implizit, dass du bitteschön genau die Vorstellung implementierst, die ausschließlich in ihren Köpfen existiert. Grundsätzlich ist das erwartete Verhalten die 100 %-Verfügbarkeitsfalle in Reinform, einschließlich des erwarteten Verhaltens, von dem du nie gehört hast, weil es halt nur im Kopf deiner Ansprechpartner*innen existiert. Das bringt dich in eine unangenehme Situation, wenn irgendein Problem auftreten sollte. Deine Ansprechpartner*innen werden darauf bestehen, dass ihre Vorstellung des Systemverhaltens korrekt ist und du falsch liegst. Du wirst einen aussichtslosen Kampf führen, weil eine gemeinsam vereinbarte Spezifikation des Systemverhaltens nicht existiert – nur Vorstellungen und Erwartungshaltungen in den Köpfen der Menschen. Und da deine Ansprechpartner*innen üblicherweise auch deine Auftraggebenden sind, wirst du den Kampf verlieren. Daher ist meine Empfehlung, das erwartete Systemverhalten immer explizit zu machen. Du wirst immer noch Diskussionen über das erwartete Systemverhalten haben und deine Ansprechpartner*innen werden immer noch versuchen, dich in Richtung der 100%-Verfügbarkeitsfalle zu drängen, die in ihren Köpfen lebt. Aber jetzt hast du die Diskussion explizit gemacht und du kannst deine Ansprechpartner*innen dabei unterstützen, ihre Verfügbarkeitserwartungen und das Geld, das sie bereit (oder in der Lage) sind auszugeben, um sie zu erreichen, auszubalancieren.

³ Wenn jeder vollständige Parameterprüfung ordnungsgemäß implementieren würde, würden wahrscheinlich mehr als 90 % aller bekannten CVEs (Common Vulnerabilities and Exposures) nicht existieren.

⁴ Observability bedeutet, dass du den internen Zustand (State) und die Verfassung (Condition) eines Systems verstehen und darüber nachdenken kannst, indem du seine extern sichtbaren Signale beobachten. Das schließt beliebige (ad-hoc) Abfragen auf den extern beobachteten (und gesammelten) Signalen ein. Traditionell wird dies von Monitoring-Lösungen nicht unterstützt. Stattdessen liegt ihr Fokus auf der Beobachtung vordefinierter Signale und dem Auslösen von Alarmen, wenn spezifische Schwellenwerte überschritten werden. Die Unterscheidung zwischen den Themen ist etwas unscharf und du findest widersprüchliche Definitionen (und die Tatsache, dass viele Monitoring-Lösungsanbieter ihre Lösungen neuerdings in „Observability-Lösungen" umbenannt haben, macht die Sache nicht einfacher). Wenn man jedoch auf die ursprünglichen, nicht-IT Definitionen der Begriffe schaut, kann man vereinfacht festhalten, dass Observability eine Obermenge von Monitoring ist.

⁵ Je nach Stelle im Ausführungspfad, an der eine stille Fehlerbehandlung des Typs „loggen und den Rest der Anfrageverarbeitung überspringen" passiert, ist es möglich, dass die Verarbeitung bereits mehrere Seiteneffekte ausgelöst hat, während Benutzende denken, dass nichts passiert ist. Als Konsequenz werden Benutzende wahrscheinlich die Anfrage erneut auslösen, möglicherweise mehrfach Seiteneffekte auslösend. Stell dir zur Veranschaulichung vor, Benutzende möchte einen Artikel bestellen. Checkout. Alles funktioniert. Dann schlägt ein relativ unwichtiger Aufruf fehl (z. B. das Schreiben einiger Echtzeit-Statistikinformationen). Der Fehler wird geloggt und der Rest der Anfrageverarbeitung, einschließlich des Teils, an dem die Benutzende über die erfolgreiche Vervollständigung des Checkouts informiert werden, wird übersprungen. In einer solchen Situation würden Benutzende höchstwahrscheinlich den „Kaufen"-Button erneut drücken, und noch einmal, und noch einmal, und dieselben Sachen immer und immer wieder bestellen. Natürlich stellen die meisten heutigen E-Commerce-Systeme sicher, dass ein solches Verhalten nicht (mehr) passiert, weil ein solches Systemverhalten die Kunde*innen massiv verärgern würde. Sollte also eine solche stille Fehlerbehandlung jemals im Checkout-Prozess implementiert gewesen sein, wäre sie inzwischen sicherlich entfernt worden. Dennoch ist das Beispiel gut, um das Problem zu veranschaulichen und es existieren viele Anfrageverarbeitungspfade in IT-Systemen, die nicht so exponiert sind wie der E-Commerce-Checkout-Prozess, die nach wie vor viele solcher „loggen und den Rest der Anfrageverarbeitung überspringen" stillen Fehlerbehandlungsroutinen implementieren.

⁶ Zur Erinnerung: Eine der Konsequenzen der laufenden digitalen Transformation ist, dass Geschäft und IT voneinander untrennbar geworden sind. Das bedeutet auch, dass du nichts auf der Geschäftsseite ändern kannst, ohne die IT anzufassen. Daher begrenzt die Fähigkeit und Geschwindigkeit der IT, auf neue Anforderungen zu reagieren (ohne die Qualität zu kompromittieren), wie schnell die Fachseite auf Marktbewegungen reagieren kann.

Dieser Blogpost ist ursprünglich auf Englisch in Uwe Friedrichsens Blog erschienen.