Rapport d’incident : Railway bloqué par Google Cloud [résolu]

 (status.railway.com)
1 points par GN⁺ 1 시간 전 | 1 commentaires | Partager sur WhatsApp
  • La panne de service généralisée de Railway a été résolue, et sa cause a été identifiée comme le blocage du compte Google Cloud de Railway
  • Pendant l’incident, les utilisateurs ont pu rencontrer "no healthy upstream", "unconditional drop overload", des échecs de connexion et l’impossibilité d’accéder au tableau de bord
  • Railway a contacté directement l’équipe de support Google Cloud pour rétablir l’accès au compte, puis a lancé la restauration du plan de contrôle et des workloads
  • Au cours de la restauration, des problèmes réseau côté Google Cloud subsistaient et empêchaient le démarrage de certains services, tandis que les builds non Enterprise ont été temporairement limités
  • Le service a été entièrement rétabli, mais certains workloads détectés comme anormaux sont en cours de redéploiement automatique, et un redéploiement manuel peut être nécessaire

Vue d’ensemble de l’incident et état final

  • Railway a résolu une panne de service généralisée, et l’analyse post-incident est disponible dans l’Incident Report
  • Pendant l’incident, les utilisateurs ont pu rencontrer "no healthy upstream", "unconditional drop overload", des échecs de connexion et l’impossibilité d’accéder au tableau de bord
  • La cause est le blocage du compte Google Cloud de Railway, rendant indisponibles certains services Railway
  • Railway a contacté directement l’équipe de support Google Cloud pour rétablir l’accès au compte et poursuivre la restauration des workloads
  • Le service a été entièrement rétabli, mais certains workloads détectés dans un état anormal sont en cours de redéploiement automatique, et les services qui ne répondent pas normalement peuvent nécessiter un redéploiement manuel par l’utilisateur

Chronologie de la restauration et impact utilisateur

  • Enquête initiale et confirmation de la cause

    • Railway a restauré l’infrastructure Google Cloud qui fait fonctionner le plan de contrôle du tableau de bord, de l’API et du réseau interne
    • Même après le rétablissement de l’accès au fournisseur cloud en amont, le tableau de bord Railway et les services exécutés sur l’infrastructure cloud pouvaient rester affectés jusqu’au déploiement des correctifs
    • Après le blocage du compte Google Cloud, l’équipe plateforme de Railway a confirmé l’accès à une partie de l’infrastructure hébergée sur Google Cloud et a rétabli l’accès au reste des services

  • Google Cloud et problèmes réseau

    • Railway a restauré le compute sur Google Cloud, mais des problèmes réseau côté Google Cloud persistaient et empêchaient le démarrage de certains services
    • Pendant la restauration, les workloads hébergés sur Google Cloud pouvaient continuer à subir des problèmes intermittents
    • L’équipe infrastructure de Railway étudiait également des voies alternatives pour remettre en ligne les services affectés

  • Limitations sur les builds et les déploiements

    • Les workloads Railway metal ont commencé à être progressivement rétablis
    • Pendant la restauration, tous les builds non Enterprise ont été temporairement limités afin d’éviter une surcharge de l’infrastructure de build
    • Par la suite, les déploiements non Enterprise sont restés temporairement suspendus, tandis que les déploiements Enterprise n’ont pas été affectés
    • Même après la reprise des déploiements, les workloads encore présents sur Google Cloud pouvaient continuer à subir des problèmes intermittents jusqu’à la fin complète de la restauration

  • Mesures actuelles

    • Les services Railway ont été entièrement rétablis, et les services qui ne répondent pas normalement doivent être redéployés depuis le tableau de bord ou la CLI
    • Des informations supplémentaires sont disponibles dans la FAQ, et si une assistance directe est nécessaire, vous pouvez ouvrir un fil sur Railway Station

À lire aussi

1 commentaires

 
GN⁺ 1 시간 전
Commentaires sur Hacker News

  • Railway a résolu cette panne et a publié une analyse post-mortem
    https://blog.railway.com/p/incident-report-may-19-2026-gcp-a...
    La page de statut a également été mise à jour au 20 mai à 07:57 UTC
    https://status.railway.com/incident/I23M92U0

    • Dans un cas comme celui-ci, il devrait être possible de réclamer des dommages-intérêts à Google. Ce n’est pas le genre de problème qui devrait être couvert par les CGU comme une panne réseau ou une défaillance de service
    • Railway dit que l’incident est résolu, mais beaucoup de services renvoient encore des 502 et restent hors ligne. De notre côté, il a fallu déclencher un redéploiement manuel pour restaurer le service, alors que Railway aurait dû le faire automatiquement
      Au total, notre indisponibilité a dépassé 11 heures

  • Cela fait 0 jour que GCP n’a pas encore mis une startup à terre
    J’ai l’impression de voir ce genre d’histoire au moins une fois par an, et je n’ai jamais entendu parler de la même chose chez AWS ou Azure
    Plus sérieusement, c’est pour ça que je n’utilise pas GCP. C’est le cloud le plus agréable à utiliser du top 3, mais ils sabotent eux-mêmes leur réputation avec ce genre d’histoires

    • À l’inverse, je me souviens mal d’une panne grave chez GCP. J’ai l’impression qu’AWS/Azure subissent des catastrophes plusieurs fois par an
    • AWS fait ça plus efficacement. Quand us-east-1 tombe, ils mettent plusieurs startups à terre d’un seul coup
    • https://en.wikipedia.org/wiki/Timeline_of_Amazon_Web_Service...
      Azure a aussi cassé l’an dernier la front door de l’ensemble de ses services Azure et O365
      Chacune de ces boîtes a ses domaines d’excellence, mais elles se plantent parfois en beauté
    • AWS nous a déjà throttlés si violemment qu’on ne pouvait plus exploiter notre service. J’avais envisagé d’écrire un billet expliquant comment ils ont stoppé notre croissance pendant un mois, mais ça ne semble plus très utile aujourd’hui
    • Nous aussi, on ne touche pas à GCP pour la même raison

  • Tout le monde a envie d’accuser Google, mais en tant qu’utilisateur de Railway depuis assez longtemps, j’aimerais aussi entendre la version de GCP avant de tirer des conclusions. Railway a déjà eu ce type de problème par le passé, et la manière dont l’équipe les gère n’inspire pas confiance
    Quoi qu’il en soit, cette fois a été celle de trop pour moi

    • Moi aussi, même si ce n’est qu’anecdotique, je suis d’accord. L’équipe de dev de Railway donne l’impression de fonctionner de façon assez relâchée, avec du vibe coding un peu partout. Il y a un niveau de “c’est encore une startup, soyez indulgents”, et Railway a largement dépassé cette limite
    • Oui. Dans d’autres fils, on voit beaucoup de comptes critiquer violemment le fournisseur cloud, mais ce qui est étrange, c’est l’absence presque totale de curiosité sur la cause racine ou même la volonté d’en envisager les possibilités dans ce déferlement de colère
    • J’avais eu besoin du support il y a deux ans, c’était tellement pénible que je suis simplement passé chez Vercel en leur disant d’aller se faire voir
      En cherchant autre chose pour un besoin similaire, j’ai découvert coolify. S’il est possible d’utiliser coolify, il n’y a absolument aucune raison d’utiliser Railway
    • Si tu peux partager des exemples concrets d’incidents passés, je serais curieux de les lire
    • J’ai entendu des détails que je ne suis pas censé connaître. Je peux dire avec assurance que cette fois-ci, c’est à 100 % la faute de Google, et je serais déçu si Railway ne pouvait pas en dire davantage
      À part éviter complètement GCP, Railway n’avait vraiment aucun moyen d’empêcher ça

  • Il y a aussi eu la panne UniSuper en mai 2024 : https://cloud.google.com/blog/products/infrastructure/detail...
    https://www.unisuper.com.au/about-us/media-centre/2024/a-joi...
    Selon la déclaration commune du CEO d’UniSuper Peter Chun et du CEO de Google Cloud Thomas Kurian, une erreur de configuration commise par inadvertance pendant le provisionnement du service Private Cloud d’UniSuper a conduit à la suppression de l’abonnement Private Cloud d’UniSuper
    Google Cloud a affirmé qu’il s’agissait d’un incident isolé et “unique en son genre”, sans précédent pour aucun client Google Cloud dans le monde, mais cette suppression d’abonnement a provoqué la suppression dans les deux régions, nécessitant la restauration de centaines de machines virtuelles, bases de données et applications

    • J’avais écrit à l’époque sur le problème UniSuper : https://danielcompton.net/google-cloud-unisuper
      C’était un bug assez grave, et leur environnement VMWare avait été créé avec une date d’expiration d’un an, tout en étant vu par Google Cloud comme une seule “ressource”
    • “La suppression de l’abonnement Private Cloud a provoqué la suppression dans les deux régions”, c’est ce qu’on appelle un point de défaillance unique, et quiconque a déjà été responsable de la sûreté y verra un cauchemar
    • Une architecture où la fermeture ou la suppression d’un abonnement déclenche immédiatement des suppressions en cascade à l’échelle mondiale ressemble à une recette pour le désastre. Je ne comprends pas pourquoi il n’y a pas simplement un marquage pour suppression, avec effacement un jour ou une semaine plus tard

  • J’ai du mal à comprendre comment une chose pareille peut arriver à une entreprise avec une grosse facture mensuelle. Dans mon ancien job, quand une charge de travail suspecte tournait sur AWS, notre TAM nous contactait avant toute action
    Ici, j’ai l’impression qu’il y a eu une mauvaise automatisation par IA, et que GCP déteste devoir réellement contacter des humains et obtenir une réponse, si bien qu’un prestataire l’a peut-être vu des heures plus tard dans la file du support avant d’envoyer une réponse standardisée

    • S’il s’agit de support GCP, plus rien ne m’étonne. Nous n’en avons absolument pas besoin, mais nous avons eu plus de 12 Account Executive différents en 6 ans, et ils ont tous été totalement inutiles
      À chaque fois, ils se présentent, demandent à organiser une réunion avec les équipes d’ingénierie, arrivent avec un deck de slides standard sans aucun rapport avec nous, ce qui nous faisait rire, puis la fois suivante où nous avions de leurs nouvelles, c’était parce qu’un nouvel AE avait été affecté
      J’aime bien GCP et ses services, j’en suis satisfait depuis des années, mais la partie humaine est vraiment nulle et je ne comprends même pas pourquoi ils s’embêtent à la maintenir
    • Il me semble qu’il y avait aussi une réponse pertinente dans un autre fil. Nous avons fini par récupérer notre compte, mais même avec un Account Rep et un CSM, il a fallu du temps pour comprendre ce qui se passait
      Sans eux, cela aurait sans doute été pire
    • C’est Google, donc oui. Ils te laissent utiliser le service, puis te suspendent dès que tu sors de la norme

  • En tant qu’opérateur d’une API publique, la quantité de spam provenant des IP de Railway est absurde. Leur prévention des abus est catastrophique, et j’espère que cet incident les poussera à améliorer leurs opérations

    • C’est exactement le conflit central quand on gère un hébergeur. Si l’inscription est facile, beaucoup de nouveaux utilisateurs arrivent, mais aussi beaucoup d’abus
      Si on met en place des protections anti-abus, on obtient des faux positifs bruyants, et l’incident GCP pourrait très bien être de cet ordre
      Je n’envie pas les gens qui dirigent une société d’hébergement. Internet est vraiment sale sous la surface
      Cela dit, AWS est très bon sur ce point. Sans doute grâce à près de 30 ans d’expérience en fraude retail et en lutte contre les abus

  • Attendez, Railway tournait sur GCP ? Ils n’avaient pas martelé qu’ils ne “construisaient pas un cloud au-dessus d’un autre cloud” ?
    Ou bien cela voulait-il simplement dire qu’ils ne louaient pas des VPS, mais seulement du bare metal à des fournisseurs cloud ?
    J’étais au moins enthousiaste à l’idée qu’un fournisseur fasse de la colocation et possède une plus grande partie de sa stack, au lieu de simplement payer un hyperscaler
    https://blog.railway.com/p/heroku-walked-railway-run

    • Dans l’article lié, vu via Wayback Machine, on lit ceci
      “Dès le premier jour, nous avons gardé cette idée au premier plan.
      Et l’une de nos intuitions était aussi qu’on ne pouvait pas construire un cloud au-dessus d’un autre cloud. Nous avons passé des années à faire le travail concret consistant à faire tourner nos propres serveurs et à bien coexister avec les autres clouds, afin que l’activité de Railway — et au final celle de ses clients — soit la plus robuste possible.”
    • Oui, et c’est pour ça que je suis furieux. Ils ont menti. Ils dépendaient entièrement de GCP
      Il va falloir que j’enquête un peu. J’ai besoin de quelque chose de plus stable que ça et moins dépendant du bon vouloir d’une seule entreprise
      C’est aussi très mauvais pour Railway, parce que cela touche en plein cœur leur grande promesse de déploiement logiciel paisible. Là, c’est le chaos

  • Je croyais que Railway construisait ses propres datacenters [0]
    “En pratique, on ne peut pas construire un cloud au-dessus du cloud de quelqu’un d’autre.”
    Eh bien, apparemment si…
    [0] https://blog.railway.com/p/launch-week-02-welcome

    • Vercel semble y parvenir. PlanetScale aussi, au moins pour les bases de données, et de toute façon, tout est base de données

  • Lors de l’inscription à Railway, il est assez inhabituel qu’on vous demande de confirmer que vous avez lu et compris les conditions sur les abus du système, le minage de cryptomonnaies, etc.
    J’imagine que beaucoup d’utilisateurs abusent du free tier et créent des problèmes au fournisseur de service
    Même du point de vue d’un concurrent, je ne me réjouis pas de voir Railway subir ce genre de coup, mais le compute gratuit attire toutes sortes d’utilisateurs douteux. Nous l’avons vécu aussi, et nous avons choisi d’éviter le compute gratuit au démarrage, même si cela réduisait le haut du funnel

  • Je ne pense pas qu’on puisse rejeter toute la faute sur Google. Railway semble avoir de plus en plus de mal à maintenir la stabilité de sa plateforme
    Un incident comme celui-ci ne devrait pas faire tomber l’ensemble du service. Si votre activité consiste littéralement à fournir un backend stable, vous devez avoir un plan de secours. À mes yeux, cela ressemble à une planification défaillante

    • Je ne vois pas très bien ce que tu veux dire. Tu t’attends vraiment à ce que Railway utilise une architecture multicloud pour héberger tous les projets clients ? Globalement, j’ai l’impression que cela réduirait plutôt la disponibilité
    • La reprise après sinistre n’est-elle pas assez coûteuse ? Surtout à l’échelle de Railway ?