Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Tipp
- Verwenden Sie hypothesengesteuerte Untersuchung, keine zufällige Protokollsuche.
- Stellen Sie eine vollständige Nachweiskette bereit, die zeigt , warum dies die Ursache ist.
- Erinnern Sie sich an ähnliche frühere Vorfälle und deren Korrekturen.
Das Problem: Eine Protokollsuche ist keine Untersuchung.
Die meisten Debugging beginnen mit "Fehler anzeigen". Sie abfragen Protokolle, Scrollen durch Ergebnisse, Kopieren eines Zeitstempels, Wechseln von Tools und Ausführen einer anderen Abfrage. Sie ermitteln nicht. Sie korrelieren Daten manuell und behalten die Argumentation im Kopf.
Das eigentliche Problem besteht darin, protokolle nicht zu finden. Es geht darum, zu wissen, welche Fragen zu stellen sind, welche Tools zu prüfen sind, und wie man die Verbindung zwischen Protokollen, Metriken, Bereitstellungen und früheren Vorfällen herstellt. Dieses mentale Modell lebt in den Köpfen Ihrer leitenden Ingenieure, und sie können nicht auf jedem Anruf sein. Neue Teammitglieder verbringen Stunden mit Problemen, die Veteranen in Minuten lösen, da die Begründung nicht überall dokumentiert ist.
Wie der Azure SRE-Agent dieses Problem löst
Ihr Agent untersucht fachmännisch wie ein erfahrener SRE. Es werden nicht nur Protokolle durchsucht. Es bildet Hypothesen darüber, was schief gelaufen ist, und überprüft systematisch jeden anhand von Beweisen.
- Sammelt Kontext: Abfragen von Application Insights, Azure Monitor, Bereitstellungsverlauf, Aktivitätsprotokolle und Ressourceneigenschaften.
- Formularhypothesen: Generiert Theorien basierend auf dem Beweismuster.
- Überprüft jeden: Testet Hypothesen systematisch und schließt falsche Leads aus.
- Erläutert die Schlussfolgerung: Zeigt den vollständigen Begründungspfad mit unterstützenden Beweisen und Zitaten.
Was macht dies anders
Im Gegensatz zur Protokollsuche haben Ihre Agenten gründe für das Problem. "Fehler anzeigen" gibt Ihnen Daten, die interpretiert werden sollen. Ihr Agent interpretiert die Daten für Sie, indem sie Theorien bilden, testen und Schlussfolgerungen erläutern.
Im Gegensatz zu statischen Dashboards passt sich Ihr Agent an den jeweiligen Vorfall an. Es werden nicht nur Metriken angezeigt. Es entscheidet, welche Metriken wichtig sind, korreliert sie mit anderen Nachweisen und teilt Ihnen mit, warum.
Im Gegensatz zu Skripts behandelt Ihr Agent neuartige Situationen. Jedes Mal führt ein Skript dieselben Schritte aus. Der Agent überlegt, was dieses Mal anders ist, und passt seine Untersuchung entsprechend an.
| Fähigkeit | Was sie beiträgt |
|---|---|
| Gedächtnis | "Wir haben dieses problem vor 3 Wochen gesehen. Der Fix war X." |
| Wissensdatenbank | Ihre Runbooks und Architekturdokumente unterstützen die Bildung von Hypothesen. |
| Quellcode | Korrelieren von Fehlern mit Quellcode und Suchen verwandter Änderungen |
| Subagenten | Delegieren Sie an servicespezifische Spezialisten (Application Insights, AKS, Container Apps und mehr) |
Vor und nachher
| Kategorie | Vorher | Nach |
|---|---|---|
| Untersuchungsansatz | Suchprotokolle, in der Hoffnung, dass Sie fündig werden | Agenten bilden und testen Hypothesen |
| Geöffnete Tools | 4+ Portale, manuelle Korrelation | 0 (Agent fragt alle Quellen ab) |
| Reasoning | "Ich denke, es ist die Datenbank..." | Die Datenbank-DTU ist bei 98 % und validiert. |
| Nachweispfad | In Ihrem Kopf | Vollständige Kette mit Erläuterung |
| Nächstes Mal | Von Grund auf neu starten | Speicher erinnert an ähnliche Vorfälle |
Beispiel: Datenbank-Timeout-Untersuchung
Symptom: "500 Fehler am /api/orders-Endpunkt"
HYPOTHESIS 1: Recent deployment broke something
├─ Checked: Last deployment was 3 days ago
├─ Evidence: Error rate stable until 30 minutes ago
└─ Result: INVALIDATED
HYPOTHESIS 2: Database overloaded
├─ Checked: Azure SQL metrics (CPU, DTU, connections)
├─ Evidence: DTU at 98%, query duration 4x normal
├─ Traced: SELECT * FROM orders WHERE... taking 8.2s
└─ Result: VALIDATED
ROOT CAUSE: Orders table missing index on customer_id column.
Query plan shows full table scan on 2.1M rows.
RECOMMENDED ACTION: Add index on orders.customer_id
Similar fix applied in INC-2341 (3 weeks ago)
Erste Schritte
Die Ursachenanalyse funktioniert automatisch mit den integrierten Azure-Tools. Um eine tiefergehende Analyse zu ermöglichen, sollten Sie die folgenden Verbesserungen berücksichtigen.
| Verbesserung | Was es ermöglicht | Konfiguration |
|---|---|---|
| Quellcodeverwaltung | Fehler-zu-Code-Korrelation, Semantikcodesuche | Quellcode verbinden |
| Wissensdatenbank | Kontext für die Hypothesengenerierung | Hochladen von Wissen |
| Benutzerdefinierte Telemetrie | Geschäftsmetriken in Kusto | Kusto Connector |