Knightmare : récit d’avertissement DevOps (2014)

• Article sur l’histoire édifiante de Knight Capital Group, une grande société mondiale de services financiers, qui a fait faillite en 45 minutes à cause d’un déploiement logiciel raté.
• En 2012, Knight Capital Group était le plus grand négociateur d’actions américaines, avec un volume moyen quotidien de plus de 3,3 milliards de transactions et plus de 21 milliards de dollars échangés chaque jour.
• L’entreprise a mis à jour SMARS, un routeur algorithmique automatisé à haute vitesse, pour préparer le lancement du nouveau Retail Liquidity Program du NYSE.
• Cette mise à jour visait à remplacer un ancien code inutilisé appelé "Power Peg", que Knight n’avait pas utilisé depuis 8 ans.
• Le nouveau code a été déployé manuellement sur 8 serveurs, mais à cause d’une erreur d’un technicien, le nouveau code n’a pas été copié sur l’un des serveurs, ce qui a réactivé l’ancien code Power Peg.
• La fonction Power Peg a commencé à router des ordres pour exécuter des ordres enfants sans suivre le nombre d’actions des ordres parents, provoquant une boucle infinie d’ordres.
• À l’ouverture du marché, le système de Knight a inondé le marché d’ordres, faisant grimper certaines actions de plus de 10 % de leur valeur, tandis que d’autres ont chuté en réaction à ces transactions erronées.
• Le système de Knight a envoyé 97 e-mails automatiques mentionnant SMARS et identifiant l’erreur comme "Power Peg disabled", mais ils n’étaient pas conçus comme des alertes système et n’ont pas été vérifiés immédiatement.
• Pendant les 45 premières minutes de cotation, le code Power Peg a traité 212 ordres parents et exécuté 4 millions de transactions sur 154 actions, pour un total de plus de 397 millions d’actions traitées.
• Knight Capital Group a subi une perte de 460 millions de dollars en 45 minutes, ce qui l’a conduit à la faillite. L’entreprise a réuni le capital nécessaire pour couvrir ces pertes grâce à un investissement de 400 millions de dollars provenant d’une demi-douzaine d’investisseurs.
• L’article souligne l’importance de rendre les déploiements entièrement automatisés et reproductibles pour éviter ce type de défaillance majeure, dans le cadre d’une stratégie DevOps/Continuous Delivery.
• L’auteur estime que les mises en production logicielles doivent être des processus reproductibles et fiables, et qu’elles doivent être automatisées autant que possible afin de réduire le risque d’erreur humaine.

[GN⁺]

Avis Hacker News

• Le déploiement automatisé n’aurait peut-être pas empêché le problème, et aurait même pu l’aggraver à cause de code incompatible.
• Les systèmes de trading automatisé devraient disposer d’un kill switch intégré, régulièrement testé pour garantir son bon fonctionnement.
• Un système de déploiement continu n’aurait peut-être pas bloqué ce bug, une erreur logique ayant conduit à une défaillance catastrophique.
• L’expression « se faire Knight Capital » est connue dans la finance quantitative pour désigner le fait de rogner sur les pratiques dans des systèmes critiques et d’en subir les conséquences.
• Le trading à haute fréquence est un exemple extrême de ce qui peut rapidement mal tourner.
• Pour les systèmes qui traitent de gros volumes de ventes, il est important de prévoir des processus manuels, des étapes de rollback et des feature flags afin d’atténuer les risques.
• L’incident de Knight Capital a résulté du fait d’avoir ignoré un système automatique de SCRAM qui arrêtait toutes les transactions ou alertait pour une intervention manuelle.
• La présence de code mort dans la base de code pendant 8 ans est un signe de risque, indiquant un manque de maintenance active.
• Si la configuration et les binaires avaient été déployés simultanément, ce type de problème aurait pu être évité.
• Réutiliser un ancien flag a été une erreur majeure, soulignant l’importance de bonnes pratiques de déploiement.