Relatório do incidente: Railway bloqueada pelo Google Cloud [Resolvido]

 (status.railway.com)
1 pontos por GN⁺ 1 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • A interrupção generalizada de serviços da Railway foi resolvida, e a causa foi confirmada como o bloqueio da conta da Railway no Google Cloud
  • Durante a interrupção, os usuários puderam enfrentar "no healthy upstream", "unconditional drop overload", falha de login e indisponibilidade de acesso ao dashboard
  • A Railway entrou em contato diretamente com a equipe de suporte do Google Cloud para restaurar o acesso à conta e realizar a recuperação do plano de controle e das cargas de trabalho
  • Durante a recuperação, permaneceu um problema de rede no Google Cloud que impediu a inicialização de alguns serviços, e builds não empresariais foram temporariamente limitadas
  • O serviço foi totalmente restaurado, mas algumas cargas de trabalho detectadas como anormais estão sendo reimplantadas automaticamente, e, se necessário, os usuários deverão reimplantar manualmente

Visão geral da interrupção e status final

  • A Railway resolveu uma interrupção generalizada de serviços, e a análise posterior pode ser consultada em Incident Report
  • Durante o período da interrupção, os usuários puderam enfrentar "no healthy upstream", "unconditional drop overload", falha de login e indisponibilidade de acesso ao dashboard
  • A causa foi o bloqueio da conta da Railway no Google Cloud, deixando alguns serviços da Railway indisponíveis
  • A Railway entrou em contato diretamente com a equipe de suporte do Google Cloud para restaurar o acesso à conta e avançar na recuperação das cargas de trabalho
  • O serviço foi totalmente restaurado, mas algumas cargas de trabalho detectadas em estado anormal estão sendo reimplantadas automaticamente, e serviços cuja resposta não estiver normal podem precisar ser reimplantados manualmente pelos usuários

Progresso da recuperação e impacto para os usuários

  • Investigação inicial e identificação da causa

    • A Railway restaurou a infraestrutura do Google Cloud que operava o plano de controle do dashboard, da API e da rede interna
    • Mesmo após a restauração do acesso ao provedor de nuvem superior, o dashboard da Railway e os serviços executados na infraestrutura em nuvem ainda podiam continuar afetados até a aplicação de uma implantação corretiva
    • Após o bloqueio da conta no Google Cloud, a equipe de plataforma da Railway confirmou acesso a parte da infraestrutura hospedada no Google Cloud e restaurou o acesso aos demais serviços

  • Google Cloud e problemas de rede

    • A Railway restaurou a computação no Google Cloud, mas um problema de rede do lado do Google Cloud permaneceu e impediu que alguns serviços fossem iniciados
    • Durante a recuperação, cargas de trabalho hospedadas no Google Cloud ainda podiam enfrentar problemas intermitentes
    • A equipe de infraestrutura da Railway também avaliou rotas alternativas para recolocar os serviços afetados no ar

  • Limitações de build e implantação

    • As cargas de trabalho em metal da Railway começaram a ser restauradas gradualmente
    • Durante a recuperação, todas as builds não empresariais foram temporariamente limitadas para evitar sobrecarga na infraestrutura de build
    • Depois disso, as implantações não empresariais permaneceram temporariamente suspensas, enquanto as implantações empresariais não foram afetadas
    • Mesmo após as implantações voltarem a ser possíveis, as cargas de trabalho ainda remanescentes no Google Cloud podiam enfrentar problemas intermitentes até a conclusão da recuperação

  • Medidas atuais

    • Os serviços da Railway foram totalmente restaurados, e serviços cuja resposta não estiver normal devem ser reimplantados pelo dashboard ou pela CLI
    • Mais contexto pode ser consultado no FAQ, e, se for necessário suporte direto, é possível abrir uma thread no Railway Station

Leituras relacionadas

1 comentários

 
GN⁺ 1 시간 전
Comentários do Hacker News

  • A Railway resolveu essa falha e publicou a análise pós-incidente
    https://blog.railway.com/p/incident-report-may-19-2026-gcp-a...
    Em 20 de maio às 07:57 UTC, a página de status também foi publicada
    https://status.railway.com/incident/I23M92U0

    • Acho que, em casos assim, deveria ser possível processar o Google por perdas e danos. Isso não é o tipo de problema que deveria estar coberto nos termos, como falha de rede ou indisponibilidade de serviço
    • A Railway diz que a falha foi resolvida, mas muitos serviços ainda estão fora do ar retornando 502. No nosso caso, só voltou depois de dispararmos manualmente um redeploy, algo que a Railway deveria ter feito automaticamente
      No total, nosso downtime foi de mais de 11 horas

  • Já faz 0 dias desde a última vez que a GCP derrubou uma startup
    Parece que vejo isso pelo menos uma vez por ano, e nunca ouvi falar de algo assim na AWS ou Azure
    Falando sério, é por isso que não uso GCP. É a nuvem mais agradável de usar entre as três grandes, mas acaba se sabotando por causa dessa reputação

    • Por outro lado, não lembro de muitos incidentes graves na GCP. AWS/Azure parecem ter quedas catastróficas algumas vezes por ano
    • A AWS faz isso de forma mais eficiente. Quando a us-east-1 cai, derruba várias startups de uma vez só
    • https://en.wikipedia.org/wiki/Timeline_of_Amazon_Web_Service...
      A Azure também quebrou o front door de todos os serviços Azure e O365 no ano passado
      Essas empresas são boas em áreas diferentes, mas às vezes falham feio
    • Já aconteceu de a AWS fazer um throttling tão agressivo no nosso serviço que ele ficou impossível de operar. Eu ia escrever sobre como eles pararam nosso crescimento por um mês, mas agora isso já nem parece tão relevante
    • Nós também não encostamos em GCP pelo mesmo motivo

  • Todo mundo quer culpar o Google, mas como alguém que usou a Railway por bastante tempo, eu gostaria de ouvir o lado da GCP antes de tirar conclusões. A Railway já teve esse tipo de problema antes, e a forma como a equipe lida com isso não passa confiança
    De qualquer forma, esse foi meu limite final

    • Também é anedótico no meu caso, mas concordo. A equipe de desenvolvimento da Railway passa a impressão de trabalhar de forma bem solta, misturando vibe coding aqui e ali. Existe um nível de “ainda somos uma startup, pega leve”, e a Railway passou desse ponto
    • Exato. Em outras threads, dá para ver várias contas criticando duramente o provedor de nuvem, mas é estranho como quase ninguém nesse fluxo de indignação parece curioso sobre a causa raiz ou disposto a considerar essa possibilidade
    • Precisei de suporte 2 anos atrás, foi tão ruim que simplesmente migrei para a Vercel e mandei eles se lascarem
      Procurando algo parecido para outros serviços, encontrei o coolify. Se você pode usar coolify, não existe motivo nenhum para usar Railway
    • Se você puder citar casos concretos do passado, eu gostaria de ler
    • Ouvi detalhes que eu provavelmente não deveria saber. Posso dizer com confiança que, desta vez, a culpa foi 100% do Google, e vou ficar desapontado se a Railway não puder compartilhar mais
      Fora evitar a GCP por completo, a Railway realmente não tinha como se proteger disso

  • Também houve a falha da UniSuper em maio de 2024: https://cloud.google.com/blog/products/infrastructure/detail...
    https://www.unisuper.com.au/about-us/media-centre/2024/a-joi...
    Segundo uma declaração conjunta do CEO da UniSuper, Peter Chun, e do CEO do Google Cloud, Thomas Kurian, ocorreu um erro de configuração por descuido durante o provisionamento do serviço Private Cloud da UniSuper, e isso acabou apagando a assinatura de Private Cloud da UniSuper
    O Google Cloud disse que foi um “incidente isolado, único na vida” sem precedentes para qualquer cliente Google Cloud no mundo, mas essa exclusão da assinatura provocou a exclusão em ambas as regiões, exigindo a recuperação de centenas de máquinas virtuais, bancos de dados e aplicações

    • Na época, escrevi sobre o problema da UniSuper: https://danielcompton.net/google-cloud-unisuper
      Foi um bug bem sério, e o ambiente VMWare deles foi criado com validade de 1 ano, sendo tratado pelo Google Cloud como um único “recurso” do ponto de vista deles
    • “A exclusão da assinatura de Private Cloud provocou a exclusão em ambas as regiões” é o que se chama de ponto único de falha, e qualquer pessoa que já teve responsabilidade por segurança vê isso como um pesadelo
    • Uma arquitetura em que, ao encerrar ou apagar uma assinatura, isso desencadeia exclusões em cascata no mundo todo parece receita para desastre. Não entendo por que não apenas marcam para exclusão e apagam um dia ou uma semana depois

  • Não entendo como algo assim pode acontecer com uma empresa que gasta tanto por mês. Num emprego anterior, quando apareceu uma carga suspeita na AWS, nosso TAM entrou em contato antes de qualquer ação
    Meu palpite é que isso aqui foi alguma automação errada com IA, e que a GCP evita entrar em contato de fato com uma pessoa e obter resposta, então talvez algum terceirizado tenha visto isso horas depois na fila de suporte e mandado só uma resposta padronizada

    • Quando o assunto é suporte da GCP, nada mais me surpreende. Tivemos mais de 12 Account Executives diferentes nos últimos 6 anos, embora não precisássemos deles para nada, e todos foram completamente inúteis
      Toda vez era a mesma coisa: se apresentavam, pediam para marcar reunião com o time de engenharia, apareciam com um slide deck padronizado sem relação nenhuma com a nossa realidade, rendiam só risadas, e o próximo contato vinha apenas quando outro AE era designado
      Gosto da GCP e dos serviços dela, e fiquei satisfeito por anos, mas a parte humana é realmente péssima e não entendo por que insistem em operar assim
    • Acho que também houve respostas relevantes em outras threads. Nós também recuperamos a conta no fim, mas mesmo com Account Rep e CSM, levou tempo para descobrir o que tinha acontecido
      Sem pessoas designadas, talvez tivesse sido ainda pior
    • É o Google, né. Deixa você usar o serviço e, no momento em que você sai do padrão, suspende tudo

  • Como alguém que opera uma API pública, o spam vindo de IPs da Railway é absurdo. A prevenção de abuso deles é péssima, e espero que isso sirva de incentivo para melhorar a operação

    • Esse é exatamente o conflito central ao tocar uma empresa de hospedagem. Se você facilita o cadastro, atrai muitos usuários novos, mas também muito abuso
      Se coloca proteções contra abuso, surgem falsos positivos barulhentos, e o caso da GCP pode ter sido isso
      Não invejo quem opera empresa de hospedagem. A internet é realmente suja por baixo da superfície
      Dito isso, a AWS é muito boa nessa parte. Imagino que por causa de uns 30 anos de experiência lidando com fraude e abuso no varejo

  • Espera, a Railway rodava em cima da GCP? Eles não falavam alto e claro que “não se constrói uma nuvem em cima de outra nuvem”?
    Ou queriam dizer apenas que, em vez de alugar VPS, alugavam só bare metal do provedor de nuvem?
    Pelo menos eu achei animador pensar que havia outro provedor fazendo colocation e controlando mais da própria stack, em vez de apenas pagar um dos hyperscalers
    https://blog.railway.com/p/heroku-walked-railway-run

    • No texto vinculado visto pelo Wayback Machine, está assim
      “Desde o primeiro dia, mantivemos essa ideia na linha de frente.
      Outra coisa que intuíamos era que não dá para construir uma nuvem em cima de outra nuvem. Passamos anos no trabalho prático de operar nossos próprios servidores e conviver bem com outras nuvens para que o negócio da Railway, e no fim o negócio dos nossos clientes, fosse o mais robusto possível.”
    • Isso mesmo, e é por isso que estou irritado. Eles mentiram. Dependiam totalmente da GCP
      Agora vou ter que investigar melhor. Preciso de algo mais confiável que isso e menos dependente do capricho de uma única empresa
      Isso também é ruim para a própria Railway, porque atinge em cheio o coração da grande promessa deles de implantação de software sem dor. Isso aqui é caos

  • Eu achava que a Railway estava construindo seus próprios datacenters [0]
    “Na prática, você não pode construir uma nuvem em cima da nuvem de outra pessoa.”
    Pois é mesmo…
    [0] https://blog.railway.com/p/launch-week-02-welcome

    • A Vercel parece conseguir fazer isso. A PlanetScale também, ao menos no caso de banco de dados, e no fim das contas tudo é banco de dados

  • Quando você se cadastra na Railway, é curioso como eles fazem você confirmar que leu e entendeu os termos sobre abuso do sistema, mineração de criptomoedas etc.
    Meu palpite é que muitos usuários abusam do tier gratuito e acabam criando problemas para o provedor de serviço
    Mesmo do ponto de vista de um concorrente, eu não fico feliz vendo a Railway levar esse golpe, mas computação gratuita atrai todo tipo de usuário estranho. Nós também já passamos por isso e decidimos evitar computação gratuita no início, mesmo que isso reduzisse o topo do funil

  • Acho difícil culpar só o Google. A Railway parece estar encontrando cada vez mais dificuldade para manter a estabilidade da plataforma
    Uma coisa dessas não deveria derrubar o serviço inteiro. Se o negócio deles é literalmente fornecer um backend estável, então deveria haver backup. Aos meus olhos, isso parece planejamento ruim

    • Não entendi bem o que você quer dizer. Você realmente espera que a Railway use uma arquitetura multicloud para hospedar os projetos de todos os clientes? No geral, isso provavelmente reduziria a disponibilidade em vez de aumentar
    • Recuperação de desastres não é bem cara? Especialmente para uma empresa do porte da Railway?