AgentSRE: Komponierbare KI-Agenten für autonome Beseitigung von Vorfällen auf AWS

Der Incident-Zyklus, der den Tag eines SRE auffrisst

Ein großer Teil des Tages eines Site-Reliability-Engineers verstreicht in einem wiederkehrenden Zyklus: Ein Alarm wird ausgelöst, jemand untersucht die Situation, es kommt zu einer Erkennung der Ursache, eine Lösung wird implementiert und das Ticket wird geschlossen. Jeder Schritt dauert Zeit, wodurch die durchschnittliche Zeit bis zur Behebung (MTTR) von Minuten bis Stunden betragen kann. Mit dem Wachstum der Cloud-Umgebungen wird diese manuelle Routine zu einem Engpass.

AgentSRE ist eine autonome Incident-Management-Plattform auf AWS, die genau diesem Engpass entgegenwirkt. Sie führt einen Incident von der Erkennung bis zur Behebung mit komponierbaren KI-Agenten durch, wobei jeder Agent auf eine bestimmte Art der Behebung spezialisiert ist. Die Architektur betrachtet die Behebung als eine Gruppe kleiner, miteinander zusammenarbeitender Agenten und nicht als ein monolithisches Automatisierungs-Skript – die Gründe dafür werden unten erläutert.

Wie ein typischer Incident aussieht

Stellen Sie sich einen CloudWatch-Alarm vor, der eine hohe Leseverzögerung in einer Datenbank anzeigt. Der diensthabende Ingenieur wird per Pager benachrichtigt, öffnet ein Dashboard, prüft Metriken und liest die Protokolle langsamer Abfragen, bis er schließlich feststellt, dass ein fehlender Index dazu führt, dass gesamte Tabellen durchsucht werden müssen. Anschließend schreibt er einen CREATE INDEX-Befehl, bestätigt, dass die Lösung funktioniert hat, und aktualisiert das Ticket.

All diese Schritte sind notwendig, doch die meisten davon sind mechanisch. Der Ingenieur löst kein neues Problem, sondern folgt einem bekannten Diagnose- und Reparaturmuster – mit realen Kosten. Das Wechseln des Kontexts, das Navigieren in Dashboards sowie das Manuell Ausführen von Abfragen verlängern die Dauer, bis der Vorfall gelöst ist, wenn er länger offen bleibt, als nötig.

Falls das Diagnosemuster verstanden ist und die Lösung klar definiert ist, kann der gesamte Prozess automatisiert werden, wobei eine Person weiterhin die Änderung freigibt. AgentSRE umfasst den gesamten Lebenszyklus eines Incidents in fünf Phasen: Erkennung, Untersuchung, Entscheidungsfindung, Ausführung und Abschluss.

Das Besondere ist die Art und Weise, wie die Ausführung organisiert wird. Anstelle eines einzigen umfangreichen Skripts, das alle möglichen Lösungen ausprobiert, werden spezialisierte Agenten eingesetzt – jeweils einer pro Kategorie: ein Datenbankagent für SQL-Beseitigungen und ein Warteschlangenagent für Kommunikationsprobleme. Jeder Agent ist eine eigene Zustandsmaschine, sodass er separat entwickelt, getestet und veröffentlicht werden kann, und neue Agententypen können ohne Änderungen an den bestehenden hinzugefügt werden. Komposition ist das zentrale Designprinzip. Es spiegelt wider, wie ein echtes Betriebsteam Probleme auf Spezialisten verteilt, und ermöglicht es der Plattform, mit dem Auftreten neuer Beseitigungsverfahren weiter zu wachsen.

Architektur im Überblick

Die Plattform läuft vollständig auf von AWS verwalteten Diensten, wodurch die Betriebskosten gering bleiben und das Skalieren automatisch erfolgt.

In dem Architekturdiagramm beginnt alles links mit einem CloudWatch-Alarm, der einen ereignisgesteuerten Pipeline ansteuert. SNS-Themen verteilen die Benachrichtigung, ein für Alarme zuständiges Lambda-Script eröffnet das ServiceNow-Incident, und der AWS DevOps Agent beginnt eigenständig mit der Untersuchung. Die Ergebnisse werden in einer React-Oberfläche angezeigt, die in Chat, Incidents und Berichte unterteilt ist. Unten zeigen drei Topologieansichten den Betreibern, wie jedes Incident visuell aussieht. Eine einzige Darstellung umfasst somit den gesamten Weg von der Erkennung bis zur Visualisierung, und keine Phase muss auf eine manuelle Weitergabe warten.

Erkennung

Das erste Signal ist eine CloudWatch-Alarmierung aufgrund einer Anomalie – beispielsweise hohe Leseverzögerungen, erschöpfte Verbindungen oder eine stetig wachsende Dead-Letter-Queue. Sie wird an ein SNS-Topic gesendet, was wiederum den Alarmierungs-Lambda-Funktion auslöst. Diese eröffnet in einem Schritt ein ServiceNow-Incident und startet die Untersuchung durch den AWS DevOps Agent. In dieser Phase ist überhaupt kein Mensch erforderlich.

Untersuchung

Der AWS DevOps Agent ist ein verwalteter Service, der die Untersuchung autonom durchführt. Er prüft CloudWatch-Metriken, RDS Performance Insights sowie Protokolle langsamer Abfragen und entscheidet selbst, welche Daten im Zusammenhang mit dem Alarm relevant sind. Eine asynchrone Lambda-Funktion sammelt die Ergebnisse ein und speichert sie in DynamoDB.

Amazon Bedrock führt Claude aus und fasst die Ergebnisse anschließend in einer kurzen Aussage zur Ursache, eine Auswirkungsbeurteilung sowie empfohlene Abhilfemaßnahmen zusammen. Diese Zusammenfassung erscheint an der oberen Kante des Untersuchungsansichts, wobei die vollständige Analyse darunter verfügbar ist.

Der Screenshot zeigt die Ansicht der Untersuchungsergebnisse, wobei zunächst die Zusammenfassung und danach die Details angezeigt werden.

Entscheidungsfindung und Governance

Sicherheitsprüfungen werden vor jeder Änderung durchgeführt. Guardrails überprüfen jeden SQL-Befehl und lehnen zerstörerische Befehle ab, wie zum Beispiel das Löschen einer Tabelle oder das Löschung von Zeilen ohne WHERE-Klausel. Der Vorgang erhält ein Risikoniveau und wird anschließend an einen Menschen zur Freigabe weitergeleitet. Das Bestätigungsfenster zeigt den genauen Befehl, die Zielressource sowie die Möglichkeit zum Rollback an.

Der menschliche Schritt ist beabsichtigt. Vollständige Autonomie ist mächtig, doch Änderungen in der Produktion verdienen einen Moment menschlichen Urteils, insbesondere bei hochriskanten Operationen.

Der obige Dialog ist das, was ein Operator sieht, wenn er aufgefordert wird, eine Korrektur zu bestätigen.

Routing einer Korrektur zum richtigen Agenten

Sobald eine Korrektur genehmigt wurde, klassifiziert der Orchestrator die Kategorie der Behebung und sendet den Antrag an den entsprechenden Agenten. Dort zeigt sich die Vorteilhaftigkeit der Komposierbarkeit.

Das Diagramm zeigt die Schritte der Behebung im Detail. Wenn jemand eine Korrektur freigibt, übernimmt der Orchestrator und führt drei Aufgaben aus. Zunächst klassifiziert er die Ursache, setzt anschließend die SQL-Sicherheitsmaßnahmen um und leitet den Antrag an den richtigen Spezialisten weiter, wobei die Aktion in DynamoDB protokolliert wird. Danach gibt es zwei weitere Schritte: Auf der Datenbankseite prüft eine LangGraph- Zustandsmaschine in Amazon Bedrock AgentCore die SQL-Anfragen mit Hilfe eines KI-Analysten, führt sie über ein Lambda-Script in der VPC gegen die Datenbank aus und schreibt das Ergebnis zusammen mit einer Prüfprotokoll-Eintragung in Jira. Auf der Warteschlangenseite funktioniert es auf ähnliche Weise bei Aufgaben wie dem Leeren einer „Dead Letter Queue“ oder dem Zurücksenden von Nachrichten an ihren ursprünglichen Ort.

Kein Agent erreicht die Ressource direkt. Jeder ruft Gateway-Tools auf: eine Gateway-Funktion, die sich mit RDS für den Datenbank-Agenten verbindet, sowie eine weitere Funktion, die SQS-Operationen für den Queue-Agenten ausführt. Diese Architektur hält die Agenten klein und sorgt dafür, dass der Zugriff auf Ressourcen kontrolliert sowie nachvollziehbar ist. Nach Abschluss einer der beiden Aufgaben speichert ein gemeinsamer Ergebnispipeline das Ergebnis in DynamoDB, fügt eine Notiz zu ServiceNow hinzu, löst das Ticket auf und aktualisiert die Topologie – so endet jedes Incident einheitlich, unabhängig davon, welcher Agent daran gearbeitet hat.

Wie die Klassifizierung funktioniert

Die intelligente Steuerung erfolgt durch den Orchestrator. Wenn der AWS DevOps Agent seine Aufgabe abgeschlossen hat, erstellt er eine Ursachenanalyse in natürlicher Sprache. Der Orchestrator liest diese Analyse und weist vor dem Ausführen eines jeden Agenten eine Korrekturmaßnahmekategorie zu.

Die Klassifizierung erfolgt in zwei Schritten. Zunächst sucht ein strukturierter Parser in der Analyse nach einem vordefinierten Korrekturblock, der den Typ der Behebung, die Zielressource sowie die geplante Aktion angibt. Fehlt ein solcher Block, wendet sich der Orchestrierer an einen Sprachmodell-Klassifizierer von Amazon Bedrock, der die freiformige Beschreibung des Problems zusammen mit dem ursprünglichen Alarmkontext liest und die Kategorie bestimmt. Der Alarmkontext hilft dabei, das Symptom mit der passenden Behebung in Verbindung zu bringen. Hohe Leseverzögerungen deuten auf die Erstellung eines Datenbankindex hin, erschöpfte Verbindungen auf das Beenden einer blockierenden Abfrage und eine wachsende Warteschlange für ungelesene Nachrichten auf eine Säuberung oder erneute Verarbeitung.

Sobald die Kategorie festgelegt ist, ist das Routing deterministisch: Die Datenbank wird an den Datenbank-Agenten gesendet, die Warteschlange an den Warteschlangen-Agenten. Die Trennung der Klassifizierung von der Ausführung macht spätere Erweiterungen einfach, da eine neue Kategorie einfach auf einen neuen Agenten abgebildet wird und die Routing-Logik sich nicht ändert.

Die beiden Produktionsagenten

AgentSRE enthält zwei Produktionsagenten, von denen jeder für eine bestimmte Kategorie der Behebung konzipiert ist. Beide laufen als konteinerisierte Laufzeiten auf Amazon Bedrock AgentCore und weisen ein gemeinsames internes Design auf: eine LangGraph-Zustandsmaschine mit wenigen gut definierten Knoten, wobei jeder Knoten so ausgestattet ist, dass seine Ausführungszeit und das Ergebnis aufgezeichnet werden.

Der Datenbank-Agent

Dieser Agent kümmert sich um alle auf SQL basierenden Korrekturen. Sein Design folgt einem realen Workflow für Datenbankoperationen und ist als Zustandsmaschine strukturiert, wobei eine Routing-Schicht den nächsten Schritt aus dem aktuellen Zustand auswählt.

Sobald eine Anfrage eintrifft, wählt der Agent zunächst die Zieldatenbank sowie den vorgeschlagenen SQL-Code aus dem Incident aus. Anschließend erfolgt die Validierung, bei der ein auf Bedrock laufender KI-Analyst den SQL-Code überprüft, um sicherzustellen, dass er korrekt strukturiert und sicher ist. Diese semantische Überprüfung wird den bereits vom Orchestrierer angewendeten deterministischen Schutzmechanismen hinzugefügt, sodass fehlerhafte oder gefährliche Abfragen einer zweiten Sicherheitsbarriere gegenüberstehen.

Sollte die Validierung erfolgreich sein, führt der Agent den SQL-Code aus – allerdings nicht direkt. Stattdessen ruft er eine Lambda-Funktion im VPC auf, die über IAM-Authentifizierung mit der Ziel-RDS-Instanz verbunden ist. Dadurch bleiben Datenbank-Zugangsdaten sowie Netzwerkzugriffe auf einen einzigen, kontrollierten Komponenten beschränkt, während der Agent weiterhin leichtgewichtig bleibt und keine direkte Verbindung zur Datenbank herstellt.

Ein einziger Pipeline dient einer Reihe von Korrekturmaßnahmen. Der Agent kann einen fehlenden Index erstellen, um Leseverzögerungen zu beheben, eine blockierende Abfrage beenden, die Sperrungen verursacht und Verbindungen aufbraucht, oder bei Bedarf weitere korrigierende Anweisungen ausführen. Anschließend protokolliert er das Ergebnis, einschließlich der betroffenen Zeilen und der Ausführungszeit, erstellt eine entsprechende Jira-Eintragsdatei sowie ein vollständiges Prüfprotokoll. Da derselbe Pipeline zur Validierung, Ausführung und Prüfung jede SQL-Operation abdeckt, erfordert die Unterstützung neuer Arten von Datenbankkorrekturen keinen Änderung an der Struktur des Agents.

Der Warteschlangenagent

Der Warteschlangenagent kümmert sich um Probleme mit Nachrichtenübertragungen, am häufigsten um eine „Dead Letter Queue“, in der fehlgeschlagene Nachrichten angesammelt sind. Er folgt demselben dreistufigen Ablauf von Validierung, Ausführung und Prüfung, verfügt jedoch über Logik, die speziell für Warteschlangen konzipiert ist.

Die Validierung zeigt, warum Sicherheit für einen autonomen Warteschlangenagenten von größter Bedeutung ist. Bevor er irgendetwas Destruktives unternimmt, stellt er zunächst sicher, dass die Zielwarteschlange tatsächlich eine Dead-Letter-Warteschlange ist, indem er das ARN-Format überprüft und anschließend sein Gateway-Tool nach den Eigenschaften der Warteschlange befragt. Eine Warteschlange, die keine Dead-Letter-Warteschlange ist, stoppt den Agenten sofort mit einem gemeldeten Sicherheitsfehler, anstatt ein Risiko mit einer aktiven Produktionswarteschlange einzugehen. Das Löschen der falschen Warteschlange würde Nachrichten im Übertragungsprozess zerstören – dieser Preis rechtfertigt daher eine spezielle Überprüfung.

Sobald die Validierung erfolgreich ist, folgt eine von zwei Aktionen. Das Löschen entfernt alle angesammelten Nachrichten aus der Dead-Letter-Queue, also solche Nachrichten, von denen bekannt ist, dass sie nicht wiederhergestellt werden können. Das Erneute Versenden schickt die Nachrichten zurück in die Quell-Queue für einen weiteren Versuch, wobei eine einstellbare Geschwindigkeitsbeschränkung vorhanden ist, damit die nachgelagerten Verarbeiter nicht überflutet werden. Ebenfalls verfügbar ist eine Statusüberprüfung, um einen laufenden Erneuten-Versand-Prozess zu überwachen.

Ebenso wie der Datenbank-Agent sendet auch der Queue-Agent jede Operation über seine eigene Gateway-Funktion, die die boto3 SQS-Aufrufe durchführt und alle Aktionen zur Prüfung protokolliert. Er akzeptiert entweder eine strukturierte Anfrage oder alltägliche Sprache und extrahiert aus beiden die jeweilige Aktion sowie den ARN der Queue.

Individuelle Konzeption

Absolutes kein Agent kennt den anderen. Jeder verwendet seine eigene Zustandsmaschine, sein eigenes Gateway-Tool sowie seine eigene Validierungslogik, die auf seinem jeweiligen Bereich abgestimmt ist. Nur der Orchestrierer kann beide sehen, und er unternimmt nichts anderes, als zu klassifizieren und weiterzuleiten.

Diese Unabhängigkeit ist das, was Praktikabilität bei der Komposition bedeutet. Ein dritter Agent zum Neustarten eines Containers, zum Ersetzen von Zugangsdaten oder zur Änderung einer Skalierungsrichtlinie würde demselben Verfahren folgen: Eine LangGraph-Zustandsmaschine führt die Schritte Validieren, Ausführen und Prüfen durch, und es steht ein eigenes Gateway-Tool zur Verfügung. Er wird beim Orchestrierer unter einer neuen Kategorie registriert, während die älteren Agenten unberührt bleiben. Der Ausbau erfolgt durch Hinzufügen neuer Komponenten, niemals durch deren Bearbeitung.

Berichterstattung und Abschluss

Sobald die Arbeit abgeschlossen ist, berichtet der Agent, ob sie erfolgreich war, wie viele Zeilen geändert wurden und wie lange sie gedauert hat. Das Ergebnis wird in DynamoDB gespeichert und als Arbeitsnotiz zum ServiceNow-Incident hinzugefügt; ein erfolgreicher Ablauf löst das Ticket ohne weitere Eingaben auf. Alle Schritte werden protokolliert, wodurch ein vollständiger Audit-Trail vom ersten Alarm bis zur Lösung entsteht.

Die Operations-Oberfläche

Automatisierung erledigt die Arbeit, doch die Operator benötigen weiterhin einen Ort, um sie zu überwachen, zu steuern und zu verstehen. AgentSRE verfügt über eine benutzerdefinierte Web-Oberfläche, die mit React entwickelt und auf AWS Amplify gehostet wird – als zentrales Kontrollfeld für den gesamten Lebenszyklus eines Incidents. Der Zugriff erfolgt über Microsoft Entra ID Single Sign-On, sodass der Identitätsanbieter des Unternehmens bestimmt, wer operative Kontrollen nutzen darf. Die Oberfläche hat drei Bereiche, die jeweils unterschiedliche Anforderungen erfüllen.

Chat

Chat ist eine konversationelle Benutzeroberfläche für den AWS DevOps Agent. Operator:innen stellen in einfachen Worten Fragen zur Verfassung einer bestimmten Datenbank, ob aktive Alarmsignale vorliegen oder wie eine Untersuchung voranschreitet. Durch Eingabe einer Incidenznummer wird direkt im Chat eine umfassende Untersuchung gestartet. Die Benutzeroberfläche behält den Kontext der Konversation über verschiedene Nachrichten hinweg bei und bewältigt langsame Antworten, indem sie im Hintergrund erneut versucht, eine Antwort zu liefern – sodass Operator:innen eine Antwort erhalten und kein Fehler angezeigt wird.

Das Screenshot zeigt die Chatansicht.

Incidenten

Incidents ist das Dashboard für den täglichen Betrieb. Jedes Incident wird zusammen mit seinem Status angezeigt – ob bereits jemand untersucht hat und ob eine Lösung umgesetzt wurde. Von dort aus kann ein Operator:in eine Untersuchung starten, die Ursache ermitteln, die Topologie betrachten und mit der Behebung beginnen. Die Behebung erfolgt mit einem Klick, anschließend erscheint ein Bestätigungsdialog, der die genauen Änderungen vor deren Ausführung anzeigt.

Das ist das Dashboard für Vorfälle.

Berichte

Durch die Berichte erhalten Sie Analysen zu allen Vorfällen: Anzahl der Untersuchungen, Lösungsraten, MTTR sowie Aufschlüsselungen nach Priorität und Ressource. Sie wandeln Daten einzelner Vorfälle in über Zeit verfügbare operative Erkenntnisse um.

Der Berichtsansicht ist oben zu sehen. In der Untersuchungsansicht bietet die Benutzeroberfläche außerdem eine Topologievisualisierung, die detaillierte Analysen in interaktive Diagramme umwandelt, die auf einen Blick Informationen vermitteln.

Integration mit ServiceNow

Eine autonome Plattform, die bestehende IT-Serviceverwaltungssysteme ignoriert, würde mehr Probleme verursachen, als sie löst. Deshalb integriert sich AgentSRE direkt mit ServiceNow – dadurch wird jeder von ihm bearbeitete Vorfall im System widergespiegelt, auf das die Betriebsmannschaften bereits angewiesen sind.

Im gesamten Lebenszyklus fließen Informationen in beide Richtungen. Ein ausgelöster CloudWatch-Alarm veranlasst die zuständige Lambda-Funktion, automatisch ein ServiceNow-Incident zu erstellen – dieses wird bereits mit den Alarmdetails sowie Priorität und Kategorie vorgefüllt, nachdem zunächst nach einem bereits vorhandenen Incident gesucht wurde, um Duplikate zu vermeiden. Somit ist das Ticket von Anfang an vorhanden, ohne dass jemand es manuell einreichen muss.

Im Laufe der Bearbeitung des Incidents fügen AgentSRE Aktualisierungen zum Ticket hinzu. Erkenntnisse aus den Ermittlungen werden als Arbeitsnotizen festgehalten, sodass jeder, der das Ticket ansieht, die vollständige Ursachenanalyse im Kontext sieht. Wenn eine Lösung angewandt wird, werden das Ergebnis – einschließlich der durchgeführten Maßnahmen, des Ausgangs und eines Zeitstempels – als weitere Arbeitsnotiz hinzugefügt. Nach einer erfolgreichen Behebung verschiebt die Plattform das Ticket in den Status „gelöst“ und fügt Lösungshinweise hinzu.

Das Ergebnis ist eine vollständige, überprüfbare Aufzeichnung in ServiceNow, die den gesamten automatisierten Workflow widerspiegelt. Die Teams arbeiten weiterhin mit dem Tool, das sie kennen, während die Automatisierung die schwierigen Aufgaben übernimmt. Durch die Einhaltung des bestehenden Prozesses wird die Plattform in einem Unternehmen einsetzbar, anstatt ein paralleles System zu sein, das man separat erlernen muss.

Dies ist ein ServiceNow-Ticket nachdem die Plattform es aktualisiert hat.

Was passiert ist erkennen: Topologieansichten

Es ist fast genauso wichtig zu wissen, was während eines Incidents geschehen ist, wie ihn zu beheben – und ein Bild vermittelt mehr als dichter Text. AgentSRE bietet drei Topologieansichten, die jeweils als interaktiver Graph dargestellt werden.

Untersuchungstopologie

Diese Ansicht zeigt den Explosionsradius: Welche Ressourcen sind betroffen und wie sind sie miteinander verbunden? Die ursächliche Ressource wird deutlich hervorgehoben, und animierte Kanten verfolgen den Fehlerweg, während sich das Problem ausbreitet. Der Graph wird dynamisch aus den Erkenntnissen der Untersuchung erstellt, sodass unterschiedliche Vorfälle unterschiedliche Topologien ergeben, da jeder Graph das widerspiegelt, was der Agent tatsächlich gefunden hat.

Die obige Ansicht zeigt eine Untersuchungstopologie.

Infrastrukturtopologie

Diese Karte zeigt die gesamte Architektur: Jedes API-Gateway, jede Lambda-Funktion, jeder Agent, jede Datenbank, jede Warteschlange sowie jeder Überwachungsteil sowie die Verbindungen zwischen ihnen. Sie gibt den Betreibern ein vollständiges Bild der eingesetzten Komponenten sowie den Weg, den Anfragen folgen.

Die Infrastrukturkarte zeigt dasselbe System.

Komponierbare Agenten-Topologie

Diese Ansicht folgt dem Behebungsprozess Schritt für Schritt: Auslösung durch den Benutzer, Klassifizierung durch den Orchestrator, Aufruf des Agents, Anruf der Gateway-Tool, Änderung der Ressource sowie das endgültige Ergebnis, das in ServiceNow eingestellt wird. Jeder Knoten steht für eine tatsächlich während der Behebung aufgerufene Komponente, sodass die komponierbare Architektur nicht mehr nur eine abstrakte Idee bleibt, sondern etwas, das Betreiber sehen und überprüfen können.

Die Agent-Topologie zeigt einen einzelnen Behebungsversuch an.

Die Topologie wird mithilfe einer hybriden Methode extrahiert. Ein regelbasiertes Extraktionswerkzeug erstellt den Graphen sofort und kostenlos, wenn der Vorfall einem bekannten Muster entspricht. Bei unbekannten Fällen bittet das System Bedrock Claude, die Topologie aus dem Ermittlungstext zu extrahieren. Häufige Fälle werden schnell bearbeitet, und auch ungewöhnliche Fälle werden weiterhin abgehandelt.

Warum die Komponierbarkeit sich lohnt

Die Entwicklung von Behebungsmechanismen als komponierbare Agenten statt als Monolith bringt mehrere praktische Vorteile mit sich.

• Erweiterbarkeit. Eine neue Behebungskategorie, wie das Neustarten eines Containers, die Anpassung einer Skalierungsrichtlinie oder der Wechsel von Zugangsdaten, bedeutet lediglich die Entwicklung eines Agenten und seine Registrierung beim Orchestrierer, wobei die bestehenden Agenten unberührt bleiben.
• Testbarkeit. Eine einzige Zustandsmaschine mit definierten Eingaben und Ausgaben kann isoliert getestet werden, wodurch eine Änderung an einem Agenten weniger wahrscheinlich dazu führt, dass ein anderer beeinträchtigt wird.
• Überwachbarkeit. Jeder Agent folgt einer definierten Zustandsmaschine, sodass seine Ausführung nachverfolgt und visualisiert werden kann; die Ansicht der komponierbaren Agentenstruktur ergibt sich direkt aus diesem Design.
• Wiederverwendbarkeit. Ein Agent kann viele Vorfälle bewältigen. Beispielsweise kümmert sich der Datenbankagent unverändert um die Erstellung von Indizes, das Beenden von Abfragen sowie andere SQL-Beseitigungen.

Technologiestack

Die Plattform kombiniert diese AWS-Dienste sowie Open-Source-Frameworks, die nach Funktionen gruppiert sind:

• Die Überwachung und Alarmierung stammen von Amazon CloudWatch, während die ereignisbasierte Orchestrierung über Amazon SNS in Kombination mit AWS Lambda erfolgt.
• Die Untersuchungen werden vom AWS DevOps Agent durchgeführt, während Amazon Bedrock mit Claude für das Reasoning, die Zusammenfassungen sowie die Topologieextraktion zuständig ist.
• Amazon Bedrock AgentCore hostet die Agents, und LangGraph stellt ihre Zustandsmaschinen bereit.
• Amazon DynamoDB speichert den Zustand sowie Auditedaten, und ServiceNow verwaltet den Lebenszyklus der Tickets.
• Die Benutzeroberfläche verwendet React zusammen mit React Flow für die Darstellung sowie Topologiediagramme und wird auf AWS Amplify gehostet.

Messbarer Einfluss

Die Automatisierung des Prozesses bringt messbare Vorteile. Manuell kann eine Untersuchung sowie die Behebung zwischen einer und vier Stunden in Anspruch nehmen, während AgentSRE von der Alarmmeldung bis zur Lösung in weniger als zehn Minuten auskommt. Die Untersuchung dauert in der Regel drei bis fünf Minuten, und eine genehmigte Behebung erfolgt in unter dreißig Sekunden.

Sowohl die Geschwindigkeit als auch die Konsistenz verbessern sich. Alle Vorfälle erhalten dieselbe sorgfältige Untersuchung, Sicherheitsprüfungen sowie einen Nachvollziehungsverlauf, sodass die Schichtplanung nicht darüber entscheidet, wie gut die Reaktion ist.

Welche weiteren Schritte sind möglich?

Die komponierbare Grundlage eröffnet mehrere Möglichkeiten. Mehr Agenten könnten Infrastrukturbehebungen über Systems Manager oder Terraform durchführen. Genehmigungsprozesse könnten über Collaboration-Tools wie Microsoft Teams abgewickelt werden. Eine Wissensschicht könnte Lektionen aus vergangenen Vorfällen nutzen, um zukünftige Empfehlungen zu verbessern. Da das Agent-Muster nicht an eine bestimmte Cloud gebunden ist, könnte derselbe Ansatz auch auf Multi-Cloud-Umgebungen angewandt werden.

Die architektonische Erkenntnis

Autonome Vorfallsbearbeitung erweist sich als praktikabel und umsetzbar, wenn sie auf den richtigen Prinzipien beruht: autonome Untersuchung, komponierbare Behebungsagenten, menschliche Genehmigung sowie detaillierte Topologieansichten. Gemeinsam verkürzen sie die durchschnittliche Zeit bis zur Lösung erheblich, während Sicherheit und vollständige Nachvollziehbarkeit gewährleistet bleiben.

Die wichtigste Lektion betrifft die Architektur. Die Aufteilung der Korrekturmaßnahmen in spezialisierte, kombinierbare Agenten anstelle einer einzigen Automatisierung entspricht der tatsächlichen Arbeitsweise von Betriebsmannschaften, hält das System für Erweiterungen offen und macht jede Aktion sichtbar. Da Cloud-Umgebungen immer komplexer werden, ist das ein skalierbarer Weg zu operationsbasierten Lösungen unter Verwendung von KI.