Runbook: evidenza fallita o ambigua

Quando usarlo

Usare questo runbook quando un provider non restituisce prova terminale, un run non è univoco, la versione servita non è dimostrata o D1 non conferma la transizione.

Prerequisiti

• operazione originaria identificata;
• evidenza disponibile già sanitizzata;
• nessun retry, secondo dispatch o seconda riconciliazione avviati;
• target di rollback ancora disponibile;
• stop condition dell'Issue applicata.

Procedura

1. Classificare il risultato come non riuscito o unknown.
2. Fermare ogni nuova mutazione.
3. Conservare richiesta, commit, workflow e timestamp.
4. Leggere una sola volta le fonti autorevoli previste dall'Issue.
5. Se l'Admin proietta reconcile e l'autorizzazione lo consente, usare il runbook di riconciliazione.
6. Se il componente è provato regressivo e il rollback è autorizzato, usare il runbook specifico.
7. In assenza di prova, lasciare l'Issue Blocked e richiedere refinement.

Verifiche attese

• nessun successo dedotto da timeout o HTTP parziale;
• nessuna duplicazione di operation, attempt, workflow o deployment;
• dati sensibili e payload provider assenti dall'evidenza;
• baseline preservata o ripristinata quando dimostrabile.

Condizioni di stop

Fermarsi se le fonti sono discordanti, più run possono corrispondere, la versione non è identificabile, servirebbe stampare dati sensibili o qualsiasi ulteriore azione amplierebbe lo scope.

Rollback o recupero

Il recupero richiede il percorso già autorizzato. Un retry o un nuovo deploy necessitano un nuovo go/no-go e, quando lo scope cambia, un nuovo Issue. Non usare lo stato unknown come autorizzazione implicita.

Evidenza da conservare

• classificazione failed o unknown;
• fonti consultate;
• commit, workflow e ambiente;
• cardinalità di operation, attempt e run;
• azioni esplicitamente non eseguite;
• decisione di rollback, blocco o refinement;
• rischio residuo.