Lecciones de la caída de GitHub: Un problema de auto-escalado y la tormenta de reintentos en VS Code

Durante el pico del incidente, las tasas de error en la web y la API rondaron el 20%, mientras que las descargas de código y archivos raw llegaron a fallar hasta en un 50%. Servicios clave como Git Operations, Actions, Pull Requests, e incluso Copilot, quedaron contra las cuerdas.

Pero más allá del impacto para nosotros los desarrolladores que vimos nuestros pipelines pausados, el análisis post-mortem revela un caso de estudio fascinante sobre arquitectura microservicios, límites de contenedores y cómo los clientes pueden empeorar exponencialmente una caída (el famoso "efecto amplificador").

Aquí te contamos técnicamente qué pasó tras bambalinas.

El detonante: El sidecar de Istio que no pudo escalar

Todo comenzó en la región Central de EE. UU. (Central US) debido a un aumento repentino en el tráfico general.

GitHub utiliza un service mesh (Istio) para gestionar la comunicación interna. En este esquema, cada pod de servicio corre junto a un contenedor "sidecar" que maneja la red.

El problema fue de configuración: las políticas de auto-escalado (HPA) vigilaban los límites del servicio principal del host, pero no los límites de concurrencia del sidecar de Istio.

Al saturarse el sidecar y no poder auto-escalar, las llamadas empezaron a fallar en cascada, provocando que cuatro nodos críticos de balanceo de carga (HAProxy) agotaran su límite de conexiones simultáneas. Esto terminó rompiendo el flujo de autenticación (SAML/OIDC).

El efecto amplificador: La tormenta de reintentos (Retry Storm)

Cuando un servicio gigante como GitHub se degrada, el comportamiento de las aplicaciones clientes es vital. En este caso, hubo dos factores que multiplicaron el tráfico de forma agresiva:

• Lógica de reintento optimista: Los gateways internos intentaron reenviar las peticiones fallidas inmediatamente, saturando aún más los balanceadores internos.
• El bug latente en VS Code: La caída de un endpoint interno específico activó un bug de reintentos oculto en VS Code. El editor empezó a reenviar peticiones de tokens de GitHub Copilot sin un backoff adecuado. El tráfico del servicio de tokens de Copilot pasó de los 7k-9k RPS habituales a una avalancha de 70k-100k RPS.

¿Cómo lograron mitigar y recuperar el servicio?

La recuperación no fue tan simple como prender y apagar los servidores. El equipo de GitHub tuvo que:

1. Pausar HAProxy simultáneamente en los nodos afectados para limpiar el cuello de botella.
2. Reducir las políticas de reintentos (mediante un PR de emergencia) a nivel del gateway.
3. Bloquear temporalmente las peticiones de tokens de Copilot con un error 403 a nivel del balanceador para frenar la tormenta de reintentos, reactivando el servicio de manera gradual por zonas geográficas.

Lecciones para nuestra propia infraestructura

Este incidente nos deja varios aprendizajes que podemos aplicar en nuestros propios desarrollos:

1. Monitorea los sidecars: Si usas Service Mesh (como Istio o Linkerd), asegúrate de que tus métricas de escalado consideren los límites de CPU/concurrencia de los sidecars, no solo del contenedor de tu aplicación.
2. Implementa Exponential Backoff y Jitter: Las aplicaciones clientes (móviles, web, integraciones) NUNCA deben reintentar inmediatamente tras un fallo de red. Deben esperar tiempos progresivamente mayores y con un factor aleatorio (jitter) para no tumbar tu base de datos o balanceador al recuperarse.
3. Circuit Breakers: Implementa patrones de tolerancia a fallos tanto en cliente como en servidor para cortar peticiones cuando un servicio secundario no responda.