O cluster Postgres da Fly.io ficou fora do ar por 3 dias, sem qualquer notícia a respeito.
(community.fly.io)- Durante uma manutenção de emergência (emergency maintenance) em hosts da Fly.io em julho de 2023, houve um incidente em que máquinas de vários usuários ficaram presas em estado "stopped" e zumbi, tornando impossível reiniciar, remover ou fazer redeploy
- Apenas um banner de "Service Interruption" aparecia no dashboard, mas não havia informação relacionada na status page, então não era possível identificar a causa nem a previsão de recuperação
- Comandos
fly machinefalhavam com o erro "could not get machine", e dados anormais também foram observados, como a data de criação "1970-01-01" exibida na lista de máquinas - Alguns conseguiram uma recuperação temporária ao subir uma nova VM com
fly scale, mas a VM com problema não podia ser excluída, gerando preocupação com cobrança contínua - Após mais de 12 a 15 horas, ainda não havia resposta oficial nem atualização de status, o que levou à perda de confiança na confiabilidade da plataforma
Ocorrência da falha e sintomas iniciais
- Pela manhã, os health checks do app começaram a falhar, e a máquina foi confirmada no estado "stopped"
- No dashboard, aparecia apenas um banner de Service Interruption com a mensagem "We are performing emergency maintenance on a host some of your apps instances are running on", sem qualquer outra informação
- A falha não aparecia na status page, então não havia como encontrar procedimento de resolução nem ETA
- Ao tentar reiniciar ou remover a instância da máquina parada, ocorria timeout
- Ao fazer redeploy, surgia um erro relacionado a máquinas unmanaged
- O
fly deployatualiza apenas máquinas comfly_platform_version=v2nos metadados, então foi necessário atualizar manualmente cada máquina comfly machine update --metadata fly_platform_version=v2 <machine id>
- O
Estado de máquinas zumbi e formas de contorno
- Algumas máquinas entraram em "zombie mode" e todos os comandos
fly machinerespondiam com "Error: could not get machine" - A disponibilidade do app foi restaurada ao alocar uma VM adicional com
fly scale, mas a VM com defeito permaneceu em estado indefinido, impedindo sua remoção e até a exclusão da conta - O
fly machine listexibiu dados incorretos, como a data de criação "1970-01-01T00:00:00Z" - Outro usuário também contornou o problema criando uma nova máquina via scale-up, mas a máquina original não podia ser removida por erro "connection refused"
- Havia preocupação com cobrança tanto pelas VMs zumbi não limpas quanto pelas VMs adicionais criadas
- O ambiente de staging também ficou no mesmo estado
Impacto em contêineres de banco de dados
- Um usuário relatou o mesmo problema havia cerca de 14 horas, e como o alvo era um contêiner de banco de dados, não era possível recuperar apenas com scale-up
- Mesmo em um plano pago, ele havia enviado e-mail ao suporte horas antes e não teve resposta
- O app estava hospedado na região syd, levantando a possibilidade de problema em um ou dois hosts dali
Impacto amplo e recuperação temporária
- Até o dia anterior, estavam em operação 4 máquinas de app + Postgres (staging e produção), mas 3 continuavam fora do ar, incluindo os dois bancos de dados
- Como esse app era a API externa da empresa, todas as integrações foram interrompidas
- Para manter a operação, foi criado um novo projeto na Fly e novas instâncias foram iniciadas, com algumas horas gastas para repor variáveis de ambiente e configurações
- Isso acabou servindo, sem intenção, como um teste da capacidade de DR (recuperação de desastres)
- Não havia como extrair dados da máquina de banco, mas como não era o banco principal de produção, o necessário foi reconstruído por engenharia reversa
Preocupações com a confiabilidade da plataforma
- Houve surpresa pelo fato de ainda não existir resposta oficial mesmo após 12 horas
- Foi mencionado que era a segunda vez enfrentando o mesmo problema: o serviço fica fora do ar, a Fly reporta tudo como normal e não fornece informação nem resposta, restando apenas esperar
- Comparação com a Heroku: quando um host ficava instável, os dynos eram migrados automaticamente, evitando esse tipo de preocupação
- A preocupação foi de que isso aconteceu até mesmo em um app pequeno e padrão de Rails + Postgres, e que a resposta seria ainda mais difícil em apps mais complexos
- Esses problemas foram descritos como algo que destrói completamente a confiança na plataforma
1 comentários
Comentários do Hacker News
A Fly deixou uma resposta no tópico de suporte: explicou que verifica o fórum regularmente, mas deixou passar esta publicação, e que houve uma falha em um único host prolongada na região syd
O host não voltou normalmente após reiniciar e também não se reconectou ao service discovery, então foi necessária uma recuperação manual
Aplicativos rodando com várias instâncias tiveram apenas algumas instâncias afetadas, mas apps com instância única ficaram inacessíveis durante a falha, e a Fly recomenda fortemente uma configuração com múltiplas instâncias
Falhas globais/regionais são publicadas em status.fly.io, e problemas de host único vinham sendo mostrados na aba de status do dashboard, mas disseram que estão reavaliando como comunicar falhas longas em um único host como esta
https://community.fly.io/t/service-interruption-cant-destroy...
Nem reiniciando foi possível recuperar, então restaurei um backup antigo no RDS e senti que foi uma boa ter migrado
Além disso, não parece ser só um container de usuário, mas algo como um serviço gerenciado de PostgreSQL, então parece ainda mais razoável esperar resiliência a falhas de host
Eu até pagaria algo como US$ 5–10 por mês, mas não usaria isso em um side project em que eu não quero uma indisponibilidade de 3 dias
[1] https://fly.io/docs/about/support/
Se a indisponibilidade durou várias horas, eu acho que deveriam ter subido uma nova máquina com Ansible ou qualquer outra coisa. Isso teria sido possível, fosse hardware ou máquina virtual da AWS/GCP
A Fly aparentemente tornou o tópico[1] privado para quem não está logado, como se estivesse tentando abafar o problema
No tópico, havia relatos de que o serviço estava fora do ar, mas o status da Fly aparecia como normal, sem informações, e não havia nada a fazer além de esperar
Outro usuário disse que três de quatro máquinas — incluindo o app e os PostgreSQL de staging/production — continuavam fora do ar, e que o app de API externa havia quebrado, arruinando todas as integrações
Disseram também que levou horas para criar um novo projeto na Fly e subir uma instância temporária, e que não conseguiram encontrar uma forma de recuperar os dados da máquina do DB
Houve também a reação de que parecia um insulto a página de status da organização mostrar “sem incidentes”, enquanto nessa mesma página o app aparecia em manutenção e inacessível
Outra postagem dizia que, durante 17 horas, quase não houve atualização na página de status nem notificações, e que só receberam alertas do Better Stack
Backup completo do tópico: https://pastebin.com/ebmCSZkC
Tweet enviado ao CEO da Fly: https://twitter.com/SouthPawNZ/status/1682181533673857024
[1] https://community.fly.io/t/service-interruption-cant-destroy...
O pior da Fly é que, quando algo dá errado, não é uma coisa só que quebra, várias quebram ao mesmo tempo, e a página de status fica toda verde
Normalmente a resposta também é silêncio ou uma atitude leve demais, tipo “é isso que acontece quando se faz deploy na sexta-feira”
O produto parece legal, mas dá a sensação de ser o serviço de hospedagem mais instável que já usei, só que com uma embalagem bonita
Não dá para arruinar o trabalho das pessoas toda semana, fazê-las passar a noite do fim de semana restaurando tudo e depois encerrar com “poderíamos ter feito melhor”. Isso é desculpa para exceção, não serve para um padrão recorrente
Este tópico do HN tem muito ruído, mas acho que o essencial é o seguinte: os funcionários aparentemente já viam o problema antes de os clientes perceberem, e mesmo depois de mandar e-mail para o suporte pago ainda levava várias horas até haver resposta, e atualizações sobre os hosts fora do ar só apareceram cerca de 20 horas depois
Não comunicaram corretamente aos usuários afetados sobre a falha do host nem sobre como restaurar, e no dashboard aparecia manutenção emergencial enquanto a página de status mostrava que estava tudo normal
Entendo que, pelo plano e pela arquitetura, esse tipo de downtime é esperado e comum, mas com uma comunicação tão ruim assim você perde clientes
Se, como outros provedores, eles me enviassem um e-mail quando o host em que estou começasse a apresentar qualquer problema, eu pelo menos poderia fazer algo imediatamente em relação ao meu app
Ainda assim, há divergência sobre se eles sabiam suficientemente bem que estavam nessa situação
Houve uma indisponibilidade anormalmente longa em um servidor específico, e a combinação desses fatores fez muita gente passar por uma falha prolongada sem explicação
O dashboard mostra apenas falhas de região/serviço e não falhas de servidor individual, e como as pessoas não sabiam disso, entenderam como se fosse mentira
Por causa de um comportamento estranho na configuração de tags do Discourse, pareceu que estavam tentando esconder o problema
Em resumo, foi azar, procedimentos ruins do ponto de vista de atendimento ao cliente, e talvez alguma falta de documentação, mas vejo o incidente mais como muita fumaça do que fogo
A linha do tempo, em UTC, foi: host caiu em 2023-07-17 16:19, página de status personalizada publicada às 16:49, host restaurado em 2023-07-19 15:00, e status marcado como resolvido às 15:17
[1] https://community.fly.io/t/new-status-page/11398
A Fly.io não queria virar um clone da Heroku, mas por causa do marketing e da experiência de usuário bem polida, acabou parecendo isso
Como resultado, passou a lidar até com uma base de usuários estilo Heroku que pode causar grande dano à marca a cada falha de host individual
Como era um projeto pessoal por diversão, tudo bem, mas para algo mais sério não sei se eu usaria
Além disso, é difícil aceitar que existam tantos provedores de nuvem assim a ponto de chamar 20 horas de downtime de algo “garantido e normal”
Infelizmente, sempre senti bastante passivo-agressividade nos tópicos do HN envolvendo a Fly.io
Eu realmente queria gostar da Fly.io. Configurar e usar é muito fácil, mas, sinceramente, acho que aplicações mission-critical não deveriam rodar nesse serviço
No fim acabei migrando tudo para a AWS, embora realmente não quisesse fazer isso
As máquinas frequentemente não funcionavam, havia falhas aleatórias, builds falhavam, e mesmo pagando um tier mais alto por causa do suporte, ele respondia devagar e nem lia direito as perguntas
Não dá para adicionar sidecars, é difícil integrar com monitoramento externo, e a documentação é aceitável no caminho feliz, mas deixa muito a desejar nos casos de borda
Para projetos de hobby tudo bem, e ainda hospedo muitos projetos pessoais lá, mas para a infraestrutura da empresa o custo em tempo e frustração ficou alto demais, então tivemos de migrar
Soava como o herdeiro espiritual do Heroku, então minhas expectativas eram altas, mas ainda não está nesse nível
Na semana anterior compilava, localmente também funcionava, e depois voltou a funcionar na Fly, mas foi um downtime incompreensível sem explicação da causa nem resposta do suporte
O tier gratuito é muito generoso, então dá para fazer bastante coisa sem chegar no limite de cobrança, mas eu tenho pouco tempo livre e nesse tempo quero simplesmente conseguir fazer build do projeto
E era só um pequeno site estático com build em Node
A ferramenta em si é excelente, então se estabilizarem a infraestrutura eu gostaria de tentar de novo
Se com o mesmo esforço eles não conseguem colocar essa informação na documentação, não sei o quão ruim é o pipeline de documentação
A resposta para perguntas de uso no fórum deveria ser “está na documentação; se não estava, acabamos de adicionar” e “se algo estiver confuso, avise e vamos atualizar a documentação”
Tive que cavar os logs do fly manualmente para ver que o proxy não conseguia chegar ao servidor, e não havia nada que eu pudesse fazer para corrigir
Algumas horas depois abri um tópico no fórum sobre o problema, mas não houve resposta nem sinal de que alguém tinha lido, e pouco depois foi corrigido como por mágica
Espero que dê certo para eles, mas por causa dessa falta de comunicação e da sensação de impotência de não poder fazer nada, por um bom tempo não vou usar fly.io
Talvez não seja uma resposta muito satisfatória, mas, pessoalmente, isto é tudo que posso dizer: eu realmente não faço ideia de por que este tópico do nosso site da comunidade saiu da lista
Estou olhando a UI de admin, e há um pequeno cadeado ao lado do post, mas a opção “unlist story” continua clicável
O melhor que posso dizer é que tenho bastante certeza de que não houve uma ordem de cima para esconder este tópico. O site é público e qualquer pessoa pode criar uma conta para ver o tópico
Podem dizer o que quiserem sobre nós, mas esconder esse tipo de coisa não é um dos nossos defeitos
Sobre o problema do servidor de Sydney, ainda não sei o suficiente para dar uma resposta útil para quem estava rodando instâncias nele. Acabei de voltar e estou começando a entender o que aconteceu
Agora que fui ver, todos os posts da categoria app-not-working parecem estar como “private”, provavelmente por causa da configuração da categoria. Aqui, private significa que é preciso se cadastrar com uma conta do Discourse para ver
O tom desta resposta e de outras comunicações da fly.io, considerando a opinião pública sobre a fly.io, parece sinalizar falta desses elementos
Se vocês têm mais de 60 funcionários e tantos problemas assim, isso não parece um tom humano e simpático, e sim sinal de um negócio que não consegue escalar
Para um negócio B2B em crescimento ter sucesso, precisa de coisas como processo e supervisão, mas pelas outras respostas parece que vocês não querem isso, o que não é um bom sinal
Quebrar uma vez é um acidente, duas vezes é azar, mas três vezes significa que o processo está quebrado. Pelos comentários aqui, na Fly.io isso parece acontecer com muito mais frequência do que três vezes
Não por causa da indisponibilidade em si, mas porque pode levar dias para conseguir suporte
Que garantia vocês podem dar à comunidade de que da próxima vez o suporte será melhor?
Rodamos o https://changelog.com na Fly.io desde abril de 2022, e a arquitetura atual está em https://github.com/thechangelog/changelog.com/blob/master/IN...
Em 15 meses na Fly.io, atendemos mais de 100 milhões de requisições com um app Phoenix + PostgreSQL, mas é difícil encontrar motivo para reclamar
Tivemos algumas implantações que falharam e corrigimos reexecutando o pipeline, no começo de julho de 2023 tivemos 9 mil requisições retornando 503 por 10 segundos em Frankfurt, e houve também um volume que não era removido durante o experimento com machines e desapareceu no dia seguinte
Falamos com frequência sobre nossa experiência com a Fly.io no podcast Kaizen: https://changelog.com/topic/kaizen
Episódio do anúncio da migração: https://changelog.com/shipit/50
PR relacionado: https://github.com/thechangelog/changelog.com/pull/407
Também falamos recentemente sobre o plano de migração de apps v1(Nomad) para apps v2(flyd): https://changelog.com/friends/2#transcript-138
É uma pena que tantas pessoas não tenham tido uma boa experiência, mas acho que a Fly.io vai continuar melhorando. Espero que, um dia, esta fase difícil vire uma boa história
Post que dá esperança: https://community.fly.io/t/reliability-its-not-great/11253
Gosto bastante da fly.io e espero que tenha sucesso. Eles estão fazendo algo difícil, então pode quebrar
Mas a falta de comunicação é decepcionante, especialmente porque foi algo que o próprio CEO apontou diretamente, no grande post sobre confiabilidade que publicou na comunidade em março, como algo que queria corrigir
https://community.fly.io/t/reliability-its-not-great/11253#s...
Temos mostrado falhas de host único no dashboard dos usuários afetados, e problemas de plataforma/região na página de status, mas claramente existe uma zona intermediária em que o status que comunicamos não bate com a experiência real dos usuários
Recentemente adicionamos muito hardware para evitar problemas de capacidade e, como esperado, a probabilidade de indisponibilidade total caiu, mas a quantidade de falhas no formato de problemas de hardware aumentou
Podemos fazer mais para ajudar os usuários a evitar esses problemas, para acelerar a recuperação e para avisar melhor quando forem afetados
Mesmo quando erramos na comunicação, estamos ouvindo esse tipo de feedback
Um sinal de alerta ainda maior é que a Fly aparentemente não tem um método automatizado para mover rapidamente cargas de trabalho de um servidor com falha para um servidor saudável
Isso apesar de contêineres e orquestradores já abstraírem o conceito de volumes de dados conectáveis/desconectáveis
Claro, oferecer isso exige um grande investimento técnico, e acho que esse é um dos motivos pelos quais armazenamento é caro nas três grandes nuvens. Mesmo assim, se você oferece um serviço de persistência de dados, isso é uma capacidade indispensável
Existe um desalinhamento entre o que a Fly quer oferecer e o que o mercado espera
A Fly queria inovar ao permitir executar apps em vários datacenters, mas sem um serviço de persistência de dados decente esse recurso não é útil para a maioria das pessoas
Parece que estão tentando resolver a questão da persistência com replicação de SQLite, mas aí a maioria dos desenvolvedores teria de mudar a forma como desenvolve apps para se adequar à plataforma da Fly
A Fly precisa escolher entre ser uma alternativa estável e barata ao Heroku ou propor uma forma própria de desenvolver apps que entregue o melhor desempenho para usuários no mundo todo
O App Engine é um caso interessante. Estava à frente do seu tempo e prescrevia uma forma de desenvolvimento que escalava até tráfego muito alto, mas as pessoas não queriam mudar seu jeito de desenvolver para se encaixar nisso
Agora parece que estão só apagando um incêndio para outro começar, então não passa confiança no roadmap técnico
Já não faz uns dois anos que várias pessoas colocaram o Fly.io na lista de “ver depois”?
Quando as pessoas passam a vê-lo como instável, é realmente muito difícil recuperar a reputação, especialmente na área de TI
A persistência de dados funciona exportando snapshots de LVM, criados manualmente ou a cada 24 horas, para o S3
Realmente não me parece um lugar para rodar cargas persistentes. Se você vai rodar PostgreSQL lá, precisa estar preparado para carregar os dados a quente em uma nova instância ou restaurar de backup
Pelo mesmo motivo, faz tempo que eu digo no HN para não usar a Fly: https://news.ycombinator.com/item?id=31394179
Depois que pedi a exclusão da conta, minha conta ficou numa espécie de estado de shadow ban, sem qualquer comunicação
Também mandei e-mail, mas até hoje nunca recebi resposta, e depois disso migrei tudo para Railway Apps e Google Cloud Run
Por que a empresa aplicaria shadow ban só porque você fez uma pergunta inofensiva?
O interessante é que, na Fly.io, parece que a história está se repetindo. É parecido com quando conheci o Heroku pela primeira vez
A Fly.io de antigamente era fresca e empolgante como o Heroku quando apareceu pela primeira vez, e eu admirava a simplicidade e a facilidade de uso
Mas, com o tempo, pequenos sinais de problema começaram a aparecer, o downtime ficou mais frequente, e deploys que antes eram rápidos e suaves passaram a ser dolorosamente lentos
Parece um déjà vu da época em que as vantagens do Heroku começaram a desaparecer
É triste ver a Fly.io seguir um caminho em que, quanto mais gente corre para a plataforma, pior o desempenho fica, e quanto mais popular ela se torna, menos estável parece
Soa como uma história de advertência sobre como até plataformas promissoras podem entrar em declínio, e espero que a Fly.io consiga escapar desse ciclo e se firmar antes de se tornar tão inútil quanto o Heroku no seu pior momento
Achei que talvez estivessem superestimando a consciência do setor, e era óbvio que, se ficasse popular como o Heroku, apareceria uma multidão querendo não pagar
Para tentar de novo uma oferta gratuita generosa, você precisa ter uma organização forte e cara de prevenção de abuso, ou bolsos fundos para despejar hardware suficiente a ponto de aguentar a ausência disso no começo
A Fly não parece forte em nenhum dos dois. E isso também é algo de que eu gosto nela. Essas coisas parecem bobagem corporativa de empresa grande, e a Fly tem menos esse cheiro
Mas eu não ficaria surpreso se os engenheiros da Fly estivessem gastando a maior parte do tempo lidando com mineradores de cripto oportunistas, golpistas e abusadores, além de otimizar alocação de recursos e limites automáticos, em vez de confiabilidade de infraestrutura de longo prazo ou experiência do desenvolvedor
Fico me perguntando se isso tem a ver com escala. Quando a empresa consegue clientes pagantes suficientes para começar a ter lucratividade ou parecer investível, ao mesmo tempo talvez já tenha acumulado problemas suficientes para ir gradualmente se tornando parecida com o velho concorrente que queria substituir, em vez de manter aquela sensação inicial de novidade e empolgação?
Foi assim na minha experiência. Quando a empresa sai do tamanho de algumas pizzas para o nível de “reservamos um espaço para o evento”, a entropia começa a se infiltrar, e máximas como a Lei de Conway e a lei de Brooks vão ficando cada vez mais evidentes