Feilsøk med testbare hypoteser

Beskriv feilen før du foreslår en rettelse

En nyttig feilsøkingsforespørsel angir forventet atferd, observert atferd og berørt omfang. Ta med versjon, relevante inndata og feil. Fjern påloggingsopplysninger og private poster fra logger før du gir dem til et AI-verktøy.

«Eksporten er ødelagt» gir lite retning. En bedre beskrivelse er: «Eksporten lykkes lokalt. I staging returnerer samme lederforespørsel 403 etter siste utrulling. Andre routes fungerer fortsatt.»

Beskrivelsen fastslår ikke årsaken. Den identifiserer forskjeller som kan styre undersøkelsen.

Hold flere forklaringer åpne

Be agenten om et lite sett plausible årsaker og dokumentasjonen for hver. Ikke be den låse seg til den første overbevisende forklaringen.

For den fiktive eksportfeilen kan årsakene være en manglende tillatelse for tjenesteidentiteten, endret rolletilordning eller en forespørsel sendt til feil miljø. Hver forklaring forutsier ulik dokumentasjon.

Tabellen er et utgangspunkt. Et 403-svar kan komme fra ulike lag. Identifiser komponenten som produserte det, før du antar at applikasjonens autorisasjon feilet.

Velg en trygg observasjon

Start med en observasjon som kan skille forklaringer til lav kostnad. Sammenlign utrullet versjon og konfigurasjon uten hemmeligheter. Undersøk relevant feil og forespørselsidentifikator. Gjenskap problemet i et autorisert testmiljø når det er mulig.

Ikke gi brede tillatelser bare for å se om feilen forsvinner. Handlingen endrer sikkerhetsgrensen og kan skjule den faktiske manglende tillatelsen. Ikke lim inn en full produksjonslogg i modellen når en renset feil og forespørselsvei er tilstrekkelig.

Angi hva som ville svekke hver hypotese. Det hjelper agenten med å revidere forklaringen i stedet for å forsvare første svar.

Endre én årsak om gangen

Gjør en fokusert rettelse etter at dokumentasjonen identifiserer en sannsynlig årsak. Unngå å kombinere en tillatelsesendring, bibliotekoppgradering og omskriving av en håndterer. Hvis symptomet forsvinner, vil du ikke vite hvilken endring som hadde betydning.

Verifiser den opprinnelige feilbetingelsen. Kontroller også den tilstøtende grensen. Hvis du retter en leders tilgang, bekreft at en uautorisert bruker fortsatt får avslag.

Legg til en regresjonskontroll på laget som kan oppdage en tilbakevendende feil. En enhetstest kan ikke oppdage alle feil i utrullingskonfigurasjon. Noen feil krever en integrasjonskontroll eller kontrollert verifisering etter utrulling.

Stopp gjentatte forsøk uten ny dokumentasjon

En agent kan generere mange varianter av en rettelse. Flere forsøk forbedrer ikke nødvendigvis diagnosen. Hvis samme feil gjentar seg, spør hvilken ny observasjon neste forsøk vil gi.

Sett en tids- eller forsøksgrense for usikker undersøkelse. Rapporter da aktuell dokumentasjon, avviste hypoteser og det uløste spørsmålet. Registreringen lar en annen person fortsette uten å gjenta de samme eksperimentene.

Registrer etter gjenoppretting årsaken og forholdet som lot feilen nå det berørte miljøet. En rettelse fjerner den umiddelbare feilen. Nyttig oppfølging reduserer sannsynligheten for at samme feil kommer tilbake.