La lezione 60 ha fissato i target. La lezione 61 ha fissato i check che producono le misurazioni. Questa lezione parla di cosa succede quando i check falliscono. Il burn rate dello SLO sta salendo. L’alert di freshness è acceso da novanta minuti. Il test di riconciliazione è fallito con una varianza a quattro cifre rispetto al sistema sorgente. Il pager dell’ingegnere on-call è appena suonato. E adesso?
L’incident response è il terzo pilastro della pratica di affidabilità, accanto agli SLO e al testing della qualità. È la disciplina che trasforma gli alert in recovery e il recovery in miglioramento sistemico. Fatta bene, riduce il blast radius dei fallimenti e cattura l’apprendimento organizzativo. Fatta male, produce cultura dell’eroismo, colpe, postmortem che nessuno legge, e l’attrito lento degli ingegneri on-call.
Il framework SRE di Google fornisce la struttura canonica (https://sre.google/sre-book/managing-incidents/, consultato 2026-05-01), ma il framework da solo non basta. Sono le discipline culturali e operative che gli stanno intorno a determinare se un team ha una vera incident response o solo carta da archivio.
Cosa conta come incidente
Un incidente è qualunque cosa rompa (o minacci di rompere) uno SLO di tier 1. Non ogni bug è un incidente. Non ogni alert è un incidente. Il segnale è “l’impegno di affidabilità concordato è a rischio se non agiamo presto”.
La soglia conta perché gli incidenti hanno overhead. L’on-call viene chiamato. Altri ingegneri possono essere coinvolti. Viene registrata una timeline, scritto un postmortem, tracciati gli action item. Quell’overhead è giustificato per eventi che contano e corrosivo quando applicato a eventi che non contano.
Due euristiche pratiche. Se il burn rate dello SLO nella prossima ora consumerà più dell’1% del budget mensile, dichiara. Se il fallimento è visibile a clienti esterni, dichiara. Un job non critico che ha avuto retry con successo, un check di tier warning, una rottura di un ambiente di dev: operazioni, non incidenti.
Il ciclo di vita
Google SRE descrive l’incident response come un ciclo di vita a cinque stadi. Ogni stadio ha uno scopo, e saltarne uno è un failure mode comune.
Detection. Scatta un alert. La sorgente potrebbe essere un alert di burn rate dello SLO, un fallimento di test di data quality, una probe sintetica, o un ticket cliente. Il meccanismo di rilevamento conta perché il tempo tra il fallimento reale e l’alert è tempo di risposta non recuperabile. Un team che apprende degli incidenti dai ticket dei clienti ha un problema di monitoraggio prima che un problema di incident response.
Triage. L’on-call accetta il page. Il primo lavoro non è aggiustare; è decidere. È reale o un falso allarme? Qual è lo scope? Chi va coinvolto? Se il runbook lo copre, l’on-call procede. Altrimenti inizia l’escalation.
Mitigation. Ferma l’emorragia. Ripristina lo SLO. La mitigation raramente è la fix vera; è l’azione che riporta il sistema nella banda verde più velocemente. Roll back del deploy. Disabilita il feature flag. Reindirizza il traffico in una region sana. Promuovi una replica. Riavvia il job che fallisce con carico ridotto. La mitigation prioritizza il ripristino del servizio sopra la comprensione della causa.
Resolution. Aggiusta la root cause in modo che la mitigation possa essere rimossa. Il bug di schema drift viene mergiato. Il problema di capacity ottiene un aumento permanente. La resolution può richiedere ore, giorni o settimane. Alcune root cause sono difficili (il sistema upstream è di un altro team; il bug è in una libreria di terze parti), e la mitigation può restare a tempo indefinito. Accettabile, finché il gap è tracciato.
Postmortem. Scrivi cosa è successo, perché, e quali cambiamenti prevengono la ricorrenza. Il postmortem trasforma un singolo incidente in apprendimento organizzativo. Senza, ogni incidente è locale.
Il ciclo di vita è sequenziale nello spirito ma sovrapposto in pratica. La mitigation spesso parte prima che il triage sia completo. L’investigazione del postmortem spesso gira in parallelo con la resolution. È una checklist, non un ordine stretto.
Il formato del runbook
Un runbook è il documento che l’on-call consulta quando l’alert scatta. Ha un solo lavoro: portare un ingegnere assonnato alle 3 di notte da “il pager è appena suonato” a “ho applicato una mitigation e lo SLO si sta riprendendo” il più velocemente possibile. Il formato conta. Un runbook che è un muro di prosa è inutile sotto pressione; un runbook che è una checklist con comandi copia-incollabili è oro.
Il formato che funziona ha cinque sezioni.
Symptom. Che aspetto ha l’alert? Quali pannelli della dashboard sono rossi? Quali pattern di log indicano questo specifico fallimento? Esempi concreti, non astrazioni. “Lo SLO customer_etl_freshness è al 95% con il burn rate di 1 ora sopra 14x” è utile. “La pipeline è lenta” no. Una buona sezione symptom permette all’on-call di confermare in trenta secondi che è sul runbook giusto.
Likely causes. Una lista ordinata delle cause storiche di questo alert, con frequenza. “1. Lag di Kafka upstream (circa 60% degli incidenti). 2. Regressione di un modello dbt da un merge recente (circa 25%). 3. Contention sul warehouse Snowflake (circa 10%). 4. Sconosciuta (circa 5%).” L’ordinamento aiuta l’on-call a investigare prima le cause ad alta probabilità invece di scorrere le possibilità in ordine alfabetico.
Mitigation steps. Per ogni causa probabile, l’azione che mitiga. Comandi copia-incollabili. Punti decisionali dove serve giudizio, con i criteri esplicitati. “Se il consumer lag di Kafka supera 1 milione di messaggi, scala il consumer group: kubectl scale deploy customer-etl-consumer --replicas=8. Verifica che il lag inizi a scendere entro 5 minuti.” Un mitigation step che richiede di tradurre la prosa in un comando alle 3 di notte è già fallito.
Escalation paths. Chi chiamare se il runbook non risolve l’incidente, in che ordine, con quale contesto. “Se lo scaling del consumer non recupera entro 15 minuti, chiama il team lead della data platform. Se il warehouse è la causa sospetta, chiama l’on-call del warehouse.” Gli escalation path mancano spesso dai runbook, e il risultato sono ingegneri on-call che lottano da soli oltre il punto in cui l’aiuto sarebbe arrivato più velocemente.
Last reviewed. Una data e un owner. I runbook stantii sono peggio di nessun runbook perché convincono l’on-call a seguire consigli che non si applicano più. La disciplina che tiene fresch i runbook è rivederli dopo ogni incidente che li ha toccati, e su uno schedule trimestrale anche se nessun incidente li ha toccati. Un runbook revisionato l’ultima volta diciotto mesi fa si presume sbagliato finché non verificato.
Il runbook vive accanto al codice, nello stesso repository in cui il servizio è definito. Gli ingegneri operativi che leggono il runbook dovrebbero poter leggere il codice. Gli sviluppatori che scrivono il codice dovrebbero aggiornare il runbook nella stessa PR. Quando i runbook vivono in una wiki separata, vanno in drift; quando vivono accanto al codice, il drift è visibile in code review.
Il postmortem blameless
Il postmortem è dove vive la parte culturale dell’incident response, ed è dove la maggior parte delle organizzazioni sbaglia. Il principio è semplice da enunciare e difficile da vivere: la root cause di un incidente non è mai una persona.
È sempre tentante identificare l’umano nella catena. L’ingegnere che ha scritto il bug. Il reviewer che ha approvato la PR. L’on-call che ha impiegato novanta minuti a mitigare. Il product manager che ha insistito per il deploy prima del weekend di festa. Indicare una di queste persone come “la causa” è il sentiero della minor resistenza, ed è il sentiero che distrugge la cultura di affidabilità, perché la prossima persona a fare un errore lo nasconderà invece di riportarlo, e gli errori nascosti diventano incidenti più grandi.
Il postmortem blameless riformula la domanda. La root cause non è “l’ingegnere ha pushato del codice cattivo”. La root cause è “il sistema ha permesso al codice cattivo di arrivare in produzione senza essere intercettato”. Quella riformulazione produce action item utili: test migliori, CI più veloce, deploy in canary, miglior tooling di code review, PR più piccole. Indicare l’ingegnere non produce action item utili; produce un team più silenzioso e incidenti peggiori.
Il formato che funziona per i postmortem ha sei sezioni.
Summary. Due o tre frasi che un dirigente potrebbe leggere. Cosa è successo, quando, qual è stato l’impatto sull’utente. Il summary è la parte che la maggior parte delle persone legge; il resto esiste per gli ingegneri e gli analyst che hanno bisogno dei dettagli.
Timeline. Log minuto per minuto o ora per ora di cosa è successo, con timestamp e le persone o i sistemi coinvolti. La timeline è costruita da log di chat, timestamp di alert, record di deploy, e memoria umana; è la parte più labour-intensive del postmortem e la più preziosa, perché forza l’analisi a essere specifica invece che vaga.
Root cause analysis. Quali condizioni sottostanti hanno permesso l’incidente? La tecnica dei “five whys” funziona qui, ma la disciplina è continuare a chiedere perché finché la risposta è una proprietà del sistema invece che di una persona. Perché il bug è arrivato in produzione? Ha passato la code review. Perché la review l’ha mancato? La diff era di 2000 righe. Perché la diff era di 2000 righe? Il team non ha una norma sulla dimensione delle PR. L’action item è la norma sulla dimensione delle PR, non “stare più attenti in review”.
Impact. Chi è stato colpito, per quanto tempo, con quali conseguenze di business? Quantificato dove possibile: la dashboard è stata sbagliata per tre ore, impattando il decision-making in due team regionali; lo SLO ha consumato il 40% dell’error budget mensile. L’inquadramento dell’impatto aiuta a prioritizzare gli action item: un incidente ad alto impatto giustifica una prevenzione più costosa di uno a basso impatto.
Action items. Specifici, con owner, time-bound. “Miglioreremo i nostri processi” non è un action item. “Aggiungere un alert di drift del conteggio righe con soglia al 10% alla pipeline customer_etl entro il 2026-04-15, owner Maria” è un action item. Le azioni che escono dai postmortem sono il vero prodotto della pratica di incident response; senza, il postmortem è un esercizio di scrittura.
Lessons learned. Cosa sa il team adesso che non sapeva prima dell’incidente? A volte la lezione è operativa (“la rotazione on-call deve includere qualcuno con esperienza sul warehouse”). A volte architetturale (“l’accoppiamento tra questi due servizi è più stretto di quanto assumessimo”). A volte culturale (“dobbiamo essere disposti a dichiarare incidenti prima”). Le lessons learned sono il filo che connette questo postmortem ai futuri.
La cultura blameless non si può dichiarare. Va modellata, soprattutto dalla leadership. La prima volta che il nome di un senior engineer compare in una timeline (e i senior engineer causano incidenti alla stessa frequenza dei junior, perché i sistemi sottostanti sono ugualmente fallibili dalla tastiera di chiunque), il team guarda cosa succede. Se il nome è trattato come dato, uguale a quello di chiunque altro, la cultura tiene. Se il senior engineer è omesso o scusato, la cultura è performativa e tutti lo sanno.
Anche la disciplina di pubblicazione conta. I postmortem si leggono trasversalmente all’organizzazione. Altri team imparano dall’analisi. I nuovi ingegneri leggono i postmortem passati durante l’onboarding per capire come fallisce il sistema. I postmortem privati catturano apprendimento locale; quelli pubblicati catturano apprendimento collettivo.
Discipline dell’on-call
L’incident response sta sopra una rotazione on-call, e la rotazione ha le sue discipline che determinano se gli ingegneri restano in salute.
Pager hygiene. Ogni alert che scatta deve essere actionable. Gli alert senza azione (“la coda a volte è profonda, non si sa cosa fare”) addestrano l’on-call a ignorare il pager, e il prossimo incidente reale è ritardato perché l’on-call ha imparato a non fidarsi degli alert. Rivedi ogni page a posteriori: era actionable? Se no, tara l’alert o cancellalo.
Hand-off. L’on-call uscente fa il briefing all’on-call entrante: issue aperte, incidenti recenti, investigazioni in corso, modifiche ai runbook. Quindici minuti. Senza, l’on-call entrante arriva freddo e il primo incidente richiede più tempo perché stanno ancora caricando il contesto.
Compensation. L’on-call è lavoro vero, incluso il lavoro di essere disponibili fuori dall’orario di ufficio. I team che fingono che l’on-call sia un’aggiunta gratuita guardano i loro ingegneri on-call andarsene o bruciarsi. La compensazione può essere tempo libero, paga aggiuntiva, o entrambe, ma deve essere esplicita.
Lunghezza e frequenza della rotazione. Una settimana è la rotazione comune, due settimane il massimo prima che si inneschi la fatica. La rotazione dovrebbe essere abbastanza corta da far sì che un ingegnere sia on-call una volta ogni quattro o sei settimane. I team più piccoli devono compromettere o sulla lunghezza della rotazione o sulla dimensione del team (assumendo o ampliando la pool).
Il ciclo di vita in un diagramma
flowchart TD
A[Alert fires] --> B[Detection]
B --> C[Triage: real or false?]
C -->|False| D[Tune alert, log]
C -->|Real| E[Mitigation: stop the bleeding]
E --> F[SLO recovering?]
F -->|No| G[Escalate]
G --> E
F -->|Yes| H[Resolution: fix root cause]
H --> I[Postmortem]
I --> J[Action items tracked]
J --> K[Runbook and tests updated]
K --> L[Next time: faster response or no incident]La freccia da K di nuovo a detection (omessa per chiarezza) è il loop che rende l’incident response un sistema di apprendimento. Ogni incidente produce aggiornamenti: alert migliori, runbook migliori, test migliori, architettura migliore. Il prossimo fallimento simile o non accade, o accade con risposta più veloce. Gli incidenti non si fermano, ma il costo per incidente decresce.
Le tre lezioni di questo modulo formano un loop completo. Gli SLO definiscono cosa significa affidabile. Il testing di qualità lo misura in continuo. L’incident response gestisce i momenti in cui la misurazione dice che lo SLO è a rischio. Il modulo 8 prosegue con l’infrastruttura di monitoraggio e le discipline di security e privacy che si sovrappongono con l’affidabilità. Un team con SLO, test di qualità, e una vera pratica di incident response ha l’apparato di base di una data platform di produzione; tutto il resto è stratificazione.