Constantin, Azure Operations bei Pexon Consulting | 11 Min. Lesezeit | 12.09.2026
TL;DR
Azure Copilot Resiliency Agent ist seit dem 01.09.2026 Public Preview. Er bewertet zonale Resilienz, schreibt IaC und zeigt, ob ein Fix Geld, Downtime oder Redeploy braucht. Stay Resilient fehlt. Die Landing Zone bleibt der Head. Wer nur den Portal-Chat hat, bleibt im POC.
| Objekt | Was es ist | Was es nicht ist |
|---|---|---|
| Azure Copilot Resiliency Agent | Portal-Assistent, Start und Get Resilient | Azure SRE Agent, Troubleshooting Agent |
| Azure Landing Zone | CAF, Hub-Spoke, Identity, Policy | ein Chat, der Zonen umschaltet |
| Troubleshooting Agent | Diagnose im Portal | Zonen-IaC |
Welche Query welche URL behält
| Query | Owner |
|---|---|
| azure sre agent | Incident-Lifecycle |
| Azure Copilot Troubleshooting Agent | Troubleshooting-GA |
| azure landing zone | Landing Zone |
| azure beratung | Azure Consulting |
| Azure Copilot Resiliency Agent | dieser Text |
Microsoft: Learn zum Resiliency Agent und die Preview-Ankündigung vom 01.09.2026. Pexon-Meinung: nützlich als erster Schnitt für Availability Zones. Kein Ersatz für die Zone als Code.
Was die Preview konkret kann
Der Azure Copilot Resiliency Agent sitzt in Azure Copilot, Einstieg über den Agent-Dropdown oder über die Resiliency-Übersicht. Administratoren können den Zugriff abschalten. Wer ihn nicht sieht, hat oft eine Tenant-Einstellung, kein Feature-Bug.
Zwei Phasen sind in der Preview: Start Resilient für neue Workloads, Get Resilient für das, was schon läuft. Stay Resilient (Recovery-Orchestrierung, Zone-Drills) kommt später. Regional-Resilienz fehlt. Learn sagt das offen. Wer Backup und Failover als Agent-Feature erwartet, liest die Ankündigung zu Ende: Recovery-Pläne liegen heute in Infrastructure Resiliency Manager, nicht in diesem Chat.
Start Resilient: Architektur in natürlicher Sprache, Report, deployment-fertige Templates mit Zonen-Defaults. Learn: in diesem Flow aktuell Bicep. Tech Community nennt parallel Terraform. Wir schreiben das so: Preview-Doku ist nicht deckungsgleich. Vor dem ersten Apply die Ausgabe gegen Ihr Repo halten, nicht die Keynote.
Get Resilient: Service Groups, zonale Lücken, Voraussetzungen, Scripts. Formate dort: PowerShell, Azure CLI, Bicep, Terraform, ARM. Manche Ressourcen lassen sich in-place umstellen. VMs brauchen oft Redeploy. Site Recovery und Multi-User-Authorization bleiben laut Microsoft oft Handarbeit.
# Portal-Assistent, kein CAF
resiliency_agent:
status: preview
since: "2026-09-01"
phases: ["start resilient", "get resilient"]
missing: ["stay resilient", "regional"]
iac_start: "bicep in Learn, terraform claimed in blog"
remediate: "human in the loop"Kostenhinweise sind qualitativ: extra Spend, Downtime, Redeploy. Das ist Entscheidungshilfe, keine FinOps-Rechnung. Die sitzt woanders.
Pexon-Meinung: drei harte Grenzen
- Preview ist kein Betrieb. Preview-Terms gelten. Coverage hängt an der Support-Matrix von Azure Infrastructure Resiliency Manager. Ein grüner Chat ist kein Abnahmeprotokoll.
- Zonal ist nicht die Landing Zone. Der Agent schaltet Zonen-Flags und schreibt Snippets. Er setzt keine Management Groups, kein Hub-Spoke, keine Policy-Initiative und kein PIM. Genau das ist die Landing Zone.
- Script ist nicht Git. Ein Bicep aus dem Portal ohne Review, Branch Policy und Apply-Log ist der Befund, den interne Revision zuerst findet. Human-in-the-loop heißt: Sie bleiben in Kontrolle. Es heißt nicht: der Chat ist das Change-Verfahren.
Der Troubleshooting-Agent diagnostiziert Symptome. Der SRE-Agent ist Incident und Schicht. Dieser Text nimmt nur zonale Resilienz im Copilot. Wer die drei mischt, kannibalisiert drei URLs.
Brownfield mit gewachsenen Subscriptions bleibt ein eigener Schnitt. Der hängt an der Brownfield-Landing-Zone, nicht an diesem Preview-Artikel.
Service Groups sind der eigentliche Schnitt
Der Agent denkt in Anwendungen, nicht in einer flachen Ressourcenliste. Microsoft zwingt Sie damit zu etwas, das in vielen Tenants fehlt: eine Service Group, die VM, Datenbank und Lastverteiler als ein Workload beschreibt.
Ohne diese Gruppe bewertet der Chat Einzelteile. Eine zonal redundante Disk an einer VM in einer Availability Set-Folie sieht gut aus und ist trotzdem falsch geschnitten. Die Preview wird erst nützlich, wenn jemand Ownership, Subscription und App-Name in die Gruppe schreibt.
Das ist der Punkt, an dem CAF wieder auftaucht. Wer Management Groups, Naming und Tags nicht hat, produziert Service Groups nach Zuruf. Nächste Woche heißt dieselbe App anders. Der Agent trackt Compliance gegen ein Ziel, das niemand pflegt.
Cost-aware Indicators helfen bei der Reihenfolge: extra Spend, Downtime, Redeploy. Sie ersetzen kein Budget. Ein zonaler Storage-Account kostet anders als ein Redeploy von zwanzig VMs. Der Chat sagt qualitativ, welcher Hebel weh tut. Die Zahl holt FinOps, nicht dieser Artikel.
AKS taucht in den Sample-Prompts auf. Der Cluster bleibt trotzdem auf der AKS-Money-Page. Hier zählt nur: ein Node-Pool ohne Zonen ist ein Resiliency-Befund, kein Implementierungsauftrag.
Well-Architected Reliability ist die Sprache, die Prüfer kennen. Der Agent übersetzt einen Teil davon in zonale Schalter. Er übersetzt nicht Backup, RPO, RTO und das Restore-Datum. Wer die Preview als Reliability-Programm verkauft, überzieht Learn.
Was wir in den ersten 90 Minuten prüfen
Kein Demo-Prompt auf einer leeren Subscription. Wir nehmen eine Service Group, die einem echten Workload entspricht: VM plus Datenbank plus Lastverteiler, oder AKS plus Storage.
Zuerst: Ist der Agent im Tenant überhaupt sichtbar? Dann: Welche Ressourcen sind nicht zonal, und was blockt (Region, SKU, Rechte)? Drittens: Was würde der Agent in-place ändern, was braucht Redeploy? Viertens: Landet das Snippet in Git, oder nur im Chatverlauf?
Wenn nach 90 Minuten nur ein Report ohne Owner und ohne Ticket liegt, ist die Preview eingeschaltet. Eine Landing Zone ist das nicht.
Was danach dokumentiert werden muss, ist langweilig und deshalb der Teil, der in Audits zählt. Welche Subscription trägt die Service Group? Welches Naming? Wer darf den Agent im Tenant sehen, wer darf Apply? Liegt das generierte Bicep in Ihrem Repo oder nur im Copilot-Verlauf? Gab es nach dem Zonen-Umschalten einen Restore-Test, oder nur den grünen Chat?
Preview-Coverage ist eine Liste, kein Versprechen. Ressourcen ohne zonale Unterstützung in der Matrix bleiben draußen. Der Agent sagt das manchmal als Voraussetzung, manchmal als Lücke. Beides ist kein CAF-Exemption-Prozess. Exemptions mit Ablaufdatum leben in Policy, nicht im Prompt. Ein Chat, der eine SKU als blockiert meldet, ersetzt nicht den Satz in der Landing-Zone-Doku, warum diese SKU trotzdem bleibt und wer das Datum verlängert.
Infrastructure Resiliency Manager bleibt die Plattform unter dem Agent. Der Copilot ist die Sprachebene. Wer nur den Agent einschaltet und den Manager nie öffnet, hat keine Ziele, die über die Session hinaus halten. Service Groups, Goals, Compliance-Refresh: das ist Arbeit im Portal, die jemand besitzen muss, sonst ist die Preview in vier Wochen wieder nur ein Screenshot.
Wer denselben Tenant schon mit dem Troubleshooting-Agent diagnostiziert, soll die beiden Chats nicht mischen. Der eine erklärt, warum der Pod stirbt. Der andere erklärt, warum die Disk nicht zonal ist. Zusammenkopieren in ein Runbook ohne Owner erzeugt genau die Folie, die Prüfer nicht wollen.
Ein zweites Muster: Teams aktivieren den Agent, weil er kostenlos wirkt, und lassen Contributor auf der Subscription stehen. Dann kann der Chat mehr sehen und in Teilfällen mehr ändern, als das Change-Verfahren erlaubt. PIM und lesende Diagnoserechte zuerst, Apply weiter über Pipeline. Das ist dieselbe Governance-Linie wie beim Troubleshooting-Agent, nur mit Zonen statt Pod-Restarts.
Der Brownfield-Fall bleibt der härtere. Fünf Jahre gewachsene Ressourcengruppen, gemischte SKUs, eine Region ohne drei Zones. Der Agent listet Blocker. Die Reihenfolge, welches Abo zuerst aufgeräumt wird, ist Landing-Zone-Arbeit. Preview macht die Lücke sichtbar. Sie räumt das Abo nicht.
Production-Gap: Zonen-Chat ja, Zone als Code nein
Häufig gestellte Fragen
Ist Azure Copilot Resiliency Agent dasselbe wie Azure SRE Agent?
Nein. Resiliency sitzt auf Zonen und IaC im Portal. SRE ist Incident und Betrieb. Zwei URLs.
Ist der Agent allgemein verfügbar?
Nein. Public Preview seit 01.09.2026. Preview-Bedingungen gelten.
Ersetzt das Azure Site Recovery?
Nein. ASR und fortgeschrittene Recovery bleiben oft manuell. Stay Resilient ist noch nicht im Agent.
Darf der Agent in Prod Zonen umschalten?
Nur wo In-place vorgesehen ist, und nur nach Review. VMs typischerweise über Redeploy und Pipeline.
Reicht der Agent für eine DORA-Akte?
Als Betriebshebel vielleicht. Als Nachweis für Change brauchen Sie Apply, PR und Restore. Das gehört auf die Landing Zone, nicht auf diese URL.
Nächster Schritt
Verwandte Themen
