Resumen
- La interrupción comenzó el 24 de julio a las 16:04 UTC; GitHub incorporó el análisis detallado el día 29 a las 02:36:25 UTC.
- Falló la conectividad entre los conmutadores spine de una jaula y la capa de agregación en una de tres zonas físicas.
- Las rutas activas restantes se saturaron cuando se perdió el 25% de la capacidad disponible de interconexión.
- Falló el 10% de los trabajos Actions; otro 5% empezó tarde; el 27% de las interacciones Issues fue lento o agotó el tiempo; Copilot y git push registraron un 4% de impacto cada uno.
- GitHub usó fibra reservada para ampliaciones, eliminó la pérdida de paquetes a las 17:07, restauró todas las rutas a las 17:36 y acelerará el paso de 100 a 400 Gbps.
La cifra principal no es una tasa total de indisponibilidad. Es una cadena de transformación. Una cuarta parte de la capacidad desapareció, el tráfico llenó las rutas supervivientes y cada servicio convirtió la congestión en un síntoma acorde con su propio modelo de estado y reintentos.
El 29 de julio se publicó evidencia, no se repitió el incidente
La actividad falló el 24 de julio. La entrada de estado se cerró ese mismo día. Cinco días después, su actualización recibió una explicación mucho más precisa: topología leaf-spine, enlace afectado, porcentajes por producto, capacidad de emergencia y una respuesta de infraestructura.
Por eso el artículo debe sostener dos fechas. Presentarlo como una caída del 29 inventaría una segunda interrupción. Mezclarlo con otros avisos de GitHub de los días 25 o 27 rompería también el límite del identificador oficial.
La explicación tiene una frontera. GitHub dice que se perdió conectividad y describe la saturación posterior, pero no identifica el dispositivo, el cambio o la acción que originó aquella pérdida. “Causa raíz” aquí explica bien la propagación, no todos los pasos del desencadenante.
Los porcentajes no se suman; se reconcilian
La jaula afectada dependía de enlaces entre sus switches spine y la agregación de la zona. Al perderlos, las cargas vinculadas a ese cómputo encontraron pérdida intermitente de paquetes. GitHub afirma que el incidente retiró el 25% de la capacidad disponible de interconexión.
El 10% de los trabajos Actions falló y el 5% consiguió completarse después de empezar tarde. En Issues, el 27% de las interacciones fue lento o agotó el tiempo. Copilot devolvió errores en el 4% de las solicitudes, aunque la mayoría se reintentó automáticamente. El 4% de los pushes se vio afectado. La autenticación ganó latencia, con errores inferiores al 1%.
Cada porcentaje tiene un denominador distinto. Sumarlos sería falso. Su valor reside en revelar distintos restos operativos: ejecuciones por repetir, colas por ordenar, escrituras por confirmar y latencias que quizá no activaron una alerta binaria.
La mitigación utilizó una reserva pensada para crecer
GitHub desvió las conexiones hacia fibras asignadas a futuras ampliaciones. A las 17:07 había capacidad suficiente para eliminar la pérdida de paquetes; a las 17:16 la mayoría de servicios mostraba recuperación completa; a las 17:36 estaban restauradas todas las rutas.
La separación de tiempos permite medir mejor. La red volvió a tener margen antes que todas las aplicaciones, y la mayoría de servicios se recuperó antes que el conjunto completo de caminos. Un único sello final no captura esa secuencia.
La maniobra demostró que existía una opción física de emergencia. No sabemos cuánta holgura quedó tras usarla, durante cuánto tiempo estuvo comprometida ni si ya ha vuelto a estar disponible como reserva.
Repetir una operación puede crear un segundo fallo
GitHub permite volver a ejecutar todo un workflow, solo los trabajos fallidos o un trabajo concreto. La nueva ejecución conserva los privilegios del actor original, el commit y la referencia Git. Esa continuidad no vuelve idempotente una publicación, un despliegue o una migración.
Un trabajo marcado como tardío puede haber terminado después de que alguien lanzara una versión posterior. Un push con respuesta fallida puede haber avanzado la referencia remota. Una edición de Issue que agotó el tiempo en el cliente puede haberse guardado. Antes de reintentar hay que leer el estado real y comparar efectos externos.
Los reintentos automáticos de Copilot reducen el error final, pero pueden ocultar la degradación del primer intento. La autenticación con menos de 1% de error también puede perjudicar sesiones sensibles a latencia. No existe un único botón de limpieza.
De 100 a 400 Gbps: respuesta relevante, prueba incompleta
Las jaulas más antiguas usan interfaces de 100 Gbps. GitHub dice que acelerará el cambio previsto a 400 Gbps para aumentar el ancho de banda en todas las capas y resistir mejor la pérdida de una ruta o dispositivo.
La dirección coincide con el mecanismo publicado: más margen reduce la probabilidad de saturación. Pero no se divulgan calendario, número de jaulas antiguas, reserva mínima ni combinación de fallos que deberá tolerar el diseño. Cuatro veces más velocidad nominal no implica automáticamente cuatro veces más resiliencia.
La prueba útil será observar el sistema durante una pérdida definida. Las rutas restantes deberían permanecer por debajo del límite, las herramientas de incidente seguir accesibles y la alarma llegar antes que los síntomas del usuario.
El siguiente informe debe cerrar ambos lados
Los clientes pueden conservar ya los IDs de workflows, comprobar pushes remotos, auditar mutaciones de Issues y separar fallo de primer intento y éxito tras reintento. La recuperación termina cuando el estado queda conciliado, no cuando se vuelve a enviar toda petición.
GitHub debería explicar el desencadenante inicial, el margen tras el desvío, el avance de 400 Gbps y los controles de aislamiento. También debería confirmar cuándo la fibra de ampliación vuelve a ser capacidad de contingencia.
El nuevo análisis convierte una dependencia cloud en algo físicamente medible. Se perdió una cuarta parte de interconexión; las rutas restantes se llenaron; los usuarios heredaron varias colas que no podían vaciarse de la misma manera.