GitHub mueve sus bases de datos primarias a Azure tras un agosto de cinco incidentes
La primera primaria MySQL de producción corrió desde Azure el 11 de agosto sin impacto para los clientes. El resto del mes acumuló cinco incidentes y varios cambios de contención.
GitHub ha publicado el informe de disponibilidad de agosto y el balance no invita a la calma: cinco incidentes degradaron el servicio a lo largo del mes. La compañía reconoce que fue un mes duro y sostiene que está invirtiendo en mejoras arquitectónicas y en la migración a Azure para ganar capacidad. Su principio de trabajo, dicen, es disponibilidad primero, después capacidad y por último funcionalidades.
La primera primaria MySQL en Azure
El movimiento más concreto llegó el 11 de agosto: GitHub ejecutó por primera vez una primaria MySQL de producción desde Azure. El impacto en escrituras que observaron los clientes fue mínimo y no hubo afectación para los usuarios. El 27 de agosto repitieron el patrón con dos primarias más, y hay otras programadas en las próximas semanas, cada vez más complejas según lo que aprenden de cada conmutación.
El tráfico de lectura también marcó máximos: las lecturas de servicios migrados llegaron al 60,4%, las del monolito a un 64,3% en Azure y las de Git al 54%. Aparte de la migración regional, la cohorte de autenticación de 24 tablas salió de mysql1, la base de datos compartida más antigua de la compañía, lo que quitó cerca de un millón de consultas por segundo a sus réplicas. Otros cambios de higiene de consultas eliminaron 120.000 consultas por segundo y unos 59.000 segundos de trabajo de base de datos desperdiciado por hora.
Contención en Actions y pull requests
En GitHub Actions, cambios en el enrutado de jobs movieron el 33% de los trabajos desde un clúster de producción con problemas a capacidad libre. El uso de CPU de caché en pico bajó del 98% al 80%, lo que añade unos tres meses de margen. La propia compañía lo califica de medida de contención a corto plazo, no de meta final.
El aislamiento de pull requests siguió avanzando: las lecturas autenticadas del primer cohorte de producción alcanzaron el 100%. Las protecciones contra sobrecarga de Git sirvieron un 6,4% más de tráfico y mejoraron la duración del percentil 95 un 24% y el retardo máximo un 78%. Las defensas de descarte de carga en el borde también se usaron para mitigar los incidentes del mes. En observabilidad, la monitorización de pull requests ahora mide por separado fallos de merge, revisión y comentario, y el 21 de agosto arrancó la detección automática de incidentes de alto impacto combinando señales de soporte con telemetría.
El incidente del 6 de agosto
El peor episodio duró 10 horas y 42 minutos. Empezó con un despliegue rutinario en un servicio interno de GitHub Actions: el contenido no era el problema, lo revirtieron para confirmarlo, pero sustituir pods durante el rollout redujo la capacidad de un sitio y empujó a los demás por encima de su límite cuando el tráfico se repartió. Los sidecars del service mesh sufrieron throttling de CPU y reinicios por falta de memoria, y eso encadenó errores de caché, DNS y API en varios clústeres. Un bug latente en la asignación de jobs alargó la recuperación: los runners recibían trabajos ya revocados y se quedaban reintentando en lugar de coger trabajo válido, generando un backlog que se amplificaba solo. GitHub fue declarando los incidentes en su página de estado conforme ocurrían.
Queda trabajo por delante: mover las siguientes primarias, seguir migrando servicios y su tráfico a Azure, sanear las bases de datos compartidas y ampliar la automatización de capacidad y autoescalado.
