Produzione in fiamme nello sviluppo — cosa significa, cause e piano d'azione

Cosa significa “la produzione è in fiamme” e tipi di guasti

L'espressione “la produzione è in fiamme” (tutto è caduto) descrive una situazione in cui l'ambiente di produzione funziona in modo errato e gli utenti sono colpiti. Il guasto può manifestarsi come indisponibilità totale dell'applicazione (schermo bianco, errore 502), indisponibilità parziale (il modulo di pagamento non funziona ma le altre funzioni sono disponibili) o degrado delle prestazioni (caricamento estremamente lento). La gravità dell'incidente è determinata dalla percentuale di utenti colpiti e dalla durata dell'interruzione.

Secondo Atlassian Statuspage (2025), il tempo di inattività medio per le applicazioni mobili nel 2024 è stato di 27 minuti per incidente. Le cause più comuni: regressione del codice dopo il deploy (34%), interruzione del provider cloud (22%), problemi con il database (18%), errori di configurazione (15%) e attacchi DDoS (11%). Conclusione principale: la maggior parte dei guasti è causata da modifiche introdotte dal team stesso, non da fattori esterni.

È importante distinguere tra un crash (arresto anomalo dell'applicazione sul client) e un'interruzione del backend (indisponibilità del server). Un crash viene solitamente risolto con un hotfix del codice client, mentre un'interruzione del backend richiede modifiche all'infrastruttura o un ridistribuzione del servizio. Metriche di monitoraggio: per il client — tasso senza crash, per il server — tasso di errore 5xx e latenza p95. APM (Application Performance Monitoring) — Sentry, New Relic, Datadog — aiuta a determinare rapidamente il tipo di guasto.

Gravità degli incidenti: P0, P1, P2 e criteri di classificazione

Una classificazione unificata della gravità è la base di una risposta rapida. Senza di essa, il team perde tempo a discutere “quanto è urgente” invece di agire. La scala classica: P0 (critico) — l'applicazione è completamente non disponibile o i dati degli utenti vengono divulgati, tempo di risposta — immediato; P1 (alto) — la funzionalità critica non funziona per il 50%+ degli utenti, tempo di risposta — 15 minuti; P2 (medio) — la funzionalità non critica non è disponibile per alcuni utenti, tempo di risposta — 1 ora.

P0 richiede escalation immediata: l'ingegnere di turno interrompe qualsiasi lavoro in corso e si concentra sull'incidente. Se il problema non viene risolto entro 10 minuti — viene coinvolto il tech lead. Se dopo 30 minuti — escalation al responsabile engineering. Per gli incidenti P0 è consentito infrangere qualsiasi processo: fare un hotfix senza revisione completa del codice, distribuire direttamente in produzione, ignorare le regole di protezione del branch. L'override di emergenza deve essere concordato preventivamente a livello di team.

Tabella di gravità

È estremamente importante non sottovalutare la gravità. Gli incidenti P0 e P1 classificati come P2 portano a una risposta ritardata e a un aumento del tempo di inattività. Regola: in caso di dubbio — imposta P0. Sopraclassificare è meglio che sottoclassificare: è meglio tenere una riunione extra che perdere un'ora di recupero.

Primi 10 minuti: algoritmo di azione durante un guasto

Il timer parte: dal momento in cui arriva un avviso o un messaggio da un utente. I primi 10 minuti sono i più importanti. Algoritmo: 1) confermare il problema — assicurarsi che il problema sia reale (non un falso allarme); 2) fermare l'emorragia — ridurre immediatamente l'impatto (rollback, feature toggle, blocco dell'endpoint); 3) comunicare — scrivere nel canale generale #incident lo stato: cosa è successo, gravità, cosa si sta facendo. I primi 10 minuti non vengono spesi per l'analisi della causa principale.

In parallelo con il fermare l'emorragia, un ingegnere inizia la diagnosi mentre un altro gestisce la comunicazione. Canali di comunicazione: canale Slack #incident (per il team), pagina di stato (per gli utenti), email/SMS di escalation (per la direzione). Ogni 15 minuti — un aggiornamento di stato con informazioni: cosa si sa, cosa si sta facendo, tempo di recupero stimato. Pagina di stato (StatusPage, Statuspal) mostra il tempo di attività e la cronologia degli incidenti per gli utenti esterni.

Come fermare l'emorragia: rollback, feature toggle e hotfix

La prima e più importante regola: non cercare di risolvere il problema in produzione. Se una nuova release ha causato il guasto — esegui il rollback alla versione stabile precedente. Se il guasto è causato da una funzionalità specifica che si trova dietro un feature toggle — disattiva semplicemente il toggle. Se né il rollback né il toggle sono disponibili — applica un hotfix con diff minimo. Il rollback è l'opzione più sicura perché riporta a uno stato che già funzionava.

Feature toggle (anche chiamato feature flag) è uno strumento potente per fermare l'emorragia senza un deploy. Se il modulo di pagamento si blocca ma è disabilitato tramite toggle — gli utenti semplicemente non vedono il pulsante di pagamento invece di ricevere una schermata di errore. Un toggle non richiede build, non richiede revisione dello store e diventa effettivo in secondi. Ogni funzionalità critica dovrebbe essere dietro un feature toggle con possibilità di disattivazione a livello di server (config remota). Feature flag — la prima linea di difesa.

Se il rollback è impossibile (ad esempio, a causa di una migrazione del database irreversibile) e non c'è toggle — l'ultima risorsa è un hotfix con modifiche minime. L'hotfix viene creato dall'ultimo tag di release, contiene solo le righe necessarie per correggere il guasto e passa attraverso un deploy accelerato (vedi l'articolo “Hotfix — correzioni urgenti”). Regola d'oro: dopo la stabilizzazione, esegui sempre un'analisi della causa principale, anche se la causa sembra ovvia.

Diagnosi delle cause: log, metriche e allarmi

Dopo aver fermato l'emorragia (o in parallelo, se il numero di ingegneri lo consente), inizia la diagnosi. La prima fonte sono i log. La registrazione centralizzata (ELK, Grafana Loki, Datadog Logs) consente di trovare errori per timestamp, ID utente o ID richiesta. Importante: i log devono essere strutturati (JSON) affinché grep funzioni rapidamente. La registrazione strutturata è un requisito obbligatorio per tutti i servizi.

La seconda fonte sono le metriche. Grafana, Datadog, New Relic mostrano quando si è verificato il picco di errori, su quali endpoint e con quali codici di stato. Il confronto delle metriche prima e dopo il deploy aiuta a localizzare il problema su un servizio o endpoint specifico. Metriche RED (Rate, Errors, Duration) — lo standard per il monitoraggio dei microservizi.

La terza fonte è il tracing distribuito (distributed tracing). Jaeger, Zipkin, Datadog APM mostrano il percorso della richiesta attraverso i microservizi e identificano dove esattamente si è verificato il ritardo o l'errore. Il tracing è particolarmente utile per i guasti a cascata, quando un guasto in un servizio causa errori in tutti i servizi dipendenti. Trace ID deve essere trasmesso dal client a tutti i servizi backend.

# Esempio di diagnosi rapida con kubectl e log
# Elencare pod con errori
kubectl get pods --field-selector=status.phase!=Running

# Controllare i log del pod crashato
kubectl logs --previous pod/auth-service-7f4b9c5d6-abc12

# Cercare errori nel servizio degli ultimi 30 minuti
kubectl logs deployment/api-gateway --since=30m
  | grep "5[0-9][0-9]" | head -50

Importante: non cercare di diagnosticare la causa prima di fermare l'emorragia. Se il 50% degli utenti vede un crash — prima esegui il rollback, poi indaga. Eccezione: se un rollback richiedesse più tempo di un hotfix diretto (ad esempio, a causa di incompatibilità dei dati). In questo caso, applica l'hotfix immediatamente e conduci il post-mortem dopo la stabilizzazione. Diagnosticare prima di correggere è un modello pericoloso che aumenta il tempo di inattività.

Post-mortem: come analizzare gli incidenti senza cercare colpevoli

Il post-mortem (chiamato anche revisione dell'incidente) è un'analisi strutturata dell'incidente condotta 24–72 ore dopo la sua risoluzione. Il suo scopo: capire perché il guasto si è verificato, perché il monitoraggio e i test non lo hanno rilevato prima della produzione, e cosa cambiare nei processi per prevenire la ricorrenza. La cultura senza colpa è un principio fondamentale: il post-mortem discute processi, strumenti e comunicazione, non gli errori di persone specifiche.

Struttura del documento post-mortem: cronologia (sequenza di eventi con timestamp), impatto (utenti colpiti, durata, perdite finanziarie), causa principale (causa tecnica principale), rilevamento (come è stato scoperto, perché non è stato rilevato prima), risposta (cosa è stato fatto, cosa si sarebbe potuto fare più velocemente), azioni (compiti specifici con responsabili e scadenze). Le azioni devono essere S.M.A.R.T.: specifiche, misurabili, assegnabili, realistiche e con scadenza.

Azioni tipiche dopo un guasto di produzione: aggiungere monitoraggio e allarmi per la metrica che era silenziosa; espandere la copertura dei test per il caso mancato; aggiungere una pagina al runbook con un algoritmo passo-passo per una situazione simile; condurre una formazione del team sullo strumento che è stato utilizzato in modo errato. Ogni azione è un cambiamento concreto che riduce la probabilità di ricorrenza dell'incidente.