1066, plus de 200 ans se sont écoulés depuis le début de l'invasion des Vikings en Angleterre. Le roi Harold, rassemblant un détachement de chevaliers, se dirigea vers la rivière Derwent pour une bataille décisive avec les troupes de son homonyme - le roi de Norvège Harald. Les armuriers ont travaillé pendant un mois pour forger suffisamment d'armures de nouvelle génération qui pourraient protéger le chevalier contre les coups de hache scandinave. Et combien d'expériences et d'essais en tournois avaient été auparavant! Mais l'attente était censée se justifier - un équipement léger mais fiable permettait même à pied, sans grandes pertes, de balayer le Viking hird. Et finalement, ils se sont rencontrés à Stamford Bridge. Le principal détachement de chevaliers, dirigé par un commandant en armure brillante, s'est affronté au milieu d'un pont avec des ennemis. Oui, l'acier des maîtres podgorny tient le coup!
Lentement mais sûrement, les Vikings se tournent vers une défense à tour de rôle. La victoire semble proche. Et enfin, sur le champ de bataille, le chevalier commandant et le norvégien jarl se retrouvent.
La hache à deux mains du Jarl est déjà cassée et il est obligé de se défendre avec un saxon ordinaire, qui ne peut pas être comparé à un chevalier et demi. Une vague avec un poignard - pour l'armure du commandant, c'est comme un canif, mais elle passe à travers l'armure et ... il semble que la magie soit entrée en jeu - l'armure des chevaliers voisins est dispersée! Une autre vague, toujours sur la cible, et maintenant sur les flancs du flanc gauche, l'armure brille d'un coup. Le troisième coup - les chevaliers nagent devant leurs yeux, ils trébuchent, tombent et ne se lèvent plus.
"*** ** **** ****!" S'écria Petrovich, se réveillant lundi à 5 heures du matin dans une sueur froide. Tout a mal tourné: à 23 heures, il est monté sur Wikipedia à la recherche de documents pour le rapport de l'enfant sur la nature de la toundra, mais au moment de la nuit, il s'est retrouvé en quelque sorte sur la description de l'invasion des Vikings en Angleterre. Et aussi, le week-end, ils ont lancé la prochaine version, qui devrait commencer aujourd'hui. Comme toujours, nous l'avons testé pendant longtemps et minutieusement, l'avons conduit à travers des systèmes d'intégration continue un million de fois, que tout se passe bien ...
Heureusement pour certains, mais malheureusement pour les victimes, il y a toujours la possibilité d'apprendre des erreurs des autres, d'améliorer quelque chose à la maison et d'obtenir une part de confiance supplémentaire. Avec cet article traduit, nous voulons encore une fois, plus en détail, rappeler l'un des cas de "notre" industrie.
L'année dernière, lors de la conférence, j'ai parlé de DevOps, de la configuration en tant que code et de la livraison continue. En utilisant l'histoire ci-dessous, j'ai expliqué l'importance de créer des déploiements entièrement automatisés et reproductibles dans le cadre de l'initiative DevOps / Continuous Delivery. Après la conférence, plusieurs personnes m'ont demandé de partager une histoire sur un blog. C'est une histoire absolument vraie. Ceci est une nouvelle de ce que j'ai lu, je n'y ai pas participé moi-même.
Ainsi, l'histoire de la faillite d'une entreprise avec des actifs de près de 400 millions de dollars en 45 minutes en raison d'un déploiement infructueux.
Un peu de fond
Knight Capital Group («Knight» en anglais signifie «knight») est une société financière mondiale américaine engagée dans la tenue de marché, l'exécution électronique, les ventes institutionnelles et le trading. En 2012, Knight était le plus grand négociant en bourse américain avec une part de marché d'environ 17% sur le NYSE et le NASDAQ. Le groupe de négociation électronique de Knight (ETG) a géré un volume de négociation quotidien moyen de plus de 3,3 milliards de transactions par jour, échangeant plus de 21 milliards de dollars ... par jour. Ce n'est pas une blague!
Au 31 juillet 2012, Knight disposait d'environ 365 millions de dollars en trésorerie et équivalents de trésorerie.
Le 1er août 2012, le NYSE prévoyait de lancer un nouveau programme de liquidité de détail, le Retail Liquidity Program (un programme conçu pour améliorer les prix pour les investisseurs de détail par le biais de courtiers de détail tels que Knight). En préparation de cet événement, Knight a mis à jour son routeur algorithmique automatisé à haute vitesse SMARS, qui envoie des applications sur le marché pour exécution. L'une des principales fonctions de SMARS est de recevoir des applications d'autres composants de la plateforme de trading Knights (applications «parents»), puis d'envoyer une ou plusieurs applications «enfants» pour exécution. En d'autres termes, SMARS recevra des commandes importantes de la plateforme de trading et les divisera en plusieurs petites afin de trouver un acheteur / vendeur pour les stocks. Plus l'application parent est grande, plus les applications enfants seront créées.
La mise à jour SMARS était censée remplacer l'ancien code inutilisé appelé «Power Peg» - cette fonctionnalité que Knight n'avait pas utilisée depuis 8 ans (pourquoi le code qui était mort depuis si longtemps était toujours dans la base de code est un mystère, mais ce n'est pas le principal). Le code mis à jour a réaffecté l'ancien indicateur utilisé pour activer la fonctionnalité Power Peg. Le code a été soigneusement testé, a fonctionné correctement et était fiable. Qu'est-ce qui aurait pu mal tourner?
Qu'est-ce qui aurait pu mal tourner? Et vraiment!
Entre le 27 juillet 2012 et le 31 juillet 2012, Knight a déployé manuellement de nouveaux logiciels sur un nombre limité de serveurs par jour - un total de huit (8) serveurs. Voici ce que dit le
document de la
SEC sur le déploiement manuel (SEC est la Securities and Exchanges Commission, le régulateur américain des marchés boursiers).
«Lors du déploiement du nouveau code, l'un des employés de Knight n'a pas copié le nouveau code sur l'un des huit serveurs SMARS. Knight n'a pas effectué de deuxième examen technique de ce déploiement, de sorte que le code Power Peg n'a pas été supprimé du huitième serveur et que le nouveau code RLP n'a pas été ajouté. L'entreprise n'avait pas mis en place de procédures nécessitant un réexamen. » Communiqué n ° 70694, 16 octobre 2013
Le 1er août 2012 à 9 h 30 HNE, les marchés se sont ouverts et Knight a commencé à traiter les demandes des courtiers pour le compte de ses clients dans le cadre du nouveau programme de liquidité au détail. Sept (7) serveurs correctement déployés ont commencé à traiter correctement les demandes. Et ces applications qui sont allées au huitième serveur ont probablement activé le drapeau modifié et ressuscité Power Peg.
Zombie Attack: Killer Code
Ici, vous devez expliquer pourquoi le code Power Peg «mort» était nécessaire. Cette fonctionnalité était destinée à compter les actions achetées / vendues à la demande d'un parent à mesure que les commandes de l'enfant sont exécutées. Une fois l'application parent exécutée, Power Peg interdit la soumission d'applications enfants. En principe, Power Peg suivra les ordres enfants et arrêtera leur exécution après le traitement de la demande parent. En 2005, Knight a annulé cette fonctionnalité de suivi cumulatif à une étape antérieure de l'exécution du code (supprimant ainsi le suivi des quantités de Power Peg).
Lorsque l'indicateur Power Peg sur le huitième serveur a été activé, Power Peg a commencé à acheminer les ordres enfants pour exécution, mais ne les a pas corrélés avec le nombre de partages dans l'ordre parent - une sorte de boucle fermée est apparue
Infernal 45 minutes
Imaginez: vous avez un système qui peut envoyer des applications automatiques à haut débit sur le marché sans aucun suivi et la possibilité de voir si suffisamment d'applications ont été terminées. Oui, tout s'est avéré si mauvais.
Lorsque le marché a ouvert à 9h30, les gens ont rapidement réalisé que quelque chose n'allait pas. À 9 h 31, beaucoup à Wall Street avaient réalisé que quelque chose de grave se passait. Le marché a été inondé d'offres avec un volume d'échange inhabituel, par rapport à la situation normale, pour certaines actions. À 9 h 32 à Wall Street, ils se sont demandé pourquoi cette honte ne s'arrêtait pas. Presque pour toujours dans le trading à grande vitesse. Pourquoi quelqu'un n'a-t-il pas cliqué sur le bouton kill du système qui l'a fait? Il s'est avéré qu'il n'y avait pas d'interrupteur. Au cours des 45 premières minutes de négociation, l'exécution des transactions de Knight a représenté plus de 50% du volume des transactions, augmentant certaines actions de plus de 10% de leur valeur. En conséquence, d'autres actions ont perdu de la valeur en raison de transactions erronées.
Et pour aggraver les choses, le système Knight a commencé à envoyer des e-mails automatisés avant même ces événements - dès 8 h 01 (lorsque SMARS a traité des ordres adaptés à la négociation avant commercialisation). Dans les messages, le système fait référence à SMARS et affiche l'erreur «Power Peg is not available». Entre 8 h 01 et 9 h 30, 97 lettres ont été envoyées aux employés de Knight. Bien sûr, ces lettres ne ressemblaient pas à des avertissements système, donc personne ne les a regardées tout de suite. Ouch.
Pendant 45 minutes infernales, Knight a essayé d'arrêter la transaction erronée. Il n'a pas été possible de désactiver le système (car il n'y avait pas de procédures documentées pour répondre à une telle situation), par conséquent, essayant de résoudre le problème dans des conditions de trading en direct, ils sont restés sur le marché, où 8 millions d'actions ont été vendues chaque minute. Étant donné que les employés de l'entreprise n'ont pas pu déterminer d'où provenaient les applications erronées, ils ont supprimé le nouveau code des serveurs sur lesquels il était correctement déployé. En d'autres termes, ils ont supprimé le code de travail et l'ont laissé en panne. Cela n'a fait qu'exacerber les problèmes entraînant des demandes parentales supplémentaires pour activer le code Power Peg sur tous les serveurs, et pas seulement là où le code a été déployé à l'origine de manière incorrecte. Au final, j'ai réussi à arrêter le système - après 45 minutes de trading.
Pendant que la négociation était en cours, le code Power Peg a reçu et traité 212 demandes parentales. En conséquence, SMARS a envoyé des millions de filiales sur le marché, réalisé 4 millions de transactions en 154 transactions avec plus de 397 millions d'actions. Pour les connaisseurs des marchés boursiers, cela signifiait que Knight avait acheté des actions de 80 sociétés différentes pour 3,5 milliards de dollars et vendu des actions de 74 sociétés pour 3,15 milliards de dollars. Du point de vue des non-professionnels, le Knight Capital Group a perdu 460 millions de dollars en 45 minutes. Mais Knight n'a que 365 millions de dollars en espèces et quasi-espèces. En 45 minutes, Knight est passé du plus grand trader des actions américaines et du principal market maker du NYSE et du NASDAQ à la faillite. Ils ont eu 48 heures pour encaisser le montant nécessaire pour couvrir les pertes (ce qu'ils ont pu faire grâce à un investissement de 400 millions de dollars d'une demi-douzaine d'investisseurs). En fin de compte, le Knight Capital Group a été acquis par Getco LLC (en décembre 2012), et maintenant la société issue du regroupement s'appelle KCG Holdings.
Quelles conclusions devez-vous tirer
Les événements du 1er août 2012 devraient être une leçon pour toutes les équipes de développement et les équipes de projet. Il ne suffit pas de créer un excellent logiciel et de le tester; Vous devez également vous assurer qu'il est correctement livré sur le marché afin que vos clients reçoivent exactement la valeur que vous fournissez (et que vous ne mettiez pas votre entreprise en faillite). Le ou les ingénieurs qui ont déployé SMARS ne sont pas seulement responsables du fait que la procédure suivie à Knight n'a pas pris en compte les risques. La procédure (ou son absence) était manifestement erronée. Chaque fois que le processus de déploiement dépend de la façon dont les gens lisent et suivent les instructions, vous vous mettez en danger. Les gens font des erreurs. Les erreurs peuvent être dans les instructions, dans l'interprétation des instructions ou dans leur mise en œuvre.
La mise en page doit être automatisée, reproductible et aussi exempte d'erreurs humaines possibles que possible. Si Knight avait mis en œuvre un système de déploiement automatisé - un ensemble de configuration, de déploiement automatique et de tests - alors l'erreur qui s'est transformée en cauchemar de Knight aurait pu être évitée.
Voici quelques principes de livraison continue (même si vous n'implémentez pas le processus complet de livraison continue):
- La sortie du logiciel doit être un processus reproductible et fiable.
- Automatisez tout ce que vous pouvez.