Circle K verkürzt DevOps-Störungsanalyse mit Amazon Bedrock auf unter 15 Minuten

Das Problem: 45 bis 60 Minuten, bevor eine Lösung beginnen kann

Circle K betreibt mehr als 17.200 Convenience- und Tankstellen-Shops in 27 Ländern. Die cloudnative Infrastruktur auf AWS trägt Kassensysteme, Loyalty-Anwendungen und Anwendungen für das Laden von Elektrofahrzeugen (EV). Mit dem Wachstum der digitalen Geschäftsprozesse stieg auch die Zahl der Alarme, und jeder einzelne erforderte dieselbe manuelle Untersuchung, bevor die Behebung beginnen konnte.

Wie es in dem Beitrag heißt, brauchte ein Ingenieur nach einem ausgelösten Alarm typischerweise 45 bis 60 Minuten, um herauszufinden, was passiert war. Das Team überwacht mehrere AWS-Konten mit Grafana. Zur manuellen Routine gehörten die Auswertung von Logs in Amazon CloudWatch, die Prüfung von Anwendungs-Traces in Amazon OpenSearch Service, die Kontrolle des Status von Amazon-ECS-Tasks und der Abgleich der Symptome mit internen Runbooks in GitHub.

Das Team stellte zwei Probleme fest: Für jede Störung wurden dieselben Abfragen und Recherchen wiederholt, und Tiefe und Tempo der Triage hingen davon ab, wie vertraut der jeweilige Bereitschaftsingenieur mit dem betroffenen Service war. Das DevOps-Team von Circle K startete deshalb eine R&D-Initiative, um das repetitive Zusammentragen von Kontext zu automatisieren und strukturierte Ergebnisse zu liefern. Die betriebliche Bewertung bleibt dabei bei den Ingenieuren.

Warum Amazon Bedrock

Das Team prüfte mehrere Ansätze, darunter Open-Source-Agenten-Frameworks auf selbst verwalteter Infrastruktur. Das hätte bedeutet, Modell-Hosting, Prompt-Versionierung, Tool-Orchestrierung und Sicherheitskontrollen selbst zu verantworten. Mit Amazon Bedrock griff das Team über eine einzige API auf Foundation Models zu und konnte Modelle austauschen, ohne Code neu zu schreiben. Da Circle K bereits auf AWS lief, passte der Dienst zu bestehenden IAM-Richtlinien, Amazon-VPC-Konfigurationen und Logging-Pipelines.

Bedrock bot zudem eine Agenten-Orchestrierung mit nativer Tool-Nutzung, um AWS-APIs aufzurufen, Datenbanken abzufragen und Dokumente abzurufen. Amazon Bedrock Knowledge Bases, die verwaltete RAG-Funktion, übernahmen Aufnahme und Abruf interner Product Cards, sodass keine separate Vektordatenbank nötig war. Zum Datenschutz heißt es in dem Beitrag, Amazon Bedrock gebe keine Kundendaten an Modellanbieter weiter und nutze sie nicht zum Training von Foundation Models. Damit erfüllte der Dienst die Sicherheitsanforderungen von Circle K für Produktions-Logs und interne Service-Details.

So funktioniert die ursprüngliche Architektur

Die erste Version nutzte Amazon Bedrock Flows als Orchestrierungsschicht. Ein Grafana-Alarm wird an Amazon SNS veröffentlicht, das ihn an eine Amazon-SQS-Warteschlange weiterleitet. Eine AWS-Lambda-Funktion fragt die Warteschlange ab, extrahiert die Alarm-Nutzlast und ruft den Flow auf.

• AWSResourceExplorerAgent: fragt die Infrastruktur über Workload-Konten ab, die mit AWS Organizations verwaltet werden, und prüft den ECS-Task-Status, den Zustand der Ziele des Application Load Balancers sowie CloudWatch-Metriken und -Logs.
• OpenSearchExplorerAgent: läuft parallel und fragt OpenSearch nach Anwendungs-Logs und verteilten Traces ab. Er ist getrennt gehalten, weil OpenSearch große Datenmengen liefert und die Isolation das Kontextfenster jedes Agenten beherrschbar hält. Zudem hat er exklusiven Zugriff auf die Knowledge Base mit den Product Cards, die jeden Service und seine Abhängigkeiten beschreiben.
• GitHubExplorerAgent: läuft nach den ersten beiden und nutzt deren Ergebnisse, um die Repositories des betroffenen Services zu finden. Er durchsucht Anwendungscode, Infrastrukturdefinitionen und aktuelle Commits nach der Ursache des Problems und einem Lösungsvorschlag.

Die Ergebnisse gehen an einen AnalysisPrompt-Knoten, einen einzelnen Modellaufruf ohne Tools. Er erstellt eine strukturierte Zusammenfassung mit der wahrscheinlichen Grundursache, den stützenden Belegen, dem betroffenen Service samt Verantwortlichem und empfohlenen Maßnahmen zur Behebung. Das Format ist so gestaltet, dass das Bereitschaftsteam es in weniger als 2 Minuten erfassen kann. Die Lambda-Funktion postet die Zusammenfassung in Slack. Der gesamte Ablauf vom Alarm bis zur Nachricht dauert laut Beitrag je nach Komplexität der Störung 5 bis 15 Minuten.

Ein Beispiel für eine Triage

Der Beitrag schildert einen Alarm, bei dem die HTTP-5xx-Fehlerrate eines Services 3 Minuten in Folge über 5 % lag. Die Agenten stellten fest, dass der Datenbank-Connection-Pool erschöpft war und ECS Neustarts versuchte. Sie fanden "connection refused"-Fehler bei Verbindungen zu einer PostgreSQL-Datenbank und ermittelten, dass der Service pro Anfrage eine neue Datenbankverbindung öffnete, statt bestehende wiederzuverwenden. Der Analyseschritt brachte den Zeitpunkt mit einer geplanten Marketingkampagne in Verbindung, die 10 Minuten vor dem Alarm begonnen hatte, und empfahl eine Korrektur im Code statt eines temporären Patches.

Was das bedeutet

Bereitschaftsingenieure von Circle K erhalten in Slack nun handlungsrelevanten Kontext statt roher Alarme und können sofort reagieren. Der Beitrag behandelt außerdem die spätere Migration zu Amazon Bedrock AgentCore und die Erfahrungen bei der Skalierung des Systems. Die genannten Ergebnisse sind interne Zahlen von Circle K und keine unabhängigen Messungen.