Le trading haute fréquence représente 50 % des transactions de titres aux États-Unis. Avec des milliers de titres totalisant des millions de dollars échangés chaque milliseconde, des systèmes informatiques robustes et fiables sont nécessaires pour automatiser les transactions. Ces microtransactions automatisées peuvent générer des profits considérables. Cependant, 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 ses systèmes l'informant d'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. À partir 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 SMARS, à des 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 SMARS. Knight n'a pas fait vérifier ce déploiement par un deuxième technicien et personne chez Knight n'a remarqué 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 ne disposait d'aucune procédure écrite exigeant une telle vérification. (page 6)

Les bugs logiciels peuvent entraîner des pertes considérables dans n'importe quel secteur. Si vous êtes un site e-commerce ou que vous avez des publicités sur votre page, vous perdrez de l'argent à chaque seconde d'indisponibilité de votre page. La fidélisation de la clientèle est également affectée. La frustration pousse les clients à se tourner vers des concurrents. La lenteur des délais de réponse a des conséquences financières et sur la réputation. En cas de problème, agissez vite.

3 étapes pour une gestion rapide des incidents informatiques

Des bugs peuvent survenir à n'importe quel stade de développement et sont la conséquence d'une erreur humaine. Leur résolution nécessite également une intervention humaine. En vous basant sur les trois erreurs les plus courantes de Knight Capital, appliquez les bonnes pratiques ci-dessous pour atténuer vos incidents informatiques.

1. Définir des seuils.

B. Knight ne disposait pas de contrôles raisonnablement conçus pour l'empêcher de saisir des ordres sur des titres de participation dépassant les seuils de capital prédéfinis pour l'entreprise, au total, comme l'exige la règle 15c3-5(c)(1)(i). En particulier, Knight n'a pas lié ses comptes aux seuils de capital de l'entreprise, et s'est appuyé sur des contrôles des risques financiers incapables d'empêcher la saisie d'ordres (page 4).

Knight Capital a commis une grave 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 leurs 450 millions de dollars de pertes. Les systèmes informatiques deviennent de plus en plus complexes et de nombreux composants peuvent tomber en panne lorsque les limites sont dépassées. Des incidents sur les sites web peuvent survenir en raison de problèmes de performances DNS ou d'utilisation du processeur ; il est donc important de fixer des seuils. Au lieu d'attendre que l'utilisation du processeur atteigne 100 %, fixez votre seuil à 70 % pour éviter une panne catastrophique. Les seuils signalent l'arrivée d'incidents majeurs et peuvent créer un sentiment d'urgence pour résoudre les problèmes. Fixez des seuils proactifs pour éviter de sombrer dans l'abîme.

2. Créer un processus humain.

19. Le 1er août, Knight a également reçu des ordres éligibles au RLP, mais destinés à être négociés avant l'ouverture des marchés. SMARS a traité ces ordres et, à partir de 8 h 01 HE environ, un système interne de Knight a généré des courriels automatisés (appelés « rejets BNET ») faisant référence à SMARS et identifiait une erreur décrite comme « Power Peg désactivé ». Le système de Knight a envoyé 97 de ces courriels à un groupe d'employés de Knight avant l'ouverture des marchés à 9 h 30. Knight n'avait pas conçu ces messages comme des alertes système, et le personnel de Knight ne les consultait généralement pas à leur réception. 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 permis à Knight d'identifier et de corriger le problème de codage avant l'ouverture des marchés. Ces notifications n'ont pas été traitées avant l'ouverture des marchés 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 d'aucune procédure de supervision concernant la gestion des incidents. Plus précisément, Knight ne disposait pas de procédures de supervision pour guider son personnel concerné en cas de problèmes importants. Le 1er août, Knight s'est principalement appuyé sur son équipe technique pour tenter d'identifier et de résoudre le problème SMARS en temps 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. Pour tenter de résoudre le problème, Knight a désinstallé le nouveau code RLP des sept serveurs où il avait été correctement déployé. Cette action a aggravé le problème, provoquant l'activation du code Power Peg présent sur ces serveurs par des ordres parents entrants supplémentaires, comme cela s'était déjà produit sur le huitième serveur. (page 8)

Les systèmes de Knight Capital ont envoyé 97 e-mails pour les avertir d'un problème. Ces e-mails n'ont servi ni à prévenir ni à diagnostiquer le problème. À quoi sert une alerte si personne n'est là pour l'entendre ? Lorsque des seuils sont franchis, les personnes concernées doivent être contactées immédiatement pour résoudre l'incident. Les systèmes informatiques fonctionnant 24 h/24, 7 j/7, 365 j/an, des équipes sont constituées pour répondre aux problèmes dès leur apparition. Qu'il s'agisse d'un centre d'opérations réseau (NOC) ou d'un système de rotation des astreintes, les bonnes personnes doivent être contactées, où qu'elles se trouvent. En cas d'astreinte, vous êtes responsable de tous les incidents qui surviennent et devez agir rapidement pour résoudre les problèmes de gravité élevée. Associer les personnes à un incident crée un sentiment de responsabilité.

3. Apprenez des incidents précédents.

33. Plusieurs événements antérieurs ont permis à Knight de réévaluer 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 lors du début des échanges ce lundi matin. Knight a subi une perte de près de 7,5 millions de dollars suite à cet événement. Knight a réagi en limitant le fonctionnement du système aux heures de marché, en modifiant le contrôle afin que le système cesse de fournir des cotations après réception d'une exécution et en ajoutant un élément à la liste de contrôle de reprise après sinistre exigeant la vérification des données de test. Knight n'a pas examiné de manière approfondie si ses contrôles étaient suffisants pour empêcher la saisie d'ordres erronés, quel que soit le système ayant émis les ordres ou la raison précise de l'erreur. Knight ne disposait pas non plus de mécanisme permettant de 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 subissait. Après avoir perdu 7,5 millions de dollars suite à un incident survenu en octobre 2011, Knight n'avait pas mis en place suffisamment de contrôles pour prévenir toute saisie d'ordres erronée. L'entreprise aurait dû tirer les leçons de cette perte de 7,5 millions de dollars – comparée à sa perte de 450 millions de dollars l'année suivante – et réévaluer l'adéquation de ses contrôles. Après la résolution d'un incident, il est essentiel d'analyser les événements et de réitérer son processus de gestion des incidents. Des mesures cohérentes et précises peuvent permettre de dégager des tendances. Ces tendances permettront ensuite de définir des seuils et d'affiner le processus de gestion des incidents, et, in fine, d'améliorer l'efficacité de la gestion des incidents.

Ne laissez pas les problèmes s'envenimer ; corrigez-les immédiatement. Les incidents coûtent cher : les clients s'irritent, 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 elles en valent la peine.