Skip to content

10 - Recovery isolato

Guida iniziale · Rilasci Access precedenti · Lavoro residuo

Il 9 novembre abbiamo verificato il recupero di un deploy fallito per un permesso mancante, su un servizio di prova senza SQL. Il helper comune ha ritentato lo stesso job dello stesso candidato approvato, senza pubblicare un'altra release. Riepilogo finale: PASSED.

Che cosa abbiamo fatto

La fixture access-recovery usa un piccolo pacchetto separato nella repo Access, con sole librerie standard. Ha pipeline recovery, runtime sa-access-recovery, identità di rilascio, ruoli e archivi dedicati; non usa database o migratore e non modifica il backend Access. Il meccanismo comune non contiene un hook speciale per provocare o aggirare il guasto.

Passaggio Riscontro concreto
Baseline Prima revisione Ready: access-recovery-mw9r8l0e. La sonda privata ha verificato 10 HTTP 200 con il corpo esatto della fixture.
Guasto limitato Rimosso solo run.services.update dal ruolo dedicato stageRecoveryBackendUpdate, con etag. Il deploy successivo è fallito con il diniego atteso; la vecchia revisione è rimasta Ready e ha risposto ad altre 10 richieste.
Ripristino Ruolo ripristinato tramite piano Terraform verificato. Riconciliati JobRun/Build falliti e diniego preciso, senza dedurre la sicurezza del retry dal solo tempo trascorso.
Retry effettivo stage_recovery.py ha ritentato l'esatto job stable/deploy. Nuovo JobRun riuscito alle 21:35:28 UTC, stesso commit, candidato, bundle, immagini, release e rollout. L'errore originale resta nella storia.
Nuova revisione access-recovery-mw9rv6ga Ready con identità e immagine attese, 100% traffico e altre 10 risposte corrette. Una seconda richiesta di retry è stata rifiutata senza nuova modifica cloud.
Cleanup Rimossi Service fixture, tre Job sonda, grant temporanei e finestra IAM iniziale. Backend Access access-backend-mw9le435 invariato. Piani finali bootstrap/stage: zero differenze.

Verifica del retry · Rifiuto della ripetizione · Riconciliazione.

Le tre fasi hanno verificato 30 risposte HTTP 200, 10 per fase. La baseline aveva inizialmente ricevuto un 403 prima di una sola ripetizione controllata: la causa non è stata accertata e quel tentativo resta registrato. Non confondiamo questa ripetizione della sonda con il successivo retry Cloud Deploy.

La sonda era nel progetto Platform con ALL_TRAFFIC. La rete dell'Execution effettiva è stata verificata anche tramite API v1 quando v2 ometteva vpcAccess, confrontando UID e generazione del Job. Non basta leggere la configurazione corrente del Job. Procedura e limiti della sonda.

Che cosa rimane e che cosa non dimostra

Le protezioni PREVENT/prevent_destroy restano attive: pipeline/target inattivi, bucket di sorgenti e artefatti, immagine nel registry e identità di catalogo rimangono per audit. I trigger automatici sono disabilitati; non c'è un Service fixture in esecuzione. Non è una promessa di costo zero né la cancellazione di tutte le risorse. Nessun nuovo Cloud SQL è stato creato.

La prova non certifica recupero di migrazioni SQL, rollback dello schema, ritorno a una versione applicativa precedente, onboarding da un'altra repository, produzione, concorrenza fra operatori o percorso Platform→Farm. Quest'ultimo è stato poi provato separatamente con Farm, come riporta la scheda 11. Lorenzo verifica le proprie azioni al normale primo uso; non serve una sessione dedicata per procedere e non la dichiariamo già eseguita.

Codice e ricevute

La PR infra #29 corregge un comportamento generale: Google omette la strategia standard vuota nella risposta API; Terraform ora dichiara la strategia esplicita soltanto se ci sono hook predeploy. I servizi senza hook usano il default, evitando un aggiornamento ripetuto a ogni piano. 24 test del modulo, compreso quello che preserva l'hook delle migrazioni, sono passati.

I collegamenti conducono ai riepiloghi condivisibili delle prove. Gli operatori conservano ricevute complete e hash nell’archivio aziendale; state, piani grezzi e credenziali non vengono pubblicati con la guida.