Pexon Consulting, Azure Operations | 9 Min. Lesezeit | aktualisiert 01.09.2026
TL;DR
Der Azure SRE Agent ist Microsofts KI-gestützter Operations-Teammate für Incidents auf Azure. Er nimmt Alerts aus ServiceNow, PagerDuty oder Azure Monitor auf, diagnostiziert, mitigiert in dem Run-Mode den Sie setzen und macht Root-Cause-Analyse im Quellcode. Das Produkt ist seit März 2026 allgemein verfügbar.
Was der Azure SRE Agent ist
Der Azure SRE Agent verbindet Azure-Ressourcen, Observability, Incident-Plattformen und Repos. Microsoft Learn beschreibt drei Muster: Incidents automatisieren, Scheduled Workflows, Investigate-and-Advise (etwa: what changed in the last hour).
Das Produkt ist seit März 2026 allgemein verfügbar. Die Azure-Friday-Folge mit Scott Hanselman und Deepti entstand noch in der Preview-Phase (East US, Sweden Central). Der Regionenstand vom 01.09.2026 ist breiter; die Tabelle gehört auf die Implementierungsseite, nicht in diesen Ablauf.
Hanselman in der Demo: KI soll tun, was dull, dirty und dangerous ist. Logs ziehen ist langweilig. In Produktion herumzufummeln ist gefährlich. Genau das übernimmt der Agent, in den Grenzen die Sie setzen.
Ein Plattform-Owner sagte uns sinngemäß: der Cluster kann perfectly healthy und gepatcht sein, aber es kommt ein Fünfhunderter zurück. Das ist der App-Incident, nicht der Cluster-Build.
Das Demo-Szenario: Add to Cart wirft Fehler
Food-Order-App, ServiceNow-Incident, East US. Ein Kunde kann nichts in den Warenkorb legen. Ohne Agent: Pager um 2 Uhr nachts. Mit Agent: die Untersuchung startet, bevor jemand aufwacht.
Das ist eine aufgezeichnete Demo mit vorbereitetem Incident, kein Kundenprojekt von Pexon Consulting. So lesen Sie die 15 Minuten.
In der Demo hing der Pfad an ServiceNow. Learn nennt zusätzlich Azure Monitor Alerts und PagerDuty. Der Agent postet Status dorthin, wo Ihr Team schon liest: E-Mail, Chat, Ticket-Feed.
Der Ablauf in sieben Schritten
Kein Tutorial zum Nachklicken im Portal. Sieben Schritte, wie sie in der Aufzeichnung sichtbar sind.
1. Incident aufnehmen
ServiceNow in der Demo, alternativ PagerDuty oder Azure Monitor Alerts. Der Agent startet die Analyse, sobald der Connector den Alert durchreicht.
2. Response-Plan
Built-in-Pläne für Azure-Dienste plus eigene. Autonomie: vollautomatisch, Mensch arbeitet mit, oder Mensch genehmigt. Der Plan ist die Instruktion, nicht ein verstecktes Skript.
3. Diagnose
CPU, Memory, Verfügbarkeit. App-Logs. In der Demo wirkte Memory unauffällig, die Logs zeigten Out-of-Memory, Korrelation mit Request-Volume. Entscheidung: App-Problem, nicht Plattform.
4. Mitigation
Scale-up der App. Jeder Schritt mit Timestamp. Nichts passiert ungefragt, außer Sie haben Autonomous für diese Klasse gewählt.
5. Überwachung danach
Der Agent zieht dieselben Metriken erneut. In der Demo sinngemäß: Recovery looks stable. No 500 errors recently. Die Watch-Dauer ist konfigurierbar.
6. Root-Cause im Code
Semantische Suche in GitHub: welche Dateien passen zum Incident. Pinpoint der undichten 10-MB-Allokation. Zusätzlich IaC-Drift: Cloud wurde hochskaliert, im Code steht etwas anderes.
7. Ticket und Handoff
GitHub-Issue mit Evidence, Assignment, optional Copilot Coding Agent erzeugt einen Pull Request. ServiceNow auf resolved, Summary zurückgeschrieben. In der Aufzeichnung 5:18 bis 5:34, 15 Minuten.
15 Minuten gelten für diese Demo, nicht als Betriebs-SLA. In Ihrem Tenant entscheiden Timeouts, Approvals, Repo-Größe und Connector-Lage.
Human-in-the-Loop ist die Standardeinstellung, nicht die Ausnahme
Nicht jeder will Vollautomatik. Hanselman in der Demo: not everyone is excited about this stuff. Sie setzen, wo der Agent stoppt: ServiceNow-Approval, Copilot-Approval, Code Review, PR-Notification.
ServiceNow-Discussion-Posts: das Team bleibt im gewohnten Feed, auch wenn niemand den Agent-Thread offen hat.
Learn-Begriffe: Review mode gegen Autonomous mode. Default im Text und in der Implementierung: Review für Produktion. Autonomous nur für klar begrenzte Klassen, etwa Dev/Test oder ein bekanntes Scale-up-Pattern.
Jeder Schritt ist im Thread sichtbar. Wartezeit auf Freigabe zählt bei Active Flow nicht.
Drei Checks bevor der erste produktive Incident durchläuft:
- Review-Mode ist Default für Produktion. Autonomous nur für eine klar begrenzte Klasse, etwa Dev/Test oder ein bekanntes Scale-up-Pattern.
- Ein Connector ist produktiv angebunden (ServiceNow, PagerDuty oder Azure Monitor) und ein Test-Incident vom Typ, den Sie später automatisieren wollen, liegt bereit.
- Repo-Rechte sind eng: der Agent liest nur die Repos, die zum Incident-Typ gehören. Write und Pull Request laufen über sichtbare Approval-Schritte.
Bring Your Runbooks
Sie geben Instruktionen in natürlicher Sprache. Beispiel aus der Demo-Logik: Wenn Add-to-Cart bricht, GitHub-Issue eröffnen, assignen, Metriken ins Ticket. Der Agent erzeugt den detaillierten Plan inklusive Tool-Calls. Der Mensch schreibt nicht den Plan.
Die Qualität der Instruktion entscheidet. Garbage-in, Garbage-out. Das ist der Hebel, warum ein Agent im Portal noch kein produktiver Incident-Pfad ist. Den Schnitt aus Incident-Typen, Tool-Policies und Repo-Rechten beschreibt die Implementierungsseite zum Azure SRE Agent.
Was Scheduled Tasks damit zu tun haben
In der Demo als coming soon gezeigt: Deployment-Health-Check, Smoke-Test, wenn kürzliches Deployment dann Health Check und Rollback. Ein Absatz-Prompt wird zu Goal, Scope, Schritten, Constraints, Report-Format. Teilbar als Best Practice.
Learn Overview (Stand 01.09.2026) beschreibt Scheduled Tasks als vorhandene Funktion. In der Demo noch angekündigt, in der Learn-Doku als Tab dokumentiert. Vor dem ersten produktiven Cron im Portal prüfen. Kein zweites Tutorial hier.
Was der Agent nicht ersetzt
Azure Monitor und Sentinel bleiben Telemetrie und SIEM. Der Agent liest Monitor, Log Analytics und App Insights. Tiefe zum Betrieb: Azure Monitor im Enterprise.
AKS bauen bleibt Cluster, Node Pools und private API. Der Agent kann AKS-Workloads untersuchen. Er ersetzt den Build nicht. Abgrenzung: Azure AKS Consulting und Implementierung.
Menschen in der Nacht bleiben ein Betriebsmodell, kein Feature des Agenten. Wer First-Level abgeben will, gehört nicht in diesen Artikel.
Live Reports und VNet-Integration sind der Launch vom 25.08.2026. Incident-Lifecycle und Morgenlage sind zwei Intents. Die Implementierungsseite hält den Kurzblock; dieser Artikel hält den Head-Term Azure SRE Agent und die Demo.
Kosten in einem Absatz
Always-on: 4 AAU pro Agent-Stunde, solange der Agent existiert. Active Flow nach Token und Modell. Learn-Beispiel Incident investigation: rund 35 AAU mit Claude Opus 4.6, rund 12 AAU mit GPT 5.3 Codex. Wartezeit auf Freigabe zählt nicht. Keine Euro-Umrechnung auf dieser Seite. Die AAU-Tabelle und der Pilot-Schnitt stehen auf der Implementierungsseite.
Häufige Fragen
Was macht der Azure SRE Agent bei einem Incident?
Er nimmt den Alert auf, folgt einem Response-Plan, zieht Metriken und Logs, unterscheidet App- von Plattform-Problem, mitigiert nach dem gesetzten Run-Mode, überwacht die Stabilisierung, sucht die Ursache im Repo und schreibt Ticket plus Summary zurück in ServiceNow oder das Incident-Tool.
Kann der Azure SRE Agent von allein in Produktion ändern?
Nur wenn Sie Autonomous für diese Incident-Klasse gesetzt haben. In Review mode wartet er auf Freigabe für Write-Actions. In der Demo war Vollautomatik eine Option, kein Zwang. Jeder Schritt ist im Thread sichtbar.
Findet der Azure SRE Agent die fehlerhafte Code-Stelle?
Wenn GitHub oder Azure DevOps angebunden sind, matcht er Incident-Daten per semantischer Suche auf Dateien, pinpointet die Stelle und kann Änderungen vorschlagen. Zusätzlich erkennt er Drift zwischen Cloud-Konfiguration und Infrastructure-as-Code, etwa nach einem Scale-up.
Wie lange dauert so eine Incident-Bearbeitung?
In der Azure-Friday-Aufzeichnung 15 Minuten von Ticket auf bis resolved, inklusive PR durch den Coding-Agent. Das ist eine vorbereitete Demo. In Ihrem Tenant entscheiden Timeouts, Approvals, Repo-Größe und Connector-Lage.
Brauche ich ServiceNow, oder reicht Azure Monitor?
Die Demo hing an ServiceNow. Learn nennt Azure Monitor Alerts, PagerDuty und ServiceNow. Der Agent postet Status dorthin, wo Ihr Team schon liest.
Wohin als Nächstes
Den Azure SRE Agent produktiv einführen: Response-Pläne, Runbooks, Connectoren, VNet und Governance. Das ist der nächste Schritt auf der Implementierungsseite.
Azure-Landschaft und Hub: Azure Consulting.
Quellen: Microsoft Learn, Azure SRE Agent Overview, Pricing and billing, sre.azure.com, Azure-Friday-Aufzeichnung (Hanselman / Deepti).
