Depureu amb hipòtesis que es puguin comprovar

Descriviu la fallada abans de proposar una correcció

Una petició útil de depuració indica el comportament esperat, el comportament observat i l’abast afectat. Incloeu la versió, l’entrada pertinent i l’error. Elimineu les credencials i els registres privats dels logs abans de proporcionar-los a una eina d’IA.

«L’exportació no funciona» orienta poc. Una descripció millor és: «L’exportació funciona localment. A preproducció, la mateixa petició d’un responsable d’equip retorna 403 després de l’últim desplegament. Les altres rutes continuen funcionant».

Aquesta descripció no acredita la causa. Identifica diferències que poden orientar la investigació.

Manteniu diverses explicacions possibles

Demaneu a l’agent un petit conjunt de causes plausibles i les evidències de cadascuna. No li demaneu que es quedi amb la primera explicació convincent.

En la fallada fictícia d’exportació, les causes possibles inclouen un permís absent a la identitat del servei, una assignació de rols modificada o una petició enviada a l’entorn equivocat. Cada explicació prediu evidències diferents.

La taula és un punt de partida. Una resposta 403 pot originar-se en capes diferents. Identifiqueu quin component l’ha produïda abans de suposar que ha fallat l’autorització de l’aplicació.

Trieu una observació segura

Comenceu amb una observació que permeti distingir les explicacions a baix cost. Compareu la versió desplegada i la configuració no secreta. Inspeccioneu l’error rellevant i l’identificador de petició. Reproduïu el problema en un entorn de proves autoritzat quan sigui possible.

No concediu permisos amplis només per veure si l’error desapareix. Aquesta acció canvia el límit de seguretat i pot amagar el permís que realment falta. No enganxeu un log complet de producció al model quan n’hi hagi prou amb un error del qual s’hagi retirat la informació sensible i la ruta de la petició.

Indiqueu què faria menys probable cada hipòtesi. Això ajuda l’agent a revisar l’explicació en lloc de defensar la primera resposta.

Canvieu una causa cada vegada

Quan les evidències identifiquin una causa probable, feu una correcció concreta. Eviteu combinar un canvi de permisos, una actualització de biblioteca i una reescriptura del gestor. Si el símptoma desapareix, no sabríeu quin canvi ha estat rellevant.

Verifiqueu la condició original de fallada. Comproveu també el límit adjacent. Si corregiu l’accés d’un responsable d’equip, confirmeu que un usuari no autoritzat continuï rebent una denegació.

Per a un defecte recurrent, afegiu una comprovació de regressió a la capa que el pot detectar. Una prova unitària no pot detectar tots els errors de configuració del desplegament. Algunes fallades necessiten una comprovació d’integració o una verificació controlada després del desplegament.

Atureu els intents repetits sense evidències noves

Un agent pot generar moltes variants d’una correcció. Més intents no milloren necessàriament el diagnòstic. Si es repeteix la mateixa fallada, pregunteu quina observació nova aportarà l’intent següent.

Fixeu un límit de temps o d’intents per a una investigació incerta. En arribar-hi, informeu de les evidències actuals, les hipòtesis descartades i la pregunta no resolta. Aquest registre permet que una altra persona continuï sense repetir els mateixos experiments.

Després de la recuperació, registreu la causa i la condició que va permetre que el defecte arribés a l’entorn afectat. Una correcció elimina el defecte immediat. Un seguiment útil redueix la probabilitat que torni la mateixa fallada.