Di Andrew Tan
Il paradosso del postmortem
Ogni grande azienda tecnologica li pubblica ora. Stripe ha una pagina di stato piena di essi. Netflix scrive analisi ingegneristiche dettagliate. Uber, LinkedIn, GitHub, Cloudflare — tutti hanno aperto il sipario su cosa è andato storto e perché.
Ecco il paradosso: gli stessi fallimenti continuano a verificarsi. Non le stesse aziende, non gli stessi sistemi, ma gli stessi schemi. Un team di DoorDash perde dati di pagamento nello stesso modo in cui un team di Netflix ha perso metriche di visualizzazione tre anni prima. Una pipeline di Uber si rompe a causa di uno schema drift nel 2024 nello stesso modo in cui una pipeline di LinkedIn si è rotta nel 2021.
Ho passato le ultime settimane a leggere 50 postmortem pubblici e rapporti sugli incidenti di aziende che hanno elaborato collettivamente trilioni di eventi. L'obiettivo non era catalogare ogni possibile modalità di fallimento. Era trovare i cluster — le cause principali che si presentano abbastanza spesso da non poter essere liquidate come sfortuna isolata.
Quattro schemi dominano. E ciò che mi ha sorpreso è che la maggior parte di essi è prevenibile nella fase di progettazione, non nella fase operativa.
Come sono stati selezionati i 50
Prima di immergerci negli schemi, una breve nota sulla metodologia. Mi sono concentrato sui postmortem pubblici di aziende che gestiscono infrastrutture dati su larga scala: Uber, Netflix, Stripe, LinkedIn, GitHub, Cloudflare, DoorDash, Airbnb, Spotify e AWS. Ho saltato le violazioni della sicurezza e le interruzioni pure dell'infrastruttura (come i fallimenti DNS) a meno che non abbiano influito direttamente sulle data pipeline.
La selezione non è stata casuale. Ho dato priorità ai postmortem che includevano:
- Analisi delle cause principali con profondità tecnica
- Cronologia del fallimento e del recupero
- Menzione esplicita della qualità dei dati o dell'impatto sulla pipeline
- Lezioni apprese o cambiamenti di processo
Alcune aziende pubblicano frequentemente (Cloudflare, GitHub). Altre raramente (Netflix). I 50 rappresentano una sezione trasversale di architetture batch ETL, streaming e ibride.
Schema 1: Schema drift (38% degli incidenti)
La causa principale più comune era ingannevolmente semplice: il sistema a monte ha cambiato il suo formato dati e la pipeline non lo sapeva.
In un incidente ben documentato, un team di dati ha scoperto che un magazzino a valle aveva caricato record corrotti per undici giorni. L'API di origine aveva aggiunto un nuovo campo. Il parser JSON della pipeline lo ha trattato come una chiave inaspettata e ha silenziosamente eliminato l'intero batch di record. Nessun allarme è scattato perché la pipeline non è andata in crash — ha semplicemente prodotto meno righe del previsto, e la differenza era entro la normale varianza fino a quando non lo era più.
Questo non è un caso limite. È il comportamento predefinito di molti strumenti di integrazione dati.
I postmortem rivelano tre varianti di questo schema:
Additive drift
Appare un nuovo campo, colonna o tipo di evento. La pipeline lo ignora o fallisce a seconda di quanto sia rigorosa la sua validazione dello schema. La maggior parte dei postmortem ha notato che le loro pipeline erano configurate per essere "permissive" perché la validazione rigorosa aveva causato falsi allarmi in passato.
Type drift
Un campo esistente cambia il suo tipo. Una stringa diventa un numero. Un timestamp perde il suo fuso orario. Questi sono i più difficili da rilevare perché i dati sembrano ancora validi. Un postmortem ha descritto una metrica di ricavi che è raddoppiata silenziosamente perché un campo di codice valuta è passato dal formato ISO a un enum numerico, e la pipeline ha interpretato il valore enum come un moltiplicatore.
Semantic drift
Il formato rimane lo stesso, ma il significato cambia. Un campo "user_id" inizia a contenere ID dispositivo invece di ID account. Un campo "status" acquisisce un nuovo stato che la logica a valle tratta come un errore. I dati superano tutti i controlli di validazione e sono comunque errati.
Ciò che colpisce è quanto raramente questi incidenti siano stati rilevati dai registri di schema o dai contratti di dati. Nella maggior parte dei casi, i team avevano un registro. Non era semplicemente applicato al confine della pipeline. Lo schema era documentato da qualche parte, ma la pipeline non era tenuta a convalidarlo.
Schema 2: Backpressure e picchi di carico (24% degli incidenti)
Il secondo cluster riguarda pipeline che funzionano perfettamente a carico normale e crollano sotto volume inaspettato. Il trigger varia — una campagna di marketing, un evento virale, un ciclo di reportistica trimestrale, un lavoro a monte configurato male che improvvisamente emette 10 volte il suo tasso usuale.
La modalità di fallimento è quasi sempre la stessa: la pipeline non può scaricare il carico, quindi lo perde.
Un postmortem da una piattaforma di streaming ha descritto un consumatore Kafka che è rimasto indietro di sei ore durante un lancio di prodotto. Il gruppo di consumatori si è auto-scalato, ma le nuove istanze hanno colpito un limite di pool di connessioni al database che non era mai stato testato a quella scala. La pipeline non è andata in crash. Ha semplicemente smesso di elaborare nuovi eventi mentre quelli vecchi invecchiavano fuori dalla retention. Quando il team se ne è accorto, i dati erano spariti.
Un altro ha descritto un lavoro batch ETL che ha funzionato bene per due anni fino al Black Friday, quando il sistema di origine ha emesso file 40 volte più grandi del solito. Il lavoro è durato 18 ore, ha esaurito lo spazio di archiviazione temporanea ed è fallito senza pulire i suoi output parziali. Il successivo esecuzione programmata è iniziata sopra i dati corrotti.
Il filo comune: queste pipeline erano progettate per operazioni in stato stazionario, non per condizioni limite. Avevano monitoraggio per se stavano funzionando, ma non per quanto vicine ai loro limiti stavano operando.
Diversi postmortem hanno notato che il test di carico era stato de-prioritizzato perché "ci auto-scaleremo". L'auto-scaling funziona per il calcolo. Non funziona per i pool di connessioni, i limiti di memoria, l'I/O del disco o i limiti di velocità delle API a valle — i colli di bottiglia che effettivamente rompono le pipeline.
Schema 3: Perdita di dati silenziosa (19% degli incidenti)
Questo è lo schema che tiene svegli gli ingegneri di notte. La pipeline riporta successo. Le dashboard mostrano verde. L'SLA è rispettato. Ma i dati sono incompleti, duplicati o corrotti — e nessuno lo sa finché un utente aziendale non chiede perché i numeri sembrano sbagliati.
La perdita silenziosa si manifesta in diverse forme nei postmortem:
Il filtro che era troppo aggressivo
Una regola di qualità dei dati ha eliminato record che corrispondevano a un modello malformato. La regola era intesa a catturare dati a monte corrotti, ma ha anche catturato record legittimi con valori insoliti ma validi. In tre settimane, il 12% delle transazioni legittime è stato filtrato.
L'esattamente-una-volta che non lo era
Una pipeline affermava di avere semantiche esattamente-una-volta ma utilizzava un sink non idempotente. Quando un errore di rete transitorio ha attivato un retry, alcuni record sono stati scritti due volte. La logica di deduplicazione esisteva in teoria ma non nel percorso effettivo del codice.
Il gap di retention
Una pipeline di streaming scriveva a una coda di messaggi con una finestra di retention di 24 ore. Quando l'elaborazione a valle è rimasta indietro a causa di un incidente separato, i dati non elaborati sono scaduti prima del recupero. I log della pipeline mostravano scritture riuscite. I dati semplicemente non c'erano quando qualcuno ha provato a leggerli.
Ciò che rende la perdita silenziosa così pericolosa è che è invisibile al monitoraggio tradizionale. Le metriche di salute della pipeline — tempo di esecuzione, throughput, tasso di errore — non la rilevano. Hai bisogno di metriche di qualità dei dati: conteggi delle righe, controlli di cardinalità, integrità referenziale, test di distribuzione. La maggior parte dei postmortem ha ammesso che questi controlli sono stati aggiunti dopo l'incidente, non prima.
Schema 4: Fallimenti a cascata da stato condiviso (14% degli incidenti)
Il cluster più piccolo ma spesso il più catastrofico. Questi sono incidenti in cui un fallimento in una pipeline corrompe o disabilita altre tramite infrastruttura condivisa.
Un postmortem memorabile ha descritto un evento "pillola avvelenata" — un singolo record malformato che ha causato un parser a entrare in un ciclo infinito. Il thread del consumatore si è bloccato, la partizione è stata ribilanciata e il nuovo thread del consumatore si è bloccato anch'esso. Nel giro di pochi minuti, un intero gruppo di consumatori era offline. Poiché la pipeline condivideva un cluster Kafka con altri servizi, la compattazione del log del broker è stata influenzata e le pipeline non correlate hanno iniziato a vedere una latenza aumentata.
Un altro ha descritto un archivio di metadati utilizzato da più lavori batch. Una migrazione dello schema per un lavoro ha bloccato la tabella dei metadati per 90 secondi. Ogni altro lavoro che toccava la stessa tabella è fallito o è andato in timeout. Ciò che avrebbe dovuto essere un problema di un singolo team è diventato un incidente a livello aziendale.
La lezione da questi postmortem non è solo "isolare i tuoi fallimenti". È che lo stato condiviso è spesso invisibile. I team non si rendono conto di condividere l'infrastruttura finché non fallisce. Il cluster Kafka, la tabella dei metadati, il mount NFS condiviso — questi non sono considerati parte del design della pipeline, ma sono parte del suo dominio di fallimento.
Cosa sembrava il restante 5%
Il resto dei postmortem erano davvero casi isolati: un raggio cosmico che capovolge un bit, un'API di un fornitore che cambia comportamento senza preavviso, un certificato che scade durante un fine settimana festivo. Questi sono i fallimenti che non puoi progettare via. Il 95% sopra, puoi.
La checklist di progettazione
Dopo aver letto questi 50 postmortem, continuavo a vedere lo stesso gap. I fallimenti non si sono verificati perché i team mancavano di talento, strumenti o consapevolezza. Si sono verificati perché domande di progettazione specifiche non sono state poste abbastanza presto.
Ecco sei domande che, se risposte onestamente durante la revisione del progetto, avrebbero prevenuto la maggior parte degli incidenti che ho analizzato:
1. Cosa succede quando lo schema cambia senza preavviso?
Non "abbiamo un registro di schema?" — questa è una domanda sugli strumenti. La domanda di progettazione è: la pipeline fallisce quando lo schema devia dalle aspettative, o si adatta silenziosamente? Il comportamento adattivo sembra più sicuro finché non produce dati errati. Imposta il fallimento come predefinito. Rendi i disallineamenti dello schema rumorosi.
2. Qual è il carico massimo a cui questa pipeline è stata testata, e cosa si rompe per primo quando lo superiamo?
La maggior parte dei team testa per la correttezza. Molti meno testano per i limiti. Conosci il tuo primo collo di bottiglia — memoria, connessioni, disco, limiti di velocità a valle — e hai un piano di degrado graduale per quando lo raggiungi.
3. Come sapremmo se stessimo perdendo silenziosamente il 10% dei nostri dati?
Questa è la domanda più importante. Se la tua unica validazione è "il lavoro è finito", stai volando alla cieca. Hai bisogno di controlli di qualità dei dati indipendenti che confrontino il volume di output, la distribuzione e le metriche chiave con le basi storiche.
4. I nostri retry sono sicuri?
Qualsiasi logica di retry è un potenziale meccanismo di duplicazione a meno che il sink non sia strettamente idempotente. Rivedi ogni chiamata API, ogni scrittura su database, ogni append di file. Se non puoi garantire l'idempotenza, garantisci al massimo una volta e accetta la perdita occasionale rispetto alla duplicazione garantita.
5. Quali altri sistemi falliscono se questo lo fa?
Mappa il tuo dominio di fallimento. Se la tua pipeline si blocca, blocca una coda condivisa? Esaurisce un pool di connessioni? Riempie un disco di cui altri lavori hanno bisogno? Progetta per il contenimento del raggio d'azione, non solo per il recupero.
6. Qualcuno che non ha mai visto questa pipeline può debuggarla alle 3 del mattino?
I postmortem con i tempi di recupero più rapidi avevano tutti una cosa in comune: osservabilità che non richiedeva conoscenza istituzionale. Log che spiegano le decisioni, non solo i cambiamenti di stato. Metriche che mostrano la salute dei dati, non solo la salute del sistema. Allarmi che indicano la causa principale, non solo i sintomi.
La scomoda verità
Leggere 50 postmortem non ti rende immune al fallimento. Ma rende gli schemi ovvi. E gli schemi sono, per la maggior parte, noiosi. Schema drift. Limiti di carico. Validazione mancante. Stato condiviso. Questi non sono problemi esotici di sistemi distribuiti. Sono igiene del design.
I team che hanno pubblicato questi postmortem sono tra i migliori al mondo nella costruzione di infrastrutture dati. Se stanno ancora colpendo questi schemi, lo stanno facendo anche tutti gli altri. La differenza è se li catturi nella revisione del progetto o alle 3 del mattino.
Se stai progettando data pipeline e vuoi una piattaforma che imponga contratti di schema, gestisca il backpressure con grazia e ti dia il debug visivo quando le cose vanno storte — sia che si tratti di batch o streaming — dai un'occhiata a layline.io. La Community Edition è gratuita da esplorare.
Andrew Tan è un imprenditore seriale e fondatore di layline.io, costruendo infrastrutture di elaborazione dati aziendali che gestiscono carichi di lavoro batch e in tempo reale su larga scala.