El apagón de GitHub: la carga de commits duplicada

Siete Horas Y Cuarenta Y Siete Minutos, Atribuidas A Un Proxy Sobrecargado

El propio informe de GitHub, publicado en su blog de ingeniería bajo el título 'The August 17 outage, and the work ahead', atribuye el fallo a un proxy sidecar de Istio en su centro de datos de Central US que alcanzó su capacidad máxima de procesamiento concurrente. La política de autoescalado que vigilaba esa capacidad evaluaba únicamente el propio servicio de aplicación, no el estado de conexión y concurrencia de los sidecars situados delante de él, así que nada escaló cuando los sidecars llegaron a su límite. Al saturarse esos proxies, las solicitudes se desplazaron hacia otros nodos, que a su vez alcanzaron sus propios límites de capacidad, y la lógica de reintento automático de GitHub agravó la espiral al enviar nuevas solicitudes hacia balanceadores de carga ya sobrecargados. Un fallo de reintento independiente, según informó The Register, situado en una extensión de VS Code usada para la autenticación de GitHub Copilot, agravó aún más el fallo: pedía nuevos tokens de autenticación sin pausa, llevando el servicio de emisión de tokens de GitHub de una base normal de entre 7.000 y 9.000 solicitudes por segundo hasta entre 70.000 y 100.000 solicitudes por segundo, unas diez veces la carga habitual.

Las Cifras Detrás De Una Mala Tarde

El apagón se extendió del 17 de agosto de 2026, de las 13:28 a las 21:15 UTC, y las propias actualizaciones de estado de GitHub situaron las tasas de error máximas en torno al 20 por ciento en tráfico web y API y alrededor del 50 por ciento en descargas de archivo y contenido en bruto, precisamente el tipo de solicitud del que dependen una canalización de compilación o una obtención de dependencias. Issues, pull requests, APIs, Actions y Copilot quedaron degradados por igual, junto con la autenticación SAML y OIDC, SCIM y Team Sync; la mayoría de los servicios se recuperaron hacia las 16:36 UTC, Actions hacia las 18:03 UTC, y el servicio de tokens de Copilot el último, a las 21:02 UTC. GitHub fue explícito en que ni este incidente ni el fallo menor de Actions del 6 de agosto se debieron a un cambio de código o configuración; ambos fueron, en palabras de la propia empresa, fallos de capacidad en esencia, es decir, el sistema se quedó sin margen en lugar de romperse por un error enviado.

El Volumen De Commits Casi Se Duplicó En Cuatro Meses

Escondida en el mismo informe está la cifra que convierte esta historia de apagón en una historia de infraestructura: GitHub afirma que el volumen mensual de commits ha crecido de 1.400 millones a 2.900 millones desde abril de 2026, es decir, prácticamente se duplicó en unos cuatro meses, acompañado de gráficos que muestran las pull requests fusionadas acercándose a 130 millones al mes y los nuevos repositorios acercándose a 24 millones al mes. GitHub ya había señalado la causa en su informe de disponibilidad de mayo de 2026, donde reconoció que la programación asistida por IA y los flujos de trabajo agénticos estaban añadiendo presión a su infraestructura, y Microsoft ha declarado públicamente que la IA ya escribe hasta el 30 por ciento del código en algunos de sus propios repositorios, sujeto a revisión humana. Una plataforma dimensionada para un mundo en el que los commits llegaban al ritmo de la escritura humana absorbe ahora un patrón de carga marcado por agentes de codificación que escriben, ramifican y publican de forma continua, y la respuesta de GitHub hasta ahora ha sido añadir capacidad: más de 3 millones de núcleos de CPU y 120 petabytes de almacenamiento de alta velocidad, con Azure asumiendo ya en torno al 58 por ciento de la carga de la plataforma, frente al 12 por ciento de mayo.

GitHub Actions Registró Trece Incidentes En Diecisiete Días

Tech Times, tras analizar el historial de incidentes y los datos de estado de GitHub, informó de que GitHub Actions por sí solo registró 13 incidentes distintos en un lapso de 17 días este agosto, y que su disponibilidad a 90 días cayó del 99,39 por ciento antes del apagón del 17 de agosto al 99,33 por ciento después, un descenso desde unas 13 horas de tiempo de inactividad acumulado en tres meses hasta cerca de 14,5 horas. Ese medio planteó que el incidente del 17 de agosto había consumido, por sí solo, casi todo el presupuesto anual de inactividad permitida frente a un objetivo de tres nueves. El propio informe de GitHub cuenta de otra manera y llama al 17 de agosto su segundo incidente significativo del mes tras el fallo de Actions del 6 de agosto, un recuento razonable de grandes apagones a escala de plataforma, pero que nada dice sobre las interrupciones de Actions más pequeñas y frecuentes que quedan por debajo. Ambos recuentos pueden ser ciertos a la vez, y juntos describen un problema de fiabilidad en dos niveles: el servicio central de Git resiste mejor que la canalización de CI/CD montada encima de él, y es precisamente esa canalización la que soporta la mayor parte de la nueva carga del desarrollo asistido por IA.

Una Plataforma, Cada Canalización: El Riesgo De Concentración

Para una empresa que gestiona todo su flujo de trabajo de ingeniería a través de GitHub, es decir, control de versiones, CI mediante Actions, su registro de paquetes y Copilot para generación de código, nada de eso es ruido de fondo; es un único proveedor situado en la ruta crítica de cada versión publicada. Un equipo de desarrollo europeo siente esto igual que uno estadounidense durante la propia ventana del apagón, pero carga con una capa adicional de exposición: los plazos de entrega contractuales, los compromisos de nivel de servicio con clientes de la UE y las obligaciones de notificación de incidentes bajo marcos como NIS2 no se detienen porque el apagón se originara en un centro de datos estadounidense fuera del control del equipo. Tratar 'GitHub está caído' como ruido de fondo deja de tener sentido en cuanto las cifras subyacentes muestran por qué ocurrió: una infraestructura construida para un mundo más lento y al ritmo humano absorbe ahora un patrón de carga que casi se ha duplicado en cuatro meses, en una plataforma que, por su propia admisión, ha pasado agosto arreglando dos veces la misma categoría de fallo de capacidad.

Cómo Es La Redundancia En La Práctica

Nada de esto es un argumento para abandonar GitHub, que sigue siendo la opción por defecto por buenas razones, pero sí es un argumento concreto para tratar la dependencia de un único proveedor como un riesgo planificado y no como una idea tardía descubierta a mitad de un apagón. Eso significa mantener una copia espejo de los repositorios críticos en un segundo host o en un servidor Git autoalojado, una configuración alternativa de ejecutor de CI capaz de asumir compilaciones cuando Actions está degradado y no solo cuando falla por completo, y una caché local o autoalojada para las dependencias de paquetes, de modo que un apagón del registro no detenga cada compilación de la canalización. Ninguna de estas medidas necesita funcionar de forma continua; necesitan existir, probarse de vez en cuando y estar documentadas lo bastante bien para que un equipo bajo presión durante el siguiente incidente no esté improvisando una solución por primera vez mientras el reloj de un plazo con un cliente sigue corriendo.

Leer a continuación: Su Segundo Alojamiento Git Se Activó Solo  |  Irlanda cancela su contrato con Microsoft