Störungsbericht: 19. Mai 2026 – Aussetzung des GCP-Kontos

 (blog.railway.com)
1 Punkte von GN⁺ 2 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Ein plattformweiter Ausfall bei Railway dauerte ab dem 19. Mai 2026, 22:20 UTC, rund 8 Stunden; die direkte Ursache war die Aussetzung des Produktionskontos bei Google Cloud.
  • Dashboard und API gaben sofort 503-Fehler zurück, und in Google Cloud gehostete Compute-, Datenbank-, Control-Plane- und Burst-Compute-Infrastruktur gingen offline.
  • Railway Metal- und AWS-Workloads liefen weiter, aber der Edge-Proxy war von der in Google Cloud gehosteten Control-Plane-API abhängig, sodass sich nach Ablauf des Route-Cache 404-Fehler ausbreiteten.
  • Auch nach Wiederherstellung des Kontozugriffs mussten Persistent Disks, Compute-Instanzen und Networking jeweils separat wiederhergestellt werden, und GitHub-OAuth- sowie Webhook-Rate-Limits blockierten zusätzlich Logins und Builds.
  • Railway erkennt die Verantwortung für Architekturentscheidungen an, durch die die Maßnahme eines einzelnen Upstream-Anbieters zu einem Totalausfall wurde, und arbeitet an einem Redesign, das Google Cloud aus dem Hot Path der Datenebene entfernt.

Auswirkungen

  • Vom 19. Mai 2026, 22:20 UTC, bis zum 20. Mai gegen 06:14 UTC kam es bei Railway etwa 8 Stunden lang zu einem plattformweiten Ausfall.
  • Nachdem Google Cloud den Dienst für Railways Produktionskonto ausgesetzt hatte, gingen API, Control Plane, Datenbanken und die in Google Cloud gehostete Compute-Infrastruktur offline.
  • Nutzer erhielten im Dashboard und in der API sofort 503-Fehler und konnten sich mit Meldungen wie "no healthy upstream" und "unconditional drop overload" nicht mehr anmelden.
  • Alle auf Google-Cloud-Compute gehosteten Workloads gingen offline.
  • Die Workloads selbst in Railway Metal und der AWS-Burst-Cloud-Umgebung liefen zwar weiter, aber Railways Edge-Proxy war darauf angewiesen, die in Google Cloud gehostete Control-Plane-API zum Befüllen der Routing-Tabellen zu nutzen.
  • Als die zwischengespeicherten Netzwerk-Routen abliefen, wurden auch Workloads außerhalb von Google Cloud unerreichbar, und die Netzwerk-Control-Plane konnte die Routen zu aktiven Instanzen nicht mehr auflösen und gab 404-Fehler zurück.
  • Am Höhepunkt der Auswirkungen waren Railway-Workloads in allen Regionen nicht erreichbar.
  • Während der Wiederherstellung der Google-Cloud-Umgebung waren plattformweit Builds und Deployments blockiert, während einzelne Dienste wiederhergestellt wurden.
  • Nachdem die gesamte Infrastruktur wiederhergestellt war, wurde ein großer Rückstau ausstehender Deployments schrittweise abgearbeitet, um die Plattform nicht zu überlasten.
  • Gleichzeitig drosselte GitHub Railways OAuth- und Webhook-Integrationen, wodurch Logins und Builds vorübergehend blockiert wurden.
  • Das erhöhte Aufrufvolumen war eine Folge der durch den Google-Cloud-Ausfall geleerten Caches.
  • Auch die Einträge zur Zustimmung zu den Nutzungsbedingungen wurden zurückgesetzt, sodass Nutzer beim nächsten Besuch des Dashboards erneut zustimmen mussten.
  • Railway erkennt die Verantwortung für Architekturentscheidungen an, die dazu führten, dass die Maßnahme eines einzelnen Upstream-Anbieters zu einem plattformweiten Ausfall eskalieren konnte.

Timeline des Ausfalls

    1. Mai, 22:10 UTC: Automatisches Monitoring erkannte fehlgeschlagene API-Healthchecks und alarmierte den On-Call-Dienst.
    1. Mai, 22:11 UTC: Das Dashboard begann 503-Fehler zurückzugeben, und Nutzer konnten sich nicht mehr anmelden.
    1. Mai, 22:19 UTC: Es wurde bestätigt, dass die Aussetzung von Railways Produktionskonto durch Google Cloud Platform die Grundursache war.
    1. Mai, 22:22 UTC: Ein P0-Ticket wurde bei Google Cloud eingereicht, und Railways GCP-Account-Manager schaltete sich direkt ein.
    1. Mai, 22:29 UTC: Der Ausfall wurde offiziell erklärt.
    1. Mai, 22:29 UTC: Der Zugriff auf das GCP-Konto wurde wiederhergestellt, aber alle Compute-Instanzen waren weiterhin gestoppt und Persistent Disks unzugänglich.
    1. Mai, 22:35 UTC: Als zwischengespeicherte Netzwerk-Routen zu verfallen begannen, gaben Railway-Metal- und AWS-Workloads 404-Fehler zurück.
    1. Mai, 23:09 UTC: Die erste Persistent Disk kam wieder online.
    1. Mai, 23:54 UTC: Alle Persistent Disks waren wieder im Status ready, aber das Netzwerk war weiterhin ausgefallen.
    1. Mai, 00:39 UTC: Der Status der Disks als ready wurde bestätigt; die Wiederherstellung wurde durch die Wiederherstellung des Google-Cloud-Netzwerks blockiert.
    1. Mai, 01:30 UTC: Compute-Instanzen begannen wieder verfügbar zu werden.
    1. Mai, 01:38 UTC: Edge-Traffic wurde wieder ausgeliefert, und das Netzwerk war wiederhergestellt.
    1. Mai, 01:57 UTC: Orchestrierungs- und Build-Infrastruktur waren wiederhergestellt; Deployments wurden vorübergehend pausiert, damit wartende Jobs nicht gleichzeitig anlaufen und das System überfordern.
    1. Mai, 02:04 UTC: Compute-Hosts kamen schrittweise wieder online.
    1. Mai, 02:47 UTC: GitHub begann, Railways OAuth- und Webhook-Integrationen zu drosseln, sodass sich einige Nutzer nicht anmelden konnten und Builds blockiert wurden.
    1. Mai, 02:55 UTC: Das Dashboard war wieder erreichbar.
    1. Mai, 03:59 UTC: Die Verarbeitung von Deployments wurde auf allen Tiers wieder aufgenommen.
    1. Mai, 04:00 UTC: Es wurde bestätigt, dass API, Dashboard und OAuth-Endpunkte funktionieren; die Wiederherstellung verbleibender Workloads lief weiter.
    1. Mai, 06:14 UTC: Der Ausfall ging in die Monitoring-Phase über.
    1. Mai, 07:58 UTC: Der Ausfall wurde behoben.

Ursache und Wiederherstellungsverlauf

  • Aussetzung des Google-Cloud-Kontos

    • Am 19. Mai um 22:20 UTC versetzte Google Cloud Railways Produktionskonto fälschlicherweise im Rahmen einer automatisierten Maßnahme in den Status ausgesetzt.
    • Diese Maßnahme betraf mehrere Konten innerhalb von Google Cloud.
    • Da es sich um eine plattformweite Maßnahme handelte, gab es vor der Einschränkung keine vorherige Kontaktaufnahme mit einzelnen Kunden.
    • Der Aussetzungsstatus deaktivierte GCP-bezogene Infrastruktur, darunter das Railway Dashboard, die API, Teile der Netzwerkinfrastruktur sowie zusätzliche in Google Cloud gehostete Burst-Compute-Infrastruktur.

  • Abhängigkeit von der Control Plane

    • Railways Control Plane ist der zentrale Satz an Abhängigkeiten, der das Dashboard bereitstellt, Builds und Deployments verarbeitet und die vom Edge verwendeten Routing-Tabellen befüllt.
    • Alle Workloads in Google Cloud waren sofort betroffen.
    • Railways Edge-Proxys halten einen Cache der Routing-Tabellen der innerhalb von Google Cloud gehosteten Netzwerk-Control-Plane.
    • Solange der Cache erhalten blieb, verarbeiteten Workloads in Railway Metal und AWS weiterhin Traffic.
    • Nachdem der Cache abgelaufen war, konnte der Edge die Routen zu aktiven Instanzen nicht mehr auflösen, und Workloads in allen Regionen, einschließlich Metal und AWS, begannen 404-Fehler zurückzugeben.
    • Die Workloads selbst waren weiterhin online, aber die Auswirkungen des Netzwerkausfalls breiteten sich auf Regionen außerhalb von Google Cloud aus.

  • Grenzen des Hochverfügbarkeitsdesigns

    • Railways Infrastruktur ist auf Hochverfügbarkeit ausgelegt; Datenbanken laufen über mehrere Availability Zones hinweg, und das Netzwerk nutzt redundante Verbindungen zwischen AWS, GCP und Railway Metal.
    • Auch nach Wiederherstellung des Kontozugriffs wurden einzelne Dienste nicht automatisch wiederhergestellt.
    • Persistent Disks, Compute-Instanzen und Networking mussten jeweils separat wiederhergestellt werden, und diese Eigenschaft der Wiederherstellung verlängerte den Ausfall um mehrere weitere Stunden.
    • Die Disks waren um 23:54 UTC wieder im Status ready, aber kritisches Networking und Edge-Routing waren erst am 20. Mai gegen 01:30 UTC vollständig wiederhergestellt.
    • Railway wartet noch auf eine Bestätigung, ob diese Verzögerung und die damit verbundenen Fehler auf Google-Seite entstanden sind.

  • Schrittweise Wiederherstellung und Sekundäreffekte

    • Mit der Wiederherstellung des Netzwerks wurden Railways Kerndienste und Endnutzer-Workloads schichtweise verifiziert.
    • Um eine Überlastung des Build-Systems zu verhindern, wurden Deployments pausiert und danach schrittweise wieder aufgenommen.
    • Parallel zur Wiederherstellung der Kernsysteme drosselte GitHub Railways OAuth- und Webhook-Integrationen.
    • Wegen des Volumens und Burst-Verhaltens aller Wiederholungsanfragen waren Nutzer-Logins und Builds vorübergehend blockiert.
    • Gegen 04:00 UTC am 20. Mai wurde bestätigt, dass API, Dashboard und OAuth-Endpunkte funktionierten, während die Wiederherstellung der verbleibenden Workloads weiterlief.

Präventivmaßnahmen

  • Bestehendes Resilienzdesign

    • Railways Netzwerk-Control-Plane ist als multi-AZ, multi-zone-Konfiguration ausgelegt und soll selbst beim Ausfall mehrerer Maschinen und Komponenten ohne Auswirkungen auf Nutzer weiter funktionieren.
    • Dieses Design wurde vor dem Launch vor einigen Monaten in Staging und unter echtem Traffic getestet.
    • Nach früheren Ausfällen wurde in Resilienz investiert; dadurch konnte man zuvor etwa GitHub-Installationen von Nutzern stabil ohne sekundäre Drosselung wiederherstellen.

  • Beseitigung einer einzelnen Abhängigkeit

    • Railways Netzwerk ist ein mesh ring aus hochverfügbaren Glasfaser-Interconnects zwischen Metal <> GCP <> AWS.
    • Selbst innerhalb dieses Rings bestand jedoch weiterhin eine starke Abhängigkeit davon, dass die Auffindbarkeit von Workloads an die Netzwerk-Control-Plane-API gebunden war, die auf Google-Cloud-Maschinen lief.
    • Das Mesh funktionierte etwa eine Stunde lang weiter, scheiterte dann aber nach Ablauf des Route-Cache daran, die Routing-Tabellen erneut zu befüllen.
    • Railway arbeitet nun daran, diese Abhängigkeit sofort zu entfernen und daraus ein echtes mesh zu machen.
    • Ziel ist, dass zwischen den Clouds immer ein Pfad bestehen bleibt, auch wenn eine Interconnect-Verbindung ausfällt.

  • Verbesserungen bei Datenbanken und Failover

    • Railway plant, hochverfügbare Datenbank-Shards über AWS und Metal hinweg auszuweiten.
    • Künftig soll dadurch der Datenbank-quorum den Dienst weiter aufrechterhalten, selbst wenn alle Instanzen in einer bestimmten Cloud sofort verschwinden, und Workloads, die nicht mehr laufen, sollen sofort per Failover ersetzt werden.

  • Redesign von Datenebene und Control Plane

    • Es läuft ein Plan, Google-Cloud-Dienste aus dem Hot Path der Datenebene zu entfernen und sie nur noch für sekundäre Zwecke oder Failover beizubehalten.
    • Das geschieht parallel zur Umsetzung einer neuen Architektur für die Datenebene, die Host-Verbindungen ermöglicht, und für die Control Plane, die das Dashboard antreibt, über das Nutzer auf Railway zugreifen und es verwalten.
    • Dieses Upgrade soll sicherstellen, dass Kerndienste, insbesondere nutzernahe Komponenten, nicht von einem einzelnen Anbieter oder einer einzelnen Plattform abhängen.

Verantwortung und Fazit

  • Die Verantwortung für die Wahl von Anbietern liegt bei Railway, und auch diese Entscheidung liegt letztlich in Railways Verantwortung.
  • Kunden betrachten das Produkt selbst, nicht ob die Ursache des Ausfalls bei Google oder Railway lag; Railways Verfügbarkeit ist Railways Verantwortung.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2 시간 전
Hacker-News-Kommentare

  • Der interessante und bislang ungeklärte Punkt ist, warum Google das Konto markiert hat
    Man kann noch so viele im Postmortem beobachtete Zeitstempel einfügen, die eigentliche Ursache wurde nicht behandelt
    In dem Teil der Geschichte, der „keinen Sinn ergibt“, steckt wahrscheinlich die echte Erklärung, die noch niemand öffentlich machen will

    • Ich habe um 2017 herum, als ich https://www.fatherly.com/ betrieben habe, exakt dasselbe erlebt
      Google hat das Konto ohne Vorwarnung abgeschaltet, obwohl wir damals rund 10.000 Dollar pro Monat ausgegeben haben
      Sogar unser Premium-Support-Konto war gesperrt, sodass wir dem Support nicht einmal mitteilen konnten, dass wir ausgesperrt waren
      Nach etwa 8 Stunden sagte irgendein Google-Support-Ingenieur, wir hätten Bitcoin geschürft, was völliger Unsinn war
      Wir hatten CPU-Auslastungsdiagramme und Logs für den gesamten Zeitraum, und es gab keinen Spike
      Nach ungefähr 12 Stunden wurde es wieder aktiviert mit der Begründung, es sei ein „Konfigurationsfehler in der Missbrauchserkennung“ gewesen, und wir bekamen etwa 100 Dollar als Gutschrift
      Man kann über AWS sagen, was man will, aber AWS hätte einem Kunden so etwas nicht angetan, ohne dass sich vorher ein Ansprechpartner meldet
      Seitdem vertraue ich GCP nicht mehr
    • Wenn Google diesen Incident-Report nicht gefällt, sollte Google dann nicht selbst antworten? Es ist ja nicht einmal sicher, ob Railway den Grund überhaupt kennt
    • Normalerweise wird bei so etwas offenbar nicht mitgeteilt, warum es passiert ist, und es wirkt größtenteils automatisiert
      Automatisierte Systeme machen Fehler, aber das größere Problem ist, dass sie vollkommen intransparent sind
      Es ist gut möglich, dass nicht einmal Google genau weiß, wie dieses System funktioniert
    • Ich weiß nicht, auf wen sich „hat die eigentliche Ursache nicht behandelt“ mit „du“ bezieht
      Wenn gemeint ist, Railway solle sich lieber damit beschäftigen, statt GCP zu verlassen, dann verstehe ich nicht, warum sie das tun sollten, außer sie wollten GCP verklagen, um den Schaden an Marke und langfristiger Kundenbindung wieder hereinzuholen
      In dem Moment, in dem GCP sie ohne jede Vorwarnung abgeschaltet hat, war die Sache aus meiner Sicht ohnehin erledigt, da muss man nicht weiter nachfragen
    • Wie immer ist der Top-Kommentar in tiefem Groll gegen Google begraben, und es wirkt nicht so, als würde das Railway dazu drängen, dieses Problem anzugehen

  • Railway scheint diesen Monat in der Tech-Presse kein gutes Bild abgegeben zu haben
    In beiden Fällen wurde der Ruf durch die automatisierten Abläufe der jeweils anderen Seite beschädigt
    Eigentlich wollte ich dem Google-Ansprechpartner von dem Problem erzählen, bei dem Gemini CLI abgeschossen wurde, aber dieser Fall ist deutlich beunruhigender

    • Wenn es um den Vorfall geht, bei dem man einer KI Admin-Zugangsdaten gegeben hat, damit sie eine Produktionsdatenbank löscht, und dann tatsächlich die Produktionsdatenbank gelöscht wurde, dann war das die eigene Schuld
      Sie selbst waren die Einzigen, die Admin-Account-Zugangsdaten in eine KI eingegeben haben
      Und persönliche Verantwortung wurde dafür auch nicht übernommen, was dem Ruf definitiv geschadet hat
      Diesmal wird zumindest ein gewisses Maß an Verantwortung eingeräumt, daher muss man ihnen diese Verbesserung zugestehen
      Außerdem sind die Zuverlässigkeitsprobleme von GCP und Googles Kundensupport tatsächlich gravierend
      Korrektur: Ich habe unten erfahren, dass die ersten beiden Absätze fälschlich zugeordnet waren und es nicht um Railway, sondern um einen Railway-Kunden ging. Entschuldigung, Railway!
    • Auf der Plattform anderer aufzubauen ist immer riskant, und auf der Plattform anderer dann noch eine Plattform aufzubauen ist noch riskanter
      Unser Unternehmen hat früher einen Hoster genutzt, der im Wesentlichen nur ein paar zusätzliche Zusicherungen auf AWS draufgesetzt hat
      Inzwischen bietet AWS die Funktionen, die wir brauchen, selbst an, daher haben wir die Migration auf normales AWS abgeschlossen

  • Leider mussten wir wegen dieser Sache gestern eine Notfallmigration zu Azure durchführen
    Zum Glück lag unsere Datenbank nicht bei Railway, daher waren wir in wenigen Stunden wiederhergestellt
    Die Einfachheit, die Railway geboten hat, war wirklich großartig, aber um darauf weiterhin eine B2B-Enterprise-App zu betreiben, gab es auf dieser Infrastruktur einfach zu viele Vorfälle und Einschränkungen
    Ein trauriger Tag :(

    • Railway könnte Google wahrscheinlich auf den entgangenen Umsatz verklagen, den sie durch dich verloren haben. Wäre unterhaltsam
    • Mich würde interessieren, warum du dich ursprünglich für Railway entschieden hast
      Ich kenne den Dienst nicht gut, daher frage ich mich, ob es wegen besonderer Funktionen war oder ob er praktisch nur als virtuelle Maschine genutzt wurde
      Falls es wegen besonderer Funktionen war, würde mich auch interessieren, wie schwierig die Exit-Migration war
    • Bedeutet das, dass Azure das Konto ebenfalls gesperrt hat?

  • Für kleine SaaS-Tools oder interne Produkte: Was wäre eine gute Alternative, wenn ein Team AWS oder andere IaaS-Anbieter nicht direkt verwalten möchte?

    1. Vercel - diesen Monat in schlechter Verfassung
    2. Supabase - diesen Monat in schlechter Verfassung
    3. Railway - jetzt ebenfalls diesen Monat in schlechter Verfassung
    • DigitalOcean. Ganz im Ernst, das gibt es schon ewig, und sie haben viel Kerninfrastruktur gebaut, auf die ich mich jeden Tag verlasse. Zum Beispiel Ceph
    • Wenn man IaaS nicht direkt nutzen kann, muss man akzeptieren, dass der Dienst ausfallen kann
      Selbst wenn man etwas wie AWS nutzt, gibt es gelegentlich Downtime, wenn man keine redundante Architektur über mehrere Availability Zones hinweg hat
      Und selbst mit Redundanz über mehrere Availability Zones ist AWS nicht vollständig isoliert aufgebaut, daher können einzelne Dienste ausfallen und es kann zu Downtime kommen
      Also sollte man Downtime akzeptieren und die Werkzeuge verwenden, die am besten passen. Außer in wirklich extrem schlechten Fällen auf GitHub-Niveau
      Wenn man Downtime überhaupt nicht akzeptieren kann, braucht man Millionen von Dollar und monatelange Arbeit, um ein Maß an Zuverlässigkeit zu erreichen, bei dem man realistischerweise erwarten kann, dass es keine Ausfälle gibt
      Etwa in der Größenordnung von Netflix mit Chaos Monkey und der dazugehörigen Infrastruktur
    • Die Lehre hier scheint zu sein, dass man einem einzelnen Cloud-Anbieter nicht vertrauen kann
      Man braucht mindestens zwei Anbieter mit voller Betriebsfähigkeit
    • Ich verstehe nicht, warum niemand in Betracht zieht, einfach Bare-Metal-Server oder VPS zu kaufen
      Auch ohne nutzungsbasierte Abrechnung kommt man damit ziemlich weit
    • Zwischenhändler können Mehrwert liefern, bringen aber auch Risiken mit sich, daher würde ich zuerst prüfen, warum man AWS, GCP usw. nicht direkt nutzen möchte
      Die großen Cloud-Anbieter liefern Services, die nur etwas schwieriger zu bedienen sind als das, was Railway macht, und man kann bei wachsendem Bedarf zu fortgeschritteneren Funktionen hochskalieren
      Man muss keinen Dritten hinzufügen, der Kontrolle über Funktionalität, Sicherheit und Verfügbarkeit hat
      Nach dieser Timeline hat GCP zum Beispiel innerhalb von 7 Minuten reagiert
      Wenn man Cloud Run genutzt hätte, wäre die Downtime um mehr als 7 Stunden kürzer gewesen, und wenn der unbekannte Trigger mit Aktivitäten anderer Kunden oder irgendeinem seltsamen Verhalten von Railway zusammenhing, wäre es womöglich gar nicht erst heruntergefahren worden
      Dazu kommt Komplexität
      Ein großer Teil der komplexen Infrastruktur, die Railway laut eigener Aussage reparieren musste, wäre gar nicht nötig gewesen, wenn sie nur ihr eigenes Konto genutzt hätten
      Dieser Code erfüllt sicher einen nützlichen Zweck, aber für einen Hosting-Anbieter gibt es viele bewegliche Teile, die normale Nutzer nicht brauchen
      Dieser Ausfall hat zwar alle gemeinsam zu Fall gebracht, aber einzelne AWS-Nutzer oder Bare-Metal-Nutzer wären ursprünglich gar nicht betroffen gewesen
      Es gibt keine eine globale optimale Lösung für alle, aber Entwickler unterschätzen oft massiv die direkten Kosten und die weniger sichtbaren Kosten der Arbeit in der Umgebung anderer im Vergleich zu der Zeit, die sie durch ein paar eingesparte Deployment-Schritte gewinnen

  • „19. Mai, 22:10 UTC - Das automatische Monitoring erkannte fehlgeschlagene API-Healthchecks, alarmierte den On-Call und die Verantwortlichen begannen mit der Untersuchung“
    „19. Mai, 22:20 UTC - Google Cloud versetzte Railways Produktionskonto im Rahmen einer automatischen Maßnahme fälschlicherweise in den Status suspendiert“
    Wenn die Zeitstempel stimmen, wodurch wurden dann die Fehler 10 Minuten vor der Kontosperrung verursacht?
    Die einfachste Erklärung ist, dass einer der beiden Zeitstempel falsch ist, und das wäre an sich nichts Dramatisches
    Wenn man sich bei den Zeitstempeln aber nicht sicher ist, ist es ziemlich seltsam, sie als gesichert in den Bericht zu schreiben, obwohl sie sich offensichtlich widersprechen

    • Wenn man annimmt, dass die Zeitstempel korrekt sind, könnte Google bereits mit dem Herunterfahren von Ressourcen begonnen haben, bevor das Konto den Status „suspendiert“ erhielt, und dieser Status wurde erst abgeschlossen, nachdem alle Ressourcen deaktiviert waren
    • Der Zeitstempel 22:20 im Haupttext ist falsch
      Der Timeline-Abschnitt mit 22:10 ist in sich konsistent und enthält auch Folgendes
      „19. Mai, 22:19 UTC - Root Cause identifiziert: Google Cloud Platform suspendiert Railways Produktionskonto“
      Man kann die Ursache nicht identifizieren, bevor sie eingetreten ist
    • Diese 10 Minuten könnten ziemlich normal sein
      Zum Beispiel könnte ein Google-Mitarbeiter eine Konfiguration falsch geändert und damit wie bei früheren Vorfällen ein Signal erzeugt haben, das eine Sperrung erforderlich erscheinen ließ, und der Ablauf bis zur tatsächlichen Sperrung hätte dann 10 Minuten gedauert
      Oder ein Railway-Kunde hat etwas Betrügerisches oder betrugsähnliches getan, und das Google-System hat zunächst Zugriffsbeschränkungen eingeleitet und dann innerhalb von 10 Minuten entschieden, auf eine Sperrung hochzustufen
      Wenn dabei ein Mensch in die Freigabe eingebunden war, wäre das noch plausibler
      Offensichtlich hat diese Person aber nicht tief genug hingeschaut, um zu erkennen, dass man das so nicht hätte tun dürfen

  • Für alle, die GCP betreiben, sollte das eine Warnung sein
    GCP scheint Konten wahllos zu sperren, ohne darüber nachzudenken, was sie da tun
    Es wirkt, als würden sie Produktionsentscheidungen von Gemini 3.1 Pro treffen lassen
    TK hat eine Vorgeschichte damit, die Unternehmenskultur wie bei OCI vollständig zu ruinieren, und soweit ich gehört habe, wohl etwas Ähnliches auch bei GCP getan
    GCP und Google sind Organisationen, die völlig unterschiedlich arbeiten
    Man sollte nicht allein wegen des Namens Google-Qualität erwarten
    Es ähnelt eher Nokia, einer alten Marke, die heute auf billigen Lizenzprodukten klebt. Das ist übertrieben, aber nicht weit von der Wahrheit entfernt
    Außerdem ist Google dafür bekannt, Dienste zufällig einzustellen und dann etwa 6 Monate Migrationszeit zu geben
    Es gibt viele Ingenieure ohne echte Aufgaben, die man intern darauf ansetzt, Nutzer von diesen Diensten wegzumigrieren, aber die meisten Kunden können das nicht
    Es gab einmal einen hervorragenden Beitrag eines ehemaligen GCP-Mitarbeiters, den ich gerade nicht finde
    Wenn man sein Geschäft ernst meint, sollte man GCP wie die Pest meiden
    Korrektur: Ironischerweise hat Gemini den Artikel gefunden. Lesenswert: https://steve-yegge.medium.com/dear-google-cloud-your-deprec...

    • Und dabei geht es hier sogar um Railway
      Das ist bekannt genug, um ganz oben auf der HN-Startseite zu landen, und groß genug, dass man bei Google vermutlich irgendwann jemanden findet, der eingreift
      Wäre es ein kleines Produkt von mir gewesen, hätte ich überhaupt keine Handhabe gehabt
    • „Man sollte nicht allein wegen des Namens Google-Qualität erwarten“ passt exakt zu der Google-Qualität, die ich in den letzten Jahrzehnten erlebt habe
    • GCP war nie für Support bekannt, und die Gefahr von Diensteinstellungen war immer groß
      Die eigentliche Produktqualität ist ziemlich gut, was es umso bedauerlicher macht
      Sie hätten leicht der Anbieter auf Platz 2 werden können, denn Azure ist extrem instabil und die Dokumentation unterirdisch
      Dass GCP nur auf Platz 3 liegt, ist zu einem erheblichen Teil selbstverschuldet
    • Von außen betrachtet scheint TK angesichts des GCP-Wachstums einen guten Job zu machen
      Meine völlig unbewiesene Einschätzung ist, dass er als disziplinierter Erwachsener geholt wurde, um Googles laxes Enterprise-Vorgehen zu korrigieren
      Wie dieser Vorfall zeigt, ist noch viel zu tun, aber um eine „ernsthafte“ Enterprise-Organisation zu werden, war das vielleicht nötig
      Dabei könnte allerdings eine Kultur entstanden sein, die mit dem Rest von Google kollidiert
      Andererseits: Hatte OCI als Oracle-Sparte überhaupt eine Kultur, die man noch zerstören konnte? Eher wirkt es so, als hätte TK diese Kultur zu Google gebracht
    • Alle Google-Produkte funktionieren so
      Man sollte sie niemals für irgendetwas Wichtiges verwenden

  • Es ist nicht das erste Mal, dass Google Cloud ein Kundenkonto massiv beschädigt hat: https://cloud.google.com/blog/products/infrastructure/detail...

  • „Railway trägt die Verantwortung für seine Vendor-Auswahl, und letztlich liegt auch diese Entscheidung in unserer Verantwortung. Den Kunden ist es egal, ob der Ausfall von Google oder von Railway verursacht wurde. Für den Kunden sichtbar ist unser Produkt. Eure Verfügbarkeit ist unsere Verantwortung, und wir werden sie weiterhin sicherstellen“
    Dass sie das anerkennen und nicht nur PR-Sprache benutzen, ist lobenswert
    Das Vertrauen in GCP war auf Seiten von Railway ein Architekturfehler, und das zeigt, dass sie versuchen, ihn zu beheben
    Hätten sie das vorhersehen müssen? Ja. Aber spät ist immer noch besser als nie

    • Klingt irgendwie wie ein Textbaustein aus dem Bürotemplate der UVic ESS :P

  • „Abschließend planen wir, Google-Cloud-Services aus dem Hot Path der Data Plane zu entfernen und sie nur noch für Backup-/Failover-Zwecke zu behalten“
    Das ist ziemlich eindeutig
    Google ist als B2B-Dienstleister nicht länger vertrauenswürdig

    • Meta ist nicht besser
      Bei irgendeiner Firma wurde die OAuth-App von Meta vollständig unbrauchbar, nur weil das persönliche Facebook-Konto eines Entwickler-Mitarbeiters ohne erkennbaren Grund von Meta gesperrt wurde
      Es wurde mehrfach eskaliert, aber niemand war erreichbar
      Bei Meta ist es noch schlimmer, weil das Konto „persönlich“ sein muss
      Selbst wenn es einen Business Manager gibt, sind alle dort hinzugefügten Nutzer weiterhin an persönliche Meta-/Facebook-Konten gebunden
      Völlig absurd
    • Mehr Unternehmen sollten diese Botschaft hören
      Google hat immer wieder bewiesen, dass man ihnen gerade wegen solcher Probleme als Dienstleister nicht vertrauen kann
    • Gleichzeitig vertraut man ihnen offenbar noch genug, um weiter Geld zu zahlen, was zeigt, wie tief Big Tech verankert ist
      Genau deshalb sollte man sie in Dutzende Teile zerschlagen
    • Google hat seit Langem eine Geschichte damit, Konten ohne Erklärung zu sperren oder zu kündigen
      Oft wird das erst spät rückgängig gemacht, nachdem Nutzer ihre Wut öffentlich gemacht haben und der Vorfall größere Kreise zieht
      Google hat sich gegenüber zahlenden Kunden immer so verhalten, als hätten sie keinerlei Verpflichtungen
    • Es wurde nicht erklärt, warum das Konto gesperrt wurde
      Für mich ist genau das der wichtigste Punkt
      Ein Cloud-Anbieter sperrt nicht ohne Grund ein komplettes Konto