AWS DevOps Agent in der Praxis: Agent Spaces, Untersuchungen, Release-Prüfungen und Skills.
Ein Überblick über den AWS DevOps Agent: Erstellen eines Agent Spaces, Durchführung einer Ursachenanalyse, die Vorabfunktionen für Release-Management sowie das Erstellen benutzerdefinierter Agent Skills.
Quellen: AWS DevOps Agent & AWS DevOps Agent Skills — Simplified with Hands-on demo
Die Betriebsteams verbringen viele Stunden mit wiederkehrenden Aufgaben: Sie untersuchen, warum ein Pipeline-Ablauf fehlschlug, überprüfen den Zustand der Infrastruktur, vergleichen Protokolle mit Metriken und beantworten die tägliche Frage „Was ist gerade kaputt?“ AWS bietet dafür ausgezeichnete Bausteine wie CloudWatch, IAM, CodePipeline und Lambda – doch es besteht weiterhin eine Lücke zwischen den Rohdaten und klaren Schlussfolgerungen, auf die man handeln kann.
Im Folgenden wird der AWS DevOps Agent praktisch vorgestellt: Wie ein Agent Space eingerichtet wird, wie eine Untersuchung von Anfang bis Ende abläuft, welche neuen Funktionen zur Release-Verwaltung hinzugefügt wurden und wie Agent Skills es dem Agenten ermöglichen, die eigenen Prozesse des Teams zu übernehmen. Die Zielgruppe sind DevOps-, SRE-, Plattform- und KI-Ingenieure, die bereits Workloads auf AWS betreiben und eine Automatisierung wünschen, die über einfache Skripte hinausgeht.
Was ein DevOps-Agent ist – und was nicht
Hier bezeichnet der Begriff einen Betriebsassistenten, der Ingenieure nicht ersetzt. Es handelt sich um ein System, das:
- Lesezugriff auf AWS-Ressourcen sowie manchmal eingeschränkten Schreibzugriff hat
- den Betriebskontext der Umgebung versteht
- Fragen beantworten kann wie zum Beispiel, warum eine Bereitstellung fehlgeschlagen ist, was sich in der letzten Stunde geändert hat oder welcher Dienst für einen Anstieg der Fehler verantwortlich ist
- als Verbindungsstelle zwischen AWS-APIs, Logs, Metriken und den diensthabenden Personen fungiert
Es ersetzt Ingenieure nicht. Seine Aufgabe besteht darin, die mentale Belastung bei routinemäßigen Untersuchungen zu verringern und diese schneller durchzuführen.
Einen Agentenraum erstellen
Dienst finden
Öffnen Sie die AWS Management Console und suchen Sie nach AWS DevOps Agent. Die grundlegenden Funktionen für Produktionsbetrieb sind in der Regel verfügbar. Die neueren Funktionalitäten für Release-Management, die weiter unten beschrieben werden, befinden sich noch in der Vorabversion.
Einen Agent Space erstellen
wählen Sie „Agent Space erstellen“ aus und geben Sie zwei Angaben ein: einen Namen, wie z. B. Demo-DevOps-Agent, sowie eine kurze Beschreibung der Umgebung oder ihres Zwecks. Der Agent Space bildet die logische Grenze für Untersuchungen, Topologien und Empfehlungen.
Ressourcenzugriff gewähren
In dem Abschnitt zur Gewährung von Zugriff auf AWS-Ressourcen wählen Sie die Option, die automatisch eine neue DevOps-Agentenrolle erstellt. AWS erstellt und verknüpft anschließend eine IAM-Rolle mit eingeschränkten Berechtigungen, die es ermöglichen, CloudWatch-Metriken und -Protokolle zu lesen, EC2 sowie verwandte Ressourcen zu überprüfen und Topologiediagramme anzufertigen. Der größte Teil der IAM-bezogenen Hindernisse, die normalerweise die Einführung verzögern, verschwindet in diesem Schritt.
Webanwendung aktivieren
In dem Abschnitt „Webanwendung aktivieren“ lassen Sie die Auswahl „Rolle automatisch erstellen“ aktiv. Dadurch wird die interaktive Benutzeroberfläche für Untersuchungen, Chat und Dashboards aktiviert. Anschließend erstellen Sie den Agentenraum.
Betreueransicht öffnen
Gehen Sie zum neuen Agentenraum und öffnen Sie den Betreuerzugriff. Hier befinden sich drei Bereiche: DevOps-Zentrum, Incidentschutz und -bekämpfung.
DevOps-Zentrum und topologiemäßig gestützte Sichtbarkeit
Darin zeigt das DevOps Center ein Echtzeit-Topologiegraphen des AWS-Umfelds. Mehrere Aspekte fallen sofort ins Auge: Ressourcen erscheinen miteinander verbunden und nicht isoliert, Abhängigkeiten zwischen Diensten sind sichtbar, und der Agent arbeitet auf Basis dieser Beziehungen und nicht nur anhand von Metriken. Diese Topologie ist für spätere Ursachenanalysen von großer Bedeutung.
Eine Untersuchung durchführen
Dort beginnt der Agent, seinen Wert zu beweisen. Wählen Sie im Dashboard „Untersuchung starten“. Das Problem kann in einfachen Worten beschrieben werden, oder ein häufiger Auslöser wie hoher CPU-Verbrauch, ein Anstieg der Fehlerraten oder fehlende Metriken und Protokolle kann ausgewählt werden.
Das hier gezeigte Beispiel betraf einen Vorfall mit fehlenden Daten. Die Anfrage lautete: Können Sie überprüfen, warum die CloudWatch-CPU-Daten für meine EC2-Instanzen nicht sichtbar sind? Sofort identifizierte der Agent die betroffenen Instanzen, platzierte sie in der Topologieansicht und suchte nach CloudWatch-Metriken in der entsprechenden Region.
Zeitlinie und Erkenntnisse
Die Untersuchungszeitlinie zeigt dar, wie die Arbeit voranschritt: Sammlung von Kontextinformationen, Erkennung der Ressourcen, Bewertung der Metriken sowie Erarbeitung der Erkenntnisse. Eine Gestaltungsoption verdient besondere Aufmerksamkeit. Wenn Metriken fehlen, teilt der Agent dies unverblümt mit und versagt nicht stillschweigend. Es handelt sich um eine kleine Entscheidung mit großer Auswirkung auf das Vertrauen.
Ursachenanalyse
Im Reiter „Ursachen“ nannte der Agent mehrere mitwirkende Ursachen, nicht nur eine:
- Detaillierte Überwachung auf den EC2-Instanzen deaktiviert. Die Instanzen zeigten
Monitoring: disabledan, und ohne detaillierte Überwachung werden diese CPU-Metriken niemals an CloudWatch übermittelt. - Kein CloudWatch-Agent installiert. Auf den Instanzen wurde nichts konfiguriert, weshalb detailliertere CPU-Daten nicht verfügbar waren.
- Instanzen gestoppt. Sie waren über einen längeren Zeitraum gestoppt, und gestoppte Instanzen liefern keine Metriken.
Wichtig ist, wie der Agent funktioniert hat. Er kam nicht auf eine einzige Erklärung, ordnete die Ursachen sinnvoll ein und untermauerte jede mit Belegen aus den AWS-APIs.
Wenn keine Maßnahme die richtige Antwort ist
Die Registerkarte „Minderungsplan“ gab an, dass keine unmittelbaren Minderungsmaßnahmen identifiziert werden konnten. Das ist ein gutes Ergebnis, kein schlechtes. Das System verhielt sich genau wie konfiguriert. Weder Rückschritte noch kürzliche Änderungen hatten das Symptom verursacht. Jede Lösung würde einer geplanten Konfigurationsänderung entsprechen und nicht der Minderung eines Incidents. Es ist wichtig, diese Grenze in der Produktion einzuhalten, da dadurch unnötige Rollbacks verhindert werden.
Prävention
Die Registerkarte „Prävention“ untersucht frühere Untersuchungen und entscheidet, ob proaktive Empfehlungen angebracht sind. Hier wurde nichts Neues erzeugt, und der Agent erkannte zu Recht kein wiederkehrendes Betriebsrisiko. Die von ihm bewerteten Kategorien sind Infrastruktur, Beobachtbarkeit, Governance und Codeoptimierung.
Warum Teams daran interessiert sein könnten
Es handelt sich dabei nicht um ein weiteres Monitoring-Produkt. Der Wert liegt in vier Aspekten: kürzere Untersuchungszeiten, strukturierte Analyse der Ursachen, weniger Alarmüberlastung sowie eine Möglichkeit für Teams, herauszufinden, warum ihre Systeme sich so verhalten. Andernfalls müssten Ingenieure CloudWatch, EC2-Einstellungen, den IAM-Zustand sowie die Bereitstellungshistorie manuell zusammenfügen. Der Agent übernimmt diese Korrelation für sie.
Funktionen zur Release-Verwaltung (Vorabversion)
Eine neuere Funktion ermöglicht es, den Agent bereits früher einzusetzen – noch bevor der Code die Produktumgebung erreicht.
Überprüfung der Bereitschaft für die Veröffentlichung. Jede Codeänderung wird anhand von Kriterien für die Bereitschaft für die Produktion, Risiken durch Abhängigkeiten zwischen Repositorien sowie ggf. von vom Unternehmen definierten Standards bewertet; falls keine solchen Standards vorhanden sind, werden allgemeine Best Practices herangezogen. Zu den spezifischen Überprüfungen gehören der Einfluss einer Änderung auf nachgelagerte Dienste in anderen Repositorien sowie Anpassungen im Bereich IAM oder Zugriffskontrolle, die am AWS Well-Architected Framework gemessen werden. Zudem startet der Agent den Build in einer von AWS verwalteten isolierten Umgebung und führt einige einfache Tests zur Überprüfung der Benutzerinteraktion durch. Diese bestätigen, dass der Build erfolgreich ist, die Anwendung läuft und grundlegende Funktionsprüfungen bestehen – alles noch bevor die Änderung in den Pipeline-Prozess aufgenommen wird.
Die Ergebnisse werden in der DevOps Agent-Konsole sowie als Kommentare zu Pull Requests auf GitHub oder GitLab angezeigt. Sie können außerdem auf Wunsch über eine IDE mithilfe des Kiro Power-Tools oder des Claude Code-Plugins ausgelöst werden, sodass Entwickler Abhängigkeitsrisiken, Standardverstöße und Zugriffssteuerungsprobleme vor dem Commit erkennen können.
Autonome Freigabetests. Dadurch wird die Idee in die Vorbereitungsphase vor dem Merge verschoben. Anstelle eines festen Testsets werden Testpläne erstellt, die speziell auf die Änderung zugeschnitten sind und in umgebungenähnlichen Produktionsumgebungen ausgeführt werden, die vom Kunden bereitgestellt werden – für Web- und API-Anwendungen. Da das System die Bedeutung der Änderungen analysiert, kann es Funktionalitäts- und Regressionstests sowie Tests zur Integration zwischen verschiedenen Diensten erstellen, die ein manuell gepflegtes Testset möglicherweise niemals berücksichtigen würde. Jede Ausführung erzeugt strukturierte Ergebnisse, nämlich Metriken, Protokolle, Spuren sowie eine Ausführungszusammenfassung, die den Prüfern eine konsistente und nachvollziehbare Dokumentation der Testabdeckung und Ergebnisse für jede Änderung liefern.
Sowohl Funktionen sind noch in der Vorabversion verfügbar und verursachen in diesem Zeitraum keine zusätzlichen Kosten. Sie sind in der Region US East (N. Virginia) verfügbar.
Was Agent Skills sind
Fähigkeiten sind modulare Anweisungssätze, die dem Agenten spezialisierte Fachwissen sowie Ermittlungsmethoden verleihen, die an die eigene Infrastruktur und Praktiken eines Teams angepasst sind. Eine Fähigkeit ist ein eigenständiger Ordner mit Markdown-Anweisungen, der dem Agenten eine neue Fähigkeit vermittelt. Der Dienst unterstützt einen Teilbereich der offenen Agent Skills-Spezifikation und akzeptiert nur nicht ausführbares Material: Markdown-Anweisungen, PDFs, Bilder und Datendateien.
Jede Fähigkeit benötigt eine SKILL.md-Datei, in der die Anweisungen gespeichert sind. Darüber hinaus kann eine Fähigkeit Folgendes enthalten:
- Ermittlungsworkflows für bestimmte Szenarien oder Infrastrukturtypen
- Referenzmaterial, wie Architekturmuster und Betriebsanleitungen
Warum sich die Mühe machen?
Fähigkeiten verwandeln einen Allzweck-Assistenten in einen Spezialisten für eine bestimmte Umgebung. Eine einmal eingegebene Anweisung im Chat verschwindet danach, während eine Fähigkeit wiederverwendbar ist und bei Bedarf automatisch geladen wird. Es ergeben sich vier Vorteile:
- Spezialisierung. Der Agent erlernt Ermittlungsverfahren, gute Praktiken sowie organisatorisches Wissen, das speziell für die Infrastruktur gilt.
- Weniger Wiederholungen. Ein einmal geschriebener Workflow wird automatisch in jeder relevanten Ermittlung verwendet, sodass dieselben Anleitungen nicht erneut dargelegt werden müssen.
- Komposition. Mehrere Fähigkeiten bilden zusammen einen vollständigen Arbeitsablauf. Der Agent kann während einer Ausführung mehrere davon nutzen, zum Beispiel eine, die Bereitstellungen aus einem benutzerdefinierten CI/CD-Pipeline abruft, und eine weitere, die in Code-Repositories sucht.
- Bessere Nutzung benutzerdefinierter Tools. Eine Fähigkeit kann dem Agenten mitteilen, wann ein bestimmtes MCP-Server-Tool aufgerufen werden soll, welche Parameter für verschiedene Szenarien geeignet sind und wie die Ergebnisse gelesen werden.
Wie sie genutzt werden
Wenn der Agent auf eine relevante Aufgabe stößt, lädt er die passenden Fähigkeiten und folgt deren Anweisungen. Eine Fähigkeit mit dem Namen „Database Performance Investigation“ könnte beispielsweise schrittweise Verfahren für das Throttling von RDS enthalten und den Agenten systematisch durch Alarmzustände, Verbindungsmetriken sowie langsame Abfragen führen.
Aufbau einer Fähigkeit
Eine Fähigkeit ist ein Verzeichnis:
my-skill/
├── SKILL.md # Main skill instructions
├── references/ # Optional: additional reference documentation
└── assets/ # Optional: images, diagrams, data files
Die Datei SKILL.md ist das einzige obligatorische Element. Sie sollte beschreiben, wann und wie die Fähigkeit angewendet wird, schrittweise Untersuchungsverfahren angeben, Entscheidungsbäume für verschiedene Szenarien enthalten sowie erwartete Ausgaben und Erfolgskriterien festlegen.
Beispiele für Fähigkeiten und deren Hochladen
AWS veröffentlicht in der aws-samples GitHub-Organisation eine Sammlung von Beispielfähigkeiten, die für diesen Laufzeitumfeld entwickelt wurden. Es handelt sich dabei nicht um allgemeine Agent-Fähigkeiten, sondern um solche, die speziell auf den DevOps Agent Laufzeitumfeld, seine Agenttypen sowie die Workflows zugeschnitten sind, die innerhalb eines Agent Spaces ausgeführt werden.
Um eine dieser Fähigkeiten zu verwenden, laden Sie das gewünschte ZIP-File aus dem Repository herunter oder erstellen Sie ein Paket mit dieser Struktur:
<skill-name>.zip
├── SKILL.md # Required: main instructions + YAML frontmatter
├── references/ # Optional: reference documentation
│ ├── architecture.md
│ └── troubleshooting.md
└── assets/ # Optional: images, diagrams, data files
Platzieren Sie SKILL.md im Wurzelverzeichnis der ZIP-Datei mit gültigem Frontmatter, das name und description enthält. Ein Muster für das Frontmatter könnte einen Namen wie eks-resilience-checker-skill-devops sowie eine Beschreibung enthalten, die beispielsweise Verfahren zur Bewertung der Widerstandsfähigkeit von Amazon EKS umfasst – einschließlich Überprüfung des Gesundheitszustands der Steuerungsplattform, Skalierung der Datenebene, Netzwerkproblemen und Mängeln in der Überwachungsfunktion – und für die Bewertung oder Behebung der Widerstandsfähigkeit des Clusters verwendet werden soll.
Folgen Sie anschließend den Schritten zum Hochladen:
- Stellen Sie sicher, dass die ZIP-Datei keinen
scripts/-Ordner enthält und insgesamt 6 MB oder weniger groß ist. - Öffnen Sie die Operator Web App und wechseln Sie zur Skills-Seite.
- Wählen Sie „Skill hinzufügen“ und anschließend „Skill hochladen“.
- Ziehen Sie die
.zip-Datei in das Fenster oder suchen Sie sie manuell. Nur ZIP-Dateien bis zu 6 MB werden akzeptiert.
Generic ist vorausgewählt und gilt für alle Typen. Deaktivieren Sie es, um On-demand, Incident Triage, Incident RCA, Incident Mitigation oder Evaluation anzusteuern.Spätere Verwaltung der Fähigkeiten
- Liste und Anzeigen: Jede Fähigkeit auf der Fähigkeitsseite kann geöffnet werden, um ihre Dateien (
SKILL.md,references/,assets/) einzusehen – nur zum Lesen. - Aktivieren oder Deaktivieren: Schalten Sie in der Detailansicht zwischen
ActiveundInactiveum. Inaktive Fähigkeiten bleiben gespeichert, werden aber bei neuen Ermittlungen nicht geladen.
Eine Fähigkeit in der Benutzeroberfläche erstellen
Ein einzelner SKILL.md-Datei ohne Referenzen oder Ressourcen kann den ZIP-Datei-Import ganz vermeiden:
- Gehen Sie auf die Skills-Seite, wählen Sie „Fähigkeit hinzufügen“ und anschließend „Fähigkeit erstellen“.
- Geben Sie einen Namen in Kleinbuchstaben, Zahlen und Bindestrichen ein – maximal 64 Zeichen, weder mit noch ohne Bindestrich am Anfang oder Ende.
- Geben Sie eine Beschreibung ein, idealerweise mindestens 100 Zeichen und maximal 1024.
- Wählen Sie einen Status (
ActiveoderInactive) sowie einen oder mehrere Agententypen aus. - Kopieren Sie den Markdown-Text in das Feld „Anweisungen“.
- Wählen Sie „Erstellen“. Das System generiert automatisch eine
SKILL.md-Datei mit den richtigen Metadaten.
Wo es zum Einsatz kommt
Für alle, die AWS in großem Umfang betreiben, lohnt es sich, diesen Service auszuprobieren – insbesondere für die Priorisierung von Vorfällen und die Analyse nach einem Vorfall. Einfach ausgedrückt verhält er sich wie ein autonomer, rund um die Uhr arbeitender Kollege. Er beginnt sofort mit der Untersuchung, sobald eine Alarmmeldung ausgelöst wird, verkürzt die Zeit bis zur Lösung durch das Abgleichen von Telemetriedaten, Code sowie Deployment-Historie und hilft dabei, zukünftige Ausfälle in AWS sowie in hybriden und multi-Cloud-Umgebungen zu vermeiden.