Por Canuto  

GitHub atribuyó una interrupción de 7 horas y 47 minutos a la saturación de balanceadores, una política de autoscaling mal configurada y una tormenta de reintentos de VS Code que multiplicó el tráfico de tokens de Copilot aproximadamente diez veces.
***

  • GitHub registró errores elevados en Issues, Pull Requests, APIs, Actions y Copilot entre las 13:28 y las 21:15 UTC del 17 de agosto.
  • Un sidecar de Istio alcanzó su límite de concurrencia, pero el autoscaling solo vigilaba el servicio host y no detectó el cuello de botella.
  • La compañía anunció cambios en sus políticas de escalamiento, límites de reintento, configuración de Istio y comportamiento de VS Code.

 

GitHub responsabilizó a una política defectuosa de autoscaling, la saturación de sus balanceadores de carga y un error latente de reintento en Visual Studio Code por la interrupción que afectó a desarrolladores durante casi ocho horas. El incidente comenzó a las 13:28 UTC del 17 de agosto y no quedó completamente resuelto hasta las 21:15 UTC, con fallas elevadas en Issues, Pull Requests, APIs, Actions y Copilot.

La explicación de la compañía muestra cómo una falla localizada en una pieza de infraestructura puede transformarse rápidamente en una interrupción generalizada cuando varios servicios dependen de la misma red interna. El problema también expone el riesgo de las políticas automáticas que aparentan añadir capacidad, pero vigilan el componente equivocado mientras el verdadero cuello de botella continúa creciendo.

GitHub publicó su análisis después de un incidente de 7 horas y 47 minutos que interrumpió actividades habituales como consultar incidencias, enviar cambios, ejecutar flujos de trabajo automatizados y utilizar herramientas vinculadas con Copilot. Para organizaciones que alojan allí sus repositorios y procesos de entrega de software, la interrupción significó una pérdida temporal de acceso a funciones centrales del ciclo de desarrollo, detalla The Register.

Una falla de monitoreo abrió la puerta a la saturación

La causa inmediata estuvo en la saturación de la red de los balanceadores de carga ubicados en la instalación de GitHub en el centro de Estados Unidos. Según la empresa, el origen técnico fue que un sidecar de Istio alcanzó su límite de concurrencia, es decir, el máximo de solicitudes que podía procesar simultáneamente dentro de esa arquitectura.

Istio funciona como una capa de infraestructura que ayuda a gestionar la comunicación entre servicios, mientras que los balanceadores distribuyen las solicitudes para evitar que una instancia concentre toda la carga. En este caso, el mecanismo automático de escalamiento no respondió como se esperaba porque una política mal configurada supervisaba el servicio host, pero ignoraba el límite de concurrencia del sidecar.

La diferencia parece técnica, pero tuvo una consecuencia directa: el sistema podía interpretar que el servicio principal todavía tenía capacidad suficiente, aunque el componente encargado de manejar las conexiones ya estuviera al máximo. Ese punto ciego de monitoreo permitió que el tráfico siguiera aumentando sin que el autoscaling incorporara capacidad en el momento necesario.

GitHub describió el resultado como un fallo en cascada, porque la presión acumulada en un componente terminó afectando a los balanceadores y, posteriormente, a varios servicios que dependían de ellos. El episodio evidencia que el escalamiento automático solo es eficaz cuando las métricas observadas representan el límite real que determina la capacidad de todo el sistema.

Los reintentos multiplicaron la presión sobre Copilot

La compañía explicó que el problema se agravó por una lógica optimista de reintento, diseñada para volver a enviar solicitudes cuando una respuesta tarda demasiado o no llega correctamente. Esa conducta puede ayudar a superar fallas breves, pero bajo saturación genera más tráfico precisamente cuando la infraestructura necesita reducirlo.

El efecto más severo apareció en un único endpoint interno relacionado con el Servicio de tokens de Copilot. GitHub afirmó que las respuestas retrasadas activaron un error latente de reintento en VS Code, lo que amplificó aproximadamente diez veces el tráfico y retrasó todavía más la recuperación de ese servicio.

La secuencia creó un círculo difícil de romper: la congestión demoraba las respuestas, las demoras provocaban nuevos intentos y esos intentos añadían solicitudes a unos balanceadores que ya operaban al límite. En lugar de absorber una falla puntual, el comportamiento del cliente convirtió el retraso inicial en una fuente adicional de presión para la plataforma.

El episodio también ilustra por qué los equipos de infraestructura suelen aplicar límites y mecanismos de espera progresiva a los reintentos, especialmente en servicios internos compartidos. Cuando una aplicación insiste de forma simultánea y automática, una respuesta tardía puede convertirse en una tormenta de tráfico que afecta tanto al servicio original como a sus dependencias.

La mitigación requirió rechazar solicitudes

Los ingenieros de GitHub redujeron temporalmente los reintentos de la puerta de enlace mediante un cambio de código, con el objetivo de cortar la amplificación del tráfico. Además, configuraron los balanceadores para rechazar las solicitudes entrantes del Servicio de tokens de Copilot mediante respuestas HTTP 403.

Rechazar solicitudes puede parecer una medida drástica, pero permite proteger una infraestructura saturada frente a nuevos intentos y conservar recursos para las funciones que todavía pueden recuperarse. En este caso, la decisión buscó contener el flujo hacia el servicio de tokens y evitar que la presión continuara retrasando la recuperación general.

La mayoría de los servicios volvió a operar a las 16:36 UTC, mientras que GitHub Actions se recuperó a las 18:03 UTC. El Servicio de tokens de Copilot, sin embargo, tardó hasta las 21:02 UTC, apenas unos minutos antes de que la compañía considerara completamente resuelto el incidente a las 21:15 UTC.

La diferencia entre la recuperación de los servicios principales y la de Copilot muestra que la interrupción no avanzó de manera uniforme por toda la plataforma. Las dependencias internas, los reintentos y la concentración de tráfico en un endpoint específico hicieron que una parte del sistema permaneciera bajo presión mucho después de que otras funciones comenzaran a estabilizarse.

Scraping y dudas sobre la fiabilidad

GitHub añadió que una serie de ataques de scraping contra los endpoints de codeload complicó la recuperación. La empresa no ofreció en la información disponible una cifra sobre el volumen de esos ataques, pero los identificó como un factor adicional que dificultó restablecer el equilibrio de la infraestructura.

El scraping consiste en extraer datos de forma automatizada, una actividad que puede generar una carga considerable cuando se dirige a puntos de descarga o distribución de código. En medio de una red ya tensionada por los balanceadores y los reintentos, ese tráfico adicional redujo el margen operativo disponible para estabilizar los servicios afectados.

El incidente vuelve a colocar la fiabilidad de GitHub en el centro del debate entre los desarrolladores que dependen de sus repositorios, automatizaciones y herramientas de inteligencia artificial. Una caída no solo interrumpe la consulta de código, sino que puede detener tareas coordinadas entre equipos, procesos de integración y despliegues que requieren acceso continuo a la plataforma.

Moritz Plassnig, CEO de CloudBees, sostuvo en una publicación de LinkedIn que Cursor, OpenAI y varias startups más pequeñas ya construyen soluciones competitivas. A su juicio, GitHub podría dejar de ser la opción predeterminada, en un escenario que produciría un ecosistema más bifurcado, con ventajas y desventajas para los usuarios.

GitHub promete cambios en su arquitectura

GitHub aseguró que corregirá las políticas de autoscaling para supervisar los límites que realmente determinan la capacidad del sistema. También prometió revisar los límites de reintento, auditar los ajustes de concurrencia de Istio y abordar el comportamiento de VS Code que amplificó el tráfico de tokens de Copilot.

Las medidas anunciadas apuntan a las distintas etapas de la cadena de fallas, desde la detección insuficiente hasta la reacción automática de los clientes. Corregir solo el autoscaling no resolvería el problema si los reintentos siguen generando una carga desproporcionada, del mismo modo que limitar reintentos sería insuficiente si la plataforma continúa sin observar el cuello de botella correcto.

La revisión de VS Code será especialmente relevante porque el editor puede actuar como un multiplicador de tráfico cuando miles de usuarios solicitan simultáneamente servicios internos. GitHub deberá determinar cómo impedir que una respuesta retrasada active nuevos intentos de manera agresiva, sin deteriorar la experiencia de quienes enfrentan fallas temporales y legítimas.

Para los usuarios, el caso refuerza la necesidad de evaluar dependencias críticas y contar con procedimientos alternativos cuando una plataforma central deja de responder. La compañía mantiene una posición dominante en el alojamiento de código, pero la aparición de competidores y la acumulación de incidentes pueden modificar la relación entre conveniencia, riesgo operativo y costo de migración.

Mientras GitHub se recuperaba, Cursor, propiedad de SpaceX, anunció una beta temprana de Origin Code Hosting. El movimiento no demuestra por sí mismo un cambio inmediato del mercado, pero llega en un momento especialmente sensible y ofrece a los desarrolladores una señal concreta de que las alternativas comienzan a competir por una infraestructura que durante años pareció casi predeterminada.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.


ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín

Artículos Relacionados