Un comando con un parámetro incorrecto bastó para provocar en 2017 una de las caídas más recordadas de Amazon Web Services (AWS). Amazon S3 perdió una parte importante de su capacidad en us-east-1, necesitó reiniciar dos subsistemas y arrastró consigo a otros servicios. El episodio es especialmente útil para sysadmins y desarrolladores porque no fue excepcional en su naturaleza: GitLab, Meta, Cloudflare, Fastly y Atlassian han documentado incidentes donde comandos, scripts, configuraciones o código perfectamente autorizados terminaron causando interrupciones enormes.
Las claves de los errores que han roto grandes plataformas en 30 segundos
- AWS retiró en 2017 demasiados servidores de S3 por un parámetro introducido incorrectamente y tuvo que reiniciar dos subsistemas.
- GitLab borró accidentalmente el directorio de su base de datos primaria ese mismo año y perdió varias horas de datos.
- Una expresión regular saturó las CPU de Cloudflare en 2019.
- Meta desconectó su backbone global en 2021 durante una operación de mantenimiento.
- Fastly y Atlassian muestran que incluso una configuración válida o un script autorizado pueden tener un radio de impacto inesperado.
El caso de S3 es particularmente ilustrativo porque AWS explicó con bastante detalle qué sucedió. A las 9:37, hora del Pacífico, del 28 de febrero de 2017, un miembro autorizado del equipo ejecutó un procedimiento habitual para retirar algunos servidores mientras investigaba un problema del sistema de facturación. Uno de los valores introducidos en el comando era incorrecto y se retiraron muchos más servidores de los previstos.
El problema alcanzó los subsistemas de índice y ubicación de S3. El primero mantenía los metadatos y la información sobre dónde estaban almacenados los objetos; el segundo gestionaba la asignación de nuevo almacenamiento. Ambos necesitaron un reinicio completo.
Y ahí apareció un segundo problema que resulta familiar en infraestructuras que llevan años creciendo: hacía años que esos grandes subsistemas no se reiniciaban completamente. S3 había aumentado enormemente de tamaño y las comprobaciones necesarias para recuperar toda la plataforma tardaron más de lo previsto.
AWS S3 y el coste de permitir que un comando tenga demasiado poder
AWS comenzó a recuperar las operaciones GET, LIST y DELETE a las 12:26. El subsistema de índice estaba completamente recuperado a las 13:18 y las operaciones PUT, dependientes también del sistema de ubicación, volvieron a funcionar normalmente a las 13:54. Otros servicios necesitaron más tiempo para procesar el trabajo acumulado.
La cifra de 150 millones de dólares asociada habitualmente al incidente necesita un matiz importante. No fue una pérdida comunicada por Amazon.
La empresa de modelización de riesgos Cyence estimó aproximadamente 150 millones de dólares en pérdidas para compañías del S&P 500 y otros 160 millones para empresas estadounidenses de servicios financieros. Son estimaciones del impacto económico, no una factura pagada por AWS ni una cifra auditada de pérdidas de Amazon.
Más interesante para un equipo técnico fue lo que AWS cambió después.
La herramienta que retiraba capacidad podía eliminar demasiados servidores con excesiva rapidez. Amazon modificó su funcionamiento para ralentizar esas operaciones e introdujo límites que impidieran bajar cualquier subsistema por debajo de la capacidad mínima necesaria.
Es un ejemplo casi perfecto de un guardrail.
La solución no consistió simplemente en decir al operador que la próxima vez comprobara mejor el comando. AWS modificó el sistema para que una equivocación humana similar no pudiera producir el mismo resultado.
También aceleró la división de S3 en unidades menores denominadas cells. El objetivo era reducir el blast radius: si una parte falla, la recuperación y el impacto pueden limitarse a una fracción del sistema.
Incluso el sistema utilizado para informar del incidente resultó afectado. La consola administrativa del Service Health Dashboard dependía de S3, por lo que AWS no pudo actualizar normalmente los estados individuales hasta las 11:37. Después del incidente, Amazon trasladó esa administración a una arquitectura distribuida entre varias regiones.
El error humano había descubierto varias dependencias que hasta entonces parecían razonables por separado.
Y AWS está lejos de ser el único ejemplo.
Seis incidentes que todo sysadmin debería conocer
Los postmortem publicados por grandes compañías permiten construir una pequeña colección de fallos con algo en común: la acción inicial parecía mucho menos peligrosa que sus consecuencias.
| Incidente | Desencadenante | Impacto documentado | Lección técnica |
|---|---|---|---|
| AWS S3, 2017 | Parámetro incorrecto en una herramienta para retirar servidores | S3 us-east-1 y servicios dependientes afectados durante horas | Límites duros para operaciones destructivas y menor blast radius |
| GitLab, 2017 | Borrado accidental del directorio de la base de datos primaria | GitLab.com estuvo unas 18 horas caído y se perdieron varias horas de cambios en la base de datos | Un backup que no se ha restaurado y probado no constituye un plan de recuperación |
| Cloudflare, 2019 | Una expresión regular del WAF provocó backtracking masivo | CPU próxima al 100 % globalmente y errores 502; el tráfico llegó a caer un 82 % | CI/CD debe probar también consumo de recursos y desplegar progresivamente |
| Meta, 2021 | Un comando de mantenimiento desconectó involuntariamente el backbone | Facebook y otros servicios quedaron inaccesibles globalmente; DNS y herramientas internas también resultaron afectados | Los sistemas que validan comandos también pueden fallar |
| Fastly, 2021 | Una configuración válida de un cliente activó un bug latente | El 85 % de la red empezó a devolver errores; el 95 % funcionaba de nuevo en 49 minutos | Una entrada válida puede activar un estado que las pruebas nunca contemplaron |
| Atlassian, 2022 | Un script de mantenimiento recibió una lista incorrecta de identificadores | 883 sitios fueron eliminados; 775 clientes afectados y algunos tardaron hasta 14 días en recuperar servicio | Automatizar una operación destructiva exige validación, observabilidad y recuperación probada |
La tabla también desmonta la explicación cómoda de que estas caídas se producen simplemente porque «alguien se equivocó».
En GitLab, por ejemplo, un ingeniero eliminó accidentalmente el directorio de datos del servidor PostgreSQL primario cuando pretendía reconstruir el secundario. Pero el postmortem descubrió una cadena mucho mayor de problemas.
GitLab estimó que perdió cambios relacionados con unos 5.000 proyectos, 5.000 comentarios y 700 nuevas cuentas. Los repositorios Git y las wikis no se perdieron porque estaban almacenados separadamente. El servicio permaneció unas 18 horas fuera de funcionamiento.
El incidente también puso a prueba sus copias y procedimientos de recuperación. El error humano fue el último eslabón visible de una cadena operativa mucho más larga.
Cloudflare ofrece un ejemplo todavía más cercano al desarrollo de software.
En julio de 2019 se desplegó una nueva regla para su Web Application Firewall (WAF). Contenía una expresión regular que generaba una cantidad enorme de backtracking. El resultado fue que las CPU encargadas del tráfico HTTP y HTTPS se aproximaron al 100 % de utilización en toda su red.
En el peor momento, Cloudflare registró una reducción del tráfico del 82 %.
Lo interesante es que el cambio había seguido el procedimiento: pull request, aprobación, integración continua, pruebas y proceso de despliegue.
Los tests verificaban que el WAF detectara correctamente determinadas peticiones, pero no comprobaban si una regla podía disparar el consumo de CPU. Además, las reglas podían distribuirse globalmente en segundos.
El pipeline estaba en verde y producción se cayó.
Cloudflare respondió incorporando perfiles de rendimiento a sus pruebas, despliegues progresivos y cambios en el motor de expresiones regulares, entre otras medidas.
Cuando el fallo también destruye las herramientas para repararlo
Meta llevó este problema a otra escala el 4 de octubre de 2021.
Durante un mantenimiento rutinario, se emitió un comando destinado a evaluar la disponibilidad de capacidad de su backbone. El comando terminó desconectando involuntariamente las conexiones de esa red global.
Existía un sistema diseñado precisamente para auditar órdenes de este tipo y bloquear errores peligrosos. Pero un bug en esa herramienta de auditoría impidió detener el comando.
El fallo del backbone provocó después que las instalaciones de Meta retiraran sus anuncios Border Gateway Protocol (BGP) para DNS. Los servidores podían seguir funcionando, pero el resto de Internet dejó de encontrar los servicios.
El problema se volvió todavía más difícil porque también desaparecieron herramientas internas utilizadas para diagnosticar la incidencia. Los ingenieros tuvieron que desplazarse físicamente hasta centros de datos para recuperar determinados sistemas.
Es la misma dependencia circular que AWS había descubierto cuatro años antes con su página de estado.
El sistema de recuperación no debería depender exclusivamente del sistema que pretende recuperar.
Fastly mostró otra variante en junio de 2021.
La compañía había introducido el 12 de mayo un bug que permaneció latente durante semanas. El 8 de junio, un cliente realizó un cambio de configuración perfectamente válido que reunió las condiciones necesarias para activarlo.
El 85 % de la red de Fastly comenzó a devolver errores.
La monitorización detectó la interrupción en aproximadamente un minuto. Fastly identificó posteriormente la configuración desencadenante y, 49 minutos después del comienzo, el 95 % de su red volvía a operar normalmente.
Aquí ni siquiera existía necesariamente un operador que hubiera escrito algo incorrectamente.
La configuración era válida.
El software no estaba preparado para ella.
Atlassian ofrece quizá el caso más inquietante para cualquiera que mantenga scripts internos.
En abril de 2022, la compañía ejecutaba un script destinado a eliminar determinadas aplicaciones antiguas. Debido a un problema en los datos proporcionados al proceso, terminó eliminando 883 sitios de clientes. Atlassian confirmó posteriormente que 775 clientes estuvieron afectados.
El script fue eliminando los sitios secuencialmente sin generar una señal de alerta inmediata.
Jira, Confluence, Atlassian Access, Opsgenie y Statuspage quedaron inaccesibles para esos clientes. Algunos tardaron hasta 14 días en recuperar completamente el servicio.
La lección no es prohibir el acceso a producción
Estos incidentes apuntan a una conclusión mucho más útil que «los humanos cometen errores».
Los sistemas deben diseñarse suponiendo que un administrador introducirá algún día un parámetro incorrecto, un desarrollador escribirá una expresión regular problemática, un script recibirá datos equivocados y una configuración aparentemente válida activará una combinación nunca probada.
Eso cambia la manera de diseñar operaciones críticas.
Un rm, un cambio BGP o una eliminación masiva no debería disponer del mismo camino de ejecución que una operación rutinaria. Las acciones destructivas pueden incorporar límites máximos, dry-run, confirmaciones independientes, ventanas de espera y mecanismos automáticos que bloqueen estados incompatibles con los mínimos operativos.
Los despliegues tampoco necesitan pasar directamente de cero al 100 %.
Canary deployments, despliegues por fases y feature flags permiten observar una pequeña parte del tráfico antes de extender un cambio globalmente. Cloudflare descubrió en 2019 cuánto importa esa diferencia cuando su capacidad para distribuir reglas mundialmente en segundos convirtió una ventaja tecnológica en un multiplicador del incidente.
Los backups requieren la misma desconfianza.
Tener una tarea que informa backup completed successfully no demuestra que el sistema pueda recuperarse dentro del RTO (Recovery Time Objective) esperado. GitLab comprobó de la manera más difícil que la restauración también forma parte del backup.
Y la observabilidad necesita sobrevivir al servicio observado.
Status pages, canales de emergencia, sistemas de autenticación y herramientas administrativas deberían disponer de rutas independientes cuando el coste de perderlas durante una caída sea elevado.
AWS, Meta y Cloudflare han documentado incidentes donde sus propias dependencias complicaron el diagnóstico o la recuperación.
La pregunta útil antes de ejecutar una operación crítica no es únicamente si el comando es correcto.
También conviene preguntar qué ocurriría si fuese incorrecto y por qué el sistema permitiría que ese error alcanzara toda la producción.
Ese cambio de enfoque convierte el error humano en una condición prevista del diseño.
Preguntas frecuentes
¿La caída de Amazon S3 de 2017 fue causada por un comando mal escrito?
AWS confirmó que un miembro autorizado del equipo introdujo incorrectamente uno de los parámetros de un comando destinado a retirar unos pocos servidores. La herramienta terminó retirando mucha más capacidad de la prevista.
¿Amazon perdió 150 millones de dólares por aquella caída?
No es correcto presentarlo así. Cyence estimó unos 150 millones de dólares de pérdidas para compañías del S&P 500 y otros 160 millones para empresas estadounidenses de servicios financieros afectadas; no eran pérdidas declaradas por Amazon.
¿Qué fue lo más importante que cambió AWS después del incidente?
AWS añadió límites a su herramienta para impedir que una orden retire demasiada capacidad o deje un subsistema por debajo de su mínimo operativo. También aceleró la división de componentes de S3 en células menores y modificó la infraestructura administrativa de su página de estado.
¿Cómo se evita que un error humano provoque una caída global?
No existe una única medida. Los casos analizados apuntan a combinar guardrails, mínimos operativos, dry-run, permisos limitados, despliegues progresivos, pruebas de recuperación, observabilidad independiente y reducción del blast radius.
