Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Suggerimento
- Usare l'analisi basata su ipotesi, non la ricerca casuale nei log.
- Fornire una catena di prove completa che mostra perché questa è la causa.
- Ricordare eventi imprevisti passati simili e le relative correzioni.
Il problema: la ricerca del registro non è un'indagine
La maggior parte del debug inizia con "mostra gli errori". È possibile eseguire query sui log, scorrere i risultati, copiare un timestamp, cambiare strumenti ed eseguire un'altra query. Non stai indagando. Si correlano manualmente i dati e si tiene il ragionamento nella testa.
Il problema reale non è trovare i log. È sapere quali domande porre, quali strumenti controllare e come connettere i punti tra log, metriche, implementazioni e incidenti passati. Questo modello mentale vive nelle menti dei tuoi ingegneri senior, e non possono partecipare a ogni riunione. I nuovi membri del team trascorrono ore su problemi che i veterani risolvono in pochi minuti, perché il ragionamento non è documentato da nessuna parte.
Come l'agente SRE di Azure risolve questo problema
Il tuo agente indaga come un esperto SRE. Non esegue solo ricerche nei log. Forma ipotesi su ciò che è andato storto e convalida sistematicamente ognuno usando prove.
- Raccoglie il contesto: esegue query su Application Insights, Monitoraggio di Azure, cronologia di distribuzione, log attività e proprietà delle risorse.
- Ipotesi di forme: genera teorie basate sul modello di evidenza.
- Convalida ognuno di essi: testa le ipotesi sistematicamente, escludendo falsi lead.
- Spiega la conclusione: mostra il ragionamento completo con prove e citazioni di supporto.
Cosa rende questo diverso
A differenza della ricerca nei log, l'agente ha motivi relativi al problema. "Mostra errori" fornisce i dati da interpretare. L'agente interpreta i dati formando teorie, testandole e spiegando le conclusioni.
A differenza dei dashboard statici, l'agente si adatta all'evento imprevisto specifico. Non mostra solo le metriche. Decide quali metriche sono importanti, le correla con altre prove e indica perché.
A differenza degli script, l'agente gestisce nuove situazioni. Uno script esegue gli stessi passaggi ogni volta. Il tuo agente ragiona su cosa è diverso questa volta e regola di conseguenza la sua indagine.
| Capability | Cosa contribuisce |
|---|---|
| Memory | "Abbiamo visto questo problema esatto 3 settimane fa. La correzione è stata X. |
| Knowledge Base | I runbook e la documentazione dell'architettura guidano la formazione di ipotesi |
| Codice sorgente | Correlare gli errori con il codice sorgente e trovare le modifiche correlate |
| Subagenti | Delegare a specialisti specifici del servizio (Application Insights, Azure Kubernetes Service (AKS), Container Apps e altro ancora) |
Prima e dopo
| Categoria | Prima | Dopo |
|---|---|---|
| Approccio di indagine | Cerca log, spero di trovare qualcosa | Formano e testano ipotesi sugli agenti |
| Strumenti aperti | 4+ portali, correlazione manuale | 0 (l'agente interroga tutte le fonti) |
| Reasoning | "Penso che sia il database..." | Database DTU al 98%, validato |
| Traccia delle prove | Nella tua testa | Catena completa con spiegazione |
| Prossima volta | Iniziare da zero | La memoria richiama eventi imprevisti simili |
Esempio: analisi del timeout del database
Sintomo: "500 errori nell'endpoint /api/orders"
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)
Inizia subito
L'analisi della causa radice funziona automaticamente con gli strumenti predefiniti di Azure. Per abilitare un'analisi più approfondita, prendere in considerazione i miglioramenti seguenti.
| Miglioramento | Cosa permette | Setup |
|---|---|---|
| Controllo del codice sorgente | Correlazione tra errori e codice, ricerca di codice semantico | Connettere il codice sorgente |
| Base di Conoscenza | Contesto per la generazione di ipotesi | Caricare le informazioni |
| Telemetria personalizzata | Metriche aziendali in Kusto | Connettore Kusto |