Knight Capital: $460 Milioni Bruciati in 45 Minuti
Un errore umano durante un deploy. Quarantacinque minuti dopo, una delle più grandi società di trading elettronico degli Stati Uniti è devastata. La vendetta del codice morto.
Tra il 27 luglio e il 1 agosto 2012, Knight distribuì a tappe il nuovo codice RLP su SMARS. In quel rollout, uno degli otto server non ricevette il nuovo codice. Quarantacinque minuti dopo, Knight Capital ha bruciato 460 milioni di dollari ed è sull'orlo del fallimento.
Non fidatevi mai del codice morto. È come sotterrare scorie radioattive in giardino e sperare che il cane non ami scavare buche.
Il Meccanismo del Disastro
Il crollo di Knight Capital non è stato causato da un hacker russo con la felpa col cappuccio, ma dalla combinazione di due delle peggiori pratiche ingegneristiche conosciute: Deployment manuale e Flag repurposing (il riciclo delle variabili).
Knight aveva un sistema di routing degli ordini chiamato SMARS, distribuito su 8 server. Stavano rilasciando un nuovo aggiornamento software (RLP). Per attivare questo nuovo codice, i programmatori decisero di riutilizzare un vecchio flag (una variabile accesa/spenta).
Il problema? Quello stesso flag, nel vecchio codice, serviva ad accendere Power Peg. Power Peg era una funzionalità legacy rimasta nel codice di SMARS. Una modifica del 2005 ne aveva compromesso il corretto stop-condition, e quando fu riattivata per errore iniziò a generare child orders ben oltre il dovuto.
Schema semplificato: il medesimo flag doveva attivare RLP sui server aggiornati, ma sul server rimasto indietro riattivò Power Peg. Quando Knight rimosse il nuovo codice dai server corretti, quel flag tornò a innescare Power Peg anche lì.
Il Deployment a Metà
La mattina del 1 agosto, durante la prosecuzione del deploy del nuovo software RLP, i tecnici aggiornarono i server. Sette server ricevettero il nuovo codice; uno no.
Quando la campanella di Wall Street suona alle 9:30, i primi 7 server gestiscono gli ordini col nuovo codice correttamente. Il Server 8, invece, ha ancora il vecchio software. Riceve il comando "Attiva il flag". Il Server 8 obbedisce, ma siccome ha il codice vecchio, non lancia il nuovo sistema: risveglia Power Peg.
Immaginate di cambiare l'interruttore della luce in salotto, ma di dimenticare di staccare un vecchio filo nel muro. Ora, ogni volta che accendete la luce, si attiva anche una sega circolare sul pavimento.
L'Inferno e la Soluzione Peggiore Possibile
Per 45 minuti, il Server 8 inizia a vomitare sul mercato ordini anomali. In totale, il sistema brucerà oltre $460 Milioni.
Quando i manager si accorgono che qualcosa non va, fanno una scelta disastrosa. Invece di spegnere i server, pensano che l'aggiornamento abbia rotto tutto e fanno rollback ai binari del giorno prima.
Riportano i 7 server aggiornati alla vecchia versione. Ma non spengono il flag. Risultato? La SEC confermò che rimuovere il nuovo codice RLP peggiorò il problema, attivando Power Peg anche sugli altri server. Passarono altri minuti prima che Knight riuscisse a disconnettere effettivamente il sistema dal mercato.
Lezioni Per Tutti Noi
- Il codice morto non è innocuo, è una mina. Se una funzione non serve più, non si commenta. Non si lascia lì "perché non si sa mai". Si cancella brutalmente dal codebase. Git serve a questo: se vi pentite, lo recuperate dalla history.
- I controlli automatici salvano la vita. Il codice morto accese l'incendio, ma l'assenza di controlli automatici su esposizione e arresto degli ordini impedì di spegnerlo in tempo.
- I flag non si riciclano. I bit non costano così tanto. Se vi serve una nuova variabile, createne una nuova.
- Automazione o Morte. Se il vostro sistema di deploy prevede l'intervento manuale macchina per macchina, state giocando alla roulette russa. È solo questione di tempo prima che il tamburo faccia click.
Knight uscì dall'episodio finanziariamente devastata e finì assorbita nell'orbita di GETCO/KCG.
🪳 Il Duca del Debug — La savana digitale non perdona.