Lecciones de sistemas distribuidos de los informes de incidentes (COE) de AWS - Principios de diseño que cambiaron las grandes interrupciones del pasado
A partir de los Correction of Errors (COE) e informes de incidentes publicados por AWS, explicamos las causas raíz de grandes incidentes pasados como la interrupción de S3, la interrupción de DNS en us-east-1 y la interrupción de Kinesis, y cómo cambiaron los principios de diseño de AWS.
El trasfondo cultural de AWS al publicar sus fallos
AWS publica informes detallados de sus incidentes importantes, conocidos como COE (Correction of Errors) o Post-Event Summaries. Esta transparencia es inusual en la industria y refleja la cultura de Amazon de aprender de los errores. Los informes incluyen una cronología detallada del incidente, la causa raíz, el impacto en los clientes y las acciones correctivas implementadas. Esta práctica beneficia tanto a AWS (que demuestra responsabilidad y mejora continua) como a la comunidad técnica (que aprende lecciones aplicables a sus propios sistemas). La publicación de estos informes también establece un estándar de transparencia que presiona a otros proveedores de nube a ser más abiertos sobre sus propios incidentes.
Interrupción de S3 en 2017 - El día que un error tipográfico detuvo la mitad de Internet
El 28 de febrero de 2017, un error tipográfico en un comando de mantenimiento eliminó más servidores de los previstos del subsistema de índices de S3 en us-east-1. La recuperación del subsistema de índices requirió un reinicio completo que no se había ejecutado en años, y el proceso tomó varias horas. Durante ese tiempo, S3 estuvo degradado, afectando a miles de sitios web y servicios que dependían de S3 para almacenar imágenes, archivos estáticos y datos. Las lecciones clave fueron: los sistemas deben poder recuperarse de la eliminación accidental de componentes, los procedimientos de mantenimiento necesitan guardrails que limiten el alcance de los cambios, y los sistemas que no se reinician regularmente acumulan dependencias ocultas que solo se descubren durante una crisis.
Interrupción de Kinesis en 2020 - La falla en cadena causada por la ampliación de servidores frontend
En noviembre de 2020, una ampliación rutinaria de la capacidad de los servidores frontend de Kinesis en us-east-1 desencadenó una falla en cadena. Los nuevos servidores necesitaban establecer conexiones con todos los demás servidores del clúster, y el número de hilos del sistema operativo necesarios excedió el límite configurado. Esto causó que los servidores frontend fallaran, lo que a su vez afectó a CloudWatch, que dependía de Kinesis para el procesamiento de métricas. Sin CloudWatch funcionando correctamente, la visibilidad del incidente se redujo, dificultando la respuesta. Las lecciones fueron: los límites del sistema operativo deben escalarse proporcionalmente con la capacidad del servicio, las dependencias circulares entre servicios (Kinesis → CloudWatch → monitoreo de Kinesis) crean puntos de fallo amplificados, y los sistemas de monitoreo deben tener rutas independientes de los servicios que monitorean.
Interrupción de red en us-east-1 en 2021 - Lo que enseñó la congestión de la red interna
En diciembre de 2021, un aumento inesperado en el tráfico de la red interna de AWS en us-east-1 causó congestión que afectó la comunicación entre servicios internos. La congestión impactó a múltiples servicios de AWS, incluyendo la consola de administración, CloudFormation y otros servicios del plano de control. Los servicios del plano de datos (las instancias EC2 en ejecución, los datos en S3, etc.) se vieron menos afectados. Las lecciones fueron: la separación entre plano de control y plano de datos es crítica para la resiliencia, la red interna necesita mecanismos de control de congestión más agresivos, y los clientes deben diseñar sus sistemas para tolerar fallos temporales del plano de control sin afectar las operaciones del plano de datos.
Principios de diseño derivados de los fallos
Los incidentes de AWS han cristalizado varios principios de diseño que ahora son fundamentales en la arquitectura de sus servicios. Primero, la separación estricta entre plano de control y plano de datos: el plano de datos (que sirve las solicitudes de los clientes) debe seguir funcionando incluso si el plano de control (que gestiona la configuración) falla. Segundo, la limitación del radio de explosión: los cambios deben aplicarse gradualmente y con mecanismos de rollback automático si se detectan anomalías. Tercero, la eliminación de dependencias circulares: un servicio no debe depender de otro servicio que a su vez depende del primero. Cuarto, la resiliencia estática: los sistemas deben poder operar con su configuración actual incluso si no pueden comunicarse con sus dependencias. Quinto, las pruebas de recuperación regulares: los procedimientos de recuperación que no se practican regularmente fallarán cuando más se necesiten. Estos principios no son teóricos; cada uno fue forjado por un incidente real que afectó a clientes reales.