Está bien tener la página de estado en un dominio separado por disponibilidad, pero no está nada bien que no actualicen esa página de estado cuando el dominio principal se cae
Ese tipo de páginas se actualizan manualmente más seguido de lo que uno pensaría. Y muchas veces lo hace la persona de guardia, que ya tiene demasiadas cosas más urgentes que atender
Puede que también se haya caído la tubería que actualiza la página de estado
Siento que fallas así pasan casi cada 2 semanas. ¿Qué le está pasando a GitHub últimamente?
Parece que agregan funciones nuevas como Copilot, pero no invierten lo suficiente en la confiabilidad del sitio
Si no hay cambios, es relativamente fácil mantenerlo estable con solo corregir bugs. Los cambios, o sea las funciones nuevas, traen bugs nuevos y carga nueva
Alguien debe haberse olvidado de poner node_modules en .gitignore
¿Será que la gente que no encajaba con el estilo de gestión de Microsoft encontró otro trabajo?
¿Estarán probando gpt4-ops?
¿Ineptitud de Microsoft + DDoS?
Tal vez no era tan buena idea meter todo nuestro open source en un solo lugar >_<
En la práctica, quizá lo único que cambia es que en algún momento terminas deseando “ojalá hubiera estado del otro lado”
Intuitivamente parece mejor que el 1% del total esté caído el 100% del tiempo, en vez de que el 100% del total esté caído el 1% del tiempo, pero no sé cuál de las dos opciones es realmente más práctica. Claro, si quieres puedes hacer mirroring, pero eso ya se podía hacer antes, así que no es el punto central
La idea clave de un sistema de control de versiones distribuido es que toda persona que hizo git clone tiene una copia completa del repositorio y puede hacer la mayoría del trabajo sin comunicarse con el servidor central
Un downtime corto afecta más a la infraestructura alrededor del código real, o sea al flujo de trabajo, los issues, etc.
Honestamente, es mejor que todo esté en un solo lugar. Es mejor que toda la industria se detenga al mismo tiempo a que personas aleatorias se queden paradas en momentos aleatorios
Es parecido a cuando se cae us-east-1. Como todos estamos en el mismo barco, todos descansan al mismo tiempo y hasta tienes una excusa legítima para tomártelo con calma un rato
Tener todo el código de la empresa ahí sí es una buena idea. Te regala un descanso gratis
El principal punto de venta de GitHub no era la distribución. Cuando me uní en 2008, se sentía más como una red social donde se reunían desarrolladores
Parece que ya volvió. Me gustaría ver un análisis profundo de las fallas recientes y escuchar una garantía de que van a priorizar la estabilidad por encima de las funciones nuevas
Hace unos meses hablé con alguien de soporte al cliente y casi le echó la culpa a todo el trabajo personalizado que hacen para clientes grandes, diciendo que eso reduce la estabilidad. En consecuencia, parece que tienen una deuda técnica enorme acumulada
Para correr una instancia de GitHub Enterprise necesitas como 64 GB de RAM. Es un monstruo enorme
Ese tipo de trabajo personalizado puede llevar a errores o a que algunas funciones fallen. Pero que se caiga todo el sitio, especialmente contenido estático como GH Pages, es totalmente un problema de SRE
Esto probablemente tenga más que ver con routing de red u otro error de capa 4 o inferior. La mayoría de los cambios de aplicación salen con despliegues graduales y canary deployments, y si algo sale mal normalmente se puede hacer rollback bastante rápido
Parece que esta falla también afecta a GitHub Pages. Las páginas .github.io muestran la página 503 del unicornio
We're having a really bad day.
The Unicorns have taken over. We're doing our best to get them under control and get GitHub back up and running.
Wow, ni siquiera puedo cargar la página de estado. Parece que toda la web se cayó, y ni me acuerdo cuándo fue la última vez que se cayó todo así
¿Qué usan para aislarse de este tipo de problemas? Agregar un caché para lecturas suena inteligente y además mejora el rendimiento. Si alguien logró evitar bien el impacto, estaría bueno que lo compartiera
En un trabajo anterior, la configuración de “GitOps” de una organización hacía mirroring de GitLab hacia AWS CodeCommit y usaba eso como única fuente de verdad para la automatización
Esa decisión demostró varias veces haber sido acertada, y no recuerdo problemas notables con CodeCommit. Pero si en el proceso real de desarrollo usas GitHub como forge, con issue tracker o PR para revisión, no se me ocurre una gran forma de aislarte por completo
En mi trabajo anterior había un GitHub Enterprise alojado localmente, y cada vez que en Twitter todos decían “¡se cayó github! ¡salimos temprano hoy!”, yo siempre sentía que me estaban estafando :(
Claro, seguía siendo molesto si alguna herramienta pedía actualizar dependencias que estaban en GitHub normal, pero al menos las cosas relacionadas con despliegues y demás seguían funcionando
Pausa para café
git fue diseñado justamente para poder usarse offline, así que usa el clon local que ya tienes
La página de estado acaba de cambiar:
Investigating - We are currently experiencing an outage of GitHub products and are investigating.
Jun 29, 2023 - 17:52 UTC
Hasta lectura está en rojo. Creo que es la primera vez que veo todos los indicadores en rojo en la página de estado
1 comentarios
Comentarios en Hacker News
https://downdetector.com/status/github/
Si no hay cambios, es relativamente fácil mantenerlo estable con solo corregir bugs. Los cambios, o sea las funciones nuevas, traen bugs nuevos y carga nueva
node_modulesen.gitignoreIntuitivamente parece mejor que el 1% del total esté caído el 100% del tiempo, en vez de que el 100% del total esté caído el 1% del tiempo, pero no sé cuál de las dos opciones es realmente más práctica. Claro, si quieres puedes hacer mirroring, pero eso ya se podía hacer antes, así que no es el punto central
git clonetiene una copia completa del repositorio y puede hacer la mayoría del trabajo sin comunicarse con el servidor centralUn downtime corto afecta más a la infraestructura alrededor del código real, o sea al flujo de trabajo, los issues, etc.
Es parecido a cuando se cae us-east-1. Como todos estamos en el mismo barco, todos descansan al mismo tiempo y hasta tienes una excusa legítima para tomártelo con calma un rato
Hace unos meses hablé con alguien de soporte al cliente y casi le echó la culpa a todo el trabajo personalizado que hacen para clientes grandes, diciendo que eso reduce la estabilidad. En consecuencia, parece que tienen una deuda técnica enorme acumulada
Esto probablemente tenga más que ver con routing de red u otro error de capa 4 o inferior. La mayoría de los cambios de aplicación salen con despliegues graduales y canary deployments, y si algo sale mal normalmente se puede hacer rollback bastante rápido
.github.iomuestran la página 503 del unicornioEsa decisión demostró varias veces haber sido acertada, y no recuerdo problemas notables con CodeCommit. Pero si en el proceso real de desarrollo usas GitHub como forge, con issue tracker o PR para revisión, no se me ocurre una gran forma de aislarte por completo
Claro, seguía siendo molesto si alguna herramienta pedía actualizar dependencias que estaban en GitHub normal, pero al menos las cosas relacionadas con despliegues y demás seguían funcionando
gitfue diseñado justamente para poder usarse offline, así que usa el clon local que ya tienesInvestigating - We are currently experiencing an outage of GitHub products and are investigating.
Jun 29, 2023 - 17:52 UTC