Felsök med testbara hypoteser

Beskriv felet innan du föreslår en rättning

En användbar felsökningsbegäran anger förväntat beteende, observerat beteende och påverkat omfång. Ta med version, relevant indata och fel. Ta bort autentiseringsuppgifter och privata poster från loggar innan du ger dem till ett AI-verktyg.

”Exporten är trasig” ger liten vägledning. En bättre beskrivning är: ”Exporten fungerar lokalt. I staging returnerar samma chefsförfrågan 403 efter senaste driftsättningen. Andra routes fungerar fortfarande.”

Beskrivningen fastställer inte orsaken. Den identifierar skillnader som kan vägleda undersökningen.

Behåll flera möjliga förklaringar

Be agenten om ett litet antal rimliga orsaker och underlag för varje. Be den inte låsa sig vid den första övertygande förklaringen.

För det fiktiva exportfelet kan möjliga orsaker vara en saknad behörighet för tjänsteidentiteten, ändrad rollmappning eller en förfrågan till fel miljö. Varje förklaring förutsäger olika underlag.

Tabellen är en utgångspunkt. Ett 403-svar kan komma från olika lager. Identifiera komponenten som skapade det innan du antar att applikationens auktorisering misslyckades.

Välj en säker observation

Börja med en observation som billigt kan skilja förklaringarna åt. Jämför driftsatt version och konfiguration utan hemligheter. Granska relevant fel och förfrågningsidentifierare. Återskapa problemet i en godkänd testmiljö när det går.

Ge inte breda behörigheter bara för att se om felet försvinner. Det ändrar säkerhetsgränsen och kan dölja den faktiska saknade behörigheten. Klistra inte in en fullständig produktionslogg i modellen när ett rensat felmeddelande och förfrågans väg räcker.

Ange vad som skulle försvaga varje hypotes. Det hjälper agenten ändra förklaringen i stället för att försvara sitt första svar.

Ändra en orsak i taget

Gör en fokuserad rättning när underlaget identifierar en sannolik orsak. Undvik att kombinera behörighetsändring, biblioteksuppgradering och omskrivning av hanteraren. Om symtomet försvinner vet du annars inte vilken ändring som spelade roll.

Verifiera det ursprungliga felvillkoret. Kontrollera också den närliggande gränsen. Om du rättar åtkomst för en chef ska du bekräfta att en obehörig användare fortfarande nekas.

Lägg till en regressionskontroll för återkommande fel i lagret som kan upptäcka dem. Ett enhetstest kan inte upptäcka alla driftsättningskonfigurationsfel. Vissa fel behöver en integrationskontroll eller kontrollerad verifiering efter driftsättning.

Stoppa upprepade försök utan nytt underlag

En agent kan generera många varianter av en rättning. Fler försök förbättrar inte nödvändigtvis diagnosen. Om samma fel upprepas ska du fråga vilken ny observation nästa försök ger.

Sätt en tids- eller försöksgräns för osäkra undersökningar. Rapportera sedan aktuellt underlag, förkastade hypoteser och den olösta frågan. Anteckningen låter någon annan fortsätta utan att upprepa samma experiment.

Dokumentera efter återställningen orsaken och villkoret som lät felet nå den berörda miljön. En rättning tar bort det omedelbara felet. En användbar uppföljning minskar risken att samma fel återkommer.