BettaTech · 17:28 · https://www.youtube.com/watch?v=h5of8RrGLeE

0:00 Seguramente ayer intentaste hacer un push o hacer algún deploy y notaste un error extraño. No eras solamente tú. GitHub estuvo caído durante más de 8 horas. Concretamente fallaban el 20% de peticiones tanto a su web como a su API como el 50% la mitad de sus descargas de ficheros. Por culpa de esta caída, muchísimos desarrolladores alrededor del mundo no podían trabajar. En este vídeo voy a analizar el documento técnico para explicar qué pasó exactamente, por qué sucedió este problema y qué cosas puede hacer GitHub para intentar solucionarlo a futuro.

0:33 El 17 de agosto a las 2:58 GitHub se encontraba en un momento crítico. Había un problema que estaba afectando a prácticamente el 100% de su infraestructura. Y es que cuando me refiero al 100% me refiero a prácticamente todas las características que tiene GitHub. la parte de Webhooks, que es uno de los motores para tener eventos en GitHub y estar informado de lo que va ocurriendo en tus repositorios, la parte de peticiones a la API. Recordemos que GitHub es una de las plataformas de soporte de código de repositorios más utilizada en el mundo.

1:04 Concretamente anuncien en su página web que tienen más de 180 millones de usuarios activos en la plataforma. Y de hecho hay un montón de empresas que utilizan GitHub día a día no solamente para tener repositorios de código, sino también para hacer la CICD y los despliegues automatizados. Por lo tanto, nos encontramos ante un problema crítico. Sinceramente, admiro a los ingenieros de GitHub que en ese momento recibieron seguramente un montón de alarmas a través del móvil indicando que todo estaba caído y que se tenían que levantar y empezar a arreglarlo.

1:32 Desde aquí, mi más sincera admiración. Además que este error no pasó desapercibido y ya sabemos que GitHub lleva unos meses en los que no está en su mejor momento. De hecho, solamente en julio GitHub había tenido ya ocho incidentes. De hecho, la broma está en que GitHub es la primera empresa tecnológica en llegar a solamente un nueve de disponibilidad, hasta el punto de que muchos usuarios están perdiendo la confianza en lo que hasta hoy había sido una de las plataformas más queridas de la industria del desarrollo.

2:02 Entonces, la situación como tal a nivel de visión de usuarios y de mantenimiento de la infraestructura no está siendo la mejor. Pero vamos directamente a lo que nos interesa. ¿Qué es lo que sucedió exactamente este 17 de agosto de 2026 para tener una infraestructura global caída durante 8 horas? La causa principal fue, cómo no, un problema de configuración en la escalabilidad de un sistema distribuido. No es novedad, que el tráfico de GitHub ha aumentado drásticamente. Con la aparición de la inteligencia artificial,

2:34 el código se genera mucho más rápido y por lo tanto, GitHub, que tenía una infraestructura pensada para ingestar cambios y contenido y código escrito por personas humanas, está viendo como su infraestructura es incapaz de soportar lo que está ocurriendo ahí fuera. Según el artículo técnico, lo que ocurrió fue que se recibió uno de estos picos de tráfico alrededor del inicio de la degradación de GitHub. Concretamente se dice que los balanceadores de carga que estaban en la región central de Estados Unidos recibieron un pico tan alto de tráfico que empezó a generar una cascada de errores.

3:09 Esta cascada de errores sucedió porque básicamente había un problema en la configuración de un Scar de Istio. La sensación que me da al leer la terminología de todos los nombres que utilizan en este escrito técnico es que KHub utiliza cubernetes o algo similar por detrás. Cubernetes es básicamente un orquestador de contenedores y te permite pues por ejemplo desplegar un servicio y definir lo que se conoce como una concurrencia. Tú puedes decir que en función de la carga tu contenedor pase de una a 10 réplicas en función, por ejemplo, de medidas como el consumo de CPU o el consumo de memoria RAM.

3:45 Dentro del entorno de cubernetes, cada unidad de ejecución, cada uno de estos contenedores que está recibiendo tráfico y se está ejecutando, es lo que se conoce como bot. Entonces, teniendo esta infraestructura, tú puedes añadirle herramientas de monitorización para visualizar y gestionar esta malla de contenedores. Esto se puede realizar con varias herramientas, pero una de ellas es Istio. Istio es lo que se conoce como una service mesesh y lo que te permite es extender las capacidades que te daría cubernete solamente a la hora de gestionar y programar la escalabilidad de tu red.

4:20 Por ejemplo, en vez de utilizar solamente CPU o la memoria RAM de un pod para saber si tengo que crear más o crear menos, con ISO poder hacer cosas tan chulas como, por ejemplo, en función de las peticiones por segundo, escálame hacia arriba o escálame hacia abajo. Para que Istio sea capaz de recoger la información que luego va a utilizar para monitorizar y para realizar escalabilidad y otros crehaceres, podríamos decir, necesita estar enchufado a tus cargas de trabajo.

4:48 Necesitas colocar una pieza de código, un pequeño ejecutable dentro de lo que sería, pues, por ejemplo, tu servidor en GitHub. Esto es lo que se conoce como Sidecar. Colocas diferentes piezas de código dentro de lo que sería tu arquitectura. Por ejemplo, cada vez que se despliegue una réplica de mi servidor, colocas este SIDCAR, que lo que va a hacer va a ser, en el caso de Istio, monitorizar, por ejemplo, tráfico entrante y saliente. Otras herramientas, aparte de Istio, también utilizan el mismo modelo de Sidecar, por ejemplo, herramientas de LX.

5:15 Por lo tanto, es algo muy útil que se utiliza enormemente en la industria de la infraestructura de código y en el cloud. ¿Qué ocurrió en el caso particular de GitHub? Pues precisamente que el Scar de Istio no tenía bien configurados los límites de concurrencia. Al recibir un pico de tráfico en la región central de Estados Unidos, los pots de la infraestructura de GitHub, de los servicios no podía crecer a más de ciertos números. Por ejemplo, no está escrito en el documento, pero podemos entender que yo que sé, quizá tenía un límite de 100.

5:47 Para gestionar el tráfico necesitaba 150, pero era incapaz de ascender. En ese momento la infraestructura, al estar al límite y no poder gestionar todo el tráfico, empezó a generar problemas y empezó a caerse. Concretamente mencionan que cuatro servidores de Happroxy se cayeron por el incremento de tráfico. Si tú empiezas a tirar agua a una cañería y esa cañería no puede crecer en diámetro para aceptar más tráfico, pues obviamente al final la cañería se acaba rompiendo. Esto es a lo que se refieren cuando dicen que los cuatro servidores de Japroxy alcanzaron su límite de flujo, su límite de ancho de banda.

6:21 Fue este error, esta caída de estos cuatro servidores de Japroxy, que es lo que se conoce como un reverse proxy, es decir, es básicamente el encargado de distribuir el tráfico a los diferentes servicios que tiene GitHub. Es decir, es el uno de los puntos de entrada principales que hizo que el error fuera tan extendido, llegando incluso a afectar a errores de autenticación. Y cuando llegamos a errores de autenticación, ya sabemos que se acaba cayendo todo, porque si el sistema es incapaz de saber quién eres, la mayoría de acciones que requieren autenticación van a acabar fallando.

6:53 Además, por si esto fuera poco, los propios clientes que estaban utilizando estos servicios de GitHub, por ejemplo, herramientas de la CLI, herramientas de la API, BS Code que se conecta a veces a GitHub, empezaron a visualizar estos errores que no paraban de aparecer. ¿Y qué ocurre cuando tú haces una llamada de red y ocurre un error? Lo más común es que al cabo de x tiempo intentes hacer un reintento. Por lo tanto, tenemos un ejército de procesos alrededor del mundo que están recibiendo errores que al cabo de exactamente un dos o 3 segundos

7:29 empiezan a hacer reintentos y vuelven a mandar todo el tráfico, que a su vez vuelve a recibir un error y por lo tanto se acabará volviendo a reintentar al cabo de un tiempo. Esto es lo que en GitHub, en el artículo llaman como una tormenta de reintentos, un retry storm. De hecho, incluso mencionan que esto hizo ver que había un book en Bcoute en el sistema de reintentos. Entonces, todos estos problemas fueron apareciendo y detectándose entre las 1340 UTC hasta que se identificó a las 16:36 UTC la causa del problema.

8:02 Aún así, la recuperación completa del servicio no ocurrió hasta las 21:15. Si a las 4 UTC ya habían identificado el problema, ¿qué hizo que se tardaran 4 horas más en arreglarlo? En general, arreglar problemas de infraestructura o de sistemas distribuidos no es algo inmediato. Requiere ciertas acciones y en muchas ocasiones tienes que hacer incluso acciones paso a paso porque no puedes solucionar el problema sin intentar aligerar antes la carga. Es por ello que el principal objetivo de los ingenieros de GitHub en ese momento era liberar todo el tráfico que estaba causando este destrozo.

8:37 Es como intentar arreglar una tubería por la que todavía está pasando agua a presión. Quizá necesitas desmontar toda la tubería, pero no puedes hacerlo porque si lo haces se va a inundar la casa. Lo que hicieron los ingenieros de GitHub fue redirigir la mayoría del tráfico desde Estados Unidos central, central US a el norte de Virginia, es decir, cambiaron de región. Esto en la mayoría de arquitecturas cloud se puede hacer de una manera sencilla si tienes la infraestructura preparada para ello.

9:04 Por ejemplo, puedes hacerlo a nivel de DNS, es decir, que el dominio en vez de resolver a las IPS de la región de Central US, resuelva a las IPS del norte de Virginia. Esto sería una forma práctica de implementar algo parecido. En el momento en que mandaron el tráfico hacia el norte de Virginia, la mayoría de usuarios ya empezaron a ver cierta recuperación del servicio. Al apagar el agua de la tubería que estaba afectada, dio aire y tiempo a los ingenieros de investigar e intentar encontrar una reparación correcta para lo que estaba sucediendo en Central US. lo que hicieron fue pausar los servidores de Happroxy y hacer una pull request para cambiar la configuración de concurrencia del SIDCard de Istio.

9:48 De esta forma, cuando volvieras a activar el agua, cuando volvieras a activar el tráfico, estos servidores podrían crecer y, por lo tanto, no tener el error. Pero los ingenieros de GitHub pocos esperaban que un error les persiguiera. Y es que ya habíamos dicho que el sistema de reintentos y un bug en BS Code había hecho que este problema se complicara todavía mucho más. Básicamente lo que pasó fue que al mover el tráfico al norte de Virginia, obviamente los clientes siguieron haciendo todo el reintento de todo el tráfico pendiente que había dado errores durante las 3 horas anteriores.

10:23 Es decir, desconectaste una tubería que estaba recibiendo agua a presión, la conectaste a otro sistema, a otro objetivo, pero la parte de los clientes, lo que sería el grifo, seguía enviando agua sin parar y cada vez con más presión. haciendo, por lo tanto, que el norte de Virginia fuera ahora la región que tiene problemas. Concretamente dicen que la región del norte de Virginia recibió 10 veces más tráfico de lo esperable por culpa de este error en los reintentos,

10:55 concretamente de el sistema de tokens de Copilot, básicamente el servicio que se encarga pues de gestionar los tokens que utilizan los agentes de IA, de autenticar los diferentes agentes de IA que se están utilizando en BS Code y en otras plataformas de Microsoft. Por lo tanto, la afectación en sistemas de Copilot en BS coe fue enorme. Esto obligó a los ingenieros a precisamente implementar un arreglo, un fix que limitara el número de reintentos o ellos comentan la lógica de reintentos dentro de este servicio.

11:27 Y para poder tener también un poquito más de tiempo y limitar la afectación de esta saturación a otros servicios de GitHub, utilizaron una técnica que se utiliza muchísimo para limitar los errores en sistemas distribuidos. Un Circuit Breaker, un rompedor de circuito es básicamente bloquear una parte de tu infraestructura para que no reciba tráfico porque está afectada.

11:50 Este ejemplo de GitHub es claro. Tenemos un error en cascada que por culpa de una saturación de un punto concreto del sistema hace que el resto de partes del sistema también se vean afectadas. Por lo tanto, si yo genero un circuit breaker y por lo tanto hago que el servicio de tokens de Copilot ahora no intente hacer cosas hacia abajo, sino que directamente devuelva un 403, que es lo que hicieron los ingenieros de GitHub, consigo que el error quede contenido solamente en esa parte del sistema.

12:20 Esto lo haces en la capa de Load Balancer, que es muy barata, directamente responde 403 a todas las peticiones y te da tiempo a arreglar lo que hay por detrás. Sería algo así como tener una subida de tensión y cuando te saltan los plomos de casa, precisamente para no afectar a los ordenadores o al material que tienes conectado a la red. En este caso, los plomos actúan como un circuit breaker, pues lo mismo implementamos en sistemas distribuidos.

12:46 Aplicando este circuit breaker y habiendo cambiado la lógica de reintentos en la parte del gateway, lo que consiguieron fue reducir el ratio de errores de una forma drástica. Obviamente, algunas puntilladas de tráfico todavía estaban recibiendo errores, pero hacia las 89 UTC ya empezaron a ver que el sistema se había recuperado, pudiendo de nuevo recuperar todas las regiones y el tráfico de forma normal. Entonces, como ves, mantener sistemas distribuidos no es algo fácil, es muy complejo, más aún si son sistemas con una alta carga no solamente de lectura, sino también de escritura, como es el caso de GitHub.

13:22 Y es que mucha gente en Twitter estuvo comparando la caída de GitHub, en teoría, por el uso de IA, ¿no? Por la gran cantidad de datos que genera la IA con YouTube, diciendo que YouTube también es un sistema que está recibiendo un montón de vídeos y de shorts hechos con IA, pero que en cambio YouTube no se caía como GitHub. Y a pesar de que entiendo que la caída de GitHub es bastante molesta, es muy pesada y bueno, pues está bien poder consultar en alternativas, también creo que se tienen que hacer comparaciones lo más justas posibles y el producto de YouTube y el producto de GitHub son totalmente distintos.

13:55 YouTube es un producto con alta necesidad de lecturas. Sí cierto que está ingestando millones de gigas de vídeo cada minuto, pero el problema principal de YouTube es la distribución de ese contenido hacia fuera. Es decir, tiene dos vías totalmente separadas entre lo que es ingestión de contenido y distribución de contenido, que además puedes hacer con cachés y con CDNs. En cambio, GitHub tiene ambas. Ahora mismo no solamente está recibiendo un montón de escrituras de código que antes no recibía ni por asomo, sino que además hay un montón de agentes de inteligencia artificial que están constantemente leyendo repositorios, leyendo código de GitHub, intentando publicar nuevas páginas web para tener también distribución y utilizando sistemas soportados por GitHub para autenticar agentes, etcétera, etcétera.

14:39 Es decir, son cosas bastante diferentes, a mi parecer. De hecho, tengo un vídeo donde hablo de sistemas distribuidos y hablo específicamente de la diferencia entre sistemas de alta lectura y sistemas de alta escritura. Te lo dejo en la descripción porque creo que puede ser interesante. Ahora bien, es cierto que GitHub, como hemos comentado, está perdiendo la confianza de la mayoría de trabajadores en esta era en la que todo el mundo quiere utilizar sistemas de inteligencia artificial para programar y la competencia lo sabe y no se quedan sentados de manos cruzadas.

15:07 De hecho, durante el tiempo en el que duró esta caída de GitHub, Cursor presentó oficialmente Origin, su nuevo sistema de repositorios de código para la era agéntica. Yo no sé si tenían ya programado sacarlo eh justamente en estas fechas o si aprovecharon que Ghub estaba caído y que había tanto ruido en redes sociales para hacer la publicación. Pero en definitiva creo que es algo que les funcionó bastante bien. Es una muy buena jugada de marketing. Por lo tanto, creo que también es interesante ver qué movimientos tiene Ghub planteados a futuro para intentar adaptarse a esta nueva realidad y ver si realmente hay partes de su infraestructura que son incapaces de aguantar la realidad que existe hoy en día en este tipo específico de producto.

15:50 Insisto, se trata de un tipo de producto, repositorios de código que estaba pensado asumiendo que eran humanos los que iban a ejecutar y escribir este código. Por lo tanto, esta asumción ha cambiado desde la propia concepción de la programación y por lo tanto los productos se tienen que adaptar y adaptar infraestructura no siempre es tan rápido como a todos nos gustaría. Te dejo el post original de GitHub en el que habla de los diferentes planes que tienen para futuro y de los cambios que están intentando realizar.

16:20 Básicamente están poniendo un montón de esfuerzo en tener redundancia de servidores, mejor monitorización y capacidad de cambio entre regiones para intentar redirigir tráfico sin que eso suponga que se caiga para todos los usuarios, además, obviamente, de intentar aumentar la capacidad de los balanceadores de carga. Entonces, ¿qué te parece esto? ¿Sigues teniendo confianza en que GitHub sea capaz de recuperar su imagen eh delante de los desarrolladores que están viendo que se cae constantemente? ¿Te ha parecido interesante ver la resolución y la explicación del problema que han compartido de forma pública?

16:53 De nuevo, considero que una de las mejores formas de aprender es leer documentos y artículos como este, no solamente de GitHC, sino de otras plataformas tecnológicas. Al final, ver por qué se originan los problemas te va a permitir aprender a futuro a evitarlos. Y como siempre digo, entender los problemas de raíz nunca va a ser molesto, siempre te va a aportar más valor que no hacerlo. Te dejo un vídeo por aquí sobre diseño de sistemas si quieres ver algunos de estos conceptos con más detalle a alto nivel.

17:22 Y sin mucho más, nos vemos en el siguiente vídeo con más informática. Hasta otra. M.