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à è l