El postmortem de GitHub: 3 millones de núcleos de CPU y una confesión sobre tormentas de reintentos tras la caída de 8 horas

GitHub ha publicado el postmortem de su caída del 17 de agosto, y el diagnóstico es incómodo: un componente crítico de su centro de datos de Central US sencillamente no escaló cuando el tráfico alcanzó un nuevo pico. El resultado: 7 horas y 47 minutos de servicio degradado o muerto en github.com, la autenticación, Actions, pull requests, issues, la API y Copilot.

Las cifras fueron brutales. Las tasas de error llegaron a rozar el 20% en el tráfico web y de API, y alrededor del 50% en las descargas de archivos y contenido raw. Más de 10.000 usuarios inundaron Downdetector en el peor momento. Para los equipos que canalizan despliegues, CI y revisión de código a través de GitHub — es decir, casi todos — la mala tarde de la plataforma fue la mala tarde de todos.

La cadena causal es un clásico de los sistemas distribuidos. Los proxies sidecar de Istio que median la comunicación entre servicios alcanzaron su límite de procesamiento, pero el auto-escalado de GitHub no contemplaba la capacidad de los sidecars, así que nada escaló. Y los clientes lo empeoraron: bucles de reintentos — incluidos los de VS Code — martillearon los servicios en plena recuperación y alargaron el incidente. GitHub admite ahora que carecía de límites y presupuestos de reintento consistentes en su propia plataforma.

Fue, además, el segundo incidente grave del mes, tras el fallo de Actions del 6 de agosto que consumió por sí solo casi todo el presupuesto de error de un año. Dos golpes en tres semanas explican que GitHub haya publicado un plan de remediación inusualmente concreto en lugar del habitual párrafo de “nos tomamos la fiabilidad muy en serio”.

El plan es descomunal: más de 3 millones de núcleos de CPU adicionales, 120 petabytes de almacenamiento y una migración acelerada a Azure, que pasará a soportar el 58% de la carga de la plataforma frente al 12% de mayo. También habrá presupuestos de reintento globales, aislamiento de sistemas críticos para que el fallo de un componente no arrastre a todos los productos, y un rediseño de la capacidad de lectura para monorepos. El CTO Vlad Fedorov no se escondió: “Es nuestra responsabilidad arreglarlo. Nos ganaremos vuestra confianza con la escalabilidad y fiabilidad de la plataforma”.

El subtexto importa: las herramientas de programación con IA son carga real de infraestructura, no una línea de marketing. Los agentes generan patrones de tráfico — polling constante, clones en paralelo, clientes agresivos con los reintentos — para los que la arquitectura de GitHub no estaba dimensionada.

Si tu plan de incidentes asume que GitHub siempre está disponible, este es el aviso. Cachea dependencias, distingue fallos de CI de caídas de plataforma y ten claro tu camino de despliegue cuando Actions no responda. GitHub va a gastar miles de millones para que esto no se repita. Tu plan B cuesta una tarde.

Fuentes

Lecturas relacionadas