Le trading haute fréquence représente 50 % des transactions de titres aux États-Unis. Des milliers de titres totalisant des millions de dollars sont échangés chaque milliseconde. Il faut donc des systèmes informatiques robustes et fiables pour automatiser les transactions. Ces microtransactions automatisées peuvent produire d'énormes bénéfices. Mais de graves répercussions peuvent survenir en cas de problème, et elles sont exacerbées lorsqu'elles ne sont pas résolues.

Le 1er août 2012, Knight Capital a perdu 460 millions de dollars après 45 minutes de négociation. Knight a reçu 97 courriels de leurs systèmes pour les informer qu'il y avait un problème, mais ils ont répondu trop tard. Document post-mortem de la SEC publié le 16 octobre 2013 donne plus de détails sur les événements qui ont conduit au bug logiciel, mais le point ci-dessous résume le mauvais processus DevOps autour de la mise en œuvre d'un nouveau code :

15. À compter du 27 juillet 2012, Knight a déployé le nouveau code RLP dans SMARS par étapes en le plaçant sur un nombre limité de serveurs dans SMARS au cours de jours successifs. Cependant, lors du déploiement du nouveau code, l'un des techniciens de Knight n'a pas copié le nouveau code sur l'un des huit serveurs informatiques SMARS. Knight n'a pas demandé à un deuxième technicien de vérifier ce déploiement et personne chez Knight ne s'est rendu compte que le code Power Peg n'avait pas été supprimé du huitième serveur, ni que le nouveau code RLP n'avait été ajouté. Knight n'avait aucune procédure écrite exigeant une telle vérification. (page 6)

Les bugs logiciels peuvent entraîner d'énormes pertes dans n'importe quel secteur. Si vous êtes un site de commerce électronique ou si vous avez des publicités sur votre page, vous perdrez de l'argent à chaque seconde où votre page est inaccessible. La fidélisation des clients est également affectée. La frustration incite les clients à se tourner vers des entreprises concurrentes. Les délais de réponse lents ont des conséquences financières et sur la réputation. Lorsque des problèmes surviennent, agissez rapidement.

3 étapes pour une gestion rapide des incidents informatiques

Les bugs peuvent survenir à n'importe quel stade de développement et sont la conséquence d'une erreur humaine. Une intervention humaine est également nécessaire pour résoudre le problème. En vous basant sur les 3 plus grosses erreurs de Knight Capital, mettez en œuvre les meilleures pratiques ci-dessous pour atténuer vos incidents informatiques.

1. Définir des seuils.

B. Knight n'avait pas mis en place de contrôles raisonnablement conçus pour l'empêcher de saisir des ordres pour des titres de participation qui dépassaient les seuils de capital prédéfinis pour la société, dans leur ensemble, comme l'exige la règle 15c3-5(c)(1)(i). En particulier, Knight n'a pas lié les comptes aux seuils de capital de l'ensemble de la société et s'est appuyée sur des contrôles des risques financiers qui n'étaient pas en mesure d'empêcher la saisie d'ordres (page 4)

Knight Capital a commis une énorme erreur en ne fixant pas de limites en fonction de sa capacité financière. S’ils avaient fixé des seuils financiers, comme une limite de 75 % du capital, ils auraient pu éviter une partie de leur perte de 450 millions de dollars. Les systèmes informatiques deviennent de plus en plus complexes et de nombreux composants peuvent se briser lorsque les limites sont dépassées. Des incidents sur un site Web peuvent survenir en raison de problèmes de performances DNS ou d’utilisation du processeur. Il faut donc fixer des seuils pour ces incidents. Au lieu d’attendre que l’utilisation du processeur atteigne 100 %, fixez votre seuil à 70 % pour éviter une panne désastreuse. Les seuils agissent comme un signal pour des incidents majeurs à venir et peuvent créer un sentiment d’urgence pour résoudre les problèmes. Fixez des seuils proactifs pour éviter de tomber dans le précipice.

2. Créer un processus humain.

19. Le 1er août, Knight a également reçu des ordres admissibles au RLP, mais destinés à être négociés avant l'ouverture du marché. SMARS a traité ces ordres et, à partir de 8 h 01 HE environ, un système interne de Knight a généré des messages électroniques automatisés (appelés « rejets BNET ») qui faisaient référence à SMARS et identifiaient une erreur décrite comme « Power Peg désactivé ». Le système de Knight a envoyé 97 de ces messages électroniques à un groupe de membres du personnel de Knight avant l'ouverture du marché à 9 h 30. Knight n'a pas conçu ces types de messages comme des alertes système et le personnel de Knight ne les a généralement pas examinés lorsqu'ils ont été reçus. Cependant, ces messages ont été envoyés en temps réel, ont été causés par l'échec du déploiement du code et ont fourni à Knight une opportunité potentielle d'identifier et de corriger le problème de codage avant l'ouverture du marché. Ces notifications n'ont pas été prises en compte avant l'ouverture du marché et n'ont pas été utilisées pour diagnostiquer le problème après l'ouverture. (page 6)

27. Le 1er août, Knight ne disposait pas de procédures de supervision concernant la réponse aux incidents. Plus précisément, Knight ne disposait pas de procédures de supervision pour guider son personnel concerné lorsque des problèmes importants survenaient. Le 1er août, Knight s'est principalement appuyée sur son équipe technologique pour tenter d'identifier et de résoudre le problème SMARS dans un environnement de négociation réel. Le système de Knight a continué d'envoyer des millions d'ordres enfants pendant que son personnel tentait d'identifier la source du problème. Dans l'une de ses tentatives pour résoudre le problème, Knight a désinstallé le nouveau code RLP des sept serveurs sur lesquels il avait été déployé correctement. Cette action a aggravé le problème, provoquant l'activation d'ordres parents entrants supplémentaires pour activer le code Power Peg qui était présent sur ces serveurs, de manière similaire à ce qui s'était déjà produit sur le huitième serveur. (page 8)

Les systèmes de Knight Capital ont envoyé 97 courriels pour les avertir qu'il y avait un problème. Ces courriels n'ont pas été utilisés pour prévenir ou diagnostiquer le problème. À quoi sert une alerte s'il n'y a personne pour l'entendre ? Lorsque les seuils sont dépassés, les bonnes personnes doivent être contactées immédiatement pour résoudre l'incident. Étant donné que les systèmes informatiques fonctionnent 24 heures sur 24, 7 jours sur 7, 365 jours par an, des équipes sont créées pour répondre aux problèmes dès qu'ils surviennent. Qu'un centre d'opérations réseau (NOC) ou un programme de rotation d'astreinte soit mis en place, les bonnes personnes doivent être contactées où qu'elles se trouvent. Si vous êtes d'astreinte, vous êtes responsable de tous les incidents qui surviennent et vous devez agir rapidement pour résoudre les problèmes de gravité élevée. En associant les personnes à un incident, cela crée un sentiment de responsabilité et de responsabilisation.

3. Apprenez des incidents précédents.

33. Plusieurs événements antérieurs ont donné à Knight l'occasion de réexaminer l'adéquation de ses contrôles dans leur intégralité. Par exemple, en octobre 2011, Knight a utilisé des données de test pour effectuer un test de reprise après sinistre pendant le week-end. Une fois le test terminé, le bureau LMM de Knight a continué par erreur à utiliser les données de test pour générer des cotations automatiques lorsque les échanges ont commencé ce lundi matin. Knight a subi une perte de près de 7,5 millions de dollars à la suite de cet événement. Knight a réagi à l'événement en limitant le fonctionnement du système aux heures de marché, en modifiant le contrôle de sorte que ce système cesse de fournir des cotations après avoir reçu une exécution et en ajoutant un élément à une liste de contrôle de reprise après sinistre qui exigeait une vérification des données de test. Knight n'a pas examiné de manière générale si elle disposait de contrôles suffisants pour empêcher la saisie d'ordres erronés, quel que soit le système spécifique qui a envoyé les ordres ou la raison particulière de l'erreur de ce système. Knight ne disposait pas non plus d'un mécanisme pour vérifier si ses systèmes s'appuyaient sur des données obsolètes. (page 10)

L’incident d’août 2012 n’était pas le premier que Knight a connu. Après avoir perdu 7,5 millions de dollars à la suite d’un incident survenu en octobre 2011, Knight n’avait pas mis en place suffisamment de contrôles pour empêcher toute saisie de commandes erronée à l’avenir. L’entreprise aurait dû utiliser cette perte de 7,5 millions de dollars comme une petite leçon – comparée à sa perte de 450 millions de dollars l’année suivante – et réévaluer l’adéquation de ses contrôles. Une fois tout incident résolu, vous devez analyser ce qui s’est passé et réitérer votre processus de gestion des incidents. Des mesures cohérentes et précises peuvent aider à découvrir des tendances. Ces tendances serviront ensuite à établir des seuils et à affiner le processus de gestion des incidents et, en fin de compte, à rendre la gestion des incidents plus efficace.

Ne laissez pas les problèmes s'envenimer ; corrigez-les immédiatement. Les incidents coûtent cher : les clients se fâchent, la réputation est entachée et l'argent est perdu. Dans le cas de Knight Capital, des centaines de millions de dollars sont perdus. Les trois meilleures pratiques ci-dessus sont un processus cyclique et sans fin, mais cela en vaut la peine.