1066, han pasado más de 200 años desde el comienzo de la invasión vikinga de Inglaterra. El rey Harold, reuniendo un destacamento de caballeros, marchó hacia el río Derwent para una batalla decisiva con las tropas de su homónimo: el rey noruego Harald. Los armeros trabajaron durante un mes para forjar suficiente armadura de nueva generación que pudiera proteger al caballero de ser golpeado por un hacha escandinava. ¡Y cuántos experimentos y pruebas en torneos habían tenido antes! Pero se suponía que la expectativa se justificaba a sí misma: un equipo liviano pero confiable permitía incluso a pie, sin grandes pérdidas, barrer el vikingo. Y finalmente, se encontraron en Stamford Bridge. El destacamento principal de caballeros, dirigido por un comandante con una armadura brillante, chocó en medio de un puente con enemigos. Sí, el acero de los maestros podgorny tiene el golpe!
Lento pero seguro, los vikingos se están moviendo a una defensa de todos contra todos. La victoria parece estar cerca. Y finalmente, en el campo de batalla, el comandante caballero y el jarl noruego se encuentran.
El hacha de dos manos de Jarl ya está rota y se ve obligado a defenderse con un sajón común, que no se puede comparar con un caballero y media espada. Una ola con una daga: para la armadura del comandante es como una navaja, pero atraviesa la armadura y ... parece que la magia ha entrado en juego: ¡la armadura de los caballeros vecinos está dispersa! Otra ola, otra vez en el blanco, y ahora en los caballeros del flanco izquierdo, la armadura de repente brilla al rojo vivo. El tercer golpe: los caballeros nadan ante sus ojos, tropiezan, caen y nunca más se levantan.
"*** ** **** ****!" Gritó Petrovich, despertando a las 5 de la mañana del lunes sudando frío. Todo salió completamente mal: a las 11 de la noche se subió a Wikipedia en busca de materiales para el informe del niño sobre la naturaleza de la tundra, pero a la hora de la noche de alguna manera se encontró con la descripción de la invasión vikinga de Inglaterra. Y también, el fin de semana pusieron en la batalla el próximo lanzamiento, que debería comenzar hoy. Como siempre, lo probamos durante mucho tiempo y a fondo, lo manejamos a través de sistemas de integración continua un millón de veces, ya sea que todo salga bien ...
Afortunadamente para algunos, pero desafortunadamente para las víctimas, siempre existe la oportunidad de aprender de los errores de los demás, mejorar algo en casa y obtener una porción extra de confianza. Con este artículo traducido, queremos recordar una vez más, con más detalle, uno de los casos en "nuestra" industria.
El año pasado en la conferencia hablé sobre DevOps, la configuración como código y la entrega continua. Usando la siguiente historia, expliqué la importancia de crear implementaciones totalmente automatizadas y reproducibles como parte de la iniciativa DevOps / Continuous Delivery. Después de la conferencia, varias personas me pidieron que compartiera una historia en un blog. Esta es una historia absolutamente verdadera. Esto es un recuento de lo que leí, yo mismo no participé en esto.
Entonces, la historia de cómo una empresa con activos de casi $ 400 millones quebró en 45 minutos debido a un despliegue fallido.
Un poco de historia
Knight Capital Group ("Knight" en inglés significa "caballero") es una compañía financiera global estadounidense dedicada a la creación de mercado, la ejecución electrónica, las ventas institucionales y el comercio. En 2012, Knight fue el mayor operador bursátil de EE. UU. Con una participación de mercado de aproximadamente el 17% en NYSE y NASDAQ. Knight's Electronic Trading Group (ETG) gestionó un volumen de negociación diario promedio de más de 3,3 mil millones de transacciones por día, negociando más de $ 21 mil millones ... por día. ¡Esto no es una broma!
Al 31 de julio de 2012, Knight tenía aproximadamente $ 365 millones en efectivo y equivalentes de efectivo.
El 1 de agosto de 2012, la NYSE planeó lanzar un nuevo programa de liquidez minorista, el Programa de liquidez minorista (un programa diseñado para mejorar los precios para los inversores minoristas a través de corredores minoristas como Knight). En preparación para este evento, Knight actualizó su enrutador algorítmico automatizado de alta velocidad SMARS, que envía las aplicaciones al mercado para su ejecución. Una de las funciones principales de SMARS es recibir aplicaciones de otros componentes de la plataforma de negociación de Knights (aplicaciones "principales"), seguidas de enviar una o más aplicaciones "secundarias" para su ejecución. En otras palabras, SMARS recibirá grandes pedidos de la plataforma de negociación y los dividirá en varios pequeños para encontrar un comprador / vendedor de acciones. Cuanto más grande sea la aplicación principal, se crearán más aplicaciones secundarias.
Se suponía que la actualización SMARS reemplazaría el antiguo código no utilizado llamado "Power Peg", esta funcionalidad que Knight no había utilizado durante 8 años (por qué el código que estuvo muerto durante tanto tiempo todavía estaba en la base del código es un misterio, pero esto no es lo principal). El código actualizado reasignó la antigua bandera que se utilizó para activar la funcionalidad de Power Peg. El código fue probado exhaustivamente, funcionó correctamente y fue confiable. ¿Qué pudo haber salido mal?
¿Qué pudo haber salido mal? Y de verdad!
Entre el 27 de julio de 2012 y el 31 de julio de 2012, Knight implementó manualmente un nuevo software en un número limitado de servidores por día, un total de ocho (8) servidores. Esto es lo
que dice el
documento de la
SEC sobre el despliegue manual (SEC es la Comisión de Valores e Intercambios, el regulador del mercado de valores estadounidense).
“Durante el despliegue del nuevo código, uno de los empleados de Knight no copió el nuevo código en uno de los ocho servidores SMARS. Knight no realizó una segunda revisión técnica de esta implementación, por lo que el código Power Peg no se eliminó del octavo servidor y no se agregó el nuevo código RLP. La compañía no tenía procedimientos establecidos que requerían un nuevo examen ". Release No. 70694, 16 de octubre de 2013
El 1 de agosto de 2012 a las 9:30 a.m. EST, se abrieron los mercados y Knight comenzó a procesar las solicitudes de los corredores de bolsa en nombre de sus clientes en el nuevo Programa de Liquidez Minorista. Siete (7) servidores que se implementaron correctamente comenzaron a procesar las aplicaciones correctamente. Y esas aplicaciones que fueron al octavo servidor probablemente activaron la bandera cambiada y resucitaron Power Peg.
Ataque zombi: código asesino
Aquí debe explicar por qué se necesitaba el código Power Peg "muerto". Esta funcionalidad estaba destinada a contar acciones compradas / vendidas a pedido de un padre a medida que se completan los pedidos del niño. Después de ejecutar la aplicación principal, Power Peg prohíbe el envío de aplicaciones secundarias. En principio, Power Peg rastreará las órdenes secundarias y detendrá su ejecución después del procesamiento de la solicitud principal. En 2005, Knight retiró esta funcionalidad de seguimiento acumulativo a una etapa anterior de ejecución del código (eliminando así el seguimiento de cantidad de Power Peg).
Cuando se activó el indicador de Power Peg en el octavo servidor, Power Peg comenzó a enrutar las órdenes secundarias para su ejecución, pero no las correlacionó con el número de acciones en la orden principal; surgió una especie de circuito cerrado
Infernal 45 minutos
Imagínese: tiene un sistema que puede enviar aplicaciones automáticas de alta velocidad al mercado sin ningún seguimiento y la capacidad de ver si se han completado suficientes aplicaciones. Sí, todo salió tan mal.
Cuando el mercado abrió a las 9:30 a.m., la gente rápidamente se dio cuenta de que algo andaba mal. A las 9:31 a.m., muchos en Wall Street se habían dado cuenta de que algo grave estaba sucediendo. El mercado se inundó de ofertas con un volumen de negociación inusual, en comparación con la situación normal, para ciertas acciones. A las 9:32 en Wall Street, se preguntaban por qué esta desgracia no se detiene. Casi para siempre en el comercio de alta velocidad. ¿Por qué alguien no hizo clic en el botón de matar en el sistema que lo hizo? Al final resultó que, no había interruptor. Durante los primeros 45 minutos de negociación, la ejecución de transacciones de Knight ascendió a más del 50% del volumen de negociación, elevando ciertas acciones en más del 10% de su valor. Como resultado, otras acciones cayeron en valor debido a transacciones erróneas.
Y para empeorar las cosas, el sistema Knight comenzó a enviar correos electrónicos automáticos incluso antes de estos eventos, ya a las 8:01 a.m. (cuando SMARS procesó los pedidos adecuados para el comercio previo a la comercialización). En los mensajes, el sistema hizo referencia a SMARS y mostró el error "Power Peg no está disponible". Entre las 8:01 a.m. y las 9:30 a.m., se enviaron 97 cartas a los empleados de Knight. Por supuesto, estas cartas no parecían advertencias del sistema, por lo que nadie las miró de inmediato. Ouch
Durante 45 minutos infernales, Knight intentó detener la transacción errónea. No fue posible apagar el sistema (ya que no había procedimientos documentados para responder a tal situación), por lo tanto, tratando de lidiar con el problema en condiciones comerciales en vivo, permanecieron en el mercado, donde se vendieron 8 millones de acciones por minuto. Como los empleados de la compañía no podían determinar de dónde provenían las aplicaciones erróneas, eliminaron el nuevo código de los servidores donde se implementó correctamente. En otras palabras, eliminaron el código de trabajo y lo dejaron roto. Esto solo exacerbó los problemas que causaron solicitudes parentales adicionales para activar el código Power Peg en todos los servidores, y no solo donde el código se implementó originalmente de forma incorrecta. Al final, logré detener el sistema, después de 45 minutos de negociación.
Mientras se negociaba, el código Power Peg recibió y procesó 212 solicitudes de los padres. Como resultado, SMARS envió millones de subsidiarias al mercado, completó 4 millones de transacciones en 154 transacciones con más de 397 millones de acciones. Para los entendidos del mercado de valores, esto significó que Knight compró acciones de 80 compañías diferentes por $ 3.5 mil millones y vendió acciones de 74 compañías por $ 3.15 mil millones. Desde el punto de vista de los no profesionales, Knight Capital Group perdió $ 460 millones en 45 minutos. Pero Knight solo tiene $ 365 millones en efectivo y equivalentes de efectivo. En 45 minutos, Knight se ha transformado del mayor comerciante de acciones estadounidenses y un importante creador de mercado en NYSE y NASDAQ en bancarrota. Tenían 48 horas para recaudar la cantidad necesaria para cubrir las pérdidas (lo que pudieron hacer gracias a una inversión de $ 400 millones de aproximadamente media docena de inversores). Finalmente, el Grupo Knight Capital fue adquirido por Getco LLC (en diciembre de 2012), y ahora la compañía combinada se llama KCG Holdings.
¿Qué conclusiones necesitas sacar?
Los eventos del 1 de agosto de 2012 deberían ser una lección para todos los equipos de desarrollo y equipos de proyecto. No es suficiente crear un excelente software y probarlo; También debe asegurarse de que se entregue correctamente al mercado para que sus clientes reciban exactamente el valor que usted proporciona (y que no quiebre a su empresa). Los ingenieros que implementaron SMARS no solo tienen la culpa del hecho de que el procedimiento seguido en Knight no tuvo en cuenta los riesgos. El procedimiento (o su ausencia) fue obviamente erróneo. Cada vez que el proceso de implementación depende de cómo las personas leen y siguen las instrucciones, usted se pone en riesgo. La gente comete errores. Los errores pueden estar en las instrucciones, en la interpretación de las instrucciones o en su implementación.
El diseño debe ser automatizado, reproducible y lo más libre posible de posibles errores humanos. Si Knight hubiera implementado un sistema de implementación automatizado, un conjunto de configuración, implementación automática y pruebas, entonces el error que se convirtió en la pesadilla de Knight podría haberse evitado.
Aquí hay un par de principios de entrega continua (incluso si no implementa el proceso completo de entrega continua):
- El lanzamiento del software debe ser un proceso repetible y confiable.
- Automatiza todo lo que puedas.