Keressen hibát ellenőrizhető hipotézisekkel

A javítás előtt írja le a hibát

A hasznos hibakeresési kérés megadja az elvárt működést, a megfigyelt működést és az érintett területet. Tartalmazza a verziót, a releváns bemenetet és a hibát. Mielőtt AI-eszköznek adná át a logokat, távolítsa el belőlük a hitelesítő adatokat és a bizalmas rekordokat.

Az „elromlott az export” kevés támpontot ad. Jobb leírás: „Az export helyben sikeres. Staging környezetben ugyanaz a menedzseri kérés 403-as választ ad a legutóbbi telepítés óta. Más route-ok továbbra is működnek.”

Ez a leírás nem bizonyítja az okot. Olyan különbségeket azonosít, amelyek irányt adhatnak a vizsgálatnak.

Tartson fenn több lehetséges magyarázatot

Kérjen az agenttől néhány lehetséges okot és mindegyikhez bizonyítékot. Ne kérje, hogy köteleződjön el az első meggyőző magyarázat mellett.

A fiktív exporthiba lehetséges okai közé tartozik a szolgáltatásidentitás hiányzó jogosultsága, a módosult szerepkör-hozzárendelés vagy a rossz környezetbe küldött kérés. Mindegyik magyarázat más bizonyítékot jelez előre.

A táblázat kiindulópont. A 403-as válasz különböző rétegekből érkezhet. Mielőtt az alkalmazás jogosultságkezelését hibáztatná, azonosítsa, melyik komponens hozta létre.

Válasszon biztonságos megfigyelést

Kezdjen olyan megfigyeléssel, amely kis költséggel különíti el a magyarázatokat. Hasonlítsa össze a telepített verziót és a nem titkos konfigurációt. Vizsgálja meg a releváns hibát és a kérés azonosítóját. Ha lehet, reprodukálja a problémát engedélyezett tesztkörnyezetben.

Ne adjon széles jogosultságokat pusztán azért, hogy kiderüljön, eltűnik-e a hiba. Ez megváltoztatja a biztonsági határt, és elrejtheti a ténylegesen hiányzó jogosultságot. Ne másoljon teljes éles logot a modellbe, ha egy érzékeny adatoktól megtisztított hibaüzenet és a kérés útvonala elegendő.

Adja meg, mi gyengítené az egyes hipotéziseket. Így az agent könnyebben felülvizsgálja a magyarázatát, ahelyett hogy az első válaszát védené.

Egyszerre egy okot javítson

Ha a bizonyítékok valószínű okot mutatnak, végezzen célzott javítást. Ne kapcsoljon össze jogosultságmódosítást, könyvtárfrissítést és kéréskezelő-újraírást. Ha a tünet eltűnne, nem tudná, melyik változás számított.

Ellenőrizze az eredeti hibát kiváltó feltételt. A kapcsolódó határt is vizsgálja meg. Ha kijavítja a menedzser hozzáférését, győződjön meg arról, hogy a jogosulatlan felhasználó továbbra is elutasítást kap.

Visszatérő hibához adjon regressziós ellenőrzést abban a rétegben, amely képes észlelni. Egy unit test nem észlelhet minden telepítési konfigurációs hibát. Egyes hibákhoz integrációs ellenőrzés vagy szabályozott, telepítés utáni ellenőrzés szükséges.

Új bizonyíték nélkül állítsa le az ismételt próbálkozásokat

Az agent sok javításváltozatot generálhat. A több próbálkozás nem feltétlenül javítja a diagnózist. Ha ugyanaz a hiba ismétlődik, kérdezze meg, milyen új megfigyelést ad a következő próbálkozás.

A bizonytalan vizsgálathoz állítson idő- vagy próbálkozási korlátot. A korlát elérésekor foglalja össze az aktuális bizonyítékokat, az elvetett hipotéziseket és a nyitott kérdést. Így más is folytathatja a munkát ugyanazon kísérletek megismétlése nélkül.

A helyreállítás után rögzítse az okot és azt a feltételt, amely lehetővé tette, hogy a hiba eljusson az érintett környezetbe. A javítás megszünteti a közvetlen hibát. A hasznos utómunka csökkenti ugyanazon hiba visszatérésének esélyét.