Hybrid- und Multicloud-Architekturen haben die Anforderungen an die Ausfallsicherheit grundlegend verändert. Anwendungen erstrecken sich heute über Regionen, Anbieter, SaaS-Plattformen, Content Delivery Networks (CDNs), Identitätsdienste und Edge-Umgebungen. Diese Reichweite ermöglicht Agilität und Skalierbarkeit, bringt jedoch auch systemische Risiken mit sich.
Doch für Teams, die die Technologie und Infrastruktur verwalten, auf denen unsere digitalen Präsenzen beruhen, stellt sich nicht mehr die Frage, ob es zu Störungen kommen wird. Entscheidend ist vielmehr, ob die zugrunde liegende Architektur so konzipiert ist, dass sie Störungen eindämmt, sich währenddessen anpasst und dadurch verbessert. Hier wird antifragile Cyberresilienz zu einem strategischen Faktor.
“Auf Cyberresilienz ausgelegte Architekturen kehren nicht einfach nur zum Normalzustand zurück. Sie passen sich noch während eines Vorfalls an und gehen beim nächsten Mal gestärkt daraus hervor.”
Teil 1 dieser zweiteiligen Reihe hat die Praktiken vorgestellt, die Cyberresilienz antifragil machen. Sehen wir uns nun an, wie jede Ebene die Begrenzung des Schadensradius, richtliniengesteuerte Anpassung, Diversifizierung und kontinuierliches Lernen in konkrete Maßnahmen während und nach einem laufenden Sicherheitsvorfall umsetzt.
Von resilient zu antifragil
„Resiliente Architektur“ bedeutet traditionell, Störungen zu überstehen. Antifragile Resilienz führt dieses Konzept noch einige Schritte weiter.
Ein antifragiles System begrenzt bei einer Störung deren Auswirkungen und passt sich noch während ihres Verlaufs an. Diese resilienten Praktiken lassen die aus einer Störung gewonnenen Erkenntnisse in das künftige Verhalten der Architektur einfließen und verringern so die Wahrscheinlichkeit und die Auswirkungen eines erneuten Auftretens.
Anstatt Ausfälle als Ausnahme zu betrachten, behandelt antifragiles Design Störungen als normalen Betriebszustand. Um Antifragilität in großem Maßstab umzusetzen, benötigen Unternehmen eine klare Struktur. Ein fünfstufiges Modell antifragiler Resilienz bietet diese Struktur.
Die fünf Stufen eines antifragilen Unternehmens
Die Ebenen definieren, wo Resilienz gezielt verankert werden muss. Antifragile Praktiken bestimmen, wie sich Resilienz verbessert. Gemeinsam verwandeln sie Störungen in architektonischen Fortschritt.
1. Die globale Ebene: Begrenzt systemweite Ausfälle, bevor sie sich ausbreiten
Die globale Ebene steuert allgegenwärtige Dienste, die sich über Regionen und Umgebungen erstrecken: DNS, Identitätsverwaltung, föderiertes Vertrauen und globales Traffic-Management. Hier zeigt sich antifragile Resilienz in Form von zustandsabhängigen Richtlinien, die das Routing automatisch anpassen, sobald Abhängigkeiten instabil werden – noch bevor ein Ticket eröffnet wird. Dadurch wird der Auswirkungsradius bereits durch das Design begrenzt (Namen, Authentifizierung, Routen), während globale Alternativen dafür sorgen, dass die Benutzerabläufe intakt bleiben.
Ausfälle sind hier besonders gefährlich, da diese Dienste den einzelnen Workloads übergeordnet sind. Fallen das globale Routing oder die Identitätsverwaltung aus, sind alle davon abhängigen Dienste gleichzeitig betroffen.
Antifragile Praktiken auf dieser Ebene konzentrieren sich auf drei Elemente. Die Begrenzung des Schadensradius definiert klare Vertrauens- und Fehlergrenzen, damit sich ein Ausfall in einer Region, Cloud oder Abhängigkeit nicht unkontrolliert ausbreiten kann. Richtliniengesteuerte Anpassung bedeutet, fest codierte Konfigurationen durch Richtlinien zu ersetzen, die auf den aktuellen Zustand reagieren. Entscheidungen über Datenverkehrssteuerung, Authentifizierung und Vertrauen müssen dynamisch angepasst werden. Darüber hinaus erfordert die Diversifizierung von Abhängigkeiten, Alternativen für kritische Dienste einzuführen und Wahlmöglichkeiten gezielt zu steuern, damit kein einzelner Anbieter das Systemverhalten bestimmen kann.
Wenn das System unter hoher Belastung steht, muss die globale Ebene Vertrauens- und Fehlergrenzen durchsetzen und ein richtliniengesteuertes Routing verwenden, damit sich Störungen auf Anbieterebene nicht zu unternehmensweiten Vorfällen ausweiten. Zu den wichtigsten Kennzahlen, die während eines Vorfalls überwacht werden sollten, gehören die Geschwindigkeit der automatischen Verkehrsumleitung, die Schwankung der Erfolgsquote bei der Authentifizierung, die DNS-Failover-Zeit und der Prozentsatz der Anfragen, die von alternativen Anbietern verarbeitet werden.
Ziel ist es, zu verhindern, dass ein einzelner Anbieter oder ein Ereignis auf der Steuerungsebene das unternehmensweite Verhalten bestimmt. Globale Dienste müssen Fehler eindämmen, statt ihre Auswirkungen zu verstärken.
2. Die Standortebene: Ermöglicht kontrollierte Isolation und alternative Ausführungszonen
Die Standortebene definiert regionale Ausführungsdomänen: Cloud-Regionen, Rechenzentren und Edge-Cluster.
In traditionellen Modellen waren Regionen redundante Replikate. In antifragilen Architekturen sind sie gezielt konzipierte Isolationszonen. Jeder Standort wird zu einer klar abgegrenzten Fehlerdomäne mit drei Funktionsbereichen.
Unabhängiger Betrieb bedeutet, Standorte so einzurichten, dass sie sowohl als Bestandteile eines größeren, zusammengefassten Netzwerks als auch als eigenständige Knoten fungieren können und den Nutzern dadurch im Falle eines Ausfalls ein gewisses Maß an Funktionalität erhalten bleibt.
Ein kontrolliertes Failover reduziert den „Dominoeffekt“ und die Wahrscheinlichkeit, dass sich der Ausfall eines Standorts auf andere ausweitet. Durch die Festlegung, wie und wohin Standorte ausweichen können, kann das Netzwerk als Ganzes die Auswirkungen einer Störung auffangen.
Alternative Ausführungspfade stellen eine weitere Gruppe wichtiger Funktionen dar. Sie leiten den Datenverkehr aktiv von einem ausfallenden Anbieter auf einen alternativen, unabhängigen Pfad um und entziehen so kritische Dienste dem Ausfallbereich.
Die Standortebene muss dazu beitragen, dass Standorte bei hoher Systembelastung als klar abgegrenzte Fehlerdomänen fungieren. Der Datenverkehr sollte ohne Folgewirkungen abgeleitet oder in andere Regionen beziehungsweise zu anderen Anbietern verlagert werden. Zu den wichtigsten Kennzahlen auf dieser Ebene zählen die mittlere Lösungszeit bei der Isolierung eines Standorts, die Dauer der anbieterübergreifenden Datenverkehrsverlagerung und der Anteil kritischer Dienste mit vorab validierten Alternativen.
Die Diversifizierung von Abhängigkeiten ist auf dieser Ebene von entscheidender Bedeutung, da Unternehmen sicherstellen müssen, dass tragfähige Alternativen verfügbar sind, wenn eine Region, ein CDN-Pfad oder ein Netztransitanbieter beeinträchtigt ist. Diese Ebene wandelt systemische Risiken in beherrschbare, lokal begrenzte Störungen um.
3. Die Plattformebene: Automatisiert die Reaktion und ermöglicht die Portabilität von Workloads
Die Plattformebene umfasst Kubernetes-Cluster, Virtualisierungsumgebungen und sämtliche Computing-Infrastrukturen, auf denen Workloads ausgeführt werden. In hybriden Multicloud-Umgebungen bestimmen Portabilität und Automatisierung, wie schnell die Anpassung beginnt, da menschliche Reaktionszyklen bei systemweiten Ereignissen zu langsam sind.
Antifragile Praktiken auf dieser Ebene legen den Schwerpunkt auf die Laufzeitautomatisierung, um Reaktionen in resilienten Unternehmen zu automatisieren, sodass die Anpassung beginnt, bevor der Vorfall eskaliert.
Eine weitere wichtige Praxis ist die Workload-Mobilität, bei der Anwendungen in mehreren Umgebungen bereitgestellt werden, um die Kontinuität zu gewährleisten und ein Netzwerk aus redundanten, diversifizierten Workloads zu schaffen.
Unter hoher Belastung muss die Plattformebene das System bei der automatischen Skalierung unterstützen können. Dazu müssen Circuit-Breaker-Richtlinien vorhanden sein und die Möglichkeit bestehen, Kapazität oder Betriebsmodus noch während des laufenden Vorfalls anzupassen. Zu den entscheidenden Kennzahlen auf dieser Ebene zählen die Zeit bis zur ersten automatisierten Aktion des Systems, die Anzahl der Richtlinienänderungen pro Vorfall und der Prozentsatz der Workloads mit einer zweiten Ausführungsumgebung.
Wenn sich die Zustandssignale verschlechtern, müssen Routing-Entscheidungen, Skalierungsverhalten und Sicherheitskonfiguration automatisch angepasst werden. Durch Automatisierung beginnt die Anpassung, bevor der Vorfall eskaliert, während die Diversifizierung der Workloads sicherstellt, dass kritische Dienste jederzeit verfügbar sind. Diese Ebene entscheidet darüber, ob eine Störung zu einer kontrollierten Leistungsminderung oder zu einem kaskadenartigen Ausfall führt.
4. Die Anwendungsebene: Fängt Störungen ab, ohne das Benutzererlebnis zu beeinträchtigen
Anwendungen stellen Geschäftslogik bereit und schaffen Mehrwert für die Nutzer. In herkömmlichen Architekturen gingen Anwendungsausfälle häufig mit Ausfällen der Infrastruktur einher.
Antifragiles Design ermöglicht eine schrittweise Anpassung, einschließlich einer kontrollierten Leistungsminderung anstelle eines vollständigen Ausfalls. Teams können katastrophale Ausfälle verhindern, indem sie den Funktionsumfang eines Dienstes einschränken, selbst wenn ein großer Teil davon aufgrund eines Ausfalls oder einer anderen Störung nicht verfügbar ist.
Die Priorisierung von Funktionen unter hoher Belastung ist ein weiteres entscheidendes Element der Anwendungsebene. Dadurch bleiben zentrale Benutzerabläufe verfügbar, selbst wenn nicht der volle Funktionsumfang bereitgestellt werden kann. Gleichzeitig werden wichtige Dienste davor geschützt, durch optionale Dienste beeinträchtigt zu werden.
Intelligente Wiederholungsversuche und Circuit Breaker sind kontextabhängige Strategien, die es Anwendungen ermöglichen, bei Ausfällen von Abhängigkeiten adaptiv zu reagieren, anstatt in unkontrollierte Wiederholungsschleifen zu geraten, die die Last erhöhen und Ausfälle beschleunigen können.
Die Anwendungsschicht muss nicht zentrale Funktionen bei der Lastreduzierung unterstützen, damit die zentralen Workflows weiterhin reibungslos funktionieren. Clients sollten sich an legitime Verhaltensänderungen vorgelagerter Systeme (z. B. DNS/Identität) anpassen und dabei einen Ansturm gleichzeitiger Anfragen vermeiden. Überwachen Sie erfolgreiche Bestellabschlüsse und Anmeldungen bei Teilausfällen, die Ausschöpfung von Wiederholungsbudgets sowie die Öffnungs- und Schließraten von Circuit Breakern.
Anwendungen müssen zulässige Änderungen im Verhalten vorgelagerter Systeme tolerieren. Sie müssen davon ausgehen, dass sich Identitätsanbieter, DNS-Antworten oder APIs ohne Vorankündigung weiterentwickeln können. Auf dieser Ebene wird Resilienz an der Kontinuität der Benutzererfahrung gemessen, nicht an der Verfügbarkeit der Infrastruktur.
5. Die Managementebene: Wandelt betriebliche Ereignisse in Verbesserungen von Governance und Richtlinien um
Die Managementebene umfasst Observability, Orchestrierung, Analysen und Governance. Ohne eine durch Telemetriedaten gestützte Governance stagniert die Resilienz. Vorfälle werden lediglich als erledigte Tickets abgeschlossen, anstatt zu architektonischen Verbesserungen zu führen.
Antifragile Praktiken auf dieser Ebene konzentrieren sich auf mehrere Faktoren, darunter eine beobachtungsbasierte Governance, bei der Telemetriedaten als Entscheidungsgrundlage dienen. Die Resilienz verbessert sich, wenn Entwurfsannahmen durch reales, unter Belastung erfasstes Verhalten ersetzt werden.
Um eine kontinuierliche Validierung sicherzustellen, sollten Annahmen zur Resilienz, Sicherheitskontrollen und das Verhalten der Architektur fortlaufend getestet werden – nicht nur bei planmäßigen Audits oder nach Ausfällen.
Stützen Sie die Weiterentwicklung von Richtlinien auf reales Verhalten, indem Sie Betriebsdaten (Latenz, Fehler, Failover-Ereignisse usw.) in die Governance- und Orchestrierungs-Frameworks zurückführen, um Richtlinien zu aktualisieren und zu optimieren. So lernen Systeme aus realen Ereignissen statt aus Prognosen oder Annahmen. Automatisierte Compliance-Artefakte wandeln Betriebsereignisse mit minimalem menschlichem Aufwand in überprüfbare, auditfähige Informationen um.
Die Management-Ebene stellt sicher, dass Telemetriedaten als Grundlage für die Governance dienen. IT-Vorfälle führen zur Erstellung aktualisierter Routing- und Segmentierungsrichtlinien sowie revisionsfertiger Artefakte.
Zu den wichtigsten Kennzahlen zählen die Zeitspanne vom Abschluss eines Vorfalls bis zur Aktualisierung der Richtlinien, der Anteil der Vorfälle, die zu Änderungen an Kontrollen führen, sowie die Anzahl der automatisch generierten Audit-Artefakte.
Hier wird Resilienz zu einem strategischen Faktor. Jede Störung fließt in die Optimierung der Routing-Richtlinien ein, verbessert die Segmentierung, verschärft die Vertrauensgrenzen und stärkt die Automatisierungslogik.
Wie die Ebenen zusammenwirken
Die Stärke des Modells liegt in der Integration.
- Die globale Ebene begrenzt die systemische Ausbreitung
- Die Standortebene begrenzt Ausfälle auf festgelegte Zonen
- Die Plattformebene passt sich automatisch an
- Die Anwendungsebene bewahrt die Benutzerfreundlichkeit
- Die Management-Ebene sorgt dafür, dass jede Störung das System stärkt.
Wenn diese Ebenen ganzheitlich konzipiert werden, beseitigen sie die durch fragmentierte Vorgehensweisen verursachte Anfälligkeit.
Resilienz liegt nicht mehr allein in der Verantwortung von NetOps, SecOps oder dem Cloud-Betrieb. Sie wird zu einem funktionsübergreifenden Betriebsmodell, das auf Governance, Architektur und Unternehmensstrategie abgestimmt ist.
Resilienz als strategische Fähigkeit
Hybride Anwendungsumgebungen haben – vielleicht ironischerweise – zu einer beispiellosen Konzentration von Risiken geführt. Eine kleine Gruppe von Hyperscale-Anbietern bildet das Fundament kritischer globaler Infrastrukturen. Unternehmen, die diese Technologien nutzen, können von deren Skalierbarkeit und Leistungsfähigkeit profitieren, übernehmen zugleich aber auch eine unerwünschte Anfälligkeit, die durch eine zu starke Abhängigkeit von wenigen Anbietern entsteht. Externe Abhängigkeiten vollständig zu beseitigen, ist weder machbar noch wünschenswert.
Ziel ist es, sicherzustellen, dass Ihre Architektur nicht von einer dauerhaft störungsfreien Verfügbarkeit der Anbieter ausgeht und keine unkontrollierte Ausbreitung von Ausfällen zulässt.
Eine resiliente Architektur betrachtet die Wiederherstellung nicht als Endziel und wiederholt nicht dasselbe Fehlermuster. Antifragile Cyberresilienz macht aus Störungen statt eines betrieblichen Ärgernisses einen Wettbewerbsvorteil.
Antifragile Cyberresilienz deutet Störungen von einem betrieblichen Ärgernis zu einem Wettbewerbsvorteil um und sieht dafür auf jeder Ebene konkrete Maßnahmen vor. Globale Richtlinien begrenzen die Ausbreitung. Standorte isolieren sich und leiten Datenströme um. Plattformen wechseln automatisiert auf alternative Kapazitäten. Anwendungen reduzieren ihre Leistung kontrolliert, sodass zentrale Abläufe erhalten bleiben. Das Management überführt Erkenntnisse aus Vorfällen in Richtlinien. Auf diese Weise konzipierte Architekturen kehren nicht einfach nur zum Normalbetrieb zurück. Sie passen sich noch während des Vorfalls an und gehen beim nächsten Mal gestärkt daraus hervor.
Wenn Sie mehr über Cyberresilienz aus einer antifragilen Perspektive erfahren möchten, lesen Sie unbedingt unseren vorherigen Blogbeitrag „Ein neues Konzept für Cyberresilienz in hybriden Multicloud-Umgebungen“ und werfen Sie einen Blick auf unsere Lösungsübersicht.
Wenn Sie tiefer in die Frage einsteigen möchten, wie Sie einen antifragilen Ansatz in Ihrer Cyberresilienzstrategie umsetzen können, lesen Sie dieses Architektur-Whitepaper.
Möchten Sie mit einem F5-Team über Resilienz sprechen? Kontaktieren Sie uns!
Ü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 ganzen Agentenflotte: Ein 90-Tage-Framework für KI-Sicherheit
Vermeiden Sie den kostspieligen Ansatz „Jetzt 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.