Descrivi il tuo incidente di produzione più grave e i primi 30 minuti.

Question

IT Interview Practice · Accepted Answer

**Una risposta efficace mostra come hai ridotto il danno ai clienti, deciso con prove incomplete e prevenuto il ripetersi dell'incidente.** Descrivi chiaramente il tuo ruolo, senza presentare tutto il lavoro del team come tuo.

Usa un incidente realmente vissuto. Lo scenario seguente è immaginario e illustra la struttura: in un colloquio sostituiscilo con azioni reali e risultati verificati. Le finestre temporali sono illustrative, non scadenze universali di risposta.

## 1. Presenta situazione e responsabilità

Supponiamo che fossi il responsabile backend reperibile quando gli errori di checkout sono aumentati poco dopo un rilascio. I clienti potevano navigare, ma alcuni non completavano gli ordini. La vicinanza temporale rendeva il rilascio un'ipotesi, non una causa dimostrata.

Spiegherei la mia responsabilità: coordinare il recupero tecnico, assegnare le indagini e aggiornare il responsabile dell'incidente. Se guidassi anche l'incidente, lo direi esplicitamente e delegherei comunicazione o indagine operativa per non diventare un collo di bottiglia.

## 2. Primi cinque minuti: conferma l'impatto e organizza la risposta

Controlla errori di checkout, latenza e ordini riusciti per capire chi è colpito e se il problema continua. Apri un unico canale, assegna responsabilità, sospendi modifiche estranee e avvia una cronologia di osservazioni e azioni.

Il motivo è pratico: più persone che cambiano cose indipendentemente possono nascondere la causa o peggiorare l'incidente. Un aggiornamento deve distinguere fatti confermati e ipotesi, indicando quando arriverà il successivo. Vedi le [indicazioni di risposta agli incidenti](https://sre.google/workbook/incident-response/) di Google.

## 3. Dieci minuti successivi: scegli un modo sicuro di ridurre il danno

Supponiamo che l'indagine trovi connessioni al database sature e che il rilascio abbia aggiunto una reportistica costosa. Confronterei il rollback con la disattivazione temporanea di quel percorso, mantenendo disponibile il checkout.

- Verifica che il rollback sia compatibile con modifiche a schema o dati già effettuate. La versione precedente dell'applicazione non è automaticamente sicura sul database attuale.
- Se un interruttore già provato può disabilitare report facoltativi, usalo per ridurre il carico e osserva se il checkout migliora.
- Assegna a una persona l'analisi delle connessioni e a un'altra la verifica del recupero, così l'indagine prosegue senza ritardare una mitigazione ragionevole.

La decisione deve seguire prove disponibili e reversibilità. Non aspetterei certezza completa sulla causa mentre i clienti restano bloccati, ma registrerei perché l'azione scelta dovrebbe aiutare.

## 4. Entro trenta minuti: verifica il ripristino del servizio utile

Un grafico CPU in discesa non basta. Conferma che checkout reali riescano, che la latenza sia accettabile e che la coda si svuoti senza creare nuova pressione. Osserva il sistema dopo la mitigazione, anziché dichiararlo ripristinato dopo una sola richiesta riuscita.

Per pagamenti dall'esito ambiguo, riconcilia con il sistema di pagamento prima di ripetere l'addebito. Un timeout può nascondere un pagamento completato. Comunica cosa è ripristinato, cosa resta incerto e cosa devono fare i clienti, senza inventare tempi di recupero non sostenuti dalle prove.

## 5. Dopo il recupero: cambia le condizioni che hanno permesso il guasto

In questo scenario immaginario, l'indagine potrebbe mostrare che report e checkout condividevano un budget di connessioni e che i report non avevano limiti efficaci. Il seguito deve correggere quel meccanismo, non fermarsi a “prestare più attenzione”.

- Limita lavoro e concorrenza dei report affinché una funzione non consumi tutta la risorsa condivisa.
- Valuta l'isolamento delle risorse dove necessario e prova report e checkout insieme sotto carico rappresentativo.
- Genera allarmi su successo e latenza del checkout e prova le procedure di mitigazione o rollback.
- Assegna a ogni azione correttiva un responsabile, una scadenza e un metodo di verifica.

In un colloquio reale, concludi con il risultato effettivo del recupero e le prove ottenute dai test successivi o dall'operatività. Se una misura non è stata raccolta, dichiaralo invece di fornire un numero impressionante. La lezione deve collegarsi direttamente a una modifica che hai contribuito a realizzare e verificare.

1. Presenta situazione e responsabilità

2. Primi cinque minuti: conferma l'impatto e organizza la risposta

3. Dieci minuti successivi: scegli un modo sicuro di ridurre il danno

4. Entro trenta minuti: verifica il ripristino del servizio utile

5. Dopo il recupero: cambia le condizioni che hanno permesso il guasto

Domande correlate