Il Modulo 8 ha costruito tutta la parte operativa della gestione di una data platform. Orchestration (lezione 57), pensiero asset-oriented (lezione 58), observability (lezione 59), SLO (lezione 60), data quality (lezione 61), incident response (lezione 62). Ognuna di quelle lezioni assume che ci sia un essere umano raggiungibile quando le cose vanno male. Questa lezione parla della rotazione che produce quell’essere umano, delle regole che la rendono sostenibile, e del lavoro di ingegneria che determina se essere on-call è una parte gestibile del lavoro o la cosa che fa scappare la gente.
Un on-call buono è invisibile: il pager suona di rado, la rotazione è condivisa equamente, gli hand-off sono puliti, le persone in turno dormono. Un on-call cattivo è corrosivo: il pager suona di continuo, le stesse due persone se lo portano tutto sulle spalle, gli alert vengono ignorati per principio, e prima o poi un incident vero passa inosservato perché il team è stato addestrato a non guardare.
Cos’è l’on-call
L’on-call è una rotazione in cui una persona (o un piccolo gruppo) è responsabile di rispondere agli alert dentro una finestra definita. La finestra può essere 24/7 per sistemi che hanno bisogno di copertura ininterrotta, o orario d’ufficio per sistemi in cui un guasto notturno è accettabile. Per la data engineering, gli alert riguardano fallimenti di pipeline, regressioni di data quality, burn dello SLO, incident infrastrutturali, e la lunga coda di “la piattaforma ha fatto qualcosa di insolito e serve che un umano dia un’occhiata”.
L’argomento per cui l’on-call esiste è semplice. I sistemi di dati sono troppo importanti per essere lasciati incustoditi. Una pipeline che fallisce alle 3 di notte e che nessuno aggiusta fino al mattino significa che la dashboard mattutina è sbagliata e che la riunione mattutina non è informata. Una regressione di data quality che resta non rilevata per un giorno inquina tabelle, modelli e report a valle, e il costo della pulizia cresce grosso modo in modo lineare con quanto tempo è rimasta lì. L’obiettivo dell’on-call non è prevenire i fallimenti; i fallimenti accadranno. L’obiettivo è limitare il tempo tra il fallimento e l’attenzione umana, in modo che il blast radius resti piccolo.
La forma della rotazione varia. Un team di quattro persone può ruotare settimanalmente. Un team più grande può separare i ruoli primary e secondary. Un team distribuito geograficamente può seguire il sole, in modo che nessuno venga svegliato alle 3 di notte ora locale. La rotazione giusta è quella che mantiene il carico distribuito e i tempi di risposta sani.
Igiene del pager
La disciplina più importante dell’on-call si può dire in una frase: ogni alert che suona deve essere actionable.
Actionable significa che c’è qualcosa che la persona on-call può fare adesso per risolvere o mitigare il problema. Riavviare un job, scalare un cluster, fare failover su una replica, fare page a un owner downstream, marcare una tabella come stale, lanciare un backfill. Qualcosa di concreto. Se un alert suona e l’unica risposta possibile dell’on-call è “preso atto”, l’alert non è actionable, e non dovrebbe svegliare un umano alle 3 di notte.
Sembra ovvio ed è violato dappertutto. Due antipattern comuni:
Alert informativi. Qualcuno ha cablato una metrica, ha messo una soglia, e l’ha puntata sul pager perché era il posto più facile dove mandare le notifiche. La metrica è interessante; non è actionable. Esempi: “la profondità della coda è andata oltre 10.000”, “questo job ha impiegato 20 minuti più del solito”, “l’utilizzo del disco ha superato il 60 percento”. Nessuno richiede un’azione immediata. Vivono in una dashboard, in un digest giornaliero, o in un canale Slack che nessuno è obbligato a leggere di notte. Il pager è una risorsa scarsa.
Alert rumorosi. Un alert suona spesso, è quasi sempre un falso positivo, e viene routinariamente acknowledged-and-ignored. Il team si è addestrato a trattarlo come rumore di fondo. Prima o poi l’alert suona per un motivo vero, e l’on-call lo ignora allo stesso modo. L’alert di cui nessuno si fida è peggio di nessun alert, perché l’assenza di un alert è almeno un segnale onesto.
La cura è trattare ogni alert falso-positivo come un bug, con tre risoluzioni possibili: tarare la soglia, sistemare la flakiness sottostante, o cancellare l’alert. Non c’è una quarta opzione. Lasciare che l’alert continui a suonare e continui a essere ignorato è una corruzione lenta della disciplina di risposta del team.
Un’euristica pratica: se un alert ha suonato più di due volte senza produrre un’azione, ha bisogno di lavoro. Rendi la manutenzione degli alert una parte esplicita del lavoro dell’on-call, non un’attività volontaria fuori orario.
Escalation
La persona on-call non può sistemare tutto da sola. L’escalation è il percorso documentato che porta da “la primary on-call ha bisogno di aiuto” a “la persona giusta è coinvolta”. Una struttura tipica:
Primary on-call. Primo a rispondere. Fa acknowledge di ogni alert, fa triage, sistema quello che può, fa escalation di quello che non può.
Secondary on-call. Backup. Coinvolta quando la primary è irraggiungibile, sopraffatta, o ha bisogno di un secondo paio d’occhi.
Manager. Coinvolto quando l’incident ha un impatto di business che richiede una decisione che l’on-call non può prendere da solo: comunicazione al cliente, escalation al vendor, autorizzazione a fare azioni che impattano produzione.
Subject-matter expert. Una persona specifica che conosce un sistema specifico: chi ha costruito l’ingestion del warehouse, chi mantiene le pipeline CDC. Non è in rotazione, ma è raggiungibile per gli incident che colpiscono la sua area.
Il percorso di escalation va documentato e testato. Documentato significa che un runbook elenca chi chiamare e come raggiungerli, con il tempo di risposta atteso a ogni livello. Testato significa che il team fa fire drill, una cadenza trimestrale è ragionevole. Il drill fa emergere i numeri di telefono ormai obsoleti, gli on-call schedule mal configurati, e gli SME che sono in congedo parentale da tre mesi senza che nessuno abbia aggiornato la rota. Meglio scoprirlo in un drill che alle 4 del mattino durante un incident vero.
Hand-off
Una rotazione che non fa hand-off in modo pulito nasconde gli incident. La persona on-call uscente ha accumulato contesto durante il turno: l’alert che lampeggia, il ticket aperto che nessuno ha chiuso, l’investigation a metà, la modifica al runbook che aspetta review. Se quel contesto non viene trasferito, la persona entrante parte da zero.
L’hand-off è una nota scritta, una breve riunione, o entrambe. La nota scritta è più affidabile perché sopravvive alla riunione ed è ricercabile dopo. Una nota ragionevole copre:
- Incident recenti durante il turno, con lo stato corrente.
- Issue aperte che potrebbero suonare stanotte, con il motivo per cui sono aperte e la mitigation.
- Alert noti come flaky, con il workaround che la persona uscente ha usato.
- Qualunque cosa schedulata per il prossimo turno: deploy pianificati, migrazioni in corso, finestre di manutenzione.
La nota vive in un posto condiviso: una pagina wiki, un documento condiviso, un canale che il team legge. Non in note private o in un DM.
Compensazione
L’on-call è lavoro vero, e la rotazione interrompe tempo personale e sonno. Far finta di no è il modo in cui i team producono burnout.
La compensazione prende diverse forme: cash extra per ogni turno on-call pagato che il pager suoni o no, comp time dopo un turno duro, o entrambi. La struttura varia per area geografica e datore di lavoro, e i vincoli di diritto del lavoro sono diversi tra giurisdizioni: in alcuni paesi l’on-call è trattato di default come tempo di lavoro retribuito. La pratica minima accettabile è che l’on-call sia riconosciuto come lavoro e compensato in qualche forma.
Il punto non è solo la giustizia. La compensazione è un meccanismo di feedback. Se l’on-call è pagato, ogni turno con page ha un costo che l’organizzazione può vedere, e il caso per sistemare gli alert rumorosi ha un numero attaccato sopra. L’on-call gratuito non ha questo feedback, che è una delle ragioni per cui le rotazioni on-call gratuite restano rumorose.
Segnali di burnout
Una rotazione sostenibile produce pochi segnali di sofferenza. Una insostenibile ne produce parecchi, e un manager che presta attenzione può individuarli presto.
Troppi alert per turno. Un turno che fa page all’on-call dieci volte a notte è un’emergenza. L’on-call di un team data sano dovrebbe essere paginato al massimo una manciata di volte a settimana, non a notte, e molti turni dovrebbero passare senza pagine notturne.
Alert durante il tempo in famiglia. Un pager che suona puntualmente durante cena, weekend, o festività sta tassando la vita dell’on-call oltre quello per cui la rotazione è ingaggiata.
Carico sproporzionato. Una persona che si porta il doppio degli incident rispetto agli altri di solito significa che il sistema ha un single point of human failure: un sottosistema che capisce solo una persona. La cura è documentazione e trasferimento graduale di expertise, non punire la persona che attualmente porta il carico.
Riluttanza a prendere la rotazione. Persone che si offrono volontarie per le ferie nelle loro settimane di on-call. Persone che chiedono ripetutamente di scambiare. Persone che citano l’on-call nei colloqui di uscita. Quando questi segnali sono visibili, la situazione è già seria.
Il lavoro del manager è individuare questi segnali e agire. L’azione raramente riguarda la rotazione in sé. Riguarda il sistema che la guida: quali alert suonano, perché, e quali investimenti renderebbero la piattaforma più facile da operare. La qualità dell’on-call è un sintomo a valle della qualità della piattaforma. Curare solo il sintomo non funziona.
Il caso per avere meno alert
Se l’on-call viene paginato due volte a notte, la piattaforma è stata progettata male. L’affermazione è scomoda ed è vera. I sistemi sani fanno page all’on-call di rado. Le pagine rare sono per incident veri.
Il percorso da molti alert a pochi è il passaggio da alerting basato su soglie ad alerting basato su SLO (lezione 60). L’alerting basato su soglia suona ogni volta che una metrica supera un valore, indipendentemente dal fatto che il superamento conti. CPU all’80 percento, profondità di coda a 1.000, runtime di un job a 30 minuti: ognuno è un numero, nessuno è di per sé un problema. L’alerting basato su SLO suona quando lo SLO è a rischio: quando il tasso di burn dell’error budget su una finestra significativa suggerisce che la promessa fatta al cliente sta per rompersi. I segnali sono accoppiati a quello che il team si è impegnato a consegnare, non alla meccanica interna di come lo consegna.
Lo shift richiede investimento. Il team deve scegliere SLO che catturano quello che conta. Le metriche devono essere affidabili e a basso rumore. Le regole di alerting devono suonare sul burn vero del budget, non su superamenti cosmetici di soglia. La maggior parte dei team ci arriva gradualmente, ritirando alert rumorosi a soglia man mano che li sostituiscono con alert basati su SLO migliori.
La ricompensa è un pager più silenzioso, più onesto. Un pager che suona per il burn dello SLO suona quando qualcosa a cui il team tiene è a rischio. La fiducia tra team e pager è ricostruita.
Il ciclo di vita dell’alert
Il flusso meccanico da una metrica fuori limite a un incident chiuso vale la pena di vederlo come una sola immagine.
flowchart LR
M[Monitoring<br/>metrics, logs, checks]
AM[Alert manager<br/>routing, dedup, suppression]
P[Primary on-call<br/>pager]
A{Acknowledge}
T{Triage}
R[Resolve]
E[Escalate<br/>secondary, manager, SME]
PIR[Post-incident review<br/>lesson 62]
M --> AM
AM --> P
P --> A
A --> T
T --> R
T --> E
E --> R
R --> PIRDiagramma da creare: un flowchart curato del ciclo di vita dell’alert. Il monitoring all’estrema sinistra alimenta l’alert manager, che instrada al pager dell’on-call primary. L’on-call fa acknowledge, fa triage, e risolve direttamente o fa escalation a secondary, manager, o subject-matter expert. La risoluzione alimenta il processo di post-incident review della lezione 62. Il punto visivo è che ogni alert ha un loop chiuso: finisce o in risoluzione o in handoff a qualcuno che può risolverlo.
L’alert manager tra monitoring e pager fa lavoro vero: deduplica, sopprime alert durante manutenzioni note, instrada categorie a persone diverse. Un team senza un alert manager prima o poi annega nei duplicati. Il passo di acknowledge è il modo in cui il team sa che l’alert è stato visto, e il modo in cui il sistema smette di rifare page finché la situazione non è gestita.
Il legame con tutto il resto del Modulo 8
Ogni altra lezione di questo modulo paga un debito all’on-call. Orchestration (lezione 57) determina quali job fanno page quando falliscono. Il pensiero asset-oriented (lezione 58) determina se l’on-call vede un singolo asset fallito o una cascata di job confusi. Observability (lezione 59) determina se l’on-call trova la root cause in cinque minuti o in cinquanta. Gli SLO (lezione 60) determinano se il pager suona per cose che contano. Data quality (lezione 61) determina se l’on-call sta debuggando fallimenti veri o inseguendo falsi positivi. Incident response (lezione 62) determina se ogni incident produce apprendimento, o se gli stessi incident si ripetono.
Quando tutto questo funziona, l’on-call è una parte gestibile dello stare nel team. Quando una sola di queste cose manca, l’on-call è il primo posto in cui la mancanza si manifesta.
Il Modulo 8 finisce qui
Questa è l’ultima lezione del Modulo 8. La prossima lezione è il case study del modulo: come Airbnb gestisce la propria data platform. Il Modulo 9 si apre poi con la cost optimization, la sorella naturale dell’affidabilità operativa e la prossima leva grossa che un team data maturo deve tirare.
Riferimenti e approfondimenti
- Google SRE Book, capitolo “Being On-Call”,
https://sre.google/sre-book/being-on-call/(consultato 2026-05-01). La descrizione scritta canonica della pratica sana di on-call, dal team che si può sostenere abbia inventato la forma moderna di tutto questo. - Google SRE Workbook, capitolo “On-Call”,
https://sre.google/workbook/on-call/(consultato 2026-05-01). Il compagno pratico del libro SRE, con consigli concreti su rotazioni, hand-off, e burnout. - PagerDuty, “Incident Response Documentation”,
https://response.pagerduty.com/(consultato 2026-05-01). La guida open-source di PagerDuty alla incident response, inclusi pattern di rotazione on-call e playbook di escalation. - Atlassian, “On-call best practices”,
https://www.atlassian.com/incident-management/on-call(consultato 2026-05-01). Indicazioni pratiche da un vendor il cui tooling sta sopra esattamente a questo problema.