El clúster de Postgres de Fly.io estuvo caído durante 3 días, sin ninguna novedad al respecto.
(community.fly.io)- Durante un mantenimiento de emergencia (emergency maintenance) en hosts de Fly.io en julio de 2023, varias máquinas de usuarios quedaron detenidas en estado "stopped" y zombie, imposibilitando reiniciarlas, eliminarlas o volver a desplegarlas
- En el panel solo aparecía un banner de "Service Interruption", pero en la status page no había información relacionada, así que no se podía conocer la causa ni el ETA de recuperación
- Los comandos de
fly machinefallaban con el error "could not get machine", y enmachine listaparecían datos anómalos como fecha de creación "1970-01-01" - Algunos lograron una recuperación temporal levantando una nueva VM con fly scale, pero la VM dañada no podía eliminarse y existía preocupación por la facturación continua
- Tras más de 12 a 15 horas sin respuesta oficial ni actualización de estado, se deterioró la confianza en la plataforma
Inicio de la falla y síntomas iniciales
- Por la mañana empezaron a fallar los health checks de la app, y se confirmó que la máquina estaba en estado "stopped"
- En el panel solo se mostraba un banner de Service Interruption con el mensaje "We are performing emergency maintenance on a host some of your apps instances are running on", sin más información
- En la status page no aparecía esta incidencia, por lo que no se podía encontrar un procedimiento de resolución ni un ETA
- Al intentar reiniciar o eliminar la instancia detenida de la máquina, ocurría un timeout
- Al volver a desplegar, aparecía un error relacionado con máquinas unmanaged
fly deploysolo actualiza máquinas que tienenfly_platform_version=v2en los metadatos, por lo que había que actualizar cada máquina manualmente confly machine update --metadata fly_platform_version=v2 <machine id>
Estado de máquinas zombie y forma de rodearlo
- Algunas máquinas entraron en "zombie mode" y todos los comandos de
fly machinerespondían con "Error: could not get machine" - Se recuperó la disponibilidad de la app asignando una VM adicional con fly scale, pero la VM averiada quedó en un estado indeterminado y no se podía eliminar ni cerrar la cuenta
fly machine listmostraba datos incorrectos como fecha de creación "1970-01-01T00:00:00Z"- Otro usuario también evitó el problema escalando y creando una máquina nueva, pero la máquina original no podía eliminarse por un error "connection refused"
- Existía preocupación por la facturación tanto de las VM zombie no limpiadas como de las VM adicionales creadas
- El entorno de staging estaba en el mismo estado
Impacto en contenedores de base de datos
- Un usuario reportó el mismo problema desde hacía unas 14 horas, y como el objetivo era un contenedor de base de datos, no era posible recuperarlo solo escalando
- Había enviado un correo a soporte horas antes con un plan de pago, pero no recibió respuesta
- La app estaba alojada en la región syd, por lo que se mencionó la posibilidad de un problema en uno o dos hosts de esa zona
Impacto amplio y recuperación temporal
- Hasta el día anterior se operaban 4 máquinas entre app + Postgres (staging y producción), pero 3 seguían caídas, incluidas las dos bases de datos
- Como esa app era la API externa de la empresa, todas las integraciones quedaron interrumpidas
- Para mantener la operación, se creó un nuevo proyecto en Fly y se levantaron instancias nuevas; reconstruir variables de entorno y configuración tomó un par de horas
- Terminó siendo, sin querer, una prueba de la capacidad de DR (recuperación ante desastres)
- No había forma de extraer los datos de la máquina de base de datos, pero como no era la base principal de producción, se pudo reconstruir por ingeniería inversa lo necesario
Preocupación por la confiabilidad de la plataforma
- Se expresó sorpresa porque, tras 12 horas, seguía sin haber respuesta oficial
- Era la segunda vez que ocurría el mismo problema, y aunque el servicio estaba caído, Fly seguía reportando normalidad y no daba información ni respuesta, dejando como única opción esperar
- Comparación con Heroku: si un host se vuelve inestable, el dyno se migra automáticamente y no había que preocuparse por algo así
- La preocupación era que esto ocurrió incluso en una app estándar pequeña de Rails + Postgres; en una app más compleja, responder sería todavía más difícil
- Se afirmó que este tipo de problemas destruyen por completo la confianza en la plataforma
1 comentarios
Comentarios de Hacker News
Fly dejó una respuesta en el hilo de soporte: explicó que revisan el foro con regularidad, pero esta vez se les pasó esta publicación, y que hubo una falla de un solo host prolongada en la región syd
El host no volvió a la normalidad después de reiniciarse y tampoco se reconectó al service discovery, por lo que fue necesaria una recuperación manual
Las apps que corrían con varias instancias solo tuvieron algunas instancias afectadas, pero las apps de una sola instancia quedaron inaccesibles durante la falla, y Fly recomienda con fuerza una configuración con varias instancias
Dicen que las fallas globales o regionales se publican en status.fly.io, y los problemas de un solo host se han mostrado en la pestaña de estado del dashboard, pero que están revisando cómo comunicar interrupciones prolongadas de un solo host como esta
https://community.fly.io/t/service-interruption-cant-destroy...
Ni siquiera reiniciándola se recuperó, así que restauré un backup antiguo en RDS y sentí que hice bien en mudarme
Además, no suena como un simple contenedor de usuario sino como un servicio PostgreSQL administrado, así que parece aún más razonable esperar resistencia ante una falla del host
Sí pagaría unos US$5-10 al mes, pero no lo usaría para un side project que no quiero que sufra una caída de 3 días
[1] https://fly.io/docs/about/support/
Si la caída duró varias horas, yo diría que debieron haber levantado una máquina nueva con Ansible o lo que fuera. Habría sido posible, ya fuera con hardware o con máquinas virtuales de AWS/GCP
Parece que Fly intentó tapar este problema cambiando el hilo[1] a privado para quienes no han iniciado sesión
En el hilo había casos donde el servicio estaba caído pero el estado de Fly aparecía como normal, no había información y no se podía hacer nada más que esperar
Otro usuario dijo que tres de sus cuatro máquinas seguían caídas, incluyendo la app y PostgreSQL de staging/production, y que la app de API externa se rompió, arruinando todas las integraciones
Comentó también que le tomó horas crear un proyecto nuevo en Fly para levantar una instancia temporal, y que no pudo encontrar una forma de sacar los datos de la máquina de DB
También hubo una reacción diciendo que se siente insultante que la página de estado de la organización muestre “sin incidentes” mientras en esa misma página la app aparece en mantenimiento e inaccesible
Otra publicación decía que en 17 horas casi no hubo actualizaciones en la página de estado ni notificaciones, y que solo recibió alertas de Better Stack
Respaldo completo del hilo: https://pastebin.com/ebmCSZkC
Tuit enviado al CEO de Fly: https://twitter.com/SouthPawNZ/status/1682181533673857024
[1] https://community.fly.io/t/service-interruption-cant-destroy...
Lo peor de Fly es que cuando algo sale mal, no se rompe una sola cosa sino varias a la vez, y la página de estado sigue toda en verde
Por lo general, la respuesta también es el silencio o una actitud demasiado ligera, como “esto pasa cuando despliegas en viernes”
El producto se ve genial, pero da la impresión de ser el servicio de hosting más inestable que he usado, solo que muy bien empaquetado
No puedes arruinar el trabajo de la gente cada semana, hacer que pasen la noche del fin de semana recuperándolo, y luego cerrar con un “podríamos haberlo hecho mejor”. Eso sirve como excusa para una excepción, no para un patrón repetido
Este hilo de HN tiene mucho ruido, pero creo que el punto clave es este: al parecer los empleados ya estaban viendo el problema antes de que los clientes lo notaran, incluso después de enviar un correo al soporte de pago la respuesta tardó varias horas, y las actualizaciones sobre el host caído no llegaron hasta unas 20 horas después
No informaron adecuadamente a los usuarios afectados sobre la caída del host ni sobre cómo recuperarse, y aunque el dashboard mostraba mantenimiento de emergencia, la página de estado seguía marcando todo como normal
Entiendo que, por la naturaleza del plan y de la arquitectura, este tipo de downtime está garantizado y es común, pero si la comunicación es así de mala, van a perder clientes
Si al menos, como otros proveedores, me enviaran un correo apenas el host en el que estoy montado muestra algo raro, por lo menos podría hacer algo de inmediato con mi app
Aun así, hay opiniones divididas sobre si realmente eran lo bastante conscientes de que estaban en ese estado
Hubo una interrupción anormalmente larga en un solo servidor específico, y la combinación de esos factores hizo que mucha gente sufriera una caída prolongada sin explicación
El dashboard solo muestra caídas por región o servicio, no caídas de servidores individuales, y como la gente no lo sabía, lo interpretó como si les estuvieran mintiendo
El comportamiento raro de la configuración de etiquetas de Discourse hizo que pareciera que intentaban ocultar el problema
En resumen, diría que fue una mezcla de mala suerte, malos procesos desde la perspectiva de atención al cliente, y quizá algo de documentación insuficiente, pero hubo más humo que incendio
La línea de tiempo fue: host caído a las 2023-07-17 16:19 UTC, publicación en la página de estado personalizada a las 16:49, host recuperado a las 2023-07-19 15:00, y estado marcado como resuelto a las 15:17
[1] https://community.fly.io/t/new-status-page/11398
Fly.io no quería ser un clon de Heroku, pero por su marketing y su experiencia de usuario tan pulida terminó viéndose así
Como resultado, también terminó atendiendo a una base de usuarios estilo Heroku para quienes cada caída de un solo host puede representar un golpe fuerte a la marca
Como era un proyecto personal por diversión, no importó tanto, pero no sé si lo usaría para algo más serio
Además, me cuesta creer que haya tantos proveedores cloud como para llamar a 20 horas de downtime algo “garantizado y normal”
Lamentablemente, siempre he sentido bastante pasivo-agresividad en los hilos de HN relacionados con Fly.io
De verdad quería que me encantara Fly.io. Configurarlo y usarlo es facilísimo, pero sinceramente no creo que debas poner una aplicación de misión crítica sobre este servicio
Al final movimos todo a AWS, y la verdad no quería tener que hacerlo
Las máquinas con frecuencia no funcionaban, había fallas aleatorias, los builds fallaban, y aunque pagué un tier más alto por soporte, respondían lento y ni siquiera leían bien las preguntas
No puedes agregar sidecars, es difícil integrarlo con monitoreo externo, y la documentación está bien para el camino feliz pero se queda muy corta en los casos borde
Está bien para proyectos hobby, y de hecho todavía tengo muchos proyectos personales ahí, pero para infraestructura de empresa el costo en tiempo y frustración se volvió demasiado alto y tuvimos que migrar
Sonaba como el heredero espiritual de Heroku y por eso tenía grandes expectativas, pero todavía no está a ese nivel
La semana anterior sí compilaba, también funcionaba bien en local, y después más tarde volvió a funcionar en Fly, pero fue un downtime incomprensible sin explicación de la causa ni respuesta de soporte
El tier gratuito es muy generoso y te deja hacer bastante sin pasar el límite de cobro, pero yo tengo poco tiempo libre y en ese tiempo solo quiero compilar mi proyecto
Y eso que solo era un pequeño sitio estático compilado con Node
La herramienta en sí es excelente, así que si logran estabilizar la infraestructura me gustaría volver a probarla
Si con el mismo esfuerzo no pueden poner esa información en la documentación, no sé qué tan malo será su pipeline de documentación
Las respuestas a las preguntas del foro sobre uso deberían ser “está en la documentación, y si no estaba, la acabamos de agregar” y “si algo te confunde, avísanos y actualizaremos la documentación”
Tuve que meterme a revisar los logs de fly para ver que el proxy no podía llegar al servidor, y no había forma de que yo lo arreglara
Horas después publiqué el problema en el foro, pero no hubo respuesta ni señal de que alguien siquiera lo hubiera leído, y poco después se arregló como por arte de magia
Espero que les vaya bien, pero por esta falta de comunicación y la sensación de impotencia de no poder hacer nada, no voy a usar fly.io por un buen tiempo
Puede que no sea una respuesta muy satisfactoria, pero esto es más o menos lo que puedo decir personalmente: no tengo idea de por qué este hilo de nuestro sitio comunitario desapareció de la lista
Estoy viendo la UI de administración y hay un pequeño candado junto al post, pero la opción “unlist story” sigue apareciendo como clicable
Lo mejor que puedo decir es que estoy bastante seguro de que no hubo una orden de arriba para ocultar este hilo. El sitio es público y cualquiera puede crear una cuenta para ver el hilo
Pueden decir lo que quieran de nosotros, pero ocultar este tipo de cosas no es uno de nuestros defectos
Sobre el problema del servidor de Sydney, todavía no sé lo suficiente como para dar una respuesta útil a quienes estaban corriendo instancias ahí. Recién vuelvo de salir y apenas estoy poniéndome al tanto
Ahora que lo veo, todos los posts de la categoría app-not-working aparecen como “private”, y probablemente sea una configuración de la categoría. Aquí private significa que hay que registrarse con una cuenta de Discourse para poder verlo
El tono de esta respuesta y otras comunicaciones de fly.io, considerando la opinión pública sobre fly.io, da la señal de que faltan esos elementos
Si ya tienen más de 60 empleados y siguen teniendo tantos problemas, en términos humanos ya no se ve como un tono cercano sino como la señal de un negocio que no logra escalar
Para que un negocio B2B en crecimiento tenga éxito, necesita cosas como procesos y supervisión, pero viendo las otras respuestas parece que no quieren eso, y no es una buena señal
Si algo se rompe una vez, es un incidente; si se rompe dos veces, es mala suerte; pero si se rompe tres veces, el proceso está roto. Viendo los comentarios aquí, en Fly.io parece romperse mucho más que tres veces
No por la caída en sí, sino porque pueden pasar días antes de recibir soporte
¿Qué garantía pueden darle a la comunidad de que la próxima vez el soporte será mejor?
Hemos estado ejecutando https://changelog.com en Fly.io desde abril de 2022, y la arquitectura actual está en https://github.com/thechangelog/changelog.com/blob/master/IN...
En 15 meses en Fly.io, con una app Phoenix + PostgreSQL, hemos manejado más de 100 millones de requests y me cuesta encontrar motivos para quejarme
Algunas implementaciones fallaron y lo arreglamos reejecutando el pipeline; a inicios de julio de 2023, en Frankfurt, 9 mil requests devolvieron 503 durante 10 segundos; y una vez hubo un volumen que no se borraba durante un experimento con machines y desapareció al día siguiente
Hablamos seguido de nuestra experiencia con Fly.io en el pódcast Kaizen: https://changelog.com/topic/kaizen
Episodio del anuncio de la migración: https://changelog.com/shipit/50
PR relacionado: https://github.com/thechangelog/changelog.com/pull/407
También hablamos hace poco del plan de migración de apps v1 (Nomad) a apps v2 (flyd): https://changelog.com/friends/2#transcript-138
Me da pena que tanta gente no haya tenido una buena experiencia, pero creo que Fly.io va a seguir mejorando. Ojalá algún día esta etapa difícil se convierta en una buena historia
Un post que da esperanza: https://community.fly.io/t/reliability-its-not-great/11253
Me gusta mucho fly.io y quiero que tenga éxito. Están haciendo algo difícil, así que es normal que se rompan cosas
Pero la falta de comunicación es decepcionante, sobre todo porque fue algo que el CEO señaló directamente en marzo, en un gran post sobre confiabilidad en la comunidad, como algo que quería corregir
https://community.fly.io/t/reliability-its-not-great/11253#s...
Hemos venido mostrando fallas de host único en el dashboard de los usuarios afectados, y los problemas de plataforma/región en la página de estado, pero claramente hay una zona intermedia donde el estado que comunicamos y la experiencia real de los usuarios no coinciden
Últimamente agregamos mucho hardware para evitar problemas de capacidad y, como era de esperarse, bajó la probabilidad de caídas generales, pero aumentó la cantidad de fallas de hardware de este tipo
Podemos hacer más para ayudar a los usuarios a evitar estos problemas, para acelerar la recuperación y para avisar mejor cuando se vean afectados
Incluso cuando nos equivocamos en la comunicación, estamos escuchando este tipo de feedback
La señal de alarma más grande es que Fly aparentemente no tiene una forma automatizada de mover rápidamente las cargas de trabajo de un servidor averiado a uno sano
Y eso a pesar de que los contenedores y los orquestadores ya abstrajeron el concepto de volúmenes de datos conectables y desacoplables
Claro, ofrecer eso requiere una gran inversión técnica, y creo que esa es una de las razones por las que el almacenamiento es caro en los tres grandes clouds. Aun así, si vas a ofrecer un servicio de persistencia de datos, es una capacidad imprescindible
Hay una desalineación entre lo que Fly quiere ofrecer y lo que el mercado espera
Fly quiso innovar permitiendo ejecutar apps en varios data centers, pero sin un verdadero servicio de persistencia de datos, esa capacidad no le resulta útil a la mayoría
Parece que intentan resolver el problema de persistencia con replicación de SQLite, pero entonces la mayoría de los desarrolladores tendría que cambiar su forma de desarrollar apps para ajustarse a la plataforma de Fly
Fly tiene que elegir entre ser una alternativa estable y barata a Heroku, o proponer una forma propia de desarrollar apps que dé el mejor rendimiento a usuarios en todo el mundo
App Engine es un caso interesante. Se adelantó a su tiempo y prescribía una forma de desarrollo capaz de escalar a tráfico muy alto, pero la gente no quería cambiar su manera de desarrollar para adaptarse a eso
Ahora da la impresión de que apenas apagan un incendio ya se les prende otro, así que no inspira confianza en su hoja de ruta técnica
¿No hace ya como dos años que mucha gente puso a Fly.io en su lista de “revisar después”?
Cuando la gente percibe que algo es inestable, es realmente difícil recuperar la reputación, y en IT más todavía
La persistencia de datos funciona exportando snapshots de LVM automáticos cada 24 horas o creados manualmente a S3
De verdad no parece un lugar para correr cargas persistentes. Si vas a correr PostgreSQL ahí, necesitas estar preparado para cargar los datos en caliente en una nueva instancia o restaurarlos desde un backup
Por la misma razón llevo tiempo diciendo en HN que no usen Fly: https://news.ycombinator.com/item?id=31394179
Después de pedir que borraran mi cuenta, esta quedó en una especie de shadow ban sin ninguna comunicación
También les escribí por correo, pero hasta hoy nunca recibí respuesta, y después migré todo a apps en Railway y Google Cloud Run
¿Por qué una empresa te haría shadow ban solo por hacer una pregunta inocente?
Lo interesante es que con Fly.io siento que la historia se está repitiendo. Se parece a cuando conocí Heroku por primera vez
En sus primeros tiempos, Fly.io se sentía fresco e interesante, como Heroku cuando apareció por primera vez, y me impresionaban su simplicidad y facilidad de uso
Pero con el tiempo empezaron a aparecer pequeñas señales de problemas, el downtime se volvió más frecuente y los despliegues, antes rápidos y fluidos, pasaron a sentirse dolorosamente lentos
Es como un déjà vu de cuando Heroku empezó a perder sus ventajas
Me da pena que Fly.io parezca estar siguiendo el mismo camino en el que, mientras más gente llega a la plataforma, peor rinde, y mientras más popular se vuelve, menos estable parece
Se siente como una advertencia de cómo incluso una plataforma prometedora puede venirse abajo, y ojalá Fly.io logre salir de ese ciclo y afirmarse antes de volverse tan inútil como Heroku en su peor momento
Me hizo pensar que tal vez estaba sobreestimando la conciencia de la industria, y que si se volvía tan conocido como Heroku, era obvio que iba a atraer a gente que no quisiera pagar
Para volver a intentar una oferta gratuita generosa, necesitas una organización fuerte y costosa de prevención de abuso, o bolsillos lo bastante profundos como para inundar de hardware y soportar la ausencia inicial de eso
Fly no parece fuerte en ninguna de las dos cosas. Y en parte eso también me gusta. Esas cosas parecen tonterías corporativas de empresa grande, y Fly huele menos a eso
Pero no me sorprendería que los ingenieros de Fly estén dedicando la mayor parte de su tiempo no a la confiabilidad de infraestructura a largo plazo ni a la experiencia del desarrollador, sino a lidiar con criptomineros oportunistas, estafadores y abusadores, y a optimizar la asignación de recursos y los límites automáticos
Me pregunto si tendrá que ver con la escala. ¿Será que para cuando la empresa consigue suficientes clientes de pago como para volverse rentable o parecer invertible, al mismo tiempo ya acumuló suficientes problemas como para ir convirtiéndose gradualmente en ese viejo competidor al que al principio quería reemplazar?
Esa también fue mi experiencia. Cuando una empresa pasa de tamaño “unas cuantas pizzas” a nivel “ya reservamos un recinto para el evento”, la entropía empieza a colarse, y aforismos como la ley de Conway o la ley de Brooks se vuelven cada vez más evidentes