45 minutos y 440 millones: el despliegue de Knight Capital
El 1 de agosto de 2012, Knight Capital desplegó código nuevo en siete de sus ocho servidores y despertó por accidente un programa de pruebas retirado en 2003. En cuarenta y cinco minutos perdió más de lo que valía la empresa.
Hoy, 1 de agosto, se cumplen años del despliegue más caro de la historia del software.
El 1 de agosto de 2012, a las 9:30 de la mañana en Nueva York, sonó la campana de apertura del NYSE. Cuarenta y cinco minutos después, Knight Capital —uno de los mayores creadores de mercado de Estados Unidos— había acumulado unos 7.000 millones de dólares en posiciones que nadie quería, repartidos entre 154 valores, y una pérdida antes de impuestos de unos 440 millones de dólares.
Para dar la escala: era más que la capitalización de la propia empresa. En cuarenta y cinco minutos, un programa gastó la compañía entera y siguió gastando.
No hubo intrusión, ni sabotaje, ni un algoritmo demasiado listo. Hubo un despliegue.
Un servidor de ocho
Ese día entraba en funcionamiento un programa nuevo del NYSE, el Retail Liquidity Program. Knight tenía que adaptar su sistema de enrutado de órdenes, así que preparó código nuevo y lo desplegó en sus servidores de producción.
A mano. Servidor por servidor. Eran ocho.
En siete quedó el código nuevo. En el octavo, no.
Aquí está el detalle que convierte un error de despliegue rutinario en una catástrofe: para activar la funcionalidad nueva, los desarrolladores reutilizaron una bandera de configuración que ya existía. Una que en su día encendía otra cosa.
El muerto que seguía en el sótano
Esa otra cosa se llamaba Power Peg. Era código de pruebas de principios de los 2000, retirado del uso en 2003. Retirado, no borrado: siguió ahí, en el repositorio y en los servidores, durante nueve años, esperando que alguien levantara su bandera.
Y Power Peg hacía exactamente lo que hace un programa de pruebas: comprar caro y vender barato a toda velocidad, sin ánimo de ganar dinero, solo para generar movimiento. En 2005, además, alguien había movido a otro sitio el contador que limitaba cuántas órdenes podía llegar a lanzar. Nadie lo comprobó, porque el código estaba muerto.
Así que en aquel octavo servidor, la bandera nueva encendió al muerto. Y el muerto se puso a comprar caro y vender barato con dinero real, contra el mercado real, sin límite acumulado.
El código muerto no existe. Existe el código dormido. Y sobrevive por la misma razón por la que sobrevive todo lo demás que no se toca: porque nadie tiene asignado el trabajo aburrido de quitarlo.
El rollback que multiplicó el incendio
Los cuarenta y cinco minutos siguientes son la parte que de verdad conviene leer despacio, porque es la parte que se repite en incidentes mucho más pequeños que este.
El equipo detectó que algo iba muy mal. Identificó el despliegue de esa mañana como la causa. Y tomó la decisión que parece obvia y es la correcta el 95 % de las veces: revertir el cambio.
Revirtieron el código nuevo en los siete servidores donde sí se había instalado.
Con lo cual los ocho pasaron a tener el código viejo. Y la bandera seguía levantada. Y ahora eran ocho servidores ejecutando Power Peg en lugar de uno.
Deshacer sin entender no es deshacer: es apostar. Salió mal.
Los 97 correos que nadie leyó
Antes de la apertura, el sistema había enviado 97 correos electrónicos a personal técnico avisando de errores en el enrutado de órdenes.
No eran alertas. Eran correos informativos, del mismo tipo que ese sistema mandaba todos los días. Se mezclaron con el resto del ruido de una mañana normal y nadie los miró con la atención de una alarma, porque nada los distinguía de una alarma que no lo era.
Esto que te suena:
- El canal de Slack donde el bot escupe cada excepción y que todo el mundo tiene silenciado.
- Los 400 correos de «cron completado correctamente» entre los que vive un «cron completado con errores».
- El panel con doce indicadores en ámbar que llevan ocho meses en ámbar.
- La alerta de disco al 90 % que se ignora porque el 90 % «es lo normal en ese servidor».
Un aviso que se emite siempre no informa de nada. Solo genera la sensación de estar vigilando. Pregúntale a cualquiera que haya estado de guardia cuántas de las alertas que le despertaron el año pasado exigían despertarse.
Lo que no había: un interruptor
Cuarenta y cinco minutos es muchísimo tiempo. Es tiempo de sobra para apagar algo. La pregunta incómoda es por qué no se apagó antes, y la respuesta es que nadie sabía qué apagar ni tenía la autoridad para hacerlo sin consultar.
No existía un botón que dijera «deja de mandar órdenes al mercado». Existía una arquitectura donde parar significaba decidir qué componente concreto matar, en qué orden, y asumir personalmente las consecuencias de haberlo parado sin permiso.
En una emergencia, el coste de equivocarse parando tiene que ser muy inferior al coste de no parar. Si no lo es, tu sistema no tiene freno: tiene un debate.
La factura
Knight Capital sobrevivió unos días. El 6 de agosto aceptó un rescate de 400 millones que diluyó a los accionistas hasta casi hacerlos desaparecer, y a finales de 2013 la compañía había sido absorbida. En 2013 la SEC le impuso además una multa de 12 millones de dólares por incumplir la norma de acceso al mercado: no tener controles de riesgo previos al envío de órdenes.
Lo llamativo del expediente no es la cifra. Es que ninguno de los fallos que lo provocaron requería un experto para verlo. Requerían tiempo, y el tiempo se había ido a otra parte.
Cuatro cosas que puedes mirar hoy
- Busca tu Power Peg. Un
grepde las banderas de configuración de tu aplicación y una pregunta por cada una: ¿qué enciende esto exactamente, y cuándo fue la última vez que estuvo encendida? Lo que lleve más de dos años apagado se borra, no se documenta. - Cuenta los pasos manuales de tu despliegue. Si el número es mayor que uno, ese es el número de sitios donde puedes desplegar en siete de ocho. La automatización no es elegancia: es la única forma de que todos los nodos acaben iguales.
- Averigua quién puede parar la producción sin pedir permiso. Si la respuesta tarda en llegar o incluye la palabra «depende», ya tienes el trabajo de esta semana.
- Cuenta las alertas de la última semana y cuántas provocaron una acción. Si la proporción es mala, el problema no es que falten alertas: es que sobran. Borra alertas hasta que quedarte mirando el panel signifique algo.
Y una regla general que sale gratis: una bandera de configuración nunca se recicla. Se crea una nueva. Los nombres son baratos; los cuarenta y cinco minutos de Knight Capital no.
(La próxima vez que alguien diga «total, es solo copiar el fichero en producción», recuerda que eso es exactamente lo que se hizo ese día, y que salió bien en siete de cada ocho intentos.)
Preguntas frecuentes
¿Qué ocurrió exactamente en Knight Capital el 1 de agosto de 2012?
Durante los primeros cuarenta y cinco minutos de la sesión bursátil, el sistema de enrutado de órdenes de la firma envió al mercado un volumen masivo de operaciones erróneas, acumulando alrededor de 7.000 millones de dólares en posiciones no deseadas sobre 154 valores. El cierre de esas posiciones se saldó con una pérdida antes de impuestos próxima a los 440 millones de dólares, una cifra superior a la capitalización bursátil de la propia compañía en aquel momento.
¿Cuál fue la causa técnica del incidente?
El despliegue manual de un componente nuevo se completó en siete de los ocho servidores de producción. La funcionalidad se activaba mediante una bandera de configuración que había sido utilizada años antes para habilitar Power Peg, un módulo de pruebas retirado del uso en 2003 pero nunca eliminado del sistema. En el servidor que no recibió el código nuevo, esa bandera activó el módulo antiguo, que generaba órdenes de compra y venta sin límite acumulado porque su contador de control había sido desplazado en 2005.
¿Por qué empeoró la situación al revertir el despliegue?
El equipo identificó el despliegue de esa mañana como causa probable y deshizo el cambio en los siete servidores donde sí se había instalado. Al hacerlo, los ocho servidores quedaron ejecutando la versión anterior del código mientras la bandera de configuración seguía activada, de modo que el módulo obsoleto pasó a ejecutarse en toda la granja en lugar de en una sola máquina. Es un ejemplo de reversión aplicada antes de comprender el mecanismo del fallo.
¿Qué es la fatiga de alertas y cómo influyó en este caso?
La fatiga de alertas es la pérdida de capacidad de reacción que se produce cuando un sistema emite avisos de forma tan frecuente o indiscriminada que dejan de percibirse como excepcionales. Antes de la apertura del mercado se enviaron 97 correos electrónicos señalando errores en el enrutado de órdenes, pero tenían el mismo formato y el mismo canal que las notificaciones informativas rutinarias, por lo que no se distinguieron del ruido habitual.
¿Qué medidas evitan un fallo de este tipo en sistemas más pequeños?
Las principales son cuatro: eliminar físicamente el código que deja de utilizarse en lugar de limitarse a desactivarlo, no reutilizar jamás una bandera de configuración para una funcionalidad distinta de la original, automatizar el despliegue de forma que todos los nodos queden en un estado verificable e idéntico, y disponer de un procedimiento de parada de emergencia que cualquier persona de guardia pueda ejecutar sin autorización previa. A ello se añade revisar periódicamente las alertas para que solo se emitan aquellas que exigen una acción.
El blog, día a día
¿Te ha resultado útil o quieres comentar algo?
Hablemos →