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

[conf_t]

Ich glaube das wurde hier schon oft wiederholt: Testumgebung sind in großen Unternehmen eine Selbstverständlichkeit. Dennoch kann es bei der Implementierung immer zu Fehlern kommen. Zu glauben es gäbe keine Testumgebung ist genauso naiv wie zu glauben es gäbe keine Redundanz. Jeder der mit Redunanzen gearbeitet hat weiß, dass es immer Situationen gibt, wo sie für den ALlerwertesten ist. Ich kennen diesen Redundanzglauben nur vom Management und Nichttechnischen Personal.

Daher gibt es ja auch eine Eintrittwahrscheinlichkeitsanalyse bei Changen, wie hoch die Wahrscheinlichkeit ist, dass ein Fehler eintritt, bei zahlreich erprobten Changes ist die eben geringer.

 

[Löschknecht]

Die DB ist ein dezentralisierter föderaler Konzern in dem allen voran „die IT“ und deren Resilienz bei genau solchen Fragen stark unter diesem System krankt.

Die DBInfraGO ist Hauptverantwortliche für den Betrieb des GSM-Netzes.

Die DB System GmbH betreut die internen Dienste, Rechenzentren, Serverstrukturen, Software etc.
Sie isolieren das Problem, prüfen Cyberangriffe, machen den Support und bearbeiten defacto das Ticket.

DB Fern und DB Regio-Verkehr (zwei separate Sparten) betreiben jeweils ihre Züge und sind von diesem Netz abhängig und Betroffene.

DB Cargo (Güterverkehr) das gleiche.

Das ist alles so falsch das lohnet e sich gar nicht zu korrigeren.

DB Systel hat da schon lange nicht mehr die Hand drauf da macht TK Betrieb.

 

[Ranayna]

Daher gibt es ja auch eine Eintrittwahrscheinlichkeitsanalyse bei Changen, wie hoch die Wahrscheinlichkeit ist, dass ein Fehler eintritt, bei zahlreich erprobten Changes ist die eben geringer.

Und dann kommt das zwanzigste Upgrade eines Systems. Etwas das Routine sein sollte.
In den Changelogs des Herstellers steht nix besonderes. Das Changeboard nickt das ab, weil es ist schon 19 mal gutgegangen.
Tests in der Testumgebung laufen problemlos durch,

Und nach dem Update sind Appliances am anderen Ende der Welt ploetzlich ohne IP Adresse und nicht mehr erreichbar, weil es eine undokumentierte Aenderung gegeben hat wodurch ein bestimmtes Modell seine VLAN Interfaces verloren hat...
Ein Modell welches wir natuerlich nicht in der Testumgebung hatten.

 

[conf_t]

Eben. Und zu den Changelogs. Selbst erwähnenswerte neue Features hat z.B. Keysight bei der Vision Edge E100 nicht für nötig empfunden zu erwähnen: Einführung von TLS 1.3 für die API und HTTPS. Die Governance gab uns damals TLS 1.3 als Mindeststandard vor…… hat damals gerade noch so gepasst. Aber wer sich auf Release Notes verlässt ist verlassen. Bei Cisco das gleiche, sowohl für die „Einführung von Bugs“ als auch von Features. Und gerne treten die Bugs nur und bbestimmten Bedingungen nur auf. Ehrlich. Ich beschäftige mich viel beruflich mit Kommunikationsfehlern zwischen Systemen, damit eine Log Meldung geschrieben werden kann, muss der Entwickler daran gedacht haben, dass der Fehler auftreten könnte. Die meisten Fehler mit denen ich zu tun habe, haben keine Log-Einträge. Da ist es Gold wert, wenn man in der Lage ist überhaupt das System einzugrenzen auf dem der Fehler entsteht. Wer weiß was ne Vision Edge E100 ist, wird wissen was ich so beruflich treibe….

 

[Ranayna]

Wer weiß was ne Vision Edge E100 ist, wird wissen was ich so beruflich treibe….

Spannend. Ich kenne Keysight als Hersteller von Messinstrumenten und Laborgeraeten. Oszilloskope und Netzteile, Funktiongenerationen, und so ein Kram.
Das die Switche herstellen haette ich jetzt nicht erwartet. Aber vermutlich ist "Switch" auch zu kurz gegriffen bei dem Geraet

 

[conf_t]

Da switcht nix…. Packet broker ist etwas anderes. Aggregiert per tap ausgeleiteten Traffic (Glasfaser taps arbeiten mit Prismen) zur Analyse von verschiedenen Ports zu einem Ausgabeport. Verschiedenste Filter möglich. So kann man in hochlastumgebungen (Datacenter, Netzwerkknoten) Verkehr permanent ausleiten, duplizieren, filtern und analysieren. Hilft bei Performanceanalysen und Forensik

 

[Ranayna]

Danke, man lernt nie aus
Ich hab beim groben ueberfliegen der Produktseite gedacht dass da nur jemand das Buzzword Bingo ausgegraben hat.

 

[Hammelkoppter]

Ein Modell welches wir natuerlich nicht in der Testumgebung hatten.

Sorry aber dann ist die Testumgebung Müll. Was sollen das denn bitte für "Tests" sein, die die Wirklichkeit nicht abbilden.

Für ne PoC Umgebung mag das iO sein, aber nicht für eine Testumgebung die einen kritischen Change vorbereiten soll.

 

[Ranayna]

Das ist die uebliche Balance die man in 99% der Firmen finden duerfte.
Man kann nicht alles abbilden.
Du kannst meinem Chef ja gerne erklaeren, dass das noch einen mittleren fuenfstellingen Betrag an Investition, plus nochmal knapp 5.000 im Jahr fuer den Softwaresupport faellig waeren.

In diesem Fall war es auch kein hochkritisches System, dementsprechend waere es absolut unwirtschaftlich gewesen alle Modelle in die Testumgebung aufzunehmen.

 

[Hammelkoppter]

Kein hochkritisches System.... hm naja. Wenn der gesamte Zugverkehr in ganz D steht, finde ich das schon kritisch. Aber hat jeder so seine Meinung.
Aber mal ehrlich.... die DB steckt voll und das Budget ist locker da. Man muss halt wollen. Weiterhin kann man sich bei etablierten Herstellern so ein Lab auch mieten. Damit umgeht man ein wenig die laufenden Kosten.

 

[Sierra1505]

Das ist alles so falsch das lohnet e sich gar nicht zu korrigeren.

okay.

Du kannst mich und auch gerne alle anderen hier erhellen. Ich habe meinen Post keineswegs mit einem vehementen „isso!“ unterstrichen und bin daher auch Formel offen für andere Standpunkte…

Was nun genau die DB Systel stand heute (2026) für eine Kernaufgabe vertritt mag die eine Frage sein. Ich erwähnte das letzte Mal persönlichen projektbedingten Kontakt 2014 mit der DB im allgemeinen gehabt zu haben.

Das die DB in Fragen der IT und allen voran der Infrastruktur-Resillienz aufgrund der fragmentierten Konzern-Struktur Defizite aufweist ist eher meine Kernaussage gewesen. Ist das ebenso falsch?

 

[JohnMcLane87]

Ich denke die Systeme bei der Bahn sind schon klar umrissen und getrennt pflegbar. Gerade das GSM R Beispiel hat ja nix mit dem Firmen-SAP oder Sharepoint oder sonst was zu tun.

Ich sehe deshalb erstmal keinen Vorteil, wenn man die Verantwortung und die Pflege in einer Einheit bündelt.
Wichtiger ist dann eher klare Regeln und Prozesse, wie die Einheiten mit Updates und Schwachstellen umgehen.

Ich glaube bzw folge auch der bisherigen Diskussion in diesem Thread nicht so ganz, dass die Bahn keine Ahnung von Tests oder ähnlichem haben soll. Ich denke sie werden schon getestet haben.
Die Frage ist die Testphilosophie:
Wenn ich mehrere neue identische Switche im System verbauen will, teste ich dann die Änderung im System mit einem dieser Switche oder teste ich jeden einzelnen der Switche, die ich geliefert bekomme und dann auch verbauen will?
Letzteres wäre wohl sinnvoll, aber wohl auch zu teuer, wenn man hunderte von identischen Bauteilen ausrollen will.

 

[Hammelkoppter]

Ja das ist die Frage. Mal nen bisschen was aus der Praxis. Habe selbst schon Software Rollouts von ca 1000 Switches am WE gemacht. Testet man jetzt jeden Switch einzeln auf Probleme mit der neuen Software - auf keinen Fall. Sind die Switches kritisch - zu 95% ja. Da hängt halt nen großer Teil der Produktion dran und wenn es irgendwo nicht weitergeht, steht halt alles.
Es ist auch schon vorgekommen, dass ne Charge an Switches auf den letzten 16 Ports auf einmal kein PoE mehr ausgegeben hat - das schlich sich dann aber nach ca. 2 Jahren ein. Is halt mega ärgerlich und sowas kannste halt nicht testen. Wenn da aber APs dran hängen in ner Logistikhalle oder Produktion dann ist halt erstmal das Bein dick.
Weiterhin habe ich selbst schon mit Kollegen der DB aus verschiedenen Bereichen zusammengearbeitet und die sind alles andere als inkompetent. Super Typen und es macht wirklich Spaß. Keine Ahnung was da also schief gegangen ist. Passiert hoffentlich so schnell nicht wieder.