News Bahnfunk-Störung: Wenn ein Update den Bahnverkehr stoppt

[Hammelkoppter]

"Künftig werden Instandhaltungsarbeiten nur noch nachts zwischen 0 und 4 Uhr sowie ausschließlich in der inaktiven Redundanz durchgeführt"

Wenn man das liest kann man sich doch nur an den Kopf fassen. Was sitzen denn da für Stümper wtf. Da mach ich nichtmal die Techniker für verantwortlich. So etwas wird weiter oben durchgewunken und es wird sicherlich genug Bedenken gegeben haben, die einfach mal ignoriert wurden.
Bei so extrem kritischen Dingen, nichtmal ne Testumgebung zu haben ist doch einfach nur peinlich. Einfach mal nen paar Millionen nen bei Stuttgart 31 abzwacken.
Und wenn man auch schon kein Changefenster bekommt ist es doch selbstverständlich dies in Zeiträume mit geringem Aufkommen zu legen. " Hauptsach früh Feierabend. Die Passagiere sind uns doch egal"

 

[Nagilum99]

Die Erklärung ist aus technischer Sicht bemerkenswert: Ein einzelner Softwarefehler konnte offenbar dazu führen, dass eine sicherheitsrelevante Funktion ausfiel. Die Rückfallebene stand zwar bereit, wurde aber erst nach manuellem Eingriff aktiv.

Ich finde es "beeindruckend" wie beschränkt das Know-How hier doch ist:
Nein, es ist nicht bemerkenswert. Rendundante Systeme funktionieren nicht mit Feenstaub. Sie müssen korrekt miteinander kommunizieren oder komplett ausfallen um "einfach" zu funktionieren.
Das hat die IT in den letzten Jahren x mal bewiesen.
Es sind hochgradig komplexe Systeme bei denen es sehr viele Möglichkeiten gibt, wo etwas schief gehen kann - und was auf gar keinen Fall passieren darf, ist dass 2 "unabhängige" Systeme sich beide für zuständig befinden.

 

[bart1983]

 

[RcTomcat]

Wenn der Fehler keine Fehlermeldung erzeugt hat hilft es doch nicht, zuerst die passive Instanz zu updaten. Dort steht doch dann auch erstmal alles auf grün und der Fehler fällt nicht auf das die Instanz ja nicht genutzt wird. Die Techniker gehen von Erfolg aus und machen weiter. Selbst wenn man nun einen Versatz von z.b. mehreren Tagen zwecks Test einbauen würde bleibt nach wie vor das Problem bestehen. Passive Instanz updaten. Wechsel auf die zuvor passive Instanz, keine Fehler. Oh, es geht nichts mehr. Cyberangriff ausschließen, dann Wechsel zurück auf die anderen Systeme. Automatischer failover greift mangels Fehlermeldung nicht, menschlicher Eingriff bleibt erforderlich. Dazu der zeitliche Aufwand um einen Angriff erstmal ausschließen zu können. Und das nun alles zwischen 0 und 4 Uhr.

Man benötigt eine Testumgebung, so nah wie möglich an den realen Systemen, in welcher zuvor rigoros getestet werden muss.

 

[JohnMcLane87]

Anhang anzeigen 1742205

Message?

 

[luckysh0t]

@JohnMcLane87 Dass manche es nicht verstehen (oder es verstehen und es dennoch amüsant finden - wie ich ), dass gewisse Anlagen entsprechend alt sind und dann dafür halt auch mal Leute gesucht werden, die das noch können.

Ergänzung (28. Juni 2026)

Man benötigt eine Testumgebung, so nah wie möglich an den realen Systemen, in welcher zuvor rigoros getestet werden muss.

Sowas ist in der Vorstellung immer schön und einfach. Bei uns wäre das gar nicht wirklich machbar, weil die Funktionen, die ggf. schiefgehen einen Live betrieb brauchen.

Unser Testsystem bei solchen Fällen, wäre quasi ein zweites Livesystem, was aber aufgrund unterschiedlicher Datenbanken dann wiederum zu Inkonsistenzen führen würde und an sich so nicht praktisch realisierbar wäre, da es keine getrennten Livesysteme geben darf, die dasselbe machen.

Unser Testsystem ist daher eher dazu da um neue Prozesse innerhalb des Systems zu testen, wie es reagiert - mit gespiegelten Produktivdaten.
Aber um zu testen, ob es nach einem Update noch funktioniert, kann man damit nicht zuverlässig abbilden - da kein Livesystem.

Davon ab, müssten dann ja wiederum Kollegen, die das Programm nutzen, ihre produktive Arbeit niederlegen und testen - was heißt, das andere Kollegen deren Arbeit on top machen müssen. Was eh schon bei Urlaub etc. der Fall ist. Ich als IT`ler kann das jedenfalls mangels Fachkenntnisse innerhalb des Programms nicht abbilden.

Ergänzung (28. Juni 2026)

Es sind hochgradig komplexe Systeme bei denen es sehr viele Möglichkeiten gibt, wo etwas schief gehen kann - und was auf gar keinen Fall passieren darf, ist dass 2 "unabhängige" Systeme sich beide für zuständig befinden.

Das hatten wir mal, als ein Kunde zu uns gewechselt ist, altes System war aus... alles gut, dann warum auch immer haben die die alten Systeme wieder angeschaltet - ohne uns zu informieren. Hat eine Weile gedauert bis wir herausgefunden haben, warum die Daten inkonsistent sind..wir hatten quasi das Szenario was ich oben drüber skizziert habe..

 

[Nagilum99]

Das hatten wir mal, als ein Kunde zu uns gewechselt ist, altes System war aus... alles gut, dann warum auch immer haben die die alten Systeme wieder angeschaltet - ohne uns zu informieren. Hat eine Weile gedauert bis wir herausgefunden haben, warum die Daten inkonsistent sind..wir hatten quasi das Szenario was ich oben drüber skizziert habe..

"Split-Brain" ist eine richtig ekelige Sache. Bei Redundatenm Storage ist danach idR. Recovery angesagt.
Ich will nicht wissen, welcher Schaden oder wieviele Tote sowas beim GSM-R bei der Bahn auslösen kann. Dann lieber auf Nummer sicher und abschalten.

Leute wie weider oben, die glauben man kann alles mal eben mit Testumgebungen abfangen oder auch der Autor der sowas für "beeindruckend" halten sind schlichtweg unerfahren oder leben nicht in der Realität.
Es besteht immer das Risiko, dass das Livesystem irgendwas macht, was so nicht abgebildet wurde oder einfach nicht abbildbar war, weil Kosten und Aufwand in keinem Verhätlnis zum Risiko gestanden hätten.
Wenn jeder Testcase Millionen kostet, riskierst du lieber, dass alle 20 Jahre die Bahn 2 Stunden steht.
Zumal das bei Fehlern im System idR. z.T. gar nicht vorhersehbar/testbar ist.
...deswegen werden Spezialisten für sowas IMHO auch oft unterbezahlt. Das Wissen und Know-How ist enorm viel wert und eher selten - und wenn es dann doch platzt kommen die ganzen YouTube-Experten und wussten vorher schon wie es hätte vermieden werden können.

 

[xexex]

Die Meldung, dass das ganze System still liegt, sollte ja wohl nicht mehr als 5min dauern bei tausenden bis zehntausenden Teilnehmern?

Das ganze System lag aber nicht still, das hätte man dann gemerkt und dann hätte vermutlich auch die HA gegriffen. Sprich, das System lief irgendwie, aber Telefonate konnten scheinbar nicht geführt werden. Wie läuft denn so ein Vorgang in der IT ab?

Vermutlich kündigt man an, um Zeitpunkt X findet ein Update statt und wird einen ungefähren Zeitraum dauern. Die IT macht das Update, prüft ob alles von ihrer Seite läuft und hält es erst einmal für erledigt. Die Nutzer wissen möglicherweise von einem Update, also warten sie erst einmal kurz ab, bis dann die ersten ungeduldig werden.

Telefonieren konnten sie nicht, also werden irgendwann die ersten Anrufe über das öffentliche Netz im First Level Support aufschlagen. Der prüft vermutlich zunächst einmal die Aussagen, ob es nur einzelne Geräte oder alle anbetrifft und leitet die Anfrage dann an die Technik weiter.

Wenn du meinst das ist alles in "5min" erledigt, dann hast du noch nie in einem Konzern gearbeitet. Erst danach fängt eine Fehlersuche an und später irgendwann die Entscheidung, das System auf die Redundanz umzuschalten.

Wenn bei uns wegen irgendeinem Problem auch nur für 2min das Netzwerk an einem unserer 30 Büros nicht funktioniert, hat man meist schon irgendeinen regionalen Chef am Apparat wann das endlich gefixt ist.

Mag sein, vermutlich kennt man dich sogar namentlich, nur nicht in einem Konzern mit 230.000 Mitarbeitern. Glaubst du irgendein Zugführer hat die direkte Durchwahl zu den Technikern die für sowas zuständig sind?

 

[luckysh0t]

Du willst mir doch nicht verkaufen, dass zu checken warum der Failover nicht gegriffen hat, lange dauert?

Wenn die erstmal prüfen müssen, ob sich um einen Angriff handelt, bevor hier auf ein Fallbacksystem gewechselt werden darf, kann sowas schonmal dauern - je nach Teamgröße und Umfang dessen.

 

[catch 22]

"Künftig werden Instandhaltungsarbeiten nur noch nachts zwischen 0 und 4 Uhr sowie ausschließlich in der inaktiven Redundanz durchgeführt"

Wenn man das liest kann man sich doch nur an den Kopf fassen. Was sitzen denn da für Stümper wtf. Da mach ich nichtmal die Techniker für verantwortlich. So etwas wird weiter oben durchgewunken und es wird sicherlich genug Bedenken gegeben haben, die einfach mal ignoriert wurden.

das ist mittlerweile ziemlich normal, dass Instandhaltungsarbeiten tagsüber während der Bürozeiten durchgeführt werden, da das die Zeiten sind, in denen notfalls der Supporter erreichbar ist Was nützt es, wenn an einem Sonntag führ um 2Uhr ein System ausfällt, der Dienstleister im Extremfall aber nicht vor Montag 8Uhr, oder bei erhöhtem SLA zwar "direkt" erreichbar ist, dieser aber aufgrund Wochenende und Uhrzeit erst mal selber nur langsamer reagieren kann (wie auch die eigene Firma, für den Fall, dass durch die Störung auch andere Systeme betroffen sind, die dann total untypischerweise auch noch gesondert beobachtet werden müsse), vor allem womöglich die Top-Leute gar nicht in Bereitschaft sind und man sich mit der zweiten oder dritten Garde für das Problem rumärgern darf?

 

[RcTomcat]

Sowas ist in der Vorstellung immer schön und einfach. Bei uns wäre das gar nicht wirklich machbar, weil die Funktionen, die ggf. schiefgehen einen Live betrieb brauchen.
.

Das hat nichts mit Vorstellung oder Theorie zu tun sondern schlicht mit Organisation und Vorgabe. Welche Risiken möchte man tragen / minimieren, gibt es gesetzliche Vorgaben etc.
Wir reden über einen Konzern mit X Milliarden Budget, Kritische Infrastruktur und nicht über kleinen Mittelstand.
Klar ist es aufwendig, der mögliche Schaden ist aber, wie wir gesehen haben, fatal. Wenn wirklich unbedingt ein Betriebstest live notwendig ist muss ich eben meine Infrastruktur so aufbauen, dass ich in Teilen updaten kann und es keine zentrale Komponenten gibt von welcher alles andere abhängig ist. Dann fällt notfalls nur regional etwas aus. Natürlich ist es personeller Aufwand, natürlich kostet das Zeit und Geld. Aber wir bewegen uns , verdammt nochmal, im Bereich der kritischen Infrastruktur.
Klar kann man schlicht sagen "wir tragen das Risiko".
Die aus diesem Vorfall gezogenen Rückschlüsse und Maßnahmen sind aber denkbar ungeeignet. Das sollte auch bei der Bewertung der Maßnahmen zur Risikominimierung auffallen....
Alleine das notwendige Personal von 0-4 Uhr vorhalten zu müssen ist bereits ein enormer Aufwand.
Die bisher kommunizierten Maßnahmen als auch der Vorfall selbst lassen Mängel an Prozessen sowie Design der Infrastruktur vermuten.

 

[Shio]

Das ganze System lag aber nicht still, das hätte man dann gemerkt und dann hätte vermutlich auch die HA gegriffen. Sprich, das System lief irgendwie, aber Telefonate konnten scheinbar nicht geführt werden.

Ach, okay. Ich hatte nur gelesen, dass das ganze System nicht mehr funktionierte. Macht das natürlich direkt komplexer.

Mag sein, vermutlich kennt man dich sogar namentlich, nur nicht in einem Konzern mit 230.000 Mitarbeitern.

Ne, Gott sei Dank sind die Zeiten vorbei. Also entweder wird mir das über den lvl1, der das direkt maximal exkaliert, da er gesehen hat das der Standort nicht erreichbar ist, mitgeteilt oder über meinen VG, der vom Standortvorgesetzten informiert wurde.

Glaubst du irgendein Zugführer hat die direkte Durchwahl zu den Technikern die für sowas zuständig sind?

Aber genau da finde ich auch, das da einfach der Prozess bzw der Ablauf besser sein muss wenn die Meldung solcher Probleme angeblich so lange dauert.

Wenn die erstmal prüfen müssen, ob sich um einen Angriff handelt, bevor hier auf ein Fallbacksystem gewechselt werden darf, kann sowas schonmal dauern - je nach Teamgröße und Umfang dessen.

Wenn sie erst prüfen müssten ob es einen Angriff gab, würden sie nicht erwähnen das der Failover nicht funktioniert hat.

 

[Ranayna]

Ferner finde ich es persönlich als vollkommen irre, dass hier NICHT zuerst in einer Testumgebung getestet wurde 🙄
Aber was ich in der vermeintlich professionellen IT so erlebe - da schockt mich das auch nicht mehr!

Testsysteme koennen nicht immer alles abdecken. Das wurde ja schon erlaeutert.

Und dazu kenn ich noch diesen Spruch:
"Alle Firmen haben ein Testsystem. Einige Firmen haben das Glueck auch ein Produktivsystem zu haben."

Wenn wir die Bahn, wie viele unserer Infrastruktur, nicht kaputtsparen wuerden, saehe die Situation wahrscheinlich ganz anders aus.

 

[Nagilum99]

Wir reden über einen Konzern mit X Milliarden Budget, Kritische Infrastruktur und nicht über kleinen Mittelstand.

Wir reden über einen Konzern, der jedes Jahr mit X Mrd. unterbudgetiert wurde. Jahrzehnte lang.

 

[Löschknecht]

Aber Personen befördern ... geht gar nicht (mehr)!?
Wenn's dann mal heiß ist fällt die Klimaanlage aus (am letzten Samstag wieder erlebt, zusätzlich zu "Zug fällt aus" bei den Verbindungen mit RE1 zwischen Nürnberg u. München, und PLUS 2 Stunden für die Rückfahrt).

Generell fährt die DB im Nahverkehr (sofern sie da noch gewinnt) immer das was bestellt wurde. Und gerade der RE1 hat Probleme weil da der Freistaat Bayern unbedingt die Skoda Züge wollte.

Ansonsten gehen halt auch zu viele Leute im Gleis spazieren.

Na klar reisst man quasi die gesamte Bordtechnik aus den ICEs, um ein modernes Betriebsssytem auf den Steuerrechnern zu installieren...

ICE /= ICE. Die 3.11 Thematik betriff den ICE 1, der 2er wird ausgeflottet.

Dienstwagen gibt es zwar, fangen aber erst in den höheren Tarifstufen an und dann gibt es maximal ein Auto aus der Kompaktklasse. A6, E-Klasse und Co. gibt es nur für obere Führungskräfte. Die haben aber dann tausende Mitarbeiter unter sich.

Das stimmt so nicht, gerade im Baubereich.

Die guten gehen irgendwann und was übrig bleibt sind die Low Performer die durch die Gewerkschaften geschützt werden.

Ist das bei einem IGM Betrieb anders?

Man hat Anfang der 2000er tausende Kilometer Schienen zurückgebaut. Grund: Instandhaltung zu teuer

Interessanterweise war das die Bundesbahn in den 70er und späten 80er Jahren. Tatsächlich waren die meisten dieser Strecken Diesel betrieben würden also bei einem Ausfall auch nix nutzen

in Schienennetz dieser Größe lässt sich nicht durch den Verkauf von Bahntickets unterhalten!

Wird es auch nicht. Jedes EVU was darauf fährt bezahlt Trassenpreise zusätzlich gibt es Bundesmittel.
Vom Fahrkartenverkauf hat die DB außer im FV in der Regel fast nichts.

 

[Ranayna]

ICE /= ICE. Die 3.11 Thematik betriff den ICE 1, der 2er wird ausgeflottet.

Das es unterschiedliche Generationen der ICEs gibt weiss ich. Was deren Unterschiede sind aber nicht wirklich. Mit der Windows 3.11 Geschichte habe ich mich auch nicht wirklich befasst, weil es, ausser einem kurzen Amuesement, eigendlich nichts verwunderliches fuer mich war.

Weisst du warum ICE 1 2 ausgeflottet wird, ICE 1 - der ja vermutlich aelter ist - nicht?

 

[M@tze]

Sofern es ein Bug war, der nur unter ganz bestimmten Bedingungen auftritt, wäre dieser in einer Testumgebung wahrscheinlich gar nicht aufgetreten.

Ich habe den wichtigen Teil mal markiert...

Aber es ist im Prinzip egal, ob er dort wahrscheinlich nicht aufgetreten wäre. Keine Updates in kritischen Umgebungen ohne vorher zu testen - Punkt. Ich möchte nicht dastehen und meinem Chef erklären müssen "Nein, habe ich nicht auf unserem Testcluster ausprobiert, aber wahrscheinlich wäre das dort auch nicht aufgetreten"...

Ich denke, er hätte wahrscheinlich kein Verständnis dafür.

 

[mkossmann]

Weisst du warum ICE 1 2 ausgeflottet wird, ICE 1 - der ja vermutlich aelter ist - nicht?

Beim Bau des ICE2 wurde wohl beim Rostschutz gespart und deswegen sind die Wagenkästen in einem Zustand bei dem Renovieren nicht mehr lohnt.

 

[conf_t]

Weisst du warum ICE 1 2 ausgeflottet wird, ICE 1 - der ja vermutlich aelter ist - nicht?

In Kurzform: Ja, der ICE1 wurde aus Stahl gebaut, der ICE2 aus Alu. Das Alu ist zu stark korrodiert und bruchgefährdet um ihn weiter laufen zu lassen.

Ergänzung (29. Juni 2026)

beim Rostschutz

Nihct Rost, weil aus Alu, aber Alu kann auch korrodieren, aber nicht rosten.

 

[JohnMcLane87]

Weisst du warum ICE 1 2 ausgeflottet wird, ICE 1 - der ja vermutlich aelter ist - nicht?

Unterschied beim Bau der Wagenkasten, wenn ich mich recht erinnere. (Stahl-/Alu)

Die Stahlkästen halten sich über die Jahre wohl besser, als die Alukästen, die wohl irgendwann am Ende der Berechnung auch technisch am Ende sind.