Group
Cloud Engineer
Cloud Engineer
Success Story:
Umfassende Cloud-Migration bei den SBB
Branche
Transport
- Hardware-Wartung läuft ab
- Standardisierter Infrastruktur-Service erforderlich
- AWS-Expertise mit schnellem operativem Support
- Komplexes DR aufgrund von Hardware-Abhängigkeit
- Nahtloser Übergang zu AWS
- Geringere menschliche Fehler durch Operations as Code
- Verbesserte Notfallbereitschaft durch automatisiertes Application Setup
Herausforderung und der Lösungsansatz
Präzision, Effizienz und Sicherheit sind im Bahnbetrieb von grösster Bedeutung. Alle Handlungen und taktischen Entscheidungen müssen auf Basis von exakten Daten und schlanken Prozessen getroffen werden.
Der Elektronische Lokführer-Assistent (LEA1) der SBB ist ein technisches Hilfsmittel für Lokführer in der Schweiz, der sowohl im Güter- und Personenverkehr als auch bei mehreren Privatbahnen zum Einsatz kommt. Die von der App bereitgestellten wichtigen Informationen, erleichtern den Lokführern ihre Arbeit. Die Applikation, die für die Bereitstellung dieser kritischen Informationen verantwortlich ist, wurde auf einer Hardware betrieben, für die die Wartung nicht mehr garantiert werden konnte. Infolgedessen wurde die Betriebskontinuität gefährdet.
Die Abhängigkeit von der Hardware war also mit erheblichen Nachteilen verbunden. Aus diesem Grund wurde der Ansatz „Operations as Code2“ gewählt, um somit den Betriebs- und Wartungsaufwand des Messaging-Subsystems von LEA zu verringern. Darüber hinaus konnte die Zeit für die von Grund auf neue Einrichtung der Anwendung dank IaC3 drastisch reduziert werden.
Abb. 1:
Tools, die für den Operations as Code-Ansatz verwendet werden
Abb. 2:
Architekturdiagramm der AWS-Umgebung
Lösung
Sorgfältige Planung:
Axians Amanox hat mit grösster Sorgfalt einen Plan erstellt, der die Migration ohne Unterbrechung des laufenden Betriebs gewährleistete, wobei die Anwendung in die Cloud verlagert wurde – insbesondere unter Nutzung der Amazon Web Services (AWS).
Während des reibungslosen Übergangs wurden Hardware-Abhängigkeiten eliminiert und der Weg für eine verbesserte Skalierbarkeit und Ausfallsicherheit geebnet.
Kapazität und Skalierbarkeit:
In der Anfangsphase der Migration ermöglichten die AWS EC24-Instanzen einen kurzen Testlauf, um die von der Applikation benötigte reelle Netzwerkkapazität zu vergewissern. Dies ermöglichte die Übernahme der EC2-Instanzen mit höheren Netzwerkkapazitäten5, um eine hohe Anzahl von Client-Anfragen aus der Produktion zu bewältigen.
Automatisierung der Abläufe im Betrieb:
Darüber hinaus konnte dank der automatisierten Anwendungskonfiguration das Betriebsteam, die Anwendung zwecks der Notfallwiederherstellung neu aufsetzen. Durch die Einführung des Infrastructure as Code (IaC)-Ansatzes wurden die Abläufe in den Test-, Entwicklungs- und Produktionsumgebungen optimiert sowie manuelle Installations- und Konfigurationsprozesse eliminiert.
Bessere Zusammenarbeit:
Die Anwendungsversionen und -zertifikate werden nun mittels Ansible (Automatisierungsplattform) automatisiert verwaltet. Demzufolge erleichterte dies einerseits eine nahtlose Zusammenarbeit innerhalb des Betriebsteams und andererseits eine flexible Verwaltung ihrer Infrastruktur. Zudem konnte zum einen dank separater Git-branches pro Umgebung der Auswirkungsradius beschränkt werden und zum anderen eine effektive Änderungsverfolgung und -prüfung der Applikation sowie der Infrastruktur bei AWS durch den «Single source of truth» in der Bitbucket-Repository.
Nachhaltigkeit und Effizienz:
Wir haben uns für dieses Modell der geteilten Verantwortung entschieden, anstatt alles selbst zu entwickeln, in Sinne einer nachhaltigen Gestaltung der Lösung.
Die Zusammenarbeit mit dem Product Owner von SBB, dem Entwicklungsteam und den AWS-Experten gewährleistete die Ausrichtung auf die Ziele (die Übereinstimmung mit den Zielen), die Einhaltung der SBB-Infrastrukturstandards und eine nahtlose Ausführung während des gesamten Projektlebenszyklus. Durch die Einhaltung der SBB-Infrastrukturstandards konnten wir die bereits von den internen Teams bereitgestellten Dienste wie Unified OS oder Jenkins wiederverwenden, um unnötige Doppelarbeit zu vermeiden.
Feinabstimmung:
Mit einem proaktiven Ansatz überwachten wir von Axians Amanox die Umgebung nach der Migration genau, um eine optimale Leistung sicherzustellen und aufkommende Probleme schnell zu beheben. Mit CloudWatch Metrics ist es möglich, erweiterte ENA-Metriken6 zu beobachten, um zu prüfen, ob die für die EC2-Instanzen zulässigen Netzwerkgrenzen überschritten werden und die EC2-Instanzen bei Bedarf zu skalieren.
Tools & Technologien
Terraform, Ansible, Jenkins und Artifactory:
IaC bildete das Rückgrat unserer Migrationsstrategie und ermöglichte Automatisierung und CD-Pipelines (Continuous Deployment).
AWS Dienste:
Von AWS EC2-Instanzen über Network Load Balancers (NLB) bis hin zu CloudWatch nutzten wir die Leistungsfähigkeit von AWS, um eine robuste, skalierbare und kosteneffiziente Infrastruktur bereitzustellen.
Schlussfolgerung
Die Partnerschaft von Axians Amanox mit der SBB hat eine neue Ära der Effizienz, Skalierbarkeit und Innovation eingeläutet.
Durch die Migration der Anwendung zu AWS haben wir die SBB von den Fesseln der Hardware-Abhängigkeit befreit und den Weg für einen nahtlosen Betrieb und Agilität geebnet.
Über SBB – Schweizerische Bundesbahnen AG
1 https://de.wikipedia.org/wiki/Lokpersonal_Electronic_Assistant
2 Operational excellence https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/operational-excellence.html
3 https://en.wikipedia.org/wiki/Infrastructure_as_code
4 https://en.wikipedia.org/wiki/Amazon_Elastic_Compute_Cloud
5 https://aws.amazon.com/blogs/networking-and-content-delivery/amazon-ec2-instance-level-network-performance-metrics-uncover-new-insights/
6 https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html
The connectivity problem
Digital Twin Service
