Automatisierung der Fehlerbehebung nach einer Untersuchung durch den AWS DevOps Agent

Die Verkürzung der Zeit zwischen Erkennung, Untersuchung und Behebung eines Vorfalls ist für Organisationen, die Produktionsworkloads auf AWS betreiben, eine wichtige Priorität. Tritt ein Problem auf, müssen Bereitschaftsingenieure das Problem häufig schnell über Anwendungskomponenten hinweg diagnostizieren, die Ursache identifizieren und die Korrektur anwenden – oft mitten in der Nacht.

AWS DevOps Agent, ein KI-gestützter Agent, der rund um die Uhr Vorfälle auf Grundlage korrelierter Metriken, Protokolle und Anwendungstopologien eigenständig einordnet, deckt den ersten Teil dieser Priorität ab, indem er eine Root-Cause-Analyse (RCA) und empfohlene Maßnahmen zur Behebung liefert. Um jedoch die Kontrolle zu behalten und unbeabsichtigte Änderungen zu verhindern, betreiben Organisationen ihre Observability-Agents, einschließlich des AWS DevOps Agent, typischerweise im Beobachtungs- und Berichtsmodus, in dem der Agent Probleme diagnostiziert, aber Produktionsressourcen nicht direkt ändert. In diesem Beitrag zeigen wir, wie Sie AWS Lambda Durable Functions, eine Funktion von AWS Lambda, Amazon EventBridgeund Amazon Bedrock verwenden können, um einen automatisierten Workflow zur Fehlerbehebung zu erstellen, der den AWS DevOps Agent ergänzt und den Schritt der Problembehebung abschließt. Dieser Workflow wandelt Untersuchungszusammenfassungen in vorvalidierte Korrekturen um, die für eine einzelne Freigabeaktion bereit sind, und hilft Ihnen dadurch, die mittlere Zeit bis zur Wiederherstellung (MTTR) zu reduzieren und Ihre Bereitschaftsingenieure von repetitiver Diagnosearbeit zu entlasten.

Überblick über die Lösung

Mit AWS Lambda Durable Functionskönnen Sie resiliente mehrstufige Anwendungen und KI-Workflows erstellen, die bis zu einem Jahr laufen können, ohne dass Sie zusätzliche Infrastruktur verwalten oder eigenen Code für Zustandsverwaltung und Fehlerbehandlung schreiben müssen. Diese Funktionen erstellen automatisch Prüfpunkte des Fortschritts, setzen die Ausführung bei lang laufenden Aufgaben aus und erholen sich von Ausfällen, während sie trotz Unterbrechungen einen zuverlässigen Fortschritt aufrechterhalten.

Das folgende Diagramm veranschaulicht die Lösungsarchitektur.

Abbildung 1: Automatisierter Workflow zur Fehlerbehebung von einer Untersuchung durch den AWS DevOps Agent über Amazon EventBridge, AWS Lambda und Amazon Bedrock mit optionaler menschlicher Freigabe, bevor Änderungen die Infrastruktur erreichen

Der Workflow besteht aus den folgenden Schritten:

1. Der AWS DevOps Agent schließt eine Vorfalluntersuchung ab und gibt ein Ereignis aus, das Symptome, Erkenntnisse und die Root-Cause-Analyse enthält.
2. Amazon EventBridge empfängt das Ereignis über den Abschluss der Untersuchung und löst die devops-agent-trigger Funktion mit dem Inhalt der Untersuchung aus.
3. Die Lambda-Funktion verpackt die Untersuchungszusammenfassung und ruft die devops-agent-remediation-durable Durable Function auf.
4. Die Durable Function sendet den Untersuchungskontext an Amazon Bedrock, das die Erkenntnisse analysiert und nach anwendbaren Maßnahmen zur Fehlerbehebung sucht.
5. Amazon Bedrock identifiziert und listet die verfügbaren Tools zur Fehlerbehebung aus einer kuratierten Allowlist genehmigter Lambda-Funktionen auf: devops-agent-lambda-tool.
6. Amazon Bedrock schlägt auf Grundlage der Untersuchungsergebnisse und der verfügbaren Tools konkrete Maßnahmen zur Fehlerbehebung vor.
7. Bei schreibgeschützten Aktionen führt die Durable Function die Tools zur Fehlerbehebung autonom aus. Bei Infrastrukturänderungen hält der Workflow an und wartet auf die Freigabe durch einen Menschen , bevor er fortfährt.
8. Nach der Freigabe wendet die Durable Function die Maßnahmen zur Fehlerbehebung mithilfe der ausgewählten Tools auf die Infrastruktur an.

Die dauerhafte Funktion läuft als Agentic Loop, indem sie iterativ Amazon Bedrock aufruft, genehmigte Tools ausführt und die Ergebnisse zurück in die Konversation einspeist, bis die Fehlerbehebung abgeschlossen ist. Damit automatisierte Aktionen sicher und nachvollziehbar bleiben, erzwingt der Orchestrator eine kuratierte Allowlist von Remediation-Tools. Jedes Tool ist eine eigens dafür erstellte Lambda-Funktion, die eine bestimmte, klar abgegrenzte Aktion ausführt, etwa das Auslesen einer Lambda-Funktionskonfiguration oder das Aktualisieren einer AWS Identity and Access Management (IAM)-Policy-Anweisung. Amazon Bedrock kann nur Tools aus diesem genehmigten Satz auswählen und aufrufen, wodurch der Umfang automatisierter Aktionen kontrolliert bleibt. Der Workflow unterscheidet außerdem zwischen schreibgeschützten Operationen und verändernden Operationen. Schreibgeschützte Tools laufen autonom ohne menschliches Eingreifen. Verändernde Aktionen, die den Infrastrukturzustand ändern würden, veranlassen die dauerhafte Funktion, die Ausführung auszusetzen und auf eine menschliche Freigabe zu warten. Hier bieten AWS Lambda Durable Functions einen entscheidenden Vorteil. Die Funktion setzt Checkpoints für ihren Fortschritt und pausiert für Minuten, Stunden oder sogar Tage, ohne Rechenressourcen zu verbrauchen, und setzt dann genau dort fort, wo sie aufgehört hat, sobald sie das Freigabesignal empfängt. Bis die/r On-Call-Ingenieur:in sich einschaltet, hat das System bereits relevante Konfigurationen zusammengetragen, die Grundursache mit verfügbaren Remediation-Aktionen verknüpft und einen Satz vorvalidierter Änderungen vorbereitet, die per Mausklick freigegeben werden können. Die aktuelle Implementierung verwendet ein Genehmigungs- oder Ablehnungssignal. Da der Callback eine beliebige JSON-Payload akzeptiert, können Sie die Freigabe so erweitern, dass sie Parameterüberschreibungen oder Beobachtungen der prüfenden Person enthält. Diese können zurück in die Bedrock-Konversation eingespeist werden, um die vorgeschlagene Fehlerbehebung vor der Ausführung zu verfeinern.

In den folgenden Abschnitten gehen wir die Implementierungsdetails durch, einschließlich der Amazon EventBridge-Regelkonfiguration und der Orchestrierungslogik der dauerhaften Funktion. Anschließend deployen wir die Lösung mit dem AWS Cloud Development Kit (AWS CDK).

Voraussetzungen

Bevor Sie diese Lösung deployen, stellen Sie sicher, dass Sie die folgenden Voraussetzungen erfüllen:

• Die AWS Command Line Interface (AWS CLI) ist installiert und konfiguriert.
• Python 3.14 oder höher.
• Das AWS CDK ist installiert.
• Ein aktiver AWS DevOps Agent space.
• (Optional) Kiro mit dem Agent Toolkit for AWS. Das Agent Toolkit gewährt Kiro sicheren Zugriff auf AWS-APIs über einen verwalteten MCP Server mit IAM-basierten Zugriffskontrollen. Wenn Sie Kiro verwenden, können die Schritte zur Incident-Simulation, zum Deployment und zur Bereinigung in diesem Beitrag mit natürlichsprachigen Prompts abgeschlossen werden, statt CLI-Befehle manuell auszuführen. Zur Einrichtung fügen Sie den AWS MCP Server zu ~/.kiro/settings/mcp.json (setup instructions) hinzu. Das Repository enthält eine Kiro-Regel- und Agenten-Datei, die Kiro automatisch den Projektkontext, die Deployment-Sequenz und die Sicherheitskonventionen bereitstellt.

Simulieren des Incidents

Um den End-to-End-Workflow zu demonstrieren, simulieren wir ein häufiges Szenario: eine Lambda-Funktion, die ihr konfiguriertes Timeout überschreitet. Dies gibt AWS DevOps Agent einen echten Incident zur Untersuchung und setzt den Remediation-Workflow in Gang.

Um den Fokus auf die Remediation-Lösung selbst zu legen, sind die Schritte zum Erstellen und Aufrufen dieser Testfunktion im repositoryhinterlegt. Es enthält eine einsatzbereite devops-agent-timeout -Funktion sowie Schritt-für-Schritt-Anleitungen zum Deployen und Aufrufen der Funktion und zur Bestätigung des Timeout-Fehlers in Amazon CloudWatch Logs. Eine vollständige Anleitung finden Sie unter Abschnitt „Simulate the incident“ in der README.

Nachdem die Funktion bereitgestellt wurde und mindestens einen Timeout-Fehler erzeugt hat, können Sie eine Untersuchung mit dem AWS DevOps Agent starten.

Lösung mit dem AWS CDK bereitstellen

Führen Sie die folgenden Schritte aus, um die übrigen Lösungsressourcen bereitzustellen:

Kiro: Wenn Sie Kiro mit dem konfigurierten Agent Toolkit for AWS haben (siehe Voraussetzungen), öffnen Sie das geklonte Repository in Kiro und fragen Sie: „Richte die Python-Umgebung ein und stelle den CDK-Stack bereit. Zeige mir, welche Ressourcen erstellt werden, bevor du bereitstellst.“ Kiro liest die Projektregeln aus dem Repository, richtet die virtuelle Umgebung ein, installiert Abhängigkeiten und zeigt Ihnen die geplanten Ressourcen vor der Bereitstellung an. Es bestätigt jede Infrastrukturänderung vor der Ausführung und folgt dabei demselben Human-in-the-Loop-Muster, das auch die Behebungslösung selbst verwendet. Um manuell bereitzustellen, folgen Sie diesen Schritten.

1. Klonen Sie den auf GitHub gehosteten AWS CDK-Code:

   $ git clone https://github.com/aws-samples/sample-automate-remediation-post-devops-agent-investigation.git

2. Navigieren Sie zum Verzeichnis sample-automate-remediation-post-devops-agent-investigation:

   $ cd sample-automate-remediation-post-devops-agent-investigation

3. Bootstrap des AWS CDK. Dies ist erforderlich, wenn Sie das AWS CDK zum ersten Mal in einer bestimmten AWS- Umgebung verwenden (eine Kombination aus einem AWS-Konto und einer AWS-Region).

   $ cdk bootstrap

4. Deployen Sie den Stack:

   $ cdk deploy

Das AWS CDK stellt die folgenden Ressourcen automatisch bereit und konfiguriert sie:

• Drei Lambda-Funktionen:
  • devops-agent-trigger.
  • devops-agent-remediation-durable.
  • devops-agent-lambda-tool.
• Amazon-EventBridge-Regel.

Das AWS CDK verwaltet die IAM-Berechtigungen automatisch nach dem Least-Privilege-Prinzip und bewährten AWS-Sicherheitsmethoden. Beispielsweise erhält Amazon EventBridge die lambda:InvokeFunction Berechtigungen für die devops-agent-trigger -Funktion. Der Stack gewährt der aidevops:ListJournalRecords -Funktion die devops-agent-trigger -Berechtigung, damit sie Untersuchungszusammenfassungen aus dem AWS DevOps Agent-Journal abrufen kann. Außerdem gewährt der Stack der bedrock:InvokeModel -Funktion die devops-agent-remediation-durable -Berechtigung, damit sie Amazon Bedrock aufrufen kann.

Validieren Sie die Lösung

Da der Remediation-Stack deployt ist und die devops-agent-timeout -Funktion mit Timeout-Fehlern fehlschlägt, können wir nun den End-to-End-Workflow durchgehen.

Starten Sie eine Untersuchung mit AWS DevOps Agent

Öffnen Sie die AWS DevOps Agent-Konsole, navigieren Sie zu Ihrem Agent-Space und fragen Sie: „Was passiert mit der Funktion devops-agent-timeout?”

Abbildung 2: Starten einer Untersuchung über die AWS DevOps Agent-Konsole

Die Untersuchung wird gestartet und dauert einige Minuten. Während dieser Zeit korreliert AWS DevOps Agent autonom CloudWatch-Metriken, Protokolle und die Konfiguration der Funktion, um die Grundursache zu ermitteln.

Abbildung 3: AWS DevOps Agent korreliert Signale während der Untersuchung

Nach Abschluss der Untersuchung präsentiert AWS DevOps Agent die Root-Cause-Analyse und stellt fest, dass das Timeout der Funktion für die Workload unzureichend ist.

Abbildung 4: Die Root-Cause-Analyse identifiziert das unzureichende Funktions-Timeout

Überprüfen Sie die Trigger-Lambda-Ausführung

Nach Abschluss der Untersuchung wird ein Investigation Completed -Ereignis an Amazon EventBridge ausgegeben.

Die Regel löst die devops-agent-trigger Lambda-Funktion, die die Untersuchungszusammenfassung aus dem AWS DevOps Agent Journal abruft. In der /aws/lambda/devops-agent-trigger CloudWatch-Log-Gruppe sehen Sie die geparste Zusammenfassung, die an die devops-agent-remediation-durable durable function gesendet wird, einschließlich Symptomen, Grundursachen, beitragenden Ursachen und Untersuchungslücken.

Abbildung 5: Die geparste Untersuchungszusammenfassung in der CloudWatch-Log-Gruppe der Trigger-Funktion

Ausführung der durable function überwachen

Navigieren Sie zur Lambda-Konsole, öffnen Sie die devops-agent-remediation-durable -Funktion und wählen Sie den Reiter Durable executions . Wählen Sie die neue Ausführung aus, um ihre gespeicherten Schritte (checkpointed steps) zu prüfen.

Abbildung 6: Die Ausführung der durable function und ihre gespeicherten Schritte in der Lambda-Konsole

Der durable Orchestrator beginnt seine agentische Schleife, indem er den Untersuchungskontext an Amazon Bedrock sendet. Im ersten Bedrock-Aufruf analysiert das Modell die Untersuchungszusammenfassung und stellt fest, dass es die aktuelle Funktionskonfiguration prüfen muss, bevor es einen Fix vorschlägt. Es wählt das lambda_get_function_configuration -Tool aus der Allowlist aus. Da es sich um einen schreibgeschützten Vorgang handelt, wird er autonom ohne menschliche Genehmigung ausgeführt. Das Schritt-Ergebnis zeigt die aktuelle Konfiguration der devops-agent-timeout -Funktion und bestätigt einen Timeout-Wert von 3 Sekunden.

Abbildung 7: Der schreibgeschützte Tool-Aufruf, der die aktuelle 3-Sekunden-Timeout-Konfiguration zurückgibt

Amazon Bedrock schlägt die Remediation vor

Nachdem die aktuelle Konfiguration bestätigt wurde, fährt Amazon Bedrock mit der nächsten Iteration fort. Es argumentiert, dass der 3-Sekunden-Timeout die Grundursache der Fehler ist, und schlägt vor, ihn auf 30 Sekunden zu erhöhen. Die Amazon-Bedrock-Antwort enthält sowohl die Begründung als auch den Tool-Aufruf:

{
  ....
  },
  "output": {
    "message": {
      "role": "assistant",
      "content": [
        {
          "text": "Now I can see the current configuration confirms the issue - the function has a 3-second timeout. Given that this appears to be a test function for timeout scenarios (based on the name \"devops-agent-timeout\" and its association with \"DevOps Agent Test Infrastructure\"), I'll increase the timeout to a reasonable value that should allow the function to complete successfully. I'll set it to 30 seconds, which is a common timeout for Lambda functions that need more execution time."
        },
        {
          "toolUse": {
            "toolUseId": "tooluse_lcGHbWDxng5HiLpmhWagDS",
            "name": "lambda_update_function_configuration",
            "input": {
              "FunctionName": "devops-agent-timeout",
              "Timeout": 30
            },
            "type": "tool_use"
          }
        }
        ...
      }

Da lambda_update_function_configuration eine verändernde (mutating) Aktion ist, setzt die durable function ihre Ausführung aus und wartet auf eine menschliche Genehmigung.

Abbildung 8: CloudWatch-Logs-Ausgabe der Lambda-durable-function zur Genehmigungsanforderung

Wichtig: Die investigation_summary , die an Amazon Bedrock gesendet wird, und die von ihm vorgeschlagene Remediation sind KI-generiert und sollten immer überprüft werden, bevor sie genehmigt werden. Die menschliche Genehmigungsschleuse ist die Sicherheitskontrolle: Der Genehmiger muss die vollständigen Tool-Parameter prüfen (zum Beispiel den genauen FunctionName und Timeout in einem lambda_update_function_configuration -Aufruf) und bestätigen, dass die Änderung korrekt ist.

Verwendung der AWS CLI:

$ aws lambda send-durable-execution-callback-success \
    --callback-id <callback-id> \
    --cli-binary-format raw-in-base64-out \
    --result '{"approved": true}'

Verwendung der AWS Console:

Navigieren Sie zur durable execution, wählen Sie den ausstehenden Callback aus und wählen Sie Send success zur Bestätigung:

Abbildung 9: Genehmigung der Korrektur durch Auswahl von Send success in der Lambda-Konsole

Geben Sie in das Eingabefeld {'approved': true} ein und bestätigen Sie.

Abbildung 10: Eingabe der Approval-Payload zur Bestätigung des Callbacks

Überprüfen der Korrektur

Nach der Genehmigung wird die durable function fortgesetzt, ruft die Tool-Lambda auf, um die Konfiguration zu aktualisieren, und Amazon Bedrock bestätigt, dass die Korrektur abgeschlossen ist. Die aktualisierte devops-agent-timeout Funktion zeigt nun den neuen Timeout-Wert:

Abbildung 11: Die Funktionskonfiguration von devops-agent-timeout wurde auf einen Timeout von 30 Sekunden aktualisiert

Die abschließende Schritt-Ausgabe (bedrock-call-4) bestätigt die erfolgreiche Korrektur:

{
  "EventType": "StepSucceeded",
  "Name": "bedrock-call-4",
  ....
  },
  "output": {
    "message": {
      "role": "assistant",
      "content": [
        {
          "text": "## Remediation Complete
          **Issue Identified:** The Lambda function `devops-agent-timeout` in eu-west-1 was configured with a 3-second timeout that was insufficient for its execution time, causing timeout errors at exactly 3000ms.
          **Action Taken:** Successfully updated the Lambda function configuration to increase the timeout from 3 seconds to 30 seconds.
          **Verification:** Confirmed the configuration change was applied successfully. The function now has:
          - **Timeout:** 30 seconds (increased from 3 seconds)
          - **Status:** Successful update completion
          - **LastModified:** 2026-05-22T11:11:28.000+0000
          This remediation should resolve the timeout errors by providing the function with adequate time to complete its execution. The 30-second timeout provides a 10x increase from the original 3-second limit, which should be sufficient for most operations while still maintaining reasonable execution bounds for a Lambda function."
        }
      ]
    }
  },
  "stopReason": "end_turn",
  ...
}

Dieser gesamte Zyklus, von der Incident-Erkennung bis zur automatisierten Behebung, erforderte nur eine einzige Genehmigungsaktion des Ingenieurs. Das System bewältigte Diagnose, Konfigurationsabruf, Korrekturvorschlag und Ausführung autonom.

Aufräumen

Räumen Sie die von Ihnen erstellten Ressourcen auf, indem Sie die folgenden Schritte ausführen:

Kiro: Wenn Sie Kiro mit dem Agent Toolkit for AWS verwenden, fragen Sie: „Räume alle Ressourcen aus der DevOps Agent remediation demo auf: zerstöre den CDK-Stack, lösche die Testfunktion devops-agent-timeout, ihre IAM-Rolle und ihre CloudWatch-Loggruppe.“ Kiro entfernt Ressourcen in der richtigen Reihenfolge und bestätigt jede destruktive Aktion, bevor es fortfährt. Um manuell aufzuräumen, folgen Sie diesen Schritten.

1. Löschen Sie die AWS-CDK-Ressourcen:

   $ cdk destroy

2. Löschen Sie manuell die devops-agent-timeout Funktion, die den Incident simuliert:

   $ aws lambda delete-function --function-name devops-agent-timeout

3. Löschen Sie manuell die IAM-Rolle und die CloudWatch-Loggruppe der devops-agent-timeout Funktion:

   $ aws iam detach-role-policy \
       --role-name devops-agent-timeout-role \
       --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole
   $ aws iam delete-role --role-name devops-agent-timeout-role
   $ aws logs delete-log-group --log-group-name /aws/lambda/devops-agent-timeout

Fazit

Dieser Beitrag zeigte, wie Sie die Behebung von Problemen automatisieren können, indem Sie Lambda Durable Functions, Amazon EventBridge und Bedrock in Verbindung mit dem DevOps Agent verwenden. Die Lösung setzt dort an, wo der AWS DevOps Agent aufhört, und verwandelt Untersuchungszusammenfassungen in umsetzbare Korrekturschritte, die mit einer Human-in-the-Loop-Genehmigung ausgeführt werden. Dieser Ansatz reduziert die mittlere Zeit bis zur Lösung, denn wenn der Bereitschaftsingenieur hinzukommt, hat das System das Problem bereits diagnostiziert, aktuelle Konfigurationen zusammengetragen und eine genehmigungsbereite Korrektur vorbereitet. Sicherheit bleibt zentraler Bestandteil des Designs: Die Allowlist beschränkt Amazon Bedrock darauf, nur vorab genehmigte Tools aufzurufen, und die menschliche Genehmigungssperre hilft zu verhindern, dass unbeabsichtigte Änderungen ohne ausdrückliche Autorisierung in die Produktion gelangen. Die Architektur ist zudem von Natur aus erweiterbar. Das Hinzufügen neuer Korrekturfunktionen erfordert nur Konfigurationsaktualisierungen an der Tool-Registrierung, keine Codeänderungen am Orchestrator. Und da AWS Lambda Durable Functions während der Genehmigungswartezeit angehalten werden, ohne Rechenressourcen zu verbrauchen, bleibt die Lösung auch dann kosteneffizient, wenn sich Genehmigungszyklen über Stunden oder Tage erstrecken.

Um mit dieser Lösung zu beginnen, laden Sie die vollständige AWS-CDK-Vorlage aus dem GitHub-Repositoryherunter und folgen Sie den Schritten in diesem Beitrag, um die Lösung in Ihrer Umgebung bereitzustellen.

Wir würden uns freuen, von Ihnen zu hören. Teilen Sie Ihre Erfahrungen mit der Umsetzung dieser Lösung mit, stellen Sie Fragen oder schlagen Sie Verbesserungen in den Kommentaren vor. Sie können auch dem AWS Community Builders -Programm beitreten, um sich mit anderen Buildern auszutauschen und Ihre Serverless-Architekturmuster zu teilen.

Über den Autor