Ausfallsicherheit wird zur Managementfrage, wenn Anwendungen ihre Abhängigkeiten verstecken

Ausfallsicherheit klingt im IT-Betrieb oft nach Backup, Redundanz und Runbook. Die neue Generation von AWS Resilience Hub verschiebt den Schwerpunkt aber an eine Stelle, die für ITSM- und IT-Management-Teams mindestens genauso wichtig ist: Anwendungen sollen nicht nur technisch geprüft werden, sondern mit ihren kritischen Nutzerwegen, Abhängigkeiten, Resilienz-Zielen und Nachweisen über ein Portfolio hinweg steuerbar werden. Genau dort wird aus SRE-Arbeit eine Managementfrage.

AWS kündigte Ende Mai eine deutlich erweiterte Resilience-Hub-Erfahrung an. Dazu gehören ein neues Anwendungsmodell, automatische Abhängigkeitsanalyse, generative KI für Failure-Mode-Analysen, modulare Resilienz-Policies und Reporting über AWS Organizations. Für Generalisten ist daran nicht die Produktoberfläche entscheidend, sondern die Betriebslogik dahinter: Wer hunderte Anwendungen verantwortet, braucht gemeinsame Kriterien dafür, welche Ausfälle tolerierbar sind, welche Datenverluste akzeptiert werden, welche Abhängigkeiten kritisch sind und ob die tatsächliche Architektur diese Erwartungen wirklich erfüllt.

Der blinde Fleck liegt zwischen Servicekatalog und Architektur

In vielen Organisationen gibt es bereits mehrere Wahrheiten über dieselbe Anwendung. Der Servicekatalog kennt einen Namen, die Cloud-Plattform kennt Ressourcen, die Fachseite kennt einen Geschäftsprozess, das Monitoring kennt Alarme und das Notfallmanagement kennt Recovery-Ziele. Problematisch wird es, wenn diese Sichten nicht sauber verbunden sind. Dann steht im Incident zwar fest, dass ein Service gestört ist, aber nicht, welcher Nutzerweg wirklich kritisch ist, welche internen Endpunkte betroffen sind, welche Drittanbieter mitlaufen und ob ein geplanter Change die Resilienz-Ziele schwächt.

Das neue Resilience-Hub-Modell setzt genau an dieser Lücke an. AWS beschreibt Systeme als geschäftliche Anwendungen, User Journeys als kritische Pfade und Services als deploybare Einheiten aus Ressourcen, Code und Observability. Diese Übersetzung ist für ITSM wichtiger als ein weiteres Dashboard. Sie zwingt Teams, technische Bausteine mit einem verständlichen Betriebszweck zu verbinden. Ein Datenbank-Cluster ist dann nicht nur Infrastruktur, sondern Teil eines Nutzerwegs, dessen Ausfall eine konkrete Geschäftsfolge haben kann.

Policies ersetzen Bauchgefühl nicht, sie machen Erwartungen verhandelbar

Besonders relevant ist die modulare Policy-Logik. Statt eine starre Resilienz-Schablone über alle Anwendungen zu legen, können Anforderungen wie Service-Level-Ziele, Multi-AZ- oder Multi-Region-Design und Datenwiederherstellung kombiniert werden. Das ist keine Kleinigkeit. Ein interner Reporting-Service braucht andere Ziele als ein kundenkritischer Bestellpfad. Ein Entwicklungssystem muss anders bewertet werden als ein Zahlungsprozess. Wenn solche Unterschiede nicht explizit gemacht werden, entstehen entweder überteuerte Architekturvorgaben oder gefährliche Ausnahmen ohne Managemententscheidung.

Für IT-Management heißt das: Resilienz wird zur bewusst gesetzten Erwartung, nicht zur nachträglichen Schuldfrage. Eine Policy sollte deshalb nicht allein von Architekturteams gepflegt werden. Sie gehört in einen Prozess, in dem Service Owner, Risiko, Plattformbetrieb, Security, Einkauf und Fachseite klären, welche Ziele fachlich nötig und technisch realistisch sind. Erst danach kann ein Tool sinnvoll prüfen, ob die Umgebung diese Erwartungen erfüllt.

Generative KI hilft nur, wenn die Abhängigkeiten stimmen

AWS stellt die neue Failure-Mode-Assessment-Funktion als generative KI-gestützte Analyse dar. Sie soll aktuelle Ressourcen, Topologie und Architektur auswerten, mögliche Ausfälle finden und priorisierte Empfehlungen erzeugen. Das kann SRE-Reviews beschleunigen, ersetzt aber nicht die Pflicht zur Datenhygiene. Eine KI kann keine verlässliche Betriebswirkung erklären, wenn die Anwendung falsch modelliert ist, Third-Party-Abhängigkeiten fehlen oder ein kritischer Nutzerweg gar nicht als solcher markiert wurde.

Damit verschiebt sich die Arbeit für ITSM-Teams. Es reicht nicht, am Ende eines Projekts einen Resilienz-Check anzustoßen. Schon bei Service-Onboarding, Architekturfreigabe, Provider-Auswahl, Change-Planung und Notfallübung muss klar sein, welche Komponenten zusammengehören. Sonst produziert die Analyse zwar Empfehlungen, aber keine belastbare Entscheidungsvorlage.

Organisationweites Reporting kann unbequem werden

Die Integration mit AWS Organizations ist für größere Umgebungen besonders spannend. Sie verspricht Resilienz-Reporting über Accounts, Regionen und Organisationseinheiten hinweg. Genau das kann unangenehm werden, weil Lücken sichtbar werden, die vorher in einzelnen Teams verborgen blieben. Ein Management-Dashboard zeigt dann nicht nur, wo Architektur verbessert werden könnte, sondern auch, wo Standards uneinheitlich gesetzt wurden, wo Anwendungen nie sauber eingestuft wurden und wo Nachweise für Audits oder Kundenfragen fehlen.

Aus ITSM-Sicht ist das eine Chance. Resilienz-Reporting kann ein gemeinsamer Gesprächspunkt für Service-Reviews, Risikokomitees, Provider-Gespräche und Investitionsplanung werden. Dafür muss es aber in bestehende Prozesse eingebettet werden. Ein rotes Ergebnis ohne Owner, Frist und Entscheidungspfad bleibt nur eine weitere Ampel. Ein rotes Ergebnis mit Servicebezug, Change-Optionen und akzeptierter Risikoentscheidung wird dagegen steuerbar.

Was Teams jetzt vorbereiten sollten

Der erste Schritt ist keine Tool-Einführung, sondern eine Begriffsklärung. Welche Anwendungen sind wirklich geschäftskritisch? Welche Nutzerwege zählen im Störungsfall zuerst? Welche Recovery-Ziele sind fachlich begründet und welche wurden nur aus alten Vorlagen übernommen? Welche Abhängigkeiten liegen außerhalb des eigenen AWS-Accounts? Ohne diese Antworten bleibt jede Resilienzbewertung unvollständig.

Danach braucht es einen sauberen Übergang in den Regelbetrieb. Neue Anwendungen sollten nur mit Service Owner, Kritikalität, Nutzerweg, Datenwiederherstellungsziel und Abhängigkeitsbild in den produktiven Betrieb gehen. Bestehende Anwendungen brauchen eine priorisierte Nachpflege, beginnend bei den Services mit hohem Risiko oder hoher Sichtbarkeit. Außerdem sollten Change- und Incident-Prozesse festlegen, wann eine Resilienz-Policy neu geprüft werden muss: etwa bei Architekturänderungen, neuen Datenflüssen, Providerwechseln oder größeren Automatisierungsumbauten.

Die eigentliche Botschaft der neuen Resilience-Hub-Generation lautet deshalb nicht: KI findet jetzt alle Ausfallrisiken. Sie lautet: Ausfallsicherheit wird nur dann skalierbar, wenn Geschäftsprozess, Architektur, Policy, Nachweis und Managemententscheidung zusammengeführt werden. Für ITSM-Generalisten ist das ein vertrautes Muster. Der beste Wiederanlauf beginnt nicht beim ersten Alarm, sondern bei der Frage, ob jemand vorher sauber beschrieben hat, was im Ernstfall wirklich weiterlaufen muss.