Analýza původní příčiny v agentovi Azure SRE

Návod

  • Používejte šetření řízené hypotézou, ne náhodné prohledávání protokolů.
  • Poskytněte úplný řetěz důkazů, který ukazuje, proč je to příčina.
  • Vzpomeňte si na podobné minulé incidenty a jejich opravy.

Problém: Prohledávání protokolu není vyšetřování

Většina ladění začíná textem "show me the errors" (Zobrazit chyby). Dotazujete se na protokoly, projdete výsledky, zkopírujete časové razítko, přepnete nástroje a spustíte jiný dotaz. Nevyšetřuješ. Data ručně korezujete a držíte odůvodnění v hlavě.

Skutečný problém není najít protokoly. Vědět, jaké otázky položit, které nástroje zkontrolovat a jak propojit souvislosti napříč protokoly, metrikami, nasazeními a předchozími incidenty. Tento mentální model žije v hlavách vašich vedoucích inženýrů a nemůžou být na každém hovoru. Noví členové týmu tráví hodiny na problémech, které veteráni řeší v řádu minut, protože důvod není nikde zdokumentovaný.

Řešení tohoto problému pomocí agenta Azure SRE

Diagram znázorňující tok analýzy původní příčiny od shromažďování důkazů prostřednictvím ověření hypotézy k závěru

Váš agent prošetřuje jako expert SRE. Neprohledává jenom protokoly. Vytváří hypotézy o tom, co se nepovedlo, a systematicky ověřuje každou z nich pomocí důkazů.

  1. Shromažďuje kontext: Zasílá dotazy na Application Insights, Azure Monitor, historii nasazení, protokoly aktivit a vlastnosti prostředků.
  2. Formy hypotéz: Generuje teorie založené na vzoru důkazů.
  3. Ověřuje každou z nich: Testuje hypotézy systematicky a vylučuje nesprávné směry.
  4. Vysvětluje závěr: Ukazuje úplnou důvodovou stopu s podpůrnými důkazy a citacemi.

Čím se tento přístup liší

Na rozdíl od prohledávání protokolu váš agent problém zdůvodní. Funkce Zobrazit chyby vám poskytne data, která se mají interpretovat. Váš agent interpretuje data za vás vytvořením teorie, testováním a vysvětlením závěrů.

Na rozdíl od statických řídicích panelů se váš agent přizpůsobí konkrétnímu incidentu. Nezobrazuje jenom metriky. Rozhoduje o tom, které metriky jsou v korelaci s jinými důkazy, a řekne vám, proč.

Na rozdíl od skriptů váš agent zpracovává nové situace. Skript pokaždé spustí stejné kroky. Váš agent zdůvodňuje, co se tentokrát liší, a odpovídajícím způsobem upraví šetření.

Před a po

Kategorie před Po
Přístup ke zkoumání Prohledejte protokoly a doufejte, že něco najdete Agent tvoří a testuje hypotézy
Otevřené nástroje 4+ portály, ruční korelace 0 (agent se dotazuje na všechny zdroje)
Reasoning "Myslím, že je to databáze..." Databáze DTU na 98 %, ověřeno
Stopa důkazů V hlavě Kompletní řetězec s vysvětlením
Příště Začátek od nuly Paměť připomíná podobné incidenty

Příklad: Šetření časového limitu databáze

Příznak: Chyby 500 v koncovém bodu /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)

Začínáme

Analýza původní příčiny funguje automaticky s integrovanými nástroji Azure. Pokud chcete povolit hlubší analýzu, zvažte následující vylepšení.

Vylepšení Co umožňuje Setup
Správa zdrojového kódu Korelace chyb ke kódu, sémantické vyhledávání kódu Připojení zdrojového kódu
Znalostní báze Kontext generování hypotéz Načtení znalostí
Vlastní telemetrie Obchodní metriky v Kusto Nastavení konektoru Kusto

Další krok

Provést hloubkové šetření

Související obsah

  • Last updated on