Azure Copilot Troubleshooting Agent: GA, Portal, nicht SRE

Constantin, Azure Operations bei Pexon Consulting | 11 Min. Lesezeit | 10.09.2026

TL;DR

Azure Copilot Troubleshooting Agent ist seit dem 09.09.2026 GA, ohne Extra-Lizenz, im Portal und unter Support + Troubleshooting. Er diagnostiziert unter RBAC und schlägt vor. Ein One-Click-Fix bleibt Portal, kein On-Call. Azure SRE Agent bleibt der Head für Incidents. Wer nur den Chat hat, bleibt im POC.

Welche Query welche URL behält

Der Azure-Baum hat schon Owner. Dieser Text nimmt nur die neue GA-Entity.

Microsoft beschreibt den Ablauf in der Learn-Doku zum Troubleshooting Agent. Die GA-Linie steht parallel in der Tech-Community. Pexon-Meinung: nützlich als erster Schnitt, kein Ersatz für Runbook, Ticket und Review.

Was GA konkret ändert

Bisher war der Agent Preview. GA heißt: Einstieg über Azure Copilot oder Support + Troubleshooting, tiefe Schnitte für Azure Compute und AKS. Azure Local und Microsoft Entra bleiben Preview. Administratoren können den Zugriff auf Azure Copilot Agents zentral ein- oder ausschalten. Wer den Agent im Chat nicht sieht, hat oft kein Feature-Problem, sondern eine Tenant-Einstellung.

Compute deckt VMs, Scale Sets und Compute Fleet. Typische Symptome: unerwarteter Neustart, RDP- oder SSH-Bruch, Boot-Fehler, AllocationFailed, ungesunde Scale-Set-Instanzen. AKS deckt CrashLoopBackOff, hängende Deployments, Scheduling, Service-Discovery, Scaling, Upgrade-Regression, Image-Pull, OOM. Das sind genau die Symptome, die bei uns in der SRE-Implementierung im Betrieb landen, nicht im Chatfenster.

AKS-Workloads, die der Agent diagnostiziert, stehen weiter auf der AKS-Implementierung. Dieser Artikel klaut den Head nicht.

Preis: Microsoft stellt den Azure Copilot Troubleshooting Agent ohne Extra-Lizenz, ohne Abo und ohne Per-Query-Gebühr. Standard-Ressourcenkosten bleiben. Bestehende Support-Pläne ändern sich nicht. Wer das als „Ops ist erledigt“ liest, hat den Satz nicht zu Ende gelesen.

Wie der Agent im Portal arbeitet

Learn beschreibt fünf Stufen: Trigger, Scope, Diagnose, Resolve, Escalate. Der Mensch beschreibt das Symptom in natürlicher Sprache, im Kontext einer Resource, Resource Group oder Subscription. Der Agent scoped, zieht Health-Signale und Diagnostics, sucht eine Ursache. Findet er eine, empfiehlt er Schritte oder bietet in Teilfällen einen One-Click-Fix. Findet er keine, zeigt er Self-Help. Bleibt das Problem, baut er einen Support-Request mit Session-Kontext. Den Request bestätigt der Mensch, bevor er rausgeht.

Das ist grounded in Diagnostic Data und RBAC. Ohne Leserecht auf der Resource bleibt die Diagnose leer. Diagnostic depth variiert nach Service. Automatische Mitigation gibt es nicht für jedes Symptom. Microsoft sagt ausdrücklich: Sie bleiben in Control, Empfehlungen sind zu reviewen, bevor etwas geändert wird.

# Portal-Helfer, kein Schichtleiter
troubleshooting_agent:
  entry: ["azure copilot", "support + troubleshooting"]
  license: "no extra fee"
  ga_skills: ["compute", "aks"]
  preview_skills: ["azure local", "entra"]
  remediate: "recommend, one-click only where available"
  ticket: "prefilled, you still submit"

Genau diese Grenze ist die Pexon-Linie. Ein Vorschlag ohne Owner und ohne Ticket ist Folie, sobald der Prüfer fragt. Ein One-Click im Portal ist immer noch kein ServiceNow-Handoff und kein Git-PR.

Pexon-Meinung: drei harte Grenzen

1. Kostenlos ist kein Betrieb. Keine Extra-Lizenz spart Budget. Sie ersetzt keine Schicht, keine Alarmkette, keine Nachtschicht. Der Chat startet schneller. Er schließt den Incident nicht.
2. Empfehlung und One-Click sind nicht der Lifecycle. Der Azure Copilot Troubleshooting Agent erklärt Befunde und kann in Teilfällen anwenden. Apply in Prod bleibt Pipeline plus Review, sobald der Cluster oder die VM unter Change-Control steht. Sonst gewinnt der Portal-Klick gegen Git.
3. Erste Services sind nicht die Landschaft. Compute und AKS zuerst. Storage, APIM, private Endpoints und Custom Networking bekommen eine dünnere Diagnose. Wer den Agent als universellen Ops-Bot verkauft, überzieht die Doku.

Live Reports, FinOps-Hub und Incident-Handoff bleiben andere URLs. Wer sie hier hineinmischt, kannibalisiert den SRE-Ast. Copilot Studio und Microsoft 365 Copilot sind ein anderer Cluster. Diesen Ast füttern wir nicht mit diesem Slug.

Was wir in den ersten 90 Minuten prüfen

Der Workshop-Schnitt ist kurz, weil das Feature im Portal sitzt. Wir prüfen nicht, ob der Chat antwortet. Wir prüfen, ob die Antwort in den Betrieb passt.

Zuerst Tenant: Wer darf Azure Copilot Agents sehen? Reader auf einer VM reicht für Diagnose, Contributor auf dem Cluster reicht für gefährliche Klicks. PIM statt Standing Contributor. Dann ein reales Symptom, nicht die Demo-VM: Pod im CrashLoop, Scale-Set unhealthy, AllocationFailed. Drittens: landet das Ergebnis in einem Ticket mit Datum, oder nur im Chatverlauf? Viertens: welche Aktion würde der Agent vorschlagen, die bei uns nur über Pipeline laufen darf?

Wenn nach 90 Minuten nur ein Screenshot aus dem Portal liegt, ist der Agent eingeschaltet. Betrieb ist das nicht. Genau dann zeigt sich, ob On-Call, Runbook und Review schon stehen oder ob der Chat die Lücke kaschiert.

Production-Gap: Chat ja, Schicht nein

Häufig gestellte Fragen

Ist Azure Copilot Troubleshooting Agent dasselbe wie Azure SRE Agent?

Nein. Troubleshooting sitzt im Portal. SRE Agent ist der Incident- und Betriebsschnitt. Zwei URLs, zwei Queries.

Kostet der Agent Copilot-Sitze?

Microsoft: keine Extra-Lizenz, keine Per-Query-Gebühr. Azure-Ressourcen weiter nach Verbrauch. Support-Plan unverändert.

Darf der Agent ohne Admin-Rechte diagnostizieren?

Er respektiert RBAC. Ohne Leserechte auf der Resource bleibt die Diagnose leer. Das ist Feature, nicht Bug. Breite Reader-Rechte machen die Diagnose breit. Das ist die eigentliche Governance-Frage.

Ersetzt das Azure Support?

Nein. Der Agent kann den Support-Fall mit besserem Kontext starten. Den Fall bestätigt und besitzt weiter der Mensch.

Sollen wir den Agent in regulierten AKS-Clustern einschalten?

Lesen ja, Apply weiter über Pipeline und Review. Der Cluster-Schnitt bleibt die Money-Page, nicht dieser Blog.

Unterscheidet sich das von der agentic CLI für AKS?

Ja. Die CLI ist lokal, anderer Einstieg, andere Query. Dieser Text bleibt beim Portal-Agent.

Nächster Schritt

Verwandte Themen