Cuando el downtime no cuesta miles, sino millones de dólares
Cuando pensamos en downtime, generalmente pensamos en minutos perdidos, algunos usuarios frustrados, tal vez un par de ventas que no se cerraron. Molesto, sí. Costoso, también. Pero raramente pensamos en el verdadero costo del downtime a escala.
Hoy te cuento 5 casos reales donde el downtime no costó cientos o miles de dólares. Costó millones. En algunos casos, cientos de millones. Y en el caso más extremo, casi destruyó una empresa completa en menos de una hora.
Estas historias no son solo para aprender de los errores de los demás. Son recordatorios de que en el mundo digital, cada minuto cuenta. Y que el costo de no estar preparado puede ser devastador.
Era julio de 2018. Amazon había promocionado su Prime Day durante semanas. Millones de usuarios listos para comprar. Descuentos masivos. El evento de ventas más grande del año.
Durante 63 minutos, los usuarios de todo el mundo vieron lo mismo: una imagen de un perro con el mensaje "Uh oh! Something went wrong on our end."
El problema: Los servidores de Amazon no pudieron manejar el tráfico masivo que ellos mismos habían generado con su marketing.
Amazon perdió aproximadamente $1.6 millones por minuto
Amazon es literalmente una de las empresas más avanzadas tecnológicamente del mundo. Tienen AWS. Tienen los mejores ingenieros. Tienen recursos prácticamente ilimitados.
Y aun así, subestimaron su propio tráfico. La lección: load testing es crítico, especialmente antes de eventos importantes.
4 de octubre de 2021. 11:40 AM ET. De repente, Facebook desaparece de internet. Literalmente.
No solo el sitio web. No solo la app. La empresa completa. Facebook, Instagram, WhatsApp, Oculus. Todo offline. Durante 6 horas.
El problema: Un error en la configuración BGP (Border Gateway Protocol) hizo que los servidores de Facebook fueran "eliminados" de internet. Para el internet global, Facebook dejó de existir.
Lo peor: Los ingenieros no podían acceder a los edificios porque las tarjetas de acceso también estaban conectadas a los sistemas internos. Tuvieron que cortar físicamente candados para entrar a los data centers.
Zuckerberg perdió $6 mil millones en acciones ese día
El error no fue en el código. No fue un bug. No fue un ataque. Fue un error en configuración de infraestructura durante una actualización de rutina.
La lección: Los errores más peligrosos no son los obvios. Son los que pasan en sistemas críticos durante "mantenimiento de rutina".
27 de mayo de 2017. Feriado largo en UK. Miles de familias listas para viajar.
Un contratista en el data center de British Airways desconecta accidentalmente la alimentación eléctrica. Cuando la reconecta, el surge de energía daña sistemas críticos.
Resultado: Caos absoluto. British Airways tuvo que cancelar 726 vuelos en 3 días. 75,000 pasajeros varados en aeropuertos de todo el mundo.
British Airways había externalizado su TI para "reducir costos". En el proceso, eliminaron redundancias críticas.
Ahorraron millones en TI. Les costó cientos de millones cuando falló. El disaster recovery no es un gasto, es un seguro.
8 de agosto de 2016, 2:30 AM. Un problema eléctrico en el data center principal de Delta en Atlanta.
El switchover automático al sistema de backup... falla. Los sistemas críticos se apagan. Check-in, boarding, crew scheduling, todo offline.
Delta tuvo que cancelar 2,300 vuelos en 3 días. El CEO tuvo que pedir disculpas públicamente.
Delta TENÍA sistemas de backup. Delta TENÍA redundancia. Delta HABÍA invertido en disaster recovery.
Pero nunca testearon adecuadamente el switchover. Cuando lo necesitaron de verdad, no funcionó. Un disaster recovery plan que no se testea es un disaster recovery plan que no existe.
1 de agosto de 2012, 9:30 AM. Knight Capital, una firma de trading, despliega nuevo software a producción.
Hay un problema: El código nuevo reactiva accidentalmente una función vieja que había sido deprecada 8 años antes. Esta función empieza a ejecutar trades automáticamente. Miles. Millones.
En 45 minutos, el software ejecuta órdenes de compra y venta por $7 mil millones. SIETE MIL MILLONES. Sin supervisión humana.
Para cuando se dan cuenta y apagan los sistemas, Knight Capital había acumulado $440 millones en pérdidas.
Knight Capital perdió $9.7 millones por minuto
Este caso es único porque no fue downtime tradicional. El sistema funcionaba "perfectamente". El problema fue que funcionaba haciendo exactamente lo que NO debía hacer.
La lección: Los errores en deployment pueden ser catastróficos. El código que desplegas puede destruir tu empresa en minutos.
Mirando estos 5 casos, hay un patrón que se repite:
La buena noticia: Ninguno de estos problemas era inevitable.
Es verdad. No tenés su escala. Pero tenés los mismos riesgos, proporcionalmente.
Si tu SaaS factura $5,000/mes y está down 6 horas, no perdés $60 millones. Pero podés perder usuarios, reputación y revenue que te costó meses construir.
No necesitás gastar miles. Pero necesitás SABER cuando algo falla. Antes de que tus usuarios te avisen.
Tener un backup que nunca probaste es lo mismo que no tener backup.
Tratá cada cambio de infra como si pudiera romper todo. Porque puede.
Cuando todo está prendido fuego, no querés estar googleando "cómo hacer rollback".
La automatización es increíble. Hasta que hace algo que no debería, a escala.
Staging, testing, feature flags. El deployment es donde más cosas pueden salir mal.
Estos casos extremos nos muestran algo importante: el costo del downtime no es solo el revenue perdido durante esos minutos u horas.
Para Amazon, $100 millones es un mal día.
Para tu startup, 6 horas de downtime pueden ser el fin.
No te cuento estas historias para asustarte. Te las cuento para que entiendas que:
No necesitás la infraestructura de Amazon para aplicar estas lecciones. Necesitás:
No es cuestión de SI va a pasar. Es cuestión de CUÁNDO.
Y qué tan preparado estés cuando pase.
Empezá con monitoring básico hoy.
Crear cuenta gratuitaConfigura tu primer check en menos de 2 minutos