45 minutos, USD 460 millones: cuando falta gobernanza de tecnología

Gobernanza tiene fama de burocracia: comité, política, documento que nadie lee. Pero cuando miro los desastres de tecnología que de verdad acabaron con empresas, casi nunca encuentro un bug genial. Encuentro un control simple que nadie tenía.

Dos casos explican esto mejor que cualquier presentación sobre riesgo.

Knight Capital: 45 minutos, USD 460 millones

El 1 de agosto de 2012, Knight Capital era una de las mayores corredoras electrónicas de Estados Unidos. Para participar en un programa nuevo de la bolsa de Nueva York, necesitaba actualizar el router de órdenes en ocho servidores.

Siete recibieron el código nuevo. Uno no lo recibió.

El detalle que convierte un error de deploy en una quiebra: el equipo había reutilizado un flag que, años antes, activaba un sistema llamado Power Peg — un código en desuso desde 2003, que nunca se eliminó. En el servidor olvidado, el flag volvió a activar ese código muerto.

En los primeros 45 minutos de negociación, el router disparó más de 4 millones de órdenes intentando ejecutar 212 órdenes de clientes. Se negociaron 397 millones de acciones y una pérdida de aproximadamente USD 460 millones.

Dos detalles duelen más que la pérdida:

• Las alertas existían. Antes de la apertura del mercado, un sistema interno había disparado 97 correos automáticos señalando el problema. Nadie actuó.
• La reacción empeoró la situación. Los técnicos desinstalaron el código nuevo de los siete servidores que lo habían recibido. Las órdenes erróneas siguieron saliendo.

La SEC concluyó que la empresa no tenía controles adecuados, incluida una revisión de código obligatoria y un proceso definido de deploy. Knight solo sobrevivió esa semana gracias a una inyección de capital de emergencia. Menos de un año después, fue vendida en una fusión y dejó de existir como empresa independiente.

Code Spaces: 12 horas

En junio de 2014, Code Spaces alojaba repositorios Git y SVN y herramientas de gestión de proyectos. Tenía backup. Tenía incluso lo que llamaba backup externo.

Un atacante consiguió acceso al panel de AWS de la empresa, inició un ataque de denegación de servicio y exigió un pago. Cuando Code Spaces intentó recuperar el control de la cuenta, el atacante borró todo lo que alcanzó: snapshots, buckets, imágenes de máquina e instancias. En palabras de la propia empresa, "la mayor parte de nuestros datos, backups, configuraciones de máquina y backups externos".

El problema no era no tener backup. Era que el backup vivía dentro de la misma cuenta que controlaba el atacante.

Ese mismo día, el comunicado en el sitio decía que la empresa no estaría en condiciones de seguir operando. Una empresa entera cerrada en horas, porque una credencial daba acceso a todo — incluida la copia de seguridad.

El patrón detrás de los dos

Décadas distintas, sectores distintos, tecnologías distintas. El patrón es el mismo:

• Proceso que depende de que alguien se acuerde. Copiar un archivo a ocho servidores a mano funciona hasta el día en que deja de funcionar.
• Control que nunca se probó. Un backup que nadie ha restaurado es esperanza, no es control. Un rollback que nadie ha ensayado, también.
• Alerta sin dueño. 97 correos no son una alerta, son ruido. Una alerta es lo que llega a una persona específica con una acción definida.
• Poder concentrado. Una credencial que borra la producción y el backup juntos no es comodidad, es riesgo existencial.
• Código muerto que se quedó. Lo que no se elimina sigue siendo ejecutable, y un día alguien reutiliza la llave que lo activa.

Ninguno de estos puntos es una decisión técnica difícil. Todos son decisiones de gobernanza: quién decide, quién revisa, quién es el dueño, cada cuánto se prueba.

El mínimo de gobernanza que evita los dos

Si tu empresa opera software en producción, este es el piso mínimo. Cada punto está ligado al desastre que habría evitado.

1. Deploy automatizado e igual en todas partes. Ningún servidor se actualiza a mano, y el deploy termina confirmando que todos están en la misma versión.
2. Sin código muerto, sin flags reutilizados. Eliminar forma parte de la tarea. Un interruptor de apagado tiene nombre propio y hace una sola cosa.
3. Rollback ensayado. Antes de la ventana de deploy, alguien ejecuta el rollback en un ambiente igual. "Si sale mal, revertimos" no es un plan.
4. Toda alerta tiene dueño y acción. Si nadie va a actuar a las seis de la mañana, esa alerta no debería existir. Lo que quede tiene que llegar a una persona, no a una bandeja de entrada.
5. Acceso mínimo y separado. MFA obligatorio, credenciales de producción separadas de las de desarrollo, y nadie capaz de borrar todo en solitario.
6. Backup fuera de alcance. Otra cuenta, otro proveedor o almacenamiento inmutable, con retención definida — y restore probado en el calendario, no en la emergencia.
7. Dueño por sistema y runbook de incidentes. ¿Quién decide detener? ¿Cómo se detiene? Por escrito, antes del incidente.

La prueba de restore es lo más fácil de automatizar y lo más caro de no tener:

# .github/workflows/restore-test.yml — corre todos los lunes y falla alto
name: restore-test
on:
  schedule:
    - cron: "0 6 * * 1"
jobs:
  restore:
    runs-on: ubuntu-latest
    steps:
      - name: Restaurar el backup más reciente en una base de datos descartable
        run: ./scripts/restore-latest.sh --target ephemeral
      - name: Verificar invariantes del negocio (conteos, saldos, integridad)
        run: ./scripts/check-invariants.sh

El valor no está en el archivo. Está en tener, cada semana, una respuesta objetiva a la pregunta más cara que existe: ¿sirve el backup de ayer?

Qué tiene que ver esto con tu empresa

Ninguna de las dos era amateur. Knight movía miles de millones al día. Code Spaces vendía infraestructura a equipos de desarrollo. Las dos tenían buena gente. Lo que faltó fue acordar, por escrito y antes del incidente, quién decide qué y qué se prueba con qué frecuencia.

La gobernanza de tecnología no es lo que impide que el equipo trabaje. Es lo que hace que la empresa sobreviva a su peor día. Implementar los siete puntos de arriba cuesta algunas semanas de trabajo. No tenerlos costó, en estos dos casos, la empresa entera.

Lectura complementaria

• Los siete puntos de arriba se vuelven trabajo en Ingeniería de Plataforma: pipeline, observabilidad, runbook y prueba de restore en el calendario.
• Del otro lado de la misma moneda, un número que casi nadie calcula: el número más incómodo de tu base de clientes.

Fuentes

• Orden administrativa de la SEC contra Knight Capital Americas (16 de octubre de 2013) y el comunicado de la SEC sobre el caso.
• Reportaje de The Register sobre el fin de Code Spaces (18 de junio de 2014).