Debug met testbare hypothesen

Beschrijf de fout vóór de oplossing

Een bruikbaar debuggingverzoek benoemt verwacht gedrag, waargenomen gedrag en getroffen scope. Neem versie, relevante invoer en foutmelding op. Verwijder toegangsgegevens en privérecords uit logs voordat u die aan een AI-tool geeft.

‘De export is kapot’ geeft weinig richting. Beter is: ‘De export slaagt lokaal. In staging geeft hetzelfde managerverzoek na de laatste deployment 403 terug. Andere routes werken nog.’

Deze beschrijving stelt de oorzaak niet vast. Ze identificeert verschillen die het onderzoek kunnen sturen.

Houd meerdere verklaringen beschikbaar

Vraag de agent om een kleine set aannemelijke oorzaken met bewijs voor elk. Vraag niet om zich vast te leggen op de eerste overtuigende verklaring.

Bij het fictieve exportprobleem zijn mogelijke oorzaken een ontbrekend recht van de dienstidentiteit, een gewijzigde roltoewijzing of een verzoek naar de verkeerde omgeving. Elke verklaring voorspelt ander bewijs.

De tabel is een beginpunt. Een 403-antwoord kan uit verschillende lagen komen. Identificeer welk component het gaf voordat u aanneemt dat applicatieautorisatie faalde.

Kies een veilige waarneming

Begin met een waarneming die verklaringen tegen lage kosten kan onderscheiden. Vergelijk de gedeployde versie en niet-geheime configuratie. Inspecteer de relevante fout en verzoekidentifier. Reproduceer het probleem waar mogelijk in een toegestane testomgeving.

Geef niet alleen om te zien of de fout verdwijnt brede rechten. Dat verandert de beveiligingsgrens en kan het werkelijk ontbrekende recht verbergen. Plak geen volledig productielog in het model als een foutmelding zonder gevoelige gegevens en het verzoekpad volstaan.

Geef aan wat elke hypothese minder aannemelijk zou maken. Zo kan de agent de verklaring herzien in plaats van het eerste antwoord verdedigen.

Verander één oorzaak tegelijk

Maak een gerichte correctie nadat het bewijs een waarschijnlijke oorzaak aanwijst. Combineer geen rechtenwijziging, library-upgrade en herschreven handler. Als het symptoom verdwijnt, weet u anders niet welke wijziging ertoe deed.

Verifieer de oorspronkelijke foutconditie. Controleer ook de aangrenzende grens. Bevestig na correctie van managertoegang dat een onbevoegde gebruiker nog steeds wordt geweigerd.

Voeg voor een terugkerend defect een regressiecontrole toe op de laag die het kan ontdekken. Een unittest kan niet elke deploymentconfiguratiefout vinden. Sommige fouten vragen een integratiecontrole of gecontroleerde verificatie na deployment.

Stop herhaalde pogingen zonder nieuw bewijs

Een agent kan veel varianten van een correctie genereren. Meer pogingen verbeteren de diagnose niet noodzakelijk. Vraag bij herhaling van dezelfde fout welke nieuwe waarneming de volgende poging zal opleveren.

Stel een tijd- of poginglimiet voor onzeker onderzoek. Rapporteer dan het huidige bewijs, verworpen hypothesen en de onopgeloste vraag. Met die documentatie kan iemand anders doorgaan zonder dezelfde experimenten te herhalen.

Leg na herstel de oorzaak vast en de omstandigheid waardoor het defect de getroffen omgeving bereikte. Een correctie verwijdert het directe defect. Nuttige opvolging verkleint de kans op herhaling.