El CTO de GitHub se disculpa con los desarrolladores después de una de las mayores interrupciones

El director de tecnología de GitHub, Vlad Fedorov, emitió una disculpa pública a los desarrolladores después de una de las interrupciones más severas de la plataforma, que duró siete horas y 47 minutos el 17 de agosto. La interrupción interrumpió los servicios básicos, incluida la autenticación, las acciones, las API, las solicitudes de extracción, los problemas y Copilot, lo que dejó a muchos usuarios sin acceso a las herramientas esenciales para sus flujos de trabajo.

El problema surgió porque la plataforma simplemente se quedó sin espacio para manejar niveles de tráfico sin precedentes. La causa raíz de la interrupción se remonta a una política de autoescalado que monitoreaba la métrica incorrecta. Específicamente, la política se centró en el servicio host en lugar del sidecar Istio, que alcanzó su límite de concurrencia. Esto llevó a la saturación de los balanceadores de carga dentro del centro de datos de GitHub Central US. Un error de retry latente en Visual Studio Code exacerbó aún más la situación amplificando el tráfico a un único punto final interno en aproximadamente 10 veces.

Como resultado, el servicio Copilot Token permaneció fuera de línea significativamente más tiempo que otros servicios. Los ingenieros finalmente desactivaron las repruebas de la puerta de enlace y comenzaron a devolver errores HTTP 403 para las solicitudes de tokens Copilot entrantes. Además, los ataques de raspado en los puntos finales de carga de código complicaron el proceso de recuperación. En el punto álgido de la interrupción, la página de estado de GitHub registró tasas de error cercanas al 20% para el tráfico web y API, y aproximadamente el 50% para las descargas de archivo y repositorio sin procesar.

El tiempo de inactividad prolongado tuvo un impacto tangible en los desarrolladores que intentan implementar o administrar código, especialmente durante un período de mayor actividad en la plataforma. Fedorov destacó que el rápido crecimiento de GitHub se ha convertido en un factor importante en sus desafíos de confiabilidad.

En respuesta, GitHub esbozó varias correcciones planificadas, incluyendo la implementación de límites de repetición consistentes, presupuestos de repetición y tiempos de espera variables en las interacciones de servicio. También planea revisar las alertas de CPU y memoria de menor prioridad e introducir una nueva arquitectura diseñada para escalar la capacidad de lectura proporcionalmente con el número de lectores concurrentes. Estos cambios inicialmente se dirigirán a los monorepositorios más grandes. El momento de estos desarrollos coincide con otro incidente que afectó a GitHub a principios de agosto, cuando ocurrió una interrupción del servicio Actions el 6 de agosto.

Durante este período, Cursor lanzó una versión beta temprana de su producto Origin Code Hosting, aprovechando la falta de disponibilidad de GitHub. El CEO de CloudBees, Moritz Plassnig, expresó su preocupación en LinkedIn, sugiriendo que GitHub podría ya no ser la opción preferida para algunos desarrolladores. Sus comentarios reflejan cambios más amplios en la industria, con el panorama de alojamiento de código cada vez más fragmentado a medida que las plataformas alternativas ganan tracción.