edición general
263 meneos
2628 clics
GitHub se cae, dejando sin repositorios a miles de desarrolladores

GitHub se cae, dejando sin repositorios a miles de desarrolladores

GitHub ha caído la mañana de este lunes, dejando así a miles de desarrolladores sin acceso a sus proyectos. La plataforma, adquirida por Microsoft hace cerca de dos años, se encuentra con dificultades para prestar servicio.

| etiquetas: github , caida , servidores
«12
  1. A esta hora, sigue off..
  2. Normal, Microsoft no puede estar a todo, o hacen chips o mantienen GitHub
  3. #2 Los de IT están ayudando a meter las nuevas XBOX en las cajas.
  4. Ay a los que dependan de "la nube"
    Marronazo
  5. #3 pues será por zonas... he renovado todo lo renovable, DNS, Caché... tocará esperar pues.
  6. Dios mío y de dónde voy a copiar yo ahora todos mis desarrollos y cobrarlos a mis clientes como si los hubiese programado yo... :troll:
  7. #6 no se, me va tanto en local (movistar) como en remoto (ovh francia)
  8. Eso es por cambiar master a primary :troll:
  9. #2 Si eso les mantiene apartados de poner actualizaciones a Windows 10 casi mejor. :troll:
  10. #12 Eso es de lo mas preocupante, saber que tendremos que adelantar nuestros despertadores media hora para que se puedan actualizar los chips antes de iniciar el dia
  11. #11 Juraría que hay un paquete para realtek (rtlwifi) o tu wifi es muy nueva o muy rara. ¿Usb?
  12. Cual es el error ¿Un BSoD en verde o en azul?
  13. Lo moverían a Azure... :troll:

    Que prueben con AWS
  14. #1 Ahora (13:15h) a mi me va...

    github.com/mcwhorpj/demoImages
  15. Dejarían el mantenimiento al departamento de actualizaciones de Windows 10...

    Salu2
  16. #11 GitHub nació de forma independiente en 2008, y hace dos años, en 2018, fue comprado por Microsoft, aunque ya llevaba bastantes años siendo el repositorio de la mayoría de proyectos de software libre.
  17. Primer dia de la migración de github a servidores con windows....
  18. Pero se supone que mientras no tengas que subir los cambios con la copia local de tu equipo tiras no?
  19. Seguro que los servidores están mostrando la pantalla azul de la muerte. Aún estarán reiniciándolos... (o instalando la ultima actualización de Windows 10).
  20. #16 Tengo entendido que Azure no es tan malo. Yo de Azure lo único que he usado es su servicio Cognitive para detección de lenguas de textos.
  21. #2 Chips & fish
  22. Que pena... hace tiempo que me cambie a gitlab
  23. #26 chiss uns fisss
  24. #5 no soy muy partidario de la nube, al menos de las controladas por terceros. Pero en tecnología siempre hay dependencias, en un entorno sin nube o de nube privada se pueden romper switches, balanceadores de carga, u otras tantas cosas que también te fastidian el trabajo.
  25. Mejor eso a que los dejen sin supositorios...
    (Perdón).
  26. #31 cuestión de gustos. Solo era un chascarrillo
  27. #15 En Azure, siempre en Azure xD
  28. #2 Chips Microsoft ?.
  29. #16 Yo he trasteado poco con esos servicios pero los compañeros que tengo siempre me han dicho que Azure va bastante bien. En parte si AWS tiene más cuota es porque salió antes y como funciona bien suele haber pocos motivos para asumir costes de migración.

    Warning: este comentario se basa en opiniones de terceros, puede no ser 100% correcto
  30. #27 Bueno, gitlab sigue conservando su puesto en el top de caídas míticas con su rm -rf en producción xD

    www.theregister.com/2017/02/01/gitlab_data_loss/
  31. Pues mejor para la humanidad.
  32. ¿Por una caida temporal ya tenemos noticia en portada?

    Si pusiéramos todas las de bitbucket íbamos a colapsar Meneame.
  33. El día que Microsoft tenga un producto que no se cuelgue será cuando fabriquen perchas.
  34. #8 Mientras las licencias sean libres y se lo expliques a los clientes, si el precio les parece correcto para el soft y soporte que reciben no habría ni que poner la cara de troll.
  35. #1 #17 A mi también me chuta ya, pero me ha dado una mañanita...
  36. #40 Lo raro con bitbucket es que estén todos los servicios en marcha
  37. #2 Querrás decir chis.

    Las fuerzas del mal, las fuerzas del mal, nos quieren controlar con un chis. con un chis, con un chis chis chis.
  38. #36 Para las vacunas del 5G
  39. #36 Claro. Los que introducen en las vacunas para controlarnos remotamente.
  40. :troll: algo tenía que aportar Microsoft...
  41. #42 me has hecho reír cabrón ja ja ja
  42. #13 Actualizando sus chips, no se despierte todavía....... no hemos podido actualizarle, deshaciendo cambios.

    Microsoft respuestas: ejecute sfc... dism... (da igual lo que preguntes).
  43. #30 Pues ya sabes no formatees ni reinstales el driver hasta que funcione github, y haz backup del instalador, tar.gz etc...

    Pd: A veces en Debian testing suelen quitar paquetes, no sé si es porque tienen muchos bugs o rompen algo, generalmente drivers o firmware.(Y por una vez parece librarse nvidia).
  44. -Pasó algo muy malo
    +¿Se ha caído stackoverflow?
    -No
    +¿Se ha caído github?
    -Sí
    +¿Pero a stackoverflow no le pasa nada?
    -Ahá
    +Entonces no importa
  45. #43
    Me has dejado igual. A ver, a no ser que sean megaproyectos si 2 menganos estan programando pueden seguir igual hasta que tengan que subir el codigo y les toque ver los posibles conflictos. Sin saber mucho de git.
  46. #32 La diferencia es que la rotura de un switch en una nube privada te jode a ti; la misma ruptura en "la nube" jode a miles de usuarios.
  47. #5 En este caso no veo en que te afecta, git es distribuido y no necesita para nada conectarse a otro sitio para poder trabajar, así que lo de que deja a miles sin desarrolladores sin repositorios es una exageración de cuidado.
  48. #5 Si tu solo eres capaz de administrar un servidor fisico para tener un uptime del 99% te felicito pero la mayoria no puden www.githubstatus.com/uptime
  49. #37 En realidad es un "disclaimer", no un "warning"... :-D :troll:
  50. #60 y no nos olvidemos, con millones de usuarios.
  51. #25 ahora usan Linux azure así que normal que no sea tan desastre.
  52. Estamos locos? Los programadores vamos a tener que resolver nuestros propios problemas!!!
  53. #2 Hoy apenas se ha caido un par de horas. Si siempre que se cae lo tenemos en portada tendríamos más noticias de Github que de Vox...  media
  54. #45 Ironía de la vida pero esa noticia me hara ganar algo mas de pasta este mes o el que viene.

    Hace años que aviso a muchas empresas que no es buena idea tenerlo todo en GitHub. Los jefes de desarrollo siempre me han llevado la contraria.

    A ver cómo lo defiende en la siguiente junta de directivos, xD Si me dejan hacerlo, muchos acabarán despedidos por irresponsables e ignorantes sin ninguna duda.
  55. #62 #60
    Tener un mirror local/Corporativo en un servidor que apenas tiene un centenar de usuarios para cuando "la nube peta" no sólo es fácil. Es fácil y barato.

    Usar "la nube" no quita curràrtelo un poco para no quedar en bragas.
  56. #58 Pasar cambios de un usuario a otro pasa de ser fácil a engorroso de cuidado si no has previsto una alternativa.

    Siempre puedes hacer un targz con el repo y mandarlo por email, pero es algo coñazo ;)
  57. #69 No lo veo viable en proyectos medianamente serios. En proyectos de juguete, pues si.
  58. #70 tan no-viable que muchas empresas lo hacen. Instancia "nube" de bitbucket e instancia "in-house" del mismo software. Sincronizados entre si.

    Por poner ejemplo que use cada día.

    (En este caso no es "barato" por eso de que son miles de usuarios, no cientos ;) )
  59. GitHub se cae y… no, no deja sin repositorios a los desarrolladores porque los repositorios de Git son locales.

    Vamos, que los desarrolladores van a poder seguir trabajando sin ningún problema. Lo que ha dejado de funcionar son los pull requests (peticiones para mezclar código), cosa que se puede hacer por infinidad de otros medios (por correo, como hacen con Linux, por ejemplo), y alguna que otra característica como los builds/deploys automáticos.

    ¿Que es una putada que GitHub se caiga? Por supuesto. Pero ni de coña impide trabajar a los desarrolladores ni estos se quedan sin repositorios.
  60. #67 Tampoco creo que tener un sistema propio te libre de estas cosas... de todas formas mi organización es tan bestia (en tamaño) que cambiar eso es utópico xD
  61. Las ventajas de la nube...
  62. #69 Distribuir un repositorio git que tengas es trivial, para eso está el git daemon, si quieres hacerlo ligeramente más complica usar claves SSH son un par de comandos más, así que no debería llevar más de 5 minutos reemplazar GitHub por otra máquina, sea de un desarrollador u otra que se tenga a mano. Una vez que tienes eso puedes hacer pull request, push o lo que se decida con los mismos comandos git, cambiando el remoto por supuesto. Yo lo he hecho un par de veces cuando el repositorio "principal" dejaba de funcionar por la razón que fuera y como solución de emergencia funciona perfectamente y es rápida de aplicar.

    Si quieres hacer un tar.gz no lo haces del repositorio, lo haces con un patch, que también lo soporta nativamente git, por ejemplo se usa en los repositorios de Linux para enviar parches, y bueno, se inventó para eso y el tipo que lo inventó lleva las dos cosas, así que digamos que es un flujo más que probado y aceptado.

    #70 Dudo mucho que haya mucha gente que trabaje en proyectos más grandes y descentralizados que Linux y usan parches para distribuir cambios, solo tienes que ir a la lista de correo del kernel y buscar PATCH para encontrarlos. Y no creo que Linux se pueda calificar precisamente como proyecto de juguete.
  63. #67 >99.5 de UpTime o eres un cuñado y has venido aquí a decir 4 palabrejas e ir de guay, o eres un cuñado que no sabe relativizar y como alguien dependa de tus sandeces...

    Seguro que consigues mejor UpTime que GitHub/GitLab/BitBucket, segurísimo.

    Por otra parte ya me dirás quien os quita tener repos propios en remoto y que se pusheen los cambios a ambos remote :roll:
  64. #67 me temo que como tu mayor argumento sea esta noticia los jefes de desarrollo van a seguir llevandote la contraria. Lo siento por tu cuenta corriente.
  65. Vamos a ver. Muy mastuerzo has de ser para no poder centrarte 2-3 horas en el repositorio local. Yo hoy no me he enterado.

    Ya son ganas de buscar el click fácil. Vaya notición
  66. Realmente parece que fué algo de caché de IPs v4. Yo cambiando la Ip de salida me funcionó (6 A.M.). Sigo ok.
  67. #57 Git es distribuido; si los desarrolladores saben usarlo bien, el único problema será el acceso a documentación o issues, y eso debería bastar para no quedarse bloqueados durante la caída, que no durará mucho previsiblemente.

    Si no puedes trabajar sin un servicio remoto, algo está mal en el pipeline.
  68. #69 o montar otro servidor de git y estar listo en minutos
  69. #75 #71 Se que hay muchas chapuzas por ahí y muchas empresas lo hacen, sin duda. Tampoco quería decir que no sea viable, técnicamente, pero es que un procedimiento de extracción manual de código y enviado en un zip o un tar a un email me parece cuanto menos peligroso. Desde luego que todo se podría automatizar vía Scripts y así le daría un voto de confianza, pero eso de tar, y luego adjuntar al email y luego el otro abriéndolo, no lo veo. Seguro que en no demasiado tiempo habría inconsistencias, descontrol en las versiones etc, etc...
  70. Es hora de tener otro espacio a git
  71. #76 Yo no he dicha que lo haga yo. Me refería que quiere echarles y contrata una empresa más seria y con más experiencia básicamente.
  72. #73 Este es el principal problema.
  73. #84 pero que empresa más seria, no te montes películas que caídas las tiene cualquier otro servicio. Lo único que puedes hacer es redundar con algún mirror para evitar caídas de... ¿Un par de horas y muy puntuales? Ya lo tienes que justificar bien justificado en esa junta de accionistas :roll:
  74. #82 No es una chapuza, es como está pensado el proceso por el que inventó git y es como se usa en los repositorios de Linux. Git, el binario, tiene comandos para hacer eso, format-patch te crear el parche en el formato apropiado, send-email lo envía, y am aplica un patch desde un mailbox. El flujo no es enviar un correo, que alguien lo reciba y lo aplique a mano, el cliente de git lo gestiona todo.
  75. Pues sera casualidad ,pero nuestro servidor de gitlab local en la empresa estuvo tambien tontorron hoy , y la unica manera de que nos dejara conectar era conectar en remoto al server donde estaba alojado y hacer un ping a la maquina cliente , y a partir de ahi , a funcionar el interfaz web tan pichi...
  76. #76 Ahí tienes un 99.81% sin ir mas lejos, atlas.ripe.net/probes/18273/#!tab-network, en los últimos casi 6 años.

    Salu2
  77. #80 Hombre, sí... git es distribuido... a nivel de la parte de código. Pero las listas de bugs, por ejemplo, eso está en el servidor. Y más cosas.
  78. #67 Se trata de un problema de service continuity... has hecho muy bien reportando que confiar en un tercero para la provisión de un servicio entrañaba un riesgo, lo que pasa que tal como lo has planteado queda un poco “cutre”: “No es una buena idea”.

    Vamos a presentarlo un poco decente pues...

    Existe un riesgo de impacto en las tareas de ¿desarrollo? Y se recomienda establecer el servicio de “xxxx?” por medios propios mediante el aprovisionamiento de “?”
    A1-. Coste de Licencias: xxxxxxx mil euros/año
    A2- Coste de infraestructura: xxxxxx mil euros/año
    A3- Coste en personal desarrollo, implantación y mejora continua: xxxxxx mil euros/año
    B1- Coste en personal operaciones: xxxxx mil euros/año
    B2- Coste en formación y transición: xxxxx mil euros/año
    C1- MTBF: xx días
    C2- MTTR: xx horas
    Z- Coste por hora de interrupción

    Coste servicio: Sum(Ai) + Sum(Bi) + ( f(Z, C1, C2) ) euros/año

    Si realmente se han aterrizado estos números para la solución actual de tu empresa, y tu propuesta alternativa, siendo claramente favorables estos números en tu alternativa, y no se ha optado por ella, no es que vayas a ganar mucho dinero, es que realmente deberías irte ya, porque tu empresa está abocada a la ruina.

    Suerte con ello!
  79. #73 No te libra, simplemente manejas tu el riesgo y el impacto
  80. #73 No sería utópico, simplemente sería (jodidamentr) caro 8-D
  81. #89 no entiendo a qué viene el enlace
  82. #94 Normal
  83. #95 sí, porque es un manzanas traigo de manual :roll:
  84. #96 No me digas? Es una sonda Atlas del Ripe, da información del SLA entre otras cosas de forma pública de muchos proveedores de servicio y de quien pida una, son gratuítas, y es mas del 99,5 que mencionas como que es imposible. Te demuestro que no lo es, si te he entendido mal, disculpa.

    Salu2
  85. #97 Nadie ha dicho que sea imposible dar más de un 99.5%, de hecho el mismo GitHub del que se está hablando lo hace en la práctica totalidad de los meses (no conozco el % historico de los últimos 5 años pero me imagino que estará por encima del 99.8 viendo los historicos mensuales que son por lo general un 100% desde 2014).

    La conversación iba de servicios de control de versiones y contestaba a otro usuario porque me pareció muy graciosa su intervención de "ya lo decía yo en las juntas de directivos, que era malo tener las cosas en GitHub, si por mi fuera estarían todos despedidos". Simplemente le señalaba que GitHub tenía más del 99.5% (99.5 porque es ligeramente peor que el peor de los últimos meses de GitHub: 99.67) y que me parecía un ejercicio de fantochería supina su intervención, como si fuese a conseguir un Up Time claramente mejor que GitHub con otra solución o fuese un motivo relevante para desperdiciar el dinero que supone migrar a otro sistema de control de versiones en una organización.
  86. #98 Gracias por tomarte el tiempo en aclararloaclararlo, pero no veo porqué no puede tener un uptime mejor si se lo curra.
  87. #99 No digo que no pueda, repito, no iba por ahí el mensaje. Estaba dirigido hacia el "oh dios mío, llevo años diciendo que no era buena idea tener todo en GitHub y los jefes de proyecto no me hacían caso, cambiaré a todos los equipos de desarrollo y contrataré a otros más competentes" que dijo el otro usuario, como si GitHub hubiese tenido una caida de varios días o como si la caida puntual de una hora un mes justificase su "¡te lo dijeeeeeeee!".

    Mira que hay razones para no tener el código en GitHub (privacidad, por ejemplo) pero no creo que el Up Time sea una de ellas.
«12
comentarios cerrados

menéame