Un incidente del 2012 che resta una lezione attualissima su deploy, flag, rollback e gestione del rischio nei sistemi critici.
Negli incidenti software più costosi non c’è quasi mai un singolo “bug geniale” che manda tutto in fumo.
Di solito è una catena: scorciatoie accumulate nel tempo, procedure fragili, osservabilità insufficiente e una reazione d’emergenza che peggiora la situazione.
Uno degli esempi più eclatanti è quello di Knight Capital: in circa 45 minuti, nel 2012, l’azienda perse 440 milioni di dollari a causa di un rilascio gestito male e di un feature flag riutilizzato in modo pericoloso.
Una storia che vale la pena ricordare perché descrive in modo chirurgico come nascono i disastri nei sistemi critici.
Contesto: quando il software muove miliardi (e non perdona) All’epoca Knight Capital era un market maker enorme: gestiva una quota rilevante delle operazioni di trading negli Stati Uniti, macinando ogni giorno volumi giganteschi.
Al centro dell’operatività c’era un sistema di routing ordini (spesso citato come SMARS/SMARS-like nei resoconti): un motore che prendeva ordini grandi e li spezzettava in ordini più piccoli per eseguirli sul mercato alle condizioni migliori.
Un classico sistema “che stampa soldi” quando è veloce, affidabile e predicibile.
Poi arriva una novità di mercato: la borsa introduce un programma (Retail Liquidity Program) con una data di go-live precisa.
Knight è costretta ad adeguarsi in tempi stretti.
La miccia: un feature flag “zombie” rimasto nel codice per 9 anni Dentro il codebase esisteva da anni un vecchio flag, non più usato dal
2003.
Attivarlo scatenava una funzione di test chiamata Power Peg: una logica pensata per comprare aggressivamente a prezzo di mercato per osservare come reagiva il prezzo.
Traduzione: era deliberatamente progettata per non ottimizzare il prezzo d’acquisto (perché l’obiettivo era “spingere” e misurare la risposta).
Nel 2012, invece di introdurre un nuovo flag per il nuovo comportamento richiesto dal mercato, viene scelta una scorciatoia: si riutilizza il vecchio flag si sostituisce la logica dietro quel flag con la nuova funzionalità Sulla carta può persino sembrare una scelta “pragmatica”.
Nella pratica è un invito al disastro, perché: il significato del flag non è più quello originale (debito cognitivo) il flag esisteva già in ambienti e server diversi (debito operativo) se una macchina resta indietro, può riesumare la vecchia logica Il detonatore: deploy manuale incompleto su un cluster La parte più inquietante non è il flag in sé, ma come veniva distribuito il software.
Il rilascio avveniva copiando manualmente le modifiche sui server (otto macchine).
Un processo che rende probabile uno degli errori più banali e frequenti dell’informatica: non aggiornare tutto.
Ed è ciò che accadde: 7 server su 8 ricevettero la nuova versione 1 server rimase con la versione vecchia (quella in cui il flag attivava ancora Power Peg) Quando il flag viene attivato in produzione: 7 server lavorano correttamente 1 server inizia a eseguire la strategia “compra alto e vendi basso” in modalità automatica In un sistema distribuito, l’incoerenza di versione è spesso più pericolosa del bug stesso.
La reazione che peggiora tutto: rollback dei server “sani” A questo punto Knight si accorge che qualcosa non va.
Ma in emergenza si tende a fare la cosa più istintiva: “è colpa del nuovo codice, torniamo indietro”.
E qui arriva il colpo di grazia: viene fatto rollback dei 7 server aggiornati e sani così facendo, l’intero cluster torna alla versione in cui il flag attiva Power Peg Risultato: da un problema “limitato a 1/8” si passa a un problema “8/8”.
In circa 45 minuti: vengono eseguite milioni di operazioni su oltre un centinaio di titoli il mercato vede movimenti assurdi (un penny stock passa da circa $3 a $14 senza motivo) la perdita finale supera $440M Perché questa storia riguarda anche chi fa frontend È facile liquidare l’episodio come “roba da finanza” o “sistemi legacy”.
In realtà è la versione estrema di dinamiche normalissime anche nel web: feature flag usati come interruttori globali senza un ciclo di vita chiaro deploy non atomici o ambienti in stato incoerente rollback automatici o manuali che non considerano compatibilità e migrazioni mancanza di guardrail (kill switch, limiti, circuit breaker) Nel frontend moderno i danni raramente sono da 440 milioni in 45 minuti, ma possono essere: downtime in checkout prezzi/calcoli sbagliati (sconti, tasse, spedizioni) leak di dati via misconfigurazioni cascata di errori lato client che amplifica carichi backend La logica è la stessa: una scorciatoia + un deploy incoerente + una risposta impulsiva.
Lezioni pratiche: come evitare una “Power Peg” nella tua pipeline Ecco cosa questa storia suggerisce, in modo molto concreto. 1) I feature flag devono avere un ciclo di vita Ogni flag deve avere owner, scopo, data di scadenza.
I flag vecchi vanno rimossi: il codice “spento” non è innocuo, è debito che aspetta il momento giusto.
Evita di “riciclare” flag cambiandone semantica: meglio crearne uno nuovo. 2) Deploy atomici e verificabili (tutti o nessuno) Niente release “a mano” server per server.
Usa strategie che garantiscano uniformità: rolling con health check, blue/green, canary, ecc.
Deve essere facile rispondere alla domanda: quale versione gira su ogni nodo? 3) Rollback non è un pulsante magico Il rollback va progettato: compatibilità con migrazioni, flag, config, cache.
Serve osservabilità per capire cosa sta fallendo prima di cambiare versione.
Spesso il rollback “alla cieca” è ciò che trasforma un’anomalia in incidente. 4) Guardrail: limiti e kill switch reali Nei sistemi ad alto impatto è essenziale mettere paletti: limiti per unità di tempo (rate/volume) circuit breaker su comportamenti anomali kill switch immediato che isola una singola componente senza trascinare tutto il cluster 5) Post-mortem e cultura del “tagliare il debito” Il dettaglio più importante è culturale: flag zombie dal 2003 non restano nel codice per caso.
Restano perché “non abbiamo tempo”.
Eppure il tempo lo si paga dopo, con interessi.
Sintesi: l’incidente non fu un bug, fu un sistema senza rete La perdita di Knight Capital non nasce da un singolo errore di programmazione, ma da un ecosistema fragile: codice con feature flag fossilizzati deploy manuali e incoerenti rollback senza una fotografia chiara dello stato reale La lezione più utile per chi costruisce prodotti digitali è semplice e scomoda: la reliability è una feature.
E come tutte le feature va progettata, testata e mantenuta, soprattutto quando “tutto sembra funzionare”.
Articolo originale: https://frontendfacile.it/blog/knight-capital-come-un-feature-flag-dimenticato-ha-bruciato-440-milioni-in-45-mi