Vorfallsbericht: Railway von Google Cloud blockiert [Behoben]

 (status.railway.com)
1 Punkte von GN⁺ 1 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Die weitreichende Service-Störung bei Railway wurde behoben; als Ursache wurde eine Sperrung des Google-Cloud-Kontos von Railway bestätigt
  • Während der Störung konnten Nutzer "no healthy upstream", "unconditional drop overload", Login-Fehler und den fehlenden Zugriff auf das Dashboard erleben
  • Railway stellte durch direkten Kontakt mit dem Google-Cloud-Supportteam den Kontozugriff wieder her und arbeitete an der Wiederherstellung der Control Plane und der Workloads
  • Während der Wiederherstellung blieben Netzwerkprobleme bei Google Cloud bestehen, wodurch der Start einiger Services blockiert wurde; Nicht-Enterprise-Builds wurden vorübergehend eingeschränkt
  • Der Service ist vollständig wiederhergestellt, aber einige als anomal erkannte Workloads werden automatisch neu bereitgestellt; falls nötig müssen Nutzer selbst eine erneute Bereitstellung auslösen

Überblick über die Störung und finaler Status

  • Railway hat die weitreichende Service-Störung behoben; die Nachanalyse ist im Incident Report zu finden
  • Während des Ausfalls konnten Nutzer "no healthy upstream", "unconditional drop overload", Login-Fehler und fehlenden Zugriff auf das Dashboard erleben
  • Die Ursache war die Sperrung des Google-Cloud-Kontos von Railway, wodurch einige Railway-Services nicht verfügbar waren
  • Railway stellte durch direkten Kontakt mit dem Google-Cloud-Supportteam den Kontozugriff wieder her und arbeitete an der Wiederherstellung der Workloads
  • Der Service ist vollständig wiederhergestellt, aber einige als anomal erkannte Workloads werden automatisch neu bereitgestellt, und bei Services mit weiterhin abnormalem Antwortverhalten müssen Nutzer möglicherweise selbst eine erneute Bereitstellung auslösen

Verlauf der Wiederherstellung und Auswirkungen auf Nutzer

  • Erste Untersuchung und Ursachenbestätigung

    • Railway stellte die Google-Cloud-Infrastruktur wieder her, die die Control Plane für Dashboard, API und internes Netzwerk betreibt
    • Auch nachdem der Zugang zum übergeordneten Cloud-Anbieter wiederhergestellt war, konnten das Railway-Dashboard und in der Cloud-Infrastruktur laufende Services bis zur Ausbringung von Fixes weiterhin betroffen sein
    • Nach der Sperrung des Google-Cloud-Kontos bestätigte das Railway-Plattformteam den Zugriff auf Teile der bei Google Cloud gehosteten Infrastruktur und stellte den Zugriff auf die übrigen Services wieder her

  • Google Cloud und Netzwerkprobleme

    • Railway stellte die Compute-Ressourcen in Google Cloud wieder her, aber Netzwerkprobleme auf Seiten von Google Cloud blieben bestehen, sodass einige Services nicht starten konnten
    • Während der Wiederherstellung konnten in Google Cloud gehostete Workloads weiterhin unter intermittierenden Problemen leiden
    • Das Infrastrukturteam von Railway prüfte parallel auch alternative Wege, um betroffene Services wieder online zu bringen

  • Build- und Deployment-Einschränkungen

    • Railway-Metal-Workloads begannen sich schrittweise zu erholen
    • Um eine Überlastung der Build-Infrastruktur während der Wiederherstellung zu vermeiden, wurden alle Nicht-Enterprise-Builds vorübergehend eingeschränkt
    • Danach blieben Nicht-Enterprise-Deployments vorübergehend ausgesetzt, während Enterprise-Deployments nicht betroffen waren
    • Auch nachdem Deployments wieder möglich waren, konnten in Google Cloud verbleibende Workloads bis zum Abschluss der Wiederherstellung weiterhin unter intermittierenden Problemen leiden

  • Aktuelle Maßnahmen

    • Die Railway-Services sind vollständig wiederhergestellt; Services mit weiterhin abnormalem Antwortverhalten sollten über das Dashboard oder die CLI neu bereitgestellt werden
    • Weitere Hintergründe finden sich in den FAQ; falls direkte Unterstützung nötig ist, kann in Railway Station ein Thread eröffnet werden

Verwandte Beiträge

1 Kommentare

 
GN⁺ 1 시간 전
Hacker-News-Kommentare

  • Railway hat den Ausfall behoben und eine Post-Mortem-Analyse veröffentlicht
    https://blog.railway.com/p/incident-report-may-19-2026-gcp-a...
    Außerdem wurde mit Stand 20. Mai, 07:57 UTC, eine Statusseite veröffentlicht
    https://status.railway.com/incident/I23M92U0

    • Ich finde, in so einem Fall sollte man Schadensersatz von Google verlangen können. Das ist kein Problem, das wie ein Netzwerkausfall oder Servicefehler in die AGB gehören sollte
    • Railway sagt zwar, der Vorfall sei gelöst, aber viele Services sind noch immer down und liefern 502 zurück. Bei uns lief die Wiederherstellung erst, nachdem wir manuell ein Redeploy ausgelöst hatten, und ich finde, Railway hätte das automatisch tun müssen
      Insgesamt hatten wir mehr als 11 Stunden Downtime

  • Es ist wieder Tag 0, seit GCP das nächste Startup abgeschossen hat
    So etwas sieht man gefühlt mindestens einmal im Jahr, und von AWS oder Azure habe ich so etwas noch nie gehört
    Im Ernst: Genau deshalb nutze ich GCP nicht. Von den großen drei ist es zwar die am angenehmsten zu nutzende Cloud, aber durch diesen Ruf sabotieren sie sich selbst

    • Umgekehrt kann ich mich kaum an einen wirklich schweren Ausfall bei GCP erinnern. AWS/Azure scheinen dafür ein paarmal im Jahr katastrophal auszufallen
    • AWS ist darin effizienter. Wenn us-east-1 ausfällt, reißen sie gleich mehrere Startups auf einmal mit runter
    • https://en.wikipedia.org/wiki/Timeline_of_Amazon_Web_Service...
      Azure hat letztes Jahr auch den Front Door für Azure- und O365-Services insgesamt kaputtgemacht
      Diese Unternehmen haben jeweils Bereiche, in denen sie stark sind, aber gelegentlich bauen sie richtig großen Mist
    • AWS hat unseren Service einmal so stark gedrosselt, dass wir ihn nicht mehr betreiben konnten. Ich wollte schon einen Beitrag darüber schreiben, dass sie unser Wachstum einen Monat lang gestoppt haben, aber inzwischen wirkt das kaum noch relevant
    • Aus genau demselben Grund fassen wir GCP ebenfalls nicht an

  • Alle wollen Google die Schuld geben, aber nachdem ich Railway ziemlich lange genutzt habe, würde ich gern auch die Sicht von GCP hören, bevor ich ein Urteil fälle. Bei Railway gab es solche Probleme schon früher, und die Art, wie das Team damit umging, hat kein Vertrauen geschaffen
    Für mich war das jetzt jedenfalls der letzte Tropfen

    • Auch wenn es nur anekdotisch ist, stimme ich zu. Das Railway-Entwicklungsteam wirkt, als würde es ziemlich locker arbeiten und überall etwas Vibe Coding einstreuen. Es gibt ein Maß an „sie sind halt noch ein Startup, drückt ein Auge zu“, und Railway überschreitet diese Grenze
    • Genau. In anderen Threads sieht man viele Accounts, die den Cloud-Anbieter hart angreifen, aber es ist merkwürdig, wie wenig in dieser Welle der Empörung jemand nach der Root Cause fragt oder überhaupt diese Möglichkeit ernsthaft abwägt
    • Ich brauchte vor zwei Jahren Support, der war so toxisch, dass ich einfach zu Vercel gewechselt bin und ihnen gesagt habe, sie sollen sich verpissen
      Als ich später für andere Services etwas Ähnliches brauchte, bin ich auf coolify gestoßen. Wenn man coolify nutzen kann, gibt es überhaupt keinen Grund, Railway zu verwenden
    • Wenn du konkrete frühere Fälle nennen kannst, würde ich das gern lesen
    • Ich habe Details gehört, die ich eigentlich nicht wissen dürfte. Ich kann mit Sicherheit sagen, dass das hier zu 100 % Googles Schuld war, und ich wäre enttäuscht, wenn Railway dazu nicht mehr teilen kann
      Railway hätte das realistisch nicht verhindern können, außer GCP komplett zu meiden

  • Im Mai 2024 gab es auch den UniSuper-Ausfall: https://cloud.google.com/blog/products/infrastructure/detail...
    https://www.unisuper.com.au/about-us/media-centre/2024/a-joi...
    Laut einer gemeinsamen Erklärung von UniSuper-CEO Peter Chun und Google-Cloud-CEO Thomas Kurian kam es bei der Bereitstellung von UniSupers Private-Cloud-Service zu einem fahrlässigen Konfigurationsfehler, wodurch schließlich das Private-Cloud-Abonnement von UniSuper gelöscht wurde
    Google Cloud bezeichnete das als einen isolierten, „einmaligen Vorfall“, für den es bei keinem Google-Cloud-Kunden weltweit einen Präzedenzfall gegeben habe, aber diese Löschung des Abonnements führte zur Löschung in beiden Regionen, sodass die Wiederherstellung Hunderte virtuelle Maschinen, Datenbanken und Anwendungen umfasste

    • Ich habe damals über den UniSuper-Fall geschrieben: https://danielcompton.net/google-cloud-unisuper
      Das war ein ziemlich schwerwiegender Bug, und ihre VMWare-Umgebung wurde mit einem Ablaufdatum von einem Jahr erstellt, war aus Sicht von Google Cloud aber eine einzige „Ressource“
    • „Die Löschung des Private-Cloud-Abonnements führte zur Löschung in beiden Regionen“ nennt man einen Single Point of Failure, und jeder, der schon einmal für Sicherheit verantwortlich war, bekommt davon Albträume
    • Eine Struktur, bei der das Schließen oder Löschen eines Abonnements sofort weltweit Kaskadenlöschungen auslöst, klingt wie ein Rezept für eine Katastrophe. Ich verstehe nicht, warum man es nicht einfach zum Löschen markiert und erst einen Tag oder eine Woche später wirklich löscht

  • Ich verstehe nicht, wie so etwas bei einem Unternehmen mit hohen monatlichen Ausgaben überhaupt passieren kann. In meinem vorherigen Job hat bei verdächtigen Workloads auf AWS der TAM zuerst Kontakt aufgenommen, bevor Maßnahmen ergriffen wurden
    Hier wirkt es, als sei irgendeine fehlerhafte AI-Automatisierung im Spiel gewesen, und als hätte GCP eine echte Kontaktaufnahme mit einem Menschen vermieden, sodass irgendein ausgelagerter Mitarbeiter es erst Stunden später in der Support-Queue gesehen und nur eine Standardantwort geschickt hat

    • Wenn es um GCP-Support geht, überrascht mich inzwischen gar nichts mehr. Bei uns wurden in den letzten sechs Jahren, obwohl wir das überhaupt nicht brauchen, mehr als 12 Account Executives ausgetauscht, und alle waren völlig nutzlos
      Jedes Mal stellten sie sich vor, wollten Meetings mit dem Engineering-Team ansetzen und kamen mit irgendwelchen Standard-Slide-Decks an, die mit uns absolut nichts zu tun hatten, was nur zum Lachen war, und die nächste Kontaktaufnahme kam dann erst wieder, wenn ein neuer AE zugewiesen wurde
      GCP und seine Services mögen wir und sind seit Jahren zufrieden damit, aber die menschliche Seite ist wirklich miserabel, und ich verstehe nicht, warum sie das überhaupt betreiben
    • Ich glaube, in einem anderen Thread gab es dazu eine aufschlussreiche Antwort. Wir haben unser Konto zwar wiederbekommen, aber selbst mit Account Rep und CSM hat es gedauert, herauszufinden, was überhaupt passiert war
      Ohne diese Ansprechpartner wäre es womöglich noch schlimmer gewesen
    • Ist halt Google. Sie lassen dich ihren Service nutzen, und in dem Moment, in dem du von der Norm abweichst, sperren sie dich

  • Als Betreiber einer öffentlichen API ist die Spam-Menge von Railway-IP-Adressen absurd hoch. Die Missbrauchsprävention ist miserabel, und ich hoffe, dass dieser Vorfall ein Anlass ist, den Betrieb zu verbessern

    • Genau das ist der zentrale Zielkonflikt beim Betrieb eines Hosting-Unternehmens. Wenn man die Anmeldung einfach macht, bekommt man viele neue Nutzer, aber eben auch viel Missbrauch
      Baut man Gegenmaßnahmen ein, gibt es laute Fehlalarme, und genau das könnte auch bei diesem GCP-Fall passiert sein
      Ich beneide niemanden, der ein Hosting-Unternehmen betreibt. Das Internet ist unter der Oberfläche wirklich schmutzig
      Nebenbei: AWS macht das wirklich gut. Vermutlich dank rund 30 Jahren Erfahrung mit Retail-Betrug und Missbrauchsabwehr

  • Moment, Railway lief auf GCP? Haben sie nicht groß behauptet, sie würden „keine Cloud auf einer anderen Cloud bauen“?
    Oder meinten sie nur, dass sie keine VPS mieten, sondern bei Cloud-Anbietern ausschließlich Bare Metal?
    Ich hatte mich gefreut zu denken, dass da ein anderer Anbieter entsteht, der nicht einfach nur einem der Hyperscaler Geld zahlt, sondern Colocation nutzt und mehr vom Stack selbst besitzt
    https://blog.railway.com/p/heroku-walked-railway-run

    • In dem verlinkten Artikel in der Wayback Machine steht:
      „Von Tag eins an hatten wir diesen Gedanken ganz vorne im Kopf.
      Außerdem war uns intuitiv klar, dass man keine Cloud auf einer anderen Cloud bauen kann. Wir haben Jahre darauf verwendet, eigene Server zu betreiben und praktisch so mit anderen Clouds zusammenzuarbeiten, dass das Geschäft von Railway und letztlich das unserer Kunden so robust wie möglich ist.“
    • Genau deshalb bin ich wütend. Sie haben gelogen. Sie waren vollständig von GCP abhängig
      Ich muss mich jetzt wohl umsehen. Ich brauche etwas, das stabiler ist und weniger von den Launen eines einzelnen Unternehmens abhängt
      Das ist auch aus Sicht von Railway schlecht, weil es den Kern ihres großen Versprechens von friedlicher Software-Bereitstellung direkt trifft. Das hier ist Chaos

  • Ich dachte, Railway würde eigene Rechenzentren aufbauen [0]
    „Tatsache ist, man kann keine Cloud auf der Cloud eines anderen bauen.“
    Tja, offenbar doch nicht…
    [0] https://blog.railway.com/p/launch-week-02-welcome

    • Vercel scheint das hinzubekommen. PlanetScale ebenfalls, zumindest bei Datenbanken, und am Ende ist sowieso alles eine Datenbank

  • Beim Anmelden bei Railway ist es auffällig, dass man bestätigen muss, die Bedingungen zu Systemmissbrauch, Krypto-Mining usw. gelesen und verstanden zu haben
    Meine Vermutung ist, dass viele Nutzer den Free Tier missbrauchen und dem Anbieter dadurch Probleme bereiten
    Selbst als Wettbewerber freut es mich nicht, Railway so getroffen zu sehen, aber kostenlose Compute-Ressourcen ziehen alle möglichen schrägen Nutzer an. Wir haben das auch erlebt und uns früh entschieden, kostenlose Compute-Angebote zu vermeiden, selbst wenn dadurch im Top of Funnel weniger hereinkommt

  • Ich finde nicht, dass man nur Google die Schuld geben kann. Railway scheint zunehmend Schwierigkeiten zu haben, die Stabilität der Plattform aufrechtzuerhalten
    So etwas sollte nicht den gesamten Service lahmlegen. Wenn das Geschäft buchstäblich darin besteht, ein stabiles Backend bereitzustellen, dann muss es Backups geben. Für mich sieht das nach schlechter Planung aus

    • Ich verstehe nicht ganz, was du meinst. Erwartest du wirklich, dass Railway zum Hosting sämtlicher Kundenprojekte eine Multi-Cloud-Architektur einsetzt? Insgesamt würde das die Verfügbarkeit eher senken
    • Ist Disaster Recovery nicht ziemlich teuer? Gerade für ein Unternehmen in Railways Größe klingt das plausibel