Der lange und steinige Weg zur Resilienz – Teil 1

Im Kern geht es in dieser Blogserie um drei Fragen:

1. Was ist Resilienz?
2. Wie können wir resilient werden?
3. Müssen wir immer das volle Programm durchziehen?

Die zweite Frage leuchtet wahrscheinlich sofort ein, während die erste und dritte Frage dich vielleicht zum Nachdenken bringt. Ist es nicht offensichtlich, was Resilienz ist? Und gibt es eine Alternative dazu, alles Notwendige zu tun, um resilient zu werden? Nach meinen Beobachtungen herrscht in Bezug auf Resilienz große Verwirrung. Fast jeder, mit dem ich spreche, meint etwas anderes, wenn er von Resilienz spricht.

Das führt zur dritten Frage. Oft sind die Menschen nicht wirklich an Resilienz interessiert, wenn sie über Resilienz sprechen (insbesondere im Kontext von IT). Es gibt mehrere prototypische Entwicklungsschritte, die Unternehmen auf ihrem Weg zur Resilienz durchlaufen. Je nach Aufgabenstellung kann es jedoch völlig in Ordnung sein, die Reise bei einem der Zwischenschritte zu beenden. Natürlich ist das, was sie in einer solchen Situation erreicht haben, keine wirkliche Resilienz – aber es kann völlig ausreichend sein, um ihre Aufgabe zu lösen.

Diese Blogserie basiert auf einem Vortrag, den ich einige Male gehalten habe (siehe z. B. die Aufzeichnung von J On the Beach 2024). Im Kern folgt die Blogserie demselben Handlungsstrang wie die Präsentation. Allerdings taucht sie tiefer in das Thema ein und füllt (hoffentlich) die Lücken, die die Präsentation aus Zeit- und Umfangsgründen lassen musste.

Da dies alles viel zu lang für einen einzigen Blogbeitrag wäre, habe ich es auf mehrere Beiträge aufgeteilt:

1. Was ist Resilienz? (dieser Beitrag)
2. Das Tal der Feature-Vollständigkeit
3. Das Plateau der Stabilität
4. Verfügbarkeit revisited
5. Das Plateau der Robustheit
6. Überraschungen und Antagonisten
7. Das Hochplateau der grundlegenden Resilienz
8. Reagieren auf sich verändernde Bedrohungslandschaften
9. Der Gipfel der fortgeschrittenen Resilienz (Anti-Fragilität)
10. Müssen wir immer das volle Programm durchziehen?

Die Grenzen des Geschichtenerzählens

Ursprünglich hatte ich geplant, diese Blogserie als Heldenreise zu schreiben. Aber im Laufe der Zeit wurde mir klar, dass diese Reise nicht von einer einzelnen Person gestaltet werden kann. Eine einzelne Person kann als Evangelist und vielleicht als Katalysator fungieren, um Dinge in Gang zu bringen. Sie wird jedoch nie in der Lage sein, die gesamte Reise zu gestalten.

Daher hätte die Person entweder den Staffelstab auf dem Weg weitergeben müssen, und die nächste Person hätte das Gleiche tun müssen und so weiter, was die Identifikation mit der jeweiligen Person erschwert. Oder ich hätte eine größere Gruppe auf dem Weg aufbauen müssen, was seine eigenen Herausforderungen mit sich bringt.

Daher habe ich beschlossen, von der Erzählmethode Abstand zu nehmen, da das vorliegende Thema dies schwierig macht und ich fürchte, dass dies meine persönlichen Erzählfähigkeiten übersteigt.

Folglich werde ich die Reise auf eine eher beschreibende Weise erklären, d. h. ich werde sie nicht aus der Ich-Perspektive erzählen. Stattdessen werde ich aufzeigen, was ein Unternehmen dazu bringt, von einer Stufe zur nächsten zu wechseln, wie man dorthin gelangt, welche Kompromisse die einzelnen Stufen eingehen und welche blinden Flecken sie aufweisen (die wiederum auf die nächste Stufe hinweisen).

Zwar wird die emotionale Bindung einer guten Heldenreise fehlen, aber ich hoffe, dass ich trotzdem die wichtigen Informationen vermitteln kann – wenn auch auf etwas prosaischere Weise.

Letzte Vorbereitungen

Bevor wir in die Materie einsteigen, möchte ich noch folgende Anmerkungen machen:

• In der Regel ist es besser, die Erklärung eines Themas mit der Beantwortung der Frage „Warum“ zu beginnen, anstatt mit der Frage „Was“. Das „Warum“ gibt einen Sinn. Das „Was“ ohne die Frage nach dem „Warum“ kann im schlimmsten Fall zu Solutioneering führen, dem Gestalten von Lösungen ohne zugehöriges Problem. Ich überspringe das „Warum“ hier, weil ich es bereits in früheren Blogbeiträgen erörtert habe, z. B. in dieser allgemeinen Einführung, warum wir Resilienz brauchen, oder in jüngerer Zeit als wesentlichen Baustein für eine bessere IT. Wenn du also nach dem „Warum“ suchst, empfehle ich, zuerst die oben genannten Blogbeiträge zu lesen.
• In diesem Blogbeitrag stelle ich eine Reihe von Denkmodellen vor. Auch die Reise selbst ist eine Art Modell, denn sie lässt viele Details aus, die deine tatsächliche Reise beeinflussen können. Wie ich in einem früheren Blogeintrag erörtert habe: „Alle Modelle sind falsch. Einige sind nützlich!“. Wenn also dein spezieller Weg anders verläuft, wenn du dein aktuelles Resilienzniveau nicht genau bestimmen kannst, weil du Teile von Stufe A und Teile von Stufe B umgesetzt hast, dann ist das völlig in Ordnung. Ich liefere nicht die eine und einzige unumstößliche Wahrheit. Ich versuche, dir ein Denkmodell zur Verfügung zu stellen, eine Vereinfachung der Realität, die dich dabei unterstützt, über deine Situation nachzudenken und zu überlegen, was der nächste sinnvolle Schritt sein könnte. Nicht mehr. Aber auch nicht weniger.

Nachdem das gesagt ist, wollen wir loslegen.

Was ist Resilienz?

Ich höre viele Leute über Resilienz sprechen. Schließlich ist es in Mode gekommen, „resilient“ zu sein oder zumindest eine „resiliente IT“ zu haben. Ich spreche mit IT-Entscheidungsträgern, die behaupten, sie hätten eine resiliente IT. Ich sehe Anbieter, die die Resilienz ihrer Lösungen anpreisen. Ich spreche mit Entwicklern, die resiliente Software schreiben wollen. Und so weiter.

Die Frage, die mir immer sofort in den Sinn kommt, ist: Reden wir über dasselbe? Ist es wirklich Resilienz, über die du sprichst, oder sprichst du über etwas anderes?

Was also ist Resilienz?

Vielleicht sollten wir vor der Beantwortung dieser Frage zunächst einmal aufzeigen, was Resilienz nicht ist.

Ich war überrascht, als ich feststellte, dass die Menschen dazu neigen, Dinge als resilient zu betrachten, die über einen längeren Zeitraum hinweg funktionieren. Die Argumentation lautet: Es hat bisher funktioniert. Also muss es resilient sein.

Ist es aber nicht!

Etwas ist nicht resilient, nur weil es über einen längeren Zeitraum hinweg funktioniert.

Wenn etwas über einen längeren Zeitraum hinweg funktioniert, beweist das nur, dass seine Grundkonstruktion unter den erwarteten Bedingungen funktioniert. Das ist alles. Mehr nicht.

Die Resilienz oder das Fehlen derselben zeigt sich, wenn etwas Unerwartetes, etwas außerhalb der erwarteten Bedingungen geschieht. Denk z. B. an Lieferketten. Viele Menschen waren davon überzeugt, dass die globalen Versorgungsketten sehr resilient sind, weil sie gut funktionieren. Sie funktionierten jedoch nur so lange gut, wie alles wie erwartet innerhalb sehr enger Toleranzgrenzen ablief.

Nun wollen wir etwas Unerwartetes hinzufügen. Hallo, Ever Given! Ein einziges Schiff blockierte den Suezkanal für ein paar Tage, und es dauerte Monate, bis sich die weltweiten Lieferketten davon erholt hatten – auch an Orten, die keine Verbindung zum Suezkanal hatten. So viel zur Resilienz. Die globalen Versorgungsketten sind nicht resilient. Sie funktionieren nur dann wie erwartet, wenn nichts Unerwartetes passiert.

Womit wir wieder bei der Frage wären: Was ist Resilienz?

Natürlich gibt es, wie bei vielen anderen Themen auch, im Internet die üblichen Besserwisser, die behaupten, die maßgebliche Wahrheit über Resilienz gepachtet zu haben. Das Problem ist, dass es mehr als eine einzige Person gibt und alle eine andere maßgebliche Wahrheit gepachtet haben, auf der sie bestehen, was die Dinge kompliziert macht.

Deshalb habe ich einen anderen Ansatz versucht. Ich habe Definitionen von Resilienz aus verschiedenen Quellen und Bereichen nachgeschlagen und versucht, auf dieser Grundlage eine vereinigende Quintessenz herauszudestillieren. Dabei besteht immer noch die Gefahr, dass ich beim Herausdestillieren der Quintessenz ein wichtiges Detail übersehen habe. Aber zumindest wird so der Ansatz einer einzigen, überlebensgroßen Autorität vermieden, der von den Anhängern der Autorität oft in eine dogmatische „Entweder Sie unterwerfen sich unserer Definition oder Sie sind unser Feind“-Überzeugung verwandelt wird. (1)

Ich habe also Bereiche wie Psychologie, Ökologie, Lieferkettentheorie, Organisationstheorie, Systemtechnik, IT und mehr durchforstet. Ich habe mir auch die Definitionen angesehen, die einige der führenden Köpfe auf dem Gebiet der Resilienz wie Erik Hollnagel und David Woods entwickelt haben. Insgesamt habe ich mich durch mehr als zwei Dutzend Definitionen gearbeitet (2) und versucht, eine gemeinsame Quintessenz zu destillieren. Dies führte mich zu der folgenden Definition von Resilienz:

Resilienz ist die Fähigkeit, mit widrigen Ereignissen und Situationen erfolgreich umzugehen, einschließlich

1. dem Umgang mit erwarteten widrigen Ereignissen und Situationen (Robustheit) 2. dem Umgang mit unerwarteten widrigen Ereignissen und Situationen (Bewältigung von Überraschungen) 3. der Verbesserung aufgrund widriger Ereignisse und Situationen (Antifragilität)

Beachte, dass Robustheit allein (der erste Teil der Definition) nicht gleichbedeutend mit Resilienz ist. Man muss auch in der Lage sein, unerwartete negative Ereignisse und Situationen erfolgreich zu bewältigen (der zweite Teil der Definition). Ohne die Fähigkeit, auch mit erwarteten Ereignissen und Situationen erfolgreich umgehen zu können, ist die Fähigkeit, mit Überraschungen umzugehen, jedoch von geringem Wert. Man braucht beides, um Resilienz zu realisieren. (3)

Nicht alle Definitionen von Resilienz schließen ausdrücklich die Fähigkeit ein, sich aufgrund von Widrigkeiten zu verbessern (der dritte Teil der Definition). Wenn man jedoch tiefer in das Kleingedruckte der Definitionen eintaucht, beinhalten die meisten Definitionen die Anpassung an Veränderungen oder sogar Transformation. Letztendlich ist es meiner Meinung nach kein Zeichen für echte Resilienz, wenn man immer wieder mit der gleichen Art von Problemen konfrontiert wird (auch wenn sie möglicherweise in verschiedenen Formen auftreten) und nicht darüber nachdenkt, wie man sich so anpassen kann, dass diese Art von Problemen weniger wahrscheinlich wird. Deshalb und weil viele Definitionen von Resilienz dies ausdrücklich einschließen, habe ich auch dieses Konzept in die Definition aufgenommen.

Beispiele für widrige Ereignisse und Situationen

Da wir nun wissen, was Resilienz ist, sollten wir kurz darüber nachdenken, was solche widrigen Ereignisse und Situationen im Zusammenhang mit der IT umfassen könnten:

• Die meisten Leute, mit denen ich gesprochen habe, denken zuerst an Hardware-Ausfälle und erst in zweiter Linie an Überlast-Situationen.
• Nicht wenige setzen Resilienz mit IT-Sicherheit gleich und somit widrige Ereignisse mit Cyberangriffen.
• Einige denken auch an Situationen, in denen ein zentraler Prozess (zu) langsam antwortet.
• Manche denken auch an Fehler bei den Eingabeparametern, d. h. an Eingaben, die nicht korrekt verarbeitet werden können.
• Nur wenige Menschen denken an Probleme wie einen Firmware-Fehler in einer Infrastrukturkomponente wie z. B. einem Switch.
• Auch an einen kritischen Software-Fehler als potenzielle Fehlerquelle denken nur wenige.
• Nur sehr wenige Menschen denken über tatsächliche Überraschungen nach. Ich hatte z. B. einmal die Situation, dass die dreifach redundante Kühlung unseres (einzigen) Rechenzentrums gleichzeitig ausfiel. Infolgedessen kam es bei allen Produktionsservern zu Notabschaltungen aufgrund von Überhitzung. Niemand (auch ich nicht) hatte erwartet, dass eine solche Situation jemals eintreten könnte.
• Außerdem betrachten nur sehr wenige Menschen die Geschäftsdomäne als Quelle von Überraschungen. Stell dir z. B. vor, dein stärkster Konkurrent bringt ein bahnbrechendes neues Produkt auf den Markt. Wenn du nicht in der Lage bist, sehr schnell zu reagieren, wirst du viele Kunden an deinen Konkurrenten verlieren und im schlimmsten Fall deine Überlebensfähigkeit einbüßen. Aufgrund der Folgen der laufenden digitalen Transformation betrifft dies deine IT-Organisation in gleicher Weise.

Und so weiter. Und wir haben noch nicht über die wirklich großen Unsicherheitsfaktoren gesprochen, wie eine globale Krise (COVID oder Klimawandel fallen mir als zwei populäre Beispiele ein) oder die grundsätzlich unvorhersehbaren zukünftigen geopolitischen und wirtschaftlichen Entwicklungen. (4)

Wie wir sehen, umfassen widrige Ereignisse und Situationen im Zusammenhang mit der IT viel mehr als nur die üblichen erwarteten technischen Probleme. Allerdings sehe ich nur wenige Menschen, die solche Themen – insbesondere Überraschungen – im Sinn haben, wenn sie über Resilienz sprechen. Wir werden tiefer in diese Diskussion eintauchen, wenn wir die Frage erörtern, wie wir resilient werden können.

Resilientes Software-Design

Bevor ich diesen ersten Blog Post abschließe, möchte ich noch eine ergänzende Definition hinzufügen: die Definition von resilientem Softwaredesign. Resilient Software Design (RSD) ist ein Thema, über das einige Leute (mich eingeschlossen) oft sprechen. Es ist jedoch wichtig, den Unterschied zwischen Resilienz und RSD zu verstehen.

Meine Definition für RSD:

Resilientes Softwaredesign bedeutet, softwarebasierte Systeme so zu entwerfen und zu bauen, dass ihre Zuverlässigkeit (Dependability) verbessert und somit die Resilienz im Sinne der obigen Definition unterstützt wird.

Wer einen Moment über diese Definition nachdenkt, wird feststellen, dass Softwarelösungen für sich genommen nicht wirklich resilient sind. Sie können robust sein. Es ist jedoch im Grunde unmöglich, Code für den Umgang mit Überraschungen zu implementieren, d. h. mit etwas, das man nicht erwartet, von dem man nicht einmal weiß, dass es überhaupt passieren kann. Wenn du Glück hast, wird dein Code zufällig mit der Überraschung erfolgreich umgehen. Aber das wäre nur Glück. Normalerweise wird dein System im Angesicht einer negativen Überraschung einfach versagen.

Aber selbst wenn ein Softwaresystem nicht von sich aus resilient ist, ist es von großem Wert, wenn es robust ist, d. h. wenn es mit bekannten und erwarteten negativen Ereignissen umgehen kann. Wie oben geschrieben: Ohne diese Fähigkeit ist die Fähigkeit, mit Überraschungen umzugehen, von geringem Wert: „Hey, wir sind perfekt auf Überraschungen vorbereitet. Aber unsere Systeme stürzen unweigerlich ab, wenn irgendein Teil von ihnen zeitweise unerreichbar ist.“

Robustheit ist also ein notwendiger Schritt auf dem Weg zur Resilienz. Bei RSD geht es darum, robuste IT-Lösungen zu schaffen. (5)

Zusammengefasst

Wir haben unsere Reise in Richtung Resilienz damit begonnen, zu klären, was Resilienz ist. Dies ist eine wichtige Voraussetzung für unsere Reise, denn basierend auf dem, was ich beobachte, meinen die meisten Menschen nicht Resilienz, wenn sie Resilienz sagen. Wir haben auch einige Beispiele für widrige Ereignisse und Situationen angeführt, um zu verdeutlichen, was Resilienz ist. Schließlich haben wir zwischen Resilienz und resilientem Softwaredesign unterschieden.

Nach diesen notwendigen Vorbereitungen, dem Packen des Rucksacks und der Ausrüstung sind wir nun bereit, unsere Reise anzutreten. Im nächsten Beitrag werden wir die Reise mit einem Blick auf den Ort beginnen, an dem viele Unternehmen immer noch leben, und erörtern, warum es keine gute Idee mehr ist, dort zu verweilen. Bleibt dran …

1. Natürlich werden mich all diese Jünger zu einem Feind erklären, weil ich mich ihrem Glauben nicht blindlings unterworfen habe. Aber gut, damit werde ich wohl leben müssen.
2. Ich werde hier nicht alle Definitionen auflisten, denn das wäre ein eigener Beitrag. Ich schreibe derzeit ein Buch über resilientes Softwaredesign, in dem ich einige der Definitionen, die ich durchgegangen bin, zitiere und diskutiere (ich habe Definitionen weggelassen, die im Grunde nur Wiederholungen der Definitionen waren, die ich aufgelistet habe). Leider weiß ich im Moment nicht, wann ich die Zeit finden werde, das Buch fertigzustellen. Bitte habt also Geduld mit mir.
3. Manchmal hört man Leute aus der Systemtechnik, die darauf beharren, dass Robustheit nicht Teil von Resilienz ist. Ich persönlich denke, dass dies darauf zurückzuführen ist, dass die meisten dieser Leute aus sicherheitskritischen Bereichen kommen. In sicherheitskritischen Bereichen können (und werden) Menschen sterben, wenn das System ausfällt. Daher werden all diese Systeme mit Blick auf Robustheit gebaut, d. h. Robustheit ist in diesen Bereichen im Grunde eine Selbstverständlichkeit. Die Herausforderung für diese Menschen besteht nicht darin, die Systeme robust zu machen (denn das sind sie bereits), sondern sich auf Überraschungen vorzubereiten. Daher vermute ich, dass diese Leute durch die Eigenschaften ihrer Domäne ein wenig in die Irre geführt werden, wenn es um Resilienz geht. In der IT, insbesondere in der Unternehmens-IT, sind wir jedoch weit davon entfernt, robuste Systeme zu bauen. Daher halte ich es für wichtig, auch die Bedeutung der Robustheit als notwendige Voraussetzung für die Entwicklung von Resilienz zu betonen.
4. Ich werde diese globalen Unsicherheitsfaktoren (und damit verbundenen Überraschungen) in dieser Beitragsserie nur am Rande streifen, da diese Themen für die meisten von uns „jenseits unserer Gehaltsklasse“ liegen. Es ist jedoch wichtig, sich vor Augen zu halten, dass ein völliges Ignorieren dieser Themen leicht zu einem lebensbedrohlichen Risiko für ein Unternehmen werden kann.
5. In dieser Blogserie lasse ich wirklich unangenehme Fehlermodi wie metastabile Fehler aus, d. h. Fehlermodi, die auch dann noch auftreten, wenn die ursprüngliche Fehlerursache aufgrund unerwarteter Nebeneffekte von Robustheitsmaßnahmen beseitigt worden ist. Wenn du tiefer in dieses Thema eintauchen möchtest, empfehle ich, mit der wissenschaftlichen Abhandlung „Metastable Failures in Distributed Systems“ von Bronson et al. und der Abhandlung „Metastable Failures in the Wild“ von Lexiang et al. zu beginnen, das eine praktische Untersuchung des Themas enthält.

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