Im Jahr 2025 führten mehrere aufsehenerregende Vorfälle in der Cloud- und Internetinfrastruktur Teams weltweit erneut vor Augen, dass Störungen unvermeidlich sind und ihre Ursache häufig außerhalb des Einflussbereichs einzelner Anbieter oder Organisationsstrukturen liegt. Wenn eine große Cloud-Region ausfällt oder eine globale Traffic-Plattform nicht ordnungsgemäß funktioniert, fallen davon abhängige Anwendungen gleichzeitig und in großem Umfang aus – unabhängig davon, wie viele Neunen im SLA stehen.
Diese Ereignisse verdeutlichen ein strukturelles Missverhältnis: Viele Unternehmen setzen bei ihrer Ausfallplanung noch immer auf reaktive Wiederherstellung, während moderne verteilte Systeme schnell, weltweit und über Grenzen hinweg ausfallen, für die kein einzelnes Team verantwortlich ist. Die Frage lautet nicht mehr: Was ist zu tun, wenn eine Störung auftritt? Sondern: Wie reagiert die Architektur während und nach einem Ausfall, wie passt sie sich an und wie verbessert sie sich?
Was Resilienz in einer hybriden Multicloud-Welt bedeutet
Traditionell konzentrierten sich Resilienzstrategien auf die Rückkehr zum Normalbetrieb: Notfallwiederherstellungspläne, Ausweichstandorte sowie Zielvorgaben für die Wiederherstellungszeit und den maximal tolerierbaren Datenverlust (RTO/RPO). Dieser Denkweise lag die Annahme zugrunde, dass Ausfälle lokal begrenzt, Abhängigkeiten bekannt und Kontrollgrenzen klar definiert seien. Hybride Multicloud-Umgebungen stellen diese Annahmen auf den Kopf: Identitätsverwaltung, Routing, Speicher und Datenverteilung liegen häufig in den Händen Dritter – und wenn diese ausfallen, sind die Auswirkungen unmittelbar und global.
“Ein antifragiler Ansatz für Cyberresilienz erweitert den Wiederherstellungsanspruch von „zurück zum Ausgangszustand“ auf „zurück zum Ausgangszustand, schnell lernen und gestärkt daraus hervorgehen“. So werden Störungen zum Motor für die Weiterentwicklung der Architektur statt zu einer operativen Belastung.”
Ein „antifragiler“ Ansatz für Cyberresilienz versteht Resilienz neu: als eine Fähigkeit, die sich unter Belastung verbessert. Dazu gehört, Störungen vorherzusehen, ihren Wirkungsradius zu begrenzen, sich in Echtzeit anzupassen und Telemetriedaten aus ungewöhnlichen Betriebszuständen zu nutzen, um die Architektur so zu optimieren, dass nachfolgende, ähnliche Ereignisse weniger (oder gar keinen) Schaden anrichten. Der Erfolg bemisst sich daran, wie wenig sich eine Störung auf das System auswirkt, wie schnell sich das System währenddessen anpasst und wie sich die Architekturen infolgedessen weiterentwickeln.
Dieser Ansatz führt zu einigen klar erkennbaren Ergebnissen: kleineren, kontrollierten Auswirkungsbereichen, höherer Verfügbarkeit bei beeinträchtigten Abhängigkeiten, kürzeren Wiederherstellungszeiten, da die Systeme im Vorfeld auf Anpassungsfähigkeit ausgelegt wurden, automatisierten Reaktionen auf ungewöhnliche Bedingungen sowie größerem Vertrauen in externe Dienste, weil Resilienz gezielt entwickelt und nicht delegiert wird. Unterm Strich erweitert ein antifragiler Ansatz für Cyberresilienz den Umfang der Wiederherstellung vom bloßen „Zurückkehren zum Normalzustand“ hin zu „Zurückkehren, schnell lernen und gestärkt daraus hervorgehen“. Dadurch werden Störungen zu einem Motor für die Weiterentwicklung der Architektur statt zu einer betrieblichen Belastung.
Warum reaktive, isolierte Strategien scheitern
Vier Muster machen herkömmliche Strategien in hybriden Multicloud-Umgebungen anfällig. Zunächst ist zu beachten, dass externe Abhängigkeiten global ausfallen können. Ausfälle bei der Identitätsverwaltung oder beim Routing beeinträchtigen jeden abhängigen Dienst gleichzeitig. Zudem hat die Fehlerisolierung in vielen Architekturen nicht Schritt gehalten. Dadurch fehlen Cloud-übergreifenden Verbindungen Abgrenzungen, die Fehler eindämmen und verhindern, dass parallele Dienste beeinträchtigt werden.
Darüber hinaus sind Resilienzmaßnahmen in vielen Umgebungen fragmentiert. Notfallwiederherstellung, Datenverkehrsmanagement, Identitätsmanagement und Data Governance sind voneinander isoliert; Ausfälle halten sich jedoch nicht an diese Grenzen.
Denken Sie schließlich daran, dass die Wiederherstellung reaktiv erfolgt. Teams stellen den Betrieb wieder her, können jedoch eine Wiederholung auf struktureller Ebene nicht immer verhindern.
Die heutigen hybriden Multicloud-Umgebungen erfordern eine Resilienz, die weder reaktiv noch isoliert ist und nicht davon abhängt, dass Drittanbieter störungsfrei arbeiten.
Fünf Praktiken, um Cyberresilienzstrategien antifragil zu gestalten
Ein antifragiler Ansatz für Cyberresilienz umfasst eine Reihe technischer Praktiken, die sich über den gesamten Technologie-Stack hinweg verankern lassen, damit sich Systeme unter Belastung vorhersehbar verhalten:
- Begrenzung des Auswirkungsradius. Definieren Sie klare Vertrauens- und Fehlergrenzen, damit sich ein Ausfall in einer Region, Cloud oder Abhängigkeit nicht unkontrolliert ausbreiten kann.
- Diversifizierung von Abhängigkeiten. Schaffen Sie praktikable Alternativen für kritische Dienste. Redundanz geht über bloße Duplizierung hinaus und wird zu einer kontrollierten Wahlmöglichkeit, die verhindert, dass ein einzelner Anbieter das Systemverhalten bestimmt.
- Richtliniengesteuerte Anpassung. Ersetzen Sie statische Konfigurationen durch Richtlinien, die auf den aktuellen Zustand reagieren, insbesondere bei Routing, Authentifizierung und Vertrauensstellung.
- Inkrementelle Anpassung. Setzen Sie kleine, nachvollziehbare Architekturanpassungen um, die die Resilienz erhöhen, ohne das System zu destabilisieren.
- Beobachtungsbasierte Governance und Laufzeitautomatisierung. Nutzen Sie Telemetriedaten als Entscheidungsgrundlage und automatisieren Sie Reaktionen, damit die Anpassung beginnt, bevor Vorfälle eskalieren.
Wer ist für Cyberresilienz verantwortlich? (Tipp: alle)
Bei der Anwendungsbereitstellung in Hybrid- und Multicloud-Umgebungen kann kein einzelner Funktionsbereich – weder Sicherheit noch Netzwerk, Cloud-Betrieb oder der Anbieter – allein die Resilienz gewährleisten. Echte Resilienz erfordert ein koordiniertes Betriebsmodell, das interne Verantwortlichkeiten mit externen Abhängigkeiten in Einklang bringt und Unklarheiten bei Vorfällen reduziert.
Dies unterstützt auch die Einhaltung regulatorischer Rahmenwerke wie des EU-Gesetzes über die digitale operationale Resilienz (DORA), das Finanzinstitute zur digitalen operationalen Resilienz verpflichtet, sowie die Ausrichtung an ISO/IEC 27001), dem weltweit anerkannten Standard für Informationssicherheits-Managementsysteme. Beide betonen das Lernen, die Weiterentwicklung und den Nachweis der operativen Funktionsfähigkeit. DORA fordert Institute ausdrücklich dazu auf, über die reine Verfügbarkeit hinauszugehen und nach Ausfällen eine kontinuierliche Verbesserung („Lernen und Weiterentwickeln“) anzustreben. Dadurch wird Resilienz nicht nur mit Wiederherstellung, sondern auch mit Governance und Automatisierung verknüpft.
Fünf Ebenen einer antifragilen Unternehmensarchitektur
Um diese Praktiken zu skalieren, empfehlen wir ein gemeinsames konzeptionelles Modell: die Fünf-Ebenen-Architektur. Jede Ebene ist sowohl eine Technologieschicht als auch ein Verantwortungsbereich, in dem Resilienz entweder entsteht oder scheitert.
Die erste Ebene ist global und regelt die externe Steuerung sowie Vertrauensgrenzen durch die Begrenzung des Auswirkungsradius und richtliniengesteuertes Routing. Die Standortebene der Architektur definiert regionale Ausführungs- und Isolationszonen durch die Diversifizierung von Abhängigkeiten und Failover-Domänen. Die Plattformebene stellt Rechen- und Datenverarbeitungskapazitäten bereit und ermöglicht die Automatisierung zur Laufzeit sowie die Verlagerung von Workloads, während die Anwendungsebene Geschäftslogik und Benutzererlebnis bereitstellt, um schrittweise Anpassungen und eine kontrollierte Leistungsminderung zu ermöglichen.
Schließlich zentralisiert die Management-Ebene Observability, Governance und Orchestrierung, um eine auf Telemetriedaten basierende Weiterentwicklung von Richtlinien zu ermöglichen.
Ebenen und Praxis in die Tat umsetzen
Jede Stufe und jede Methode klingt in der Theorie überzeugend. Um jedoch das Beste aus einer antifragilen Resilienzstrategie herauszuholen, müssen Sie genau verstehen, wie sie zusammenwirken, um eine antifragile Architektur zu schaffen.
Auf globaler Ebene tragen die Begrenzung des Auswirkungsradius und die richtlinienbasierte Weiterleitung dazu bei, systemweite Ausfälle einzudämmen, bevor sie sich ausbreiten, und so die Auswirkungen auf Ihre verbundenen Systeme zu minimieren.
Auf Standortebene können Sie durch die Diversifizierung von Abhängigkeiten und die Bereitstellung von Failover-Domänen Störungen isolieren und die Kontinuität mithilfe alternativer Ausführungszonen sicherstellen.
Laufzeitautomatisierung und Workload-Mobilität ermöglichen auf der Plattformebene eine schnelle Anpassung an jede Störung. Dank automatisierter Reaktionen kann Ihr System sofort auf Ausfälle reagieren, während die Workload-Mobilität dafür sorgt, dass Ihre Anwendungen in mehreren Umgebungen bereitgestellt werden können, um die Kontinuität zu gewährleisten.
Auf der Anwendungsebene tragen schrittweise Anpassung und kontrollierte Leistungsminderung dazu bei, Störungen abzufedern, sodass das Benutzererlebnis nicht vollständig beeinträchtigt wird. So können Sie Teilausfälle überstehen und die Auswirkungen auf Ihre Endbenutzer auf ein Minimum reduzieren.
Zu den Anforderungen auf der Verwaltungsebene gehören telemetriegestützte Richtlinien, die das Ergebnis der Überführung betrieblicher Ereignisse in Verbesserungen der Governance und der Richtlinien sind. Das Lernen aus Störungen schafft eine Rückkopplungsschleife, durch die Sie Richtlinien anhand historischer Daten optimieren können, sodass Ihre antifragile Ausrichtung kontinuierlich gestärkt wird.
Zusammen machen die Ebenen und Praktiken Störungen zu einem Motor für den architektonischen Fortschritt statt zu einer permanenten Reset-Taste.
Wohin sich diese Idee entwickelt
Dieser Blogbeitrag ist nur ein Teil einer Sammlung von Artikeln, Architekturen und Demonstrationen, die Muster, Fehlermodi, Kennzahlen und Implementierungshinweise für die fünf Stufen einer antifragilen Cyberresilienzstrategie aufzeigen.
Wir empfehlen Ihnen, eine der oben aufgeführten Praktiken auszuwählen und sie als Sprint-Ziel oder Quartalsziel zu erproben. Machen Sie sich bewusst, dass eine antifragile Cyberresilienzstrategie nicht auf einen Schlag entsteht, sondern sich aus kleinen, messbaren Veränderungen entwickelt. Fangen Sie jetzt an, lernen Sie schnell und nutzen Sie den nächsten Ausfall als Gelegenheit, bei der Ihre Architektur beweist, dass sie widerstandsfähiger wird.
Lesen Sie unbedingt unsere Lösungsübersicht, wenn Sie mehr über Cyberresilienz aus einer antifragilen Perspektive erfahren möchten.
Wenn Sie tiefer in die Frage einsteigen möchten, wie Sie einen antifragilen Ansatz in Ihre Cyberresilienzstrategie integrieren können, lesen Sie dieses Architektur-Whitepaper.
Über die Autoren
Griff Shelley ist Product Marketing Manager bei F5 und auf Lösungen für die Anwendungsbereitstellung in den Bereichen Hardware, Software und SaaS spezialisiert. Mit seiner Leidenschaft dafür, innovative Technologien mit dem Erfolg seiner Kunden zu verbinden, treibt Griff Go-to-Market-Projekte für die globale und lokale Anwendungsbereitstellung, Cloud-Dienste und die Infrastruktur für KI-Datenverkehr voran. Vor seiner Karriere in der Technologiebranche war er Studienberater im Hochschulbereich und erwarb Abschlüsse an der Eastern Washington University und der Auburn University.
Weitere Blogbeiträge von Griff ShelleyColin Clauset ist Senior Product Marketing Manager bei F5 und auf SaaS-basierte Lösungen für die Anwendungsbereitstellung spezialisiert. Als Go-to-Market-Verantwortlicher betreut Colin Projekte und Services für die verteilte Anwendungsbereitstellung. Dabei gilt sein besonderes Interesse der Frage, wie Technologie komplexe Prozesse vereinfachen und so die Anforderungen von IT-Fachkräften besser erfüllen kann. Dank seiner Beratungserfahrung vor seiner Zeit bei F5 betrachtet Colin die Herausforderungen seiner Kunden ganzheitlich und entwickelt Lösungen, die über einzelne Produkte hinausgehen.
Weitere Blogbeiträge von Colin ClausetMark Menger ist Solutions Architect bei F5 und auf Technologiepartnerschaften in den Bereichen KI und Sicherheit spezialisiert. Er leitet die Entwicklung der KI-Referenzarchitektur von F5 und treibt damit sichere, skalierbare KI-Lösungen voran. Dank seiner Erfahrung als Global Solutions Architect und Solutions Engineer wirkte Mark an der Secure Cloud Architecture von F5 mit und war an der gemeinsamen Entwicklung der Distributed Four-Tiered Architecture beteiligt. Als Mitautor von „Solving IT Complexity“ verfügt er über umfassende Expertise bei der Bewältigung von IT-Herausforderungen. Zuvor war er als Anwendungsentwickler und Enterprise Architect tätig, wobei sein Schwerpunkt auf modernen Anwendungen, Automatisierung und einer schnelleren Wertschöpfung aus KI-Investitionen lag.
Weitere Blogbeiträge von Mark MengerÄhnliche Blogbeiträge
Vier Gründe, warum Sie den F5 Post-Mythos Security Summit nicht verpassen sollten
Holen Sie sich Expertenrat, um Ihre Apps, APIs und Modelle in der Post-Mythos-Welt zu schützen.
Von einer App zu einer Flotte von KI-Agenten: Ein 90-Tage-Framework für KI-Sicherheit
Vermeiden Sie den kostspieligen Ansatz „Erst bereitstellen, später absichern“ – mit einem umfassenden Framework zum Schutz von KI-Modellen, Anwendungen und autonomen Agenten.
Fünf Stufen antifragiler Cyberresilienz verwandeln Praxis in Ergebnisse
Erfahren Sie, wie fünf Stufen antifragiler Resilienz Störungen in adaptive Verhaltensweisen überführen, die Ausfälle begrenzen und hybride Multicloud-Architekturen stärken.
Warum Ihre KI-Richtlinien, Governance und Leitplanken nicht warten können
KI-Richtlinien und -Governance dürfen nicht länger als reine Formalitäten oder Zukunftsthemen betrachtet werden. Sie müssen durch praktische, durchsetzbare Leitplanken ergänzt werden.
Wenn „privat“ nicht privat ist: Wie ChatGPT-Unterhaltungen öffentlich wurden
KI verändert die Arbeitsabläufe in Unternehmen, doch eine übersehene Einstellung hat bereits Tausende vertraulicher Unterhaltungen öffentlich zugänglich gemacht
KI-Nutzung verstehen: Warum Unternehmen Transparenz brauchen
Anstatt einen zu laxen oder zu strengen Ansatz zu verfolgen, können Unternehmen durch mehr Transparenz bei der KI-Nutzung fundierte und durchsetzbare Entscheidungen treffen.