Knightmare: una historia de advertencia de DevOps (2014)

• Un artículo sobre la aleccionadora historia de una importante empresa global de servicios financieros, Knight Capital Group, que quebró en 45 minutos debido a un despliegue de software fallido.
• En 2012, Knight Capital Group era el mayor operador de acciones de EE. UU., con un volumen promedio diario de más de 3.3 mil millones de operaciones y más de 21 mil millones de dólares negociados cada día.
• La empresa actualizó SMARS, un router algorítmico automatizado de alta velocidad, mientras se preparaba para el lanzamiento del nuevo Retail Liquidity Program de la NYSE.
• Esta actualización buscaba reemplazar código antiguo sin uso llamado "Power Peg", que Knight no había utilizado durante 8 años.
• El nuevo código se desplegó manualmente en 8 servidores, pero por un error del técnico, el nuevo código no se copió en uno de ellos y se activó el antiguo código de Power Peg.
• La función Power Peg empezó a enrutar para ejecutar órdenes hijas sin rastrear la cantidad de acciones de las órdenes padre, lo que provocó un bucle infinito de órdenes.
• Cuando abrió el mercado, el sistema de Knight inundó el mercado con órdenes; algunas acciones subieron más del 10% de su valor y otras cayeron al reaccionar a operaciones erróneas.
• El sistema de Knight envió 97 correos electrónicos automáticos que hacían referencia a SMARS e identificaban el error como "Power Peg disabled", pero no estaban diseñados como alertas del sistema y no se revisaron de inmediato.
• Durante los primeros 45 minutos de negociación, el código Power Peg procesó 212 órdenes padre y 4 millones de operaciones sobre 154 acciones, manejando más de 397 millones de acciones.
• Knight Capital Group perdió 460 millones de dólares en 45 minutos, lo que la llevó a la quiebra. Reunieron el capital necesario para cubrir las pérdidas mediante una inversión de 400 millones de dólares de media docena de inversionistas.
• El artículo enfatiza la importancia de hacer que los despliegues sean completamente automatizados y repetibles para evitar fallas de esta magnitud, como parte de una estrategia de DevOps/Continuous Delivery.
• El autor sugiere que los lanzamientos de software deben ser un proceso repetible y confiable, y automatizarse tanto como sea posible para reducir el riesgo de error humano.

[GN⁺]

Opiniones de Hacker News

• Es posible que el despliegue automatizado no haya evitado el problema, e incluso podría haberlo agravado debido a código incompatible.
• Los sistemas automatizados de trading deben contar con un kill switch integrado, y este debe probarse regularmente para garantizar que funcione.
• Es posible que el sistema de despliegue continuo no hubiera bloqueado este bug, un error lógico que derivó en una falla catastrófica.
• La expresión "hacer un Knight Capital" es conocida en las finanzas cuantitativas para describir cuando se recortan esquinas en sistemas importantes y luego se enfrentan las consecuencias.
• El trading de alta frecuencia es un ejemplo extremo de lo rápido que algo puede salir mal.
• En sistemas que manejan grandes volúmenes de ventas, es importante contar con procesos manuales, pasos de rollback y feature flags para mitigar el riesgo.
• El incidente de Knight Capital fue resultado de ignorar un sistema automático de SCRAM que detenía todas las operaciones o alertaba para intervención manual.
• Que haya existido código muerto en la base de código durante 8 años representa un riesgo y muestra falta de mantenimiento activo.
• Si la configuración y los binarios se hubieran desplegado al mismo tiempo, este tipo de problema podría haberse evitado.
• Reutilizar flags antiguos fue un error importante y subraya la importancia de aplicar prácticas adecuadas en los despliegues.