Cuando un bug te cuesta $440 millones en 45 minutos: el caso de Knight Capital
- Juan de Jesús Fernández Graciano
- 3 jul
- 2 Min. de lectura
¿Qué es Knight Capital y por qué deberías importar?
Antes de los detalles, es importante saber que es Knight Capital Group. Knight Capital Group era (sí, en pasado) una de las firmas de trading más grandes de Estados Unidos. Su negocio consistía en comprar y vender acciones automáticamente usando algoritmos que operaban a muy rápido.
Pero un día, una línea de código mal probada hizo estragos en la empresa.
El desastre: todo por una actualización
El 1 de agosto de 2012, Knight Capital lanzó una nueva versión de su software de trading. Querían usar una nueva funcionalidad llamada “Retail Liquidity Program” (RLP), que les permitiría competir mejor en el mercado.
Pero uno de los desarrolladores reactivó por error un código viejo que ya no se usaba, conocido como el “Power Peg”.
Este viejo módulo fue diseñado para pruebas, pero no estaba pensado para producción. ¿El resultado? Durante 45 minutos, el sistema compró y vendió acciones sin lógica alguna, causando caos en la bolsa.
El costo del error
$440 millones de pérdida en menos de una hora.
El precio de muchas acciones se volvió loco sin explicación aparente.
La empresa casi se va a la quiebra ese mismo día.
Knight Capital tuvo que ser "rescatada" por otros bancos… y terminó vendida meses después.
¿Qué falló exactamente?
No se probó el despliegue completo: El nuevo código solo se desplegó correctamente en 7 de los 8 servidores.
No hubo pruebas de integración completas antes de producción.
Sin rollback automatizado: Una vez que el sistema comenzó a actuar mal, no pudieron detenerlo fácilmente.
Presión por salir rápido: El enfoque era "entreguemos ya", sin pensar en el costo de fallar.
¿Cómo se resolvió (o al menos lo intentaron)?
Knight intentó frenar el proceso manualmente. Pero ya era muy tarde. La solución vino en forma de una inyección de capital externo (básicamente: rescate financiero). Sin embargo, la reputación de la empresa nunca se recuperó y fue adquirida por otra firma poco después.
Lecciones para testers, devs y líderes de producto
El testing no es un lujo, es un seguro de vida.
Las estrategias de deployment canary releases pueden evitar estos desastres.
Rollback automatizado y monitoreo activo son primordiales a la hora de devolver un cambio innesperado en producción.
Nunca, NUNCA, dejes un feature de pruebas activado en producción. Haz un doble check SIEMPRE.
Comments