Le 1er aot 2012, Knight Capital Group, une entreprise de trading haute frquence, a connu un dsastre financier sans prcdent aux premires heures de l’ouverture de la bourse. Quelque chose a trs mal tourn dans le code qui avait t introduit pendant la nuit. Il s’agissait d’un algorithme de ngociation haute frquence conu pour acheter et vendre des quantits massives d’actions dans un court laps de temps. La combinaison d’un mauvais timing et de mauvais ordres a conduit des rsultats dsastreux.
Knight Capital Group est une socit amricaine de services financiers d’envergure mondiale qui exerce des activits de tenue de march, d’excution lectronique, de vente et de ngociation institutionnelles. En 2012, Knight tait le plus grand ngociateur d’actions amricaines, avec une part de march d’environ 17 % sur le New York Stock Exchange (NYSE) ainsi que sur le Nasdaq Stock Market.
Il a fallu 17 ans de travail acharn pour faire de Knight Capital Group l’une des principales maisons de courtage de Wall Street. Et tout a failli s’arrter en moins d’une heure. Ce qui est arriv Knight le matin du 1er aot 2012 est le cauchemar de tout chef d’entreprise : une simple erreur humaine, facilement reprable a posteriori mais presque impossible prvoir, a menac de mettre fin l’entreprise.
Chez Knight, un nouveau logiciel de ngociation contenait une faille qui n’est devenue apparente qu’aprs l’activation du logiciel l’ouverture de la Bourse de New York (NYSE) ce jour-l. Le logiciel erron a entran Knight dans une frnsie d’achat, s’emparant de 150 actions diffrentes pour un cot total de plusieurs milliards de dollars, le tout au cours de la premire heure d’ouverture de la bourse.
Selon les rgles de la bourse, Knight aurait d payer ces actions trois jours plus tard. Cependant, il n’y avait aucun moyen de payer, tant donn que les transactions n’taient pas intentionnelles et qu’elles n’avaient aucune source de financement. Les seules alternatives taient d’essayer de faire annuler les transactions ou de vendre les actions nouvellement acquises le mme jour.
Knight a tent de faire annuler les transactions. La prsidente de la Securities and Exchange Commission (SEC), Mary Schapiro, a refus de le faire pour la plupart des actions en question, et cette dcision semble avoir t la bonne. Des rgles ont t tablies aprs le « flash crash » de mai 2010 pour dterminer quand les transactions doivent tre annules. La frnsie d’achat de Knight n’a pas fait grimper le prix des actions achetes de plus de 30 %, le seuil d’annulation, sauf pour six actions. Ces transactions ont t annules. Dans les autres cas, les transactions ont t maintenues
Des dlais serrs pour les dveloppeurs
Les dveloppeurs ont t chargs de porter leur robot HFT (High-frequency, en franais, transactions haute frquence) sur un service API NYSE venir, dont la mise en service a t annonce moins de 33 jours plus tard. Ils ont donc entam un sprint de 80 heures par semaine. Le robot HFT tait crit en C++. Pour ne pas avoir recompiler une seule fois, l’architecte en chef a dcid de conserver exactement la mme classe et la mme signature de mthode pour leur mthode PowerPeg::trade(), qui tait leur robot de test automatis qu’ils utilisaient depuis 2003. Cela signifiait galement qu’ils n’avaient pas mettre jour le WSDL (Web Services Description Language, un langage de description fond sur XML) pour les clients qui utilisaient le robot.
Ils ont supprim l’ancien code mort et mis en place le nouveau code. Un code qui faisait appel une logique relle, au lieu du code de test, qui tait conu, par dfaut, pour acheter l’offre la plus leve qui lui tait faite.
Ils l’ont test, ils ont crit des tests unitaires, tout semblait bon. Ils ont donc dcid de le dployer 8 heures EST, 90 minutes avant l’ouverture du march. Les testeurs d’assurance qualit l’ont test en production et ont donn le feu vert. Tout le monde tait trs heureux. Ils avaient russi. Ils avaient respect le dlai serr et dploy l’application avec seulement 90 minutes d’avance…
Ils se sont immdiatement rendus une runion de sprint standup puis une runion de sprint retro. Conformment la politique de leur bureau, ils ont laiss leurs tlphones (en sourdine) leur bureau.
Tuez les serveurs !!!
Pendant la rtro, les marchs ont ouvert 9:30 EDT, et le nouveau bot a simplement commenc acheter l’offre la plus leve pour tous les titres de sa liste d’achat. Les marchs n’ont pas ragi de manire trs anormale, parce qu’ils avaient simplement l’air d’tre haussiers. Mais le bot achetait environ 5 millions d’actions par seconde… En l’espace de 2 minutes, les alarmes se sont dclenches dans leur secteur bancaire interne… un pourcentage norme de leurs 2,5 milliards de dollars de liquidits d’exploitation tait en train de s’puiser, et rapidement !
De nombreuses personnes ont essay de contacter les dveloppeurs, mais ils se trouvaient dans un bureau loign Hoboken en raison du prix lev de l’immobilier Manhattan. Leurs tlphones taient teints et personne ne se trouvait devant leur ordinateur.
Le PDG a t vu en train de faire courir des gens dans les couloirs du btiment, en criant, et finalement les dveloppeurs l’ont remarqu. 11 minutes s’taient coules et les robots avaient achet pour plus de 3 milliards de dollars d’actions. Les rserves de liquidits taient puises. La socit avait de srieux problmes…
Aucun des dveloppeurs n’a pu trouver la source du bogue. Le PDG, dsespr, a demand des solutions. L’un des dveloppeurs a cri : TUEZ LES SERVEURS !!! .
Des techniciens du centre de donnes situ ct du btiment de la Bourse de New York ont trouv les 8 serveurs sur lesquels fonctionnaient les robots et les ont dtruits l’aide d’un cble d’incendie. Et finalement, au bout de 37 minutes, les bots ont cess d’oprer. Perte totale sur papier : 10,8 milliards de dollars.
La SEC et le NYSE ont refus de rtablir les transactions pour toutes les actions sauf 6, les pertes sur papier taient encore de 8 milliards de dollars. Impossible de payer. Goldman Sachs est intervenu et a propos d’acheter toutes les actions un prix lucratif de 457 millions de dollars, ce qu’ils ont accept. Au final, la socit a perdu prs de 500 millions de dollars et tous ses clients ont quitt la socit, qui a fait faillite quelques semaines plus tard.
Quelle tait la cause de ce bogue ? Une grossire erreur humaine lors de la mise en production
L’administrateur systme avait refus d’implmenter un pipeline CI/CD, qui en tait encore ses balbutiements, probablement parce que c’tait son travail plein temps. Il y avait 8 serveurs qui hbergeaient le bot et quelques clients sur les mmes serveurs.
Il avait tap et coll les bonnes commandes rsync pour obtenir le nouveau binaire C++ sur les serveurs, l’exception du serveur 5. Dans son cas, il y avait un 5 supplmentaire dans le nom du serveur. Le rsync a chou, mais comme il a coll toutes les commandes en mme temps, il ne l’a pas remarqu…
Comme le code utilisait exactement la mme signature de mthode pour la mthode trade(), le serveur 5 tait heureux d’acheter l’offre la plus chre qu’on lui proposait, parce qu’il excutait le logiciel de trading de test Sad Path. S’il avait chang la signature de la mthode, il n’aurait pas fonctionn et le bogue ne se serait pas produit.
9:43 EDT, les dveloppeurs ont dcid collectivement de faire un « rollback » la version prcdente. C’tait la pire erreur possible, car ils ont ajout le code Power Peg mort aux 7 autres serveurs, ce qui a provoqu une croissance exponentielle des problmes. Il a fallu environ trois minutes pour que quelqu’un de la direction financire en soit inform. ce moment-l, plus de 50 millions de dollars par seconde taient perdus cause du bogue.
Ce n’est qu’ 9:58 EDT, lorsque tous les serveurs ont t dtruits, que les transactions se sont arrtes.
Leons tires du fiasco de Knight Capital en matire de tests de logiciels
Rick Lane, qui tait alors directeur technique de Trading Technologies Chicago, a soulign que ces algorithmes de trading sont dvelopps trs rapidement, car ils sont conus pour saisir des opportunits fugaces, et qu’une bonne gestion du changement peut tre relgue au second plan par rapport la rapidit.
Il a propos l’poque quatre faons d’amliorer les tests de logiciels et de rduire les risques :
- Amliorer la gestion des changements et de la configuration : Le fait de conserver le code de test et le code de production dans des « bacs sable » diffrents est une pratique trs rpandue pour rduire les risques. Chez Zappos, l’quipe dispose d’un processus distinct et plus rigoureux pour le code qui touche aux donnes sensibles des clients et aux informations financires. Etsy, quant elle, dploie tout le code en production, mais attnue ce risque grce la technique n2.
- Amliorer le contrle de la production : Lane suggre d’utiliser des processus automatiss pour dtecter les erreurs et envoyer des alertes. Jeffery Reeves, rdacteur en chef de InvestorPlaceMedia, recommande que des personnes surveillent les volumes de transactions et fassent preuve de discernement. Les entreprises qui effectuent un grand nombre de transactions automatises ont tout intrt avoir les deux.
- Considrer les tests comme un processus de gestion des risques de haut niveau : Dans de nombreux cas, les socits commerciales estiment qu’elles n’ont pas assez de temps pour effectuer des tests traditionnels en raison de la brivet de ces opportunits phmres , a expliqu Lane. Paradoxalement, de nombreux bogues ne seraient pas dtects par les tests traditionnels, car il s’agit de risques de configuration. Le logiciel peut avoir fonctionn correctement, mais au mauvais endroit, au mauvais moment ou partir d’un code de test qui tait en production. Le type de testeurs qui cliquent sur ceci, cliquent sur cela, s’assurent que ces chiffres correspondent , comme les dcrit Lane, ne pourrait pas trouver de tels bogues. Une meilleure gestion des risques est ncessaire.
- Renforcer les contrles internes sur les transactions fort volume : Il est possible que la dfaillance de Knight Capital ait pu tre vite grce un simple bouton sur lequel un humain devait cliquer, en particulier lorsque le volume atteignait un certain niveau. Un tel contrle ne se situerait pas au niveau du programme, mais plutt au niveau de l’API publique. Tant que de tels contrles externes n’existent pas, nous ferions bien de les intgrer dans nos programmes de passerelle.
Source : Security Exchange Commission
Et vous ?
Quelles mesures de contrle auraient pu empcher ce bogue logiciel ? voquez les pratiques de dveloppement, de test et de dploiement qui auraient pu viter une telle catastrophe.
Les conseils de Rick Lane pour amliorer les tests de logiciels et de rduire les risques vous semblent-ils encore d’actualit ? Quels sont les points que vous auriez supprims, changs, amliors ou ajouts ?
Quelles leons les autres entreprises peuvent-elles tirer de cet vnement ? Pensez la manire dont votre propre entreprise gre les risques lis aux bogues logiciels et la qualit du code.
Comment les rgulateurs devraient-ils intervenir dans de tels cas ? Discutez des rles et responsabilits des organismes de rgulation dans la prvention de tels incidents.