GitHub reveló que la interrupción que afectó a su plataforma el 17 de agosto y duró 7 horas y 47 minutos se debió a que un componente crítico de infraestructura no pudo escalar al alcanzar el tráfico un nivel récord dentro de su centro de datos en la región central de Estados Unidos. La presión resultante sobre la capacidad provocó la propagación de problemas a varios sistemas, por lo que se vieron afectados github.com, la autenticación, GitHub Actions, las API, las solicitudes de incorporación de cambios y las incidencias, además de Copilot, mientras que el impacto de la interrupción se extendió a desarrolladores y organizaciones de todo el mundo.
El incidente representa el segundo acontecimiento importante al que se enfrentó GitHub durante agosto, después de un fallo que afectó a Actions el 6 de agosto. La empresa explicó que la investigación no encontró relación entre ninguno de los dos incidentes y un cambio en el código o la configuración; más bien, ambos tuvieron como núcleo una insuficiencia de capacidad, ya que los componentes esenciales no se ampliaron antes de que la demanda superara sus límites. Según GitHub, el número de operaciones de inserción mensuales aumentó de 1.400 millones en abril a 2.900 millones desde entonces, pero la empresa reconoció que el crecimiento del uso no la exime de la responsabilidad de evitar interrupciones.
¿Cómo se recuperaron los servicios?
El proceso de recuperación requirió redirigir el tráfico, aislar la infraestructura afectada y restaurar los servicios por etapas. La mayoría de los servicios de GitHub volvió a funcionar ese mismo día, pero algunos servicios de Copilot tardaron más. Los errores de esos servicios provocaron un bucle de reintentos por parte del cliente que aumentó el tráfico durante la recuperación, lo que obligó a los equipos a limitar este comportamiento antes de redirigir el tráfico de forma segura.
GitHub afirma que el informe completo del análisis de la causa raíz incluye una cronología técnica detallada, mientras que la empresa continúa ejecutando los compromisos anunciados anteriormente para mejorar la disponibilidad y la fiabilidad.
¿Qué cambia en la práctica?
El plan de GitHub se centra en aumentar la capacidad, mejorar la eficiencia y eliminar los cuellos de botella arquitectónicos. La empresa anunció que añadió más de 3 millones de núcleos de CPU y 120 petabytes de almacenamiento de alta velocidad, además de capacidades de red adicionales. También instaló la mayor cantidad posible de hardware dentro de la energía disponible en sus centros de datos actuales, al tiempo que aceleró su transición a Azure.
Actualmente, Azure gestiona aproximadamente el 58% de la carga de la plataforma de GitHub y la mitad de las operaciones de Git, frente al 12% de la carga de la plataforma en mayo. Esta expansión también ayudó a respaldar el crecimiento de las operaciones de ejecución de tareas de GitHub Actions. La empresa trabaja en una nueva arquitectura para ampliar linealmente la capacidad de lectura de repositorios enormes con respecto al número de lectores, lo que en teoría permitiría operaciones de lectura ilimitadas; su despliegue comenzará gradualmente en los repositorios monolíticos más grandes.
Reducir el alcance de las interrupciones y evitar las tormentas
GitHub no considera suficiente la ampliación por sí sola; ha destinado equipos y recursos adicionales a la disponibilidad, e invertido en pruebas más sólidas, procesos de despliegue más seguros, una supervisión mejor y alertas más eficaces. También aísla los sistemas críticos y elimina las dependencias compartidas entre ellos para reducir la probabilidad de que se produzca una interrupción y limitar su impacto si ocurre.
A partir de los incidentes del 6 y el 17 de agosto, la empresa aplicará límites y presupuestos unificados para los reintentos, junto con tiempos de espera variables en las comunicaciones entre servicios, con el objetivo de evitar tormentas de reintentos y cargas en cascada. Asimismo, revisará las alertas de CPU y memoria de baja prioridad para detectar componentes que puedan fallar durante aumentos repentinos del tráfico. Estas medidas son directamente importantes para los desarrolladores y las organizaciones que dependen de GitHub para crear, distribuir y ejecutar software, ya que la recuperación de la plataforma no depende únicamente de restaurar el servicio, sino también de evitar que el fallo se repita y limitar su alcance cuando ocurra.