Debuggaa testattavilla hypoteeseilla

Kuvaa virhe ennen korjausehdotusta

Hyödyllinen debuggauspyyntö kertoo odotetun toiminnan, havaitun toiminnan ja vaikutusalueen. Lisää versio, olennainen syöte ja virhe. Poista tunnukset ja yksityiset tietueet lokeista ennen niiden antamista AI-työkalulle.

”Vienti on rikki” antaa vähän suuntaa. Täsmällisempi kuvaus on: ”Vienti toimii paikallisesti. Stagingissa sama manager-pyyntö palauttaa 403:n uusimman deploymentin jälkeen. Muut routet toimivat.”

Kuvaus ei vielä osoita syytä. Se tunnistaa erot, joiden avulla selvitystä voi suunnata.

Pidä useampi selitys mukana

Pyydä agentilta muutama mahdollinen syy ja kunkin puolesta puhuva näyttö. Älä pyydä sitä lukitsemaan ensimmäistä uskottavaa selitystä.

Kuvitteellisen vientivirheen syy voi olla palveluidentiteetiltä puuttuva käyttöoikeus, muuttunut roolikuvaus tai väärään ympäristöön lähtevä pyyntö. Kukin selitys ennustaa erilaista näyttöä.

Taulukko on lähtökohta. 403 voi tulla eri kerroksista. Selvitä vastauksen tuottanut komponentti ennen kuin oletat sovelluksen authorizationin epäonnistuneen.

Valitse turvallinen havainto

Aloita havainnosta, joka erottaa selityksiä pienellä kustannuksella. Vertaa julkaistua versiota ja ei-salaisia asetuksia. Tarkasta olennainen virhe ja request-tunniste. Toista ongelma valtuutetussa testiympäristössä, jos mahdollista.

Älä myönnä laajoja oikeuksia vain nähdäksesi, katoaako virhe. Toimi muuttaa tietoturvarajaa ja voi peittää todellisen puuttuvan oikeuden. Älä myöskään kopioi koko tuotantolokia mallille, jos rajattu virhe ja pyyntöpolku riittävät.

Kirjaa, mikä havainto heikentäisi kutakin hypoteesia. Näin agentti voi muuttaa selitystään sen sijaan, että puolustaisi ensimmäistä vastaustaan.

Muuta yhtä syytä kerrallaan

Kun näyttö tukee todennäköistä syytä, tee rajattu korjaus. Älä yhdistä käyttöoikeusmuutosta, kirjastopäivitystä ja handlerin uudelleenkirjoitusta. Jos oire katoaa, et tiedä, mikä muutos vaikutti.

Tarkista alkuperäinen virhetilanne ja viereinen raja. Kun korjaat managerin pääsyn, varmista, että luvaton käyttäjä saa edelleen kielteisen vastauksen.

Lisää toistuvalle virheelle regressiotarkistus siihen kerrokseen, jossa virhe voidaan havaita. Unit-testi ei tunnista kaikkia deployment-konfiguraation virheitä. Osa vaatii integraatiotarkistuksen tai hallitun tarkistuksen julkaisun jälkeen.

Lopeta yritykset, jotka eivät tuota uutta tietoa

Agentti voi generoida monta korjausversiota. Yritysten määrä ei välttämättä paranna diagnoosia. Jos sama virhe toistuu, kysy, minkä uuden havainnon seuraava yritys tuottaa.

Aseta epävarmalle selvitykselle aika- tai yritysraja. Sen kohdalla kirjaa nykyinen näyttö, hylätyt hypoteesit ja avoin kysymys. Toinen tekijä voi jatkaa toistamatta samoja tutkimuksia.

Palautumisen jälkeen kirjaa syy ja ehto, joka päästi virheen kyseiseen ympäristöön. Korjaus poistaa välittömän vian. Hyödyllinen jatkotoimi vähentää saman virheen palaamista.