Der lange und steinige Weg zur Resilienz – Teil 7

Das Hochplateau der grundlegenden Resilienz

Im vorherigen Beitrag haben wir darüber gesprochen, was es bedeutet, sich auch auf Überraschungen vorzubereiten, welche Erkenntnisse uns zum nächsten Plateau führen und was dabei wahrscheinlich das größte Hindernis ist: Effizienz-Besessenheit.

In diesem Beitrag werden wir uns damit befassen, was uns auf dem dritten Plateau erwartet, dem Hochplateau der grundlegenden Resilienz.

Das Hochplateau der grundlegenden Resilienz

Das Hochplateau der grundlegenden Resilienz ist die dritte Zwischenstation, die Unternehmen auf ihrem Weg zur Resilienz in der Regel erreichen.

Dort sind nur wenige Unternehmen angekommen – zumindest aus IT-Sicht. Die Hauptgründe dafür sind:

• Es braucht Zeit, um zu akzeptieren, dass Überraschungen unvermeidlich sind.
• Die Vorbereitung auf Überraschungen erfordert in der Regel Veränderungen in den Prozessen und der Organisation – und Veränderungen sind bekanntermaßen schwierig.
• Resilienz und Effizienz sind gewissermaßen Gegenspieler. Hocheffiziente Organisationen können nicht resilient sein, und resiliente Organisationen sind nicht hocheffizient. Das Schlüsselwort ist „hoch“. Resiliente Organisationen sind in der Regel effizient, aber sie versuchen nicht, das letzte Quäntchen Effizienz aus ihrer Organisation herauszupressen. Effizienz und Resilienz müssen in Einklang gebracht werden, was in der Regel äußerst schwierig ist, da die meisten Organisationen so sehr auf Effizienz fixiert sind, dass ihre Antwort auf alle Probleme „mehr Effizienz” lautet, was Resilienz verhindert. Wir haben diesen Punkt bereits im vorherigen Beitrag diskutiert.

Wie zuvor bedeutet der Übergang zum Hochplateau der grundlegenden Resilienz nicht, dass die tiefer gelegenen Plateaus irrelevant werden. Es ist ziemlich sinnlos, mit Überraschungen umgehen zu können, wenn wir mit erwarteten widrigen Ereignissen und Situationen nicht richtig umgehen können. Daher brauchen wir weiterhin die Konzepte aus den tiefer gelegenen Plateaus.

Robustheit ausbalancieren

Die Konzepte des neuen Plateaus schaffen eine weitere Ebene und ergänzen die bisherigen Konzepte. Sie helfen auch dabei, Prioritäten neu zu justieren und zu optimieren. Auf dem Plateau der Robustheit haben wir gelernt, dass es nicht sinnvoll ist, die MTTF übermäßig zu maximieren. Auf dem Hochplateau der grundlegenden Resilienz lernen wir, dass es nicht sinnvoll ist, unsere Anwendungen übermäßig robust zu gestalten.

Dafür gibt es zwei Gründe:

• Jede Robustheitsmaßnahme erhöht die Komplexität der Lösung. Der Code wird komplexer. Die Laufzeitumgebung wird komplexer. Komplexität steht jedoch im Widerspruch zu Robustheit. Je einfacher eine Lösung ist, desto robuster ist sie in der Regel: leichter zu verstehen, weniger bewegliche Teile zur Laufzeit, weniger fehleranfällig. Das bedeutet, dass wir ein Gleichgewicht zwischen der Einfachheit der Lösung und dem Umfang der integrierten Robustheitsmaßnahmen finden müssen. Wie so oft liegt das Optimum zwischen den beiden Extremen.
• Robustheitsmaßnahmen können manchmal zu unerwarteten, emergenten Verhaltensweisen führen. Das heißt, während sie mit der Art von widrigen Situationen, für die sie entwickelt wurden, gut umgehen können, kann es unter anderen Bedingungen zu Überraschungen kommen, wie z. B. metastabilen Ausfällen [1]. Natürlich wollen wir keine neuen unerwünschten Überraschungen hervorrufen, indem wir mit erwarteten widrigen Situationen umgehen. Daher müssen wir sorgfältig abwägen, welche Robustheitsmaßnahmen wir wie in unsere Systeme integrieren und welche Teile wir der Organisation überlassen wollen. Es ist jedoch nicht einfach, den richtigen Mittelweg zu finden, und es kann eine Weile dauern, bis wir ihn gefunden haben.

Eine gute Faustregel ist, mit einer eher geringen Anzahl von Robustheitsmaßnahmen zu beginnen, die sich gegenseitig ergänzen, und dann zu prüfen, ob zusätzliche Maßnahmen erforderlich sind. Sich gegenseitig ergänzende Maßnahmen sind Maßnahmen, die in Kombination mehr unerwünschte Ereignisse und Situationen bewältigen können als einzeln, d. h. zusammen bilden sie eine Art Konstellation, bei der „das Ganze mehr ist als die Summe seiner Teile“. Es kann eine Weile dauern, bis man eine solche Reihe sich wechselseitig ergänzender Maßnahmen identifiziert hat, aber letztendlich lohnt sich der Aufwand.

Bewertung des Hochplateaus der grundlegenden Resilienz

Nach diesen einleitenden Bemerkungen wollen wir nun das Hochplateau der grundlegenden Resilienz anhand des bereits bekannten Bewertungsschemas genauer erkunden.

Haupttreiber

Der Haupttreiber ist, das Unerwartete zu erwarten.

Mit der Akzeptanz, dass Überraschungen unvermeidlich sind, kommt die Erkenntnis, dass wir uns auf sie vorbereiten müssen, wenn wir das Risiko verringern wollen, von der nächsten Überraschung, die uns trifft, aus der Bahn geworfen zu werden.

Leitfragen

Dies führt zu einer ganz anderen Reihe typischer Leitfragen, wie z. B.:

• Wie kann ich die Wahrscheinlichkeit maximieren, einen unerwarteten Fehler schnell zu erkennen und darauf zu reagieren, bevor er zu einem Ausfall führt?
• Wie kann ich mich am besten organisieren, um schnell und erfolgreich auf unerwünschte Überraschungen reagieren zu können?
• Welche Ressourcen benötigt meine IT-Organisation, um schnell und erfolgreich auf unerwünschte Überraschungen reagieren zu können?
• Wie schaffe ich ein Gleichgewicht zwischen Resilienz und Effizienz?

Es ist wichtig zu verstehen, dass wir nicht garantieren können, dass uns Überraschungen niemals aus der Bahn werfen werden, egal wie sehr wir uns auch bemühen. Wir können lediglich die Wahrscheinlichkeit verringern. Eine 50-prozentige Chance, einer unangenehmen Überraschung standzuhalten oder sich schnell davon zu erholen, ist jedoch viel besser als eine 0-prozentige Chance. Wenn du mit einem sicherheitskritischen System arbeitest, kann jedes zusätzliche Prozent letztendlich Menschenleben retten oder Verletzungen verhindern.

Resilienz wirkt sich auch auf die Organisation und Prozesse aus. Da wir in der Regel aus Organisationen kommen, die auf Effizienz optimiert sind, müssen wir unsere Prozesse und Organisationen höchstwahrscheinlich bis zu einem gewissen Grad ändern, um resilient zu werden. Das Gute daran ist, dass resiliente Organisationen in der Regel perfekt für hochdynamische VUCA-artige Märkte geeignet sind, in denen die eigene Reaktionsgeschwindigkeit und Flexibilität entscheidend sind (“economies of speed”). Sich für hochdynamische Märkte (die heute meistens gegeben sind) aufzustellen, erfordert ähnliche Maßnahmen wie das Streben nach Resilienz. [2]

Wir haben bereits im vorherigen Beitrag darüber gesprochen, dass wir ein Gleichgewicht zwischen Effizienz und Resilienz finden müssen. Effizienzoptimierung bedeutet, eine Aufgabe mit möglichst wenigen Ressourcen zu erledigen. Resilienz hingegen erfordert gewisse Reserven an Ressourcen und personellen Kapazitäten, um unerwartete Widrigkeiten zu bewältigen oder sich schnell davon erholen zu können. Wenn wir also unsere Resilienz wirklich verbessern wollen, müssen wir die Effizienz so ausbalancieren, dass sie die Resilienz nicht beeinträchtigt.

Typische Maßnahmen

Wir betreten einen Bereich, in dem wir nicht nur die IT-Systeme berücksichtigen müssen, sondern insbesondere auch die umgebende Organisation und Prozesse. Daher konzentrieren sich die typischen Maßnahmen auch eher auf die Organisation und die Prozesse als auf die technischen Systeme:

• Selbstorganisierte Teams tragen dazu bei, die spontanen Kooperationsmuster zu etablieren, die wir benötigen, um mit unerwarteten Situationen umzugehen.
• Fire Drills und Chaos Engineering schaffen die erforderliche Routine und tragen dazu bei, Überraschungen „langweilig“ zu machen.
• Bestärken breiten Wissens und Kreativität fördert unkonventionelles Denken und Kreativität, was oft erforderlich ist, um unerwartete widrige Situationen erfolgreich zu meistern.
• Spielraum („Slack”) im System bietet die Kapazitäten und Ressourcen, die erforderlich sind, um unerwarteten Widrigkeiten standzuhalten oder sich schnell davon zu erholen.
• Observability der IT-Systeme erhöht die Wahrscheinlichkeit, drohende widrige Situationen früher zu erkennen, und hilft, die Situationen besser zu analysieren.

Trade-offs

Der Ansatz des Hochplateaus der grundlegenden Resilienz hat mehrere Vor- und Nachteile:

• Es erfordert viel Arbeit und Mühe, um dieses Plateau zu erreichen, insbesondere aufgrund der erforderlichen Veränderungen in Bezug auf die Organisation und die Prozesse.
• Ein Umdenken ist erforderlich, weg von der Effizienz-Besessenheit hin zu einem vernünftigen Gleichgewicht zwischen Effizienz und Resilienz, was für Unternehmen, die traditionell auf Effizienz fixiert sind, oft sehr schwierig ist.
• Das gesamte soziotechnische System muss berücksichtigt werden.
• In der Regel müssen die Kooperationsmodelle an den Systemgrenzen neu gestaltet werden, d. h. die Art und Weise, wie die jeweiligen Geschäfts- und IT-Abteilungen (oder funktionsübergreifende, prozessorientierte Teams) mit anderen Teilen des Unternehmens interagieren.
• Der Ansatz funktioniert sehr gut mit einem “Economies of Speed”-Geschäftsmodell, d. h. für Unternehmen, die sich auf Markt-Feedback-Zykluszeiten konzentrieren.
• Er ermöglicht eine sehr hohe Verfügbarkeit, selbst im Angesicht unerwarteter widriger Situationen.
• Er ermöglicht eine sehr hohe Innovationsgeschwindigkeit, ohne die Zuverlässigkeit selbst in hochgradig ungewissen und unklaren Umgebungen zu beeinträchtigen. [3]
  Resilienz, d. h. die Fähigkeit, erwartete und unerwartete widrige Ereignisse und Situationen erfolgreich zu bewältigen, wird erreicht.

Wann ist es sinnvoll

Eine solche Aufstellung ist für sicherheitskritische Kontexte auf jeden Fall erforderlich.

Sie eignet sich auch, wenn die Verfügbarkeitsanforderungen sehr hoch sind, die technische Umgebung jedoch tendenziell sehr unzuverlässig ist.

Außerdem eignet sie sich, wenn hohe Innovationsgeschwindigkeit in hochgradig ungewissen Geschäftskontexten erforderlich ist.

Wann ist es zu vermeiden

Eine solche Konfiguration reicht nicht aus, wenn sich die Angriffsfläche (“Threat surface”) häufig ändert (siehe auch „Blinder Fleck“ weiter unten).

Wirkungskreis

Der Wirkungskreis umfasst das gesamte soziotechnische System, d. h. er umfasst die IT-Systeme, die IT-Abteilung, die Fachabteilungen, die Prozesse, die Organisation und die Kooperationsmodi an den (soziotechnischen) Systemgrenzen.

Blinder Fleck

Der blinde Fleck dieser Konfiguration ist der Mangel an Weiterentwicklung. Die Organisation ist zwar in der Lage, mit Überraschungen umzugehen, lernt aber nicht dazu und passt sich so nicht kontinuierlich an eine sich verändernde Bedrohungslage an.

Zusammenfassung

Das Hochplateau der grundlegenden Resilienz ist die dritte Zwischenstation auf unserem Weg zur Resilienz. Hier akzeptieren wir, dass Überraschungen unvermeidlich sind und dass Überraschungen nicht allein durch technische Systeme behandelt werden können, sondern dass Menschen mit einbezogen werden müssen. Daher ändert sich unsere Grundeinstellung zu “Erwarte das Unerwartete” und wir berücksichtigen das gesamte soziotechnische System.

Es erfordert viel Aufwand, um dieses Plateau zu erreichen: Eine große Umstellung in der Denkweise ist erforderlich. Es sind mehr Parteien beteiligt. Prozesse und die Organisation sind betroffen. Die Kooperationsmodi an den Systemgrenzen sind betroffen. Daher haben bisher nur wenige Unternehmen dieses Plateau erreicht.

Es ermöglicht hervorragende Verfügbarkeit, selbst wenn widrige Überraschungen auftreten. Daher eignet es sich auch für sicherheitskritische Kontexte. Allerdings schöpft es das volle Potenzial der Resilienz nicht aus, da es keine kontinuierliche Anpassung an eine sich verändernde Bedrohungslage ermöglicht.

Im nächsten Beitrag werden wir uns damit befassen, was erforderlich ist, um sich kontinuierlich an eine sich wandelnde Bedrohungs- und Überraschungslandschaft anzupassen, die uns schließlich auf den Gipfel des Berges der Resilienz bringen wird. Bleibt dran … ;)

1) Metastabile Fehler sind Fehlermodi, die aufgrund unerwarteter Nebenwirkungen von Robustheitsmaßnahmen auch dann bestehen bleiben, wenn die ursprüngliche Fehlerursache beseitigt wurde. Wer sich näher mit diesem Thema befassen möchte, dem empfehle ich zunächst als Einführung „Metastable Failures in Distributed Systems” von Bronson et al. sowie „Metastable Failures in the Wild” von Lexiang et al., das eine praktische Untersuchung des Themas enthält.

2) Ergänzend ist zu beobachten, dass Economies of Speed nicht versuchen, die Effizienz zu maximieren (Minimierung der Herstellungskosten). Stattdessen versuchen sie, die Effektivität zu maximieren (Maximierung des Umsatzes durch Maximierung der Wirksamkeit der Arbeit). Um die Gewinne zu maximieren, versuchen sie, die linke Seite der Bilanz zu verbessern, nicht die rechte Seite. Aus wirtschaftlicher Sicht versucht Resilienz, das Risiko von Umsatzverlusten (aufgrund von Nichtverfügbarkeit) zu minimieren, d. h. sie zielt ebenfalls auf die linke Seite der Bilanz ab. Daher stehen Resilienz und Economies of Speed nicht im Widerspruch zueinander, wie dies bei Resilienz und Effizienz-Besessenheit der Fall ist. Eine ausführlichere Diskussion über Effizienz und Effektivität findest du im (englischen) Blogbeitrag „Forget efficiency”.

3) Denke daran, dass eine der Folgen der fortschreitenden digitalen Transformation darin besteht, dass Geschäft und IT nicht mehr voneinander trennbar sind. Das bedeutet auch, dass wir auf der Geschäftsseite nichts ändern können, ohne die IT anzufassen. Daher begrenzt die Geschwindigkeit, mit der die IT Änderungen ohne Qualitätseinbußen (was für Robustheit und Resilienz unerlässlich ist) implementieren und ausliefern kann, auch die Geschwindigkeit, mit der die Geschäftsseite auf Marktbewegungen reagieren kann. Darüber hinaus begrenzt die Fähigkeit der IT-Abteilung, mit erwarteten und unerwarteten widrigen Ereignissen und Situationen umgehen zu können, auch die Fähigkeit der Geschäftsseite, auf widrige Ereignisse und Situationen zu reagieren.

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