El 17 de agosto, GitHub sufrió una interrupción que duró 7 horas y 47 minutos. Esta interrupción afectó a github.com, la autenticación, GitHub Actions, las API, los pull requests, los issues y Copilot, perjudicando a desarrolladores y organizaciones de todo el mundo. Si ese día intentaban publicar software, les dejamos a mitad de camino.
Este fue nuestro segundo incidente importante de agosto, después de la interrupción de Actions del 6 de agosto. En marzo y abril compartí el trabajo que estábamos realizando para mejorar la fiabilidad de GitHub. Hemos avanzado, pero estos incidentes dejan claro que debemos acelerar ese trabajo.
Qué ocurrió
Nuestra investigación reveló que la interrupción comenzó cuando el tráfico alcanzó un nuevo máximo y un componente crítico de la infraestructura de nuestro centro de datos del centro de EE. UU. no pudo escalar para hacerle frente. La presión sobre la capacidad resultante se propagó por nuestros sistemas, provocó fallos de autenticación y afectó a varios servicios de GitHub.
La recuperación requirió varios pasos coordinados. Los equipos redirigieron el tráfico, aislaron la infraestructura afectada y restauraron los servicios gradualmente. La mayoría de los servicios de GitHub se recuperaron antes ese mismo día, pero algunos servicios de Copilot tardaron más. Los fallos en estos servicios activaron un ciclo de reintentos en el lado del cliente que aumentó el tráfico durante la recuperación. Antes de poder restaurar el tráfico de forma segura, tuvimos que mitigar este comportamiento. El análisis exhaustivo de la causa raíz incluye una cronología técnica detallada.
Ninguna de las dos interrupciones fue causada por cambios en el código o la configuración. La causa subyacente de ambos incidentes fue una capacidad insuficiente. No pudimos escalar los componentes críticos antes de que la capacidad de la demanda los superara. Desde abril, el número mensual de commits aumentó de 1,4 mil millones a 2,9 mil millones. Este crecimiento explica la presión sobre nuestros sistemas, pero no excusa estas interrupciones.
Qué hicimos y qué sigue
Como parte de los compromisos de fiabilidad que asumimos a principios de este año, nos centramos en tres prioridades: añadir capacidad, mejorar la eficiencia y eliminar los cuellos de botella arquitectónicos. Desde entonces, hemos añadido más de 3 millones de núcleos de CPU, 120 petabytes de almacenamiento de alta velocidad y una capacidad de red considerablemente mayor. En nuestros centros de datos actuales, aceleramos también nuestra migración a Azure mientras instalábamos hardware en la medida que lo permitía la capacidad eléctrica existente.
Hoy, Azure presta servicio a aproximadamente el 58% de la carga de plataforma de GitHub y a la mitad de todas las operaciones de Git; esta proporción ha aumentado desde el 12% de la carga de plataforma registrada en mayo. Esta infraestructura en expansión también respaldó el crecimiento de las ejecuciones de trabajos de GitHub Actions que se muestra a continuación.
La infraestructura y la capacidad de Azure también aceleraron nuestros esfuerzos para escalar los monorepos más grandes. Nuestro próximo hito es una arquitectura que escale la capacidad de lectura linealmente con el número de lectores y permita operaciones de lectura ilimitadas.
La implementaremos gradualmente, comenzando por los monorepos más grandes.
La escala no es el único desafío al que nos enfrentamos. A medida que aumentaron la velocidad y la complejidad de los cambios, nuestras prácticas operativas actuales no pudieron mantener el ritmo. Destinamos equipos y recursos a la disponibilidad e invertimos en pruebas más sólidas, procesos de despliegue más seguros, una mejor observabilidad y mecanismos de alerta más eficaces. Hemos avanzado, pero este trabajo aún no ha concluido.
Además, estamos aislando entre sí los sistemas críticos y eliminando las dependencias compartidas entre ellos. Este trabajo está diseñado para reducir la probabilidad de una interrupción y limitar su impacto cuando se produzca.
Aprendemos de cada interrupción y añadimos nuevas tareas a nuestro plan de trabajo de disponibilidad. Los incidentes del 6 de agosto y del 17 de agosto dieron lugar a dos cambios urgentes.
En primer lugar, estamos implementando límites de reintentos coherentes, presupuestos de reintentos y tiempos de espera variables en las interacciones entre servicios para evitar tormentas de reintentos y cargas en cascada. En segundo lugar, estamos revisando las alertas de CPU y memoria de baja prioridad para identificar los componentes que podrían fallar durante aumentos repentinos del tráfico.
Nuestro compromiso con la alta disponibilidad no es solo una promesa técnica.