Orchestrator/bahn/project-audit/analysis/runbook-analyse.md

Runbook-Analyse — pathOS Architekturdokumentation

Quelle: Runbook (arc42-Format), ~346KB, Stand April 2026 Analyse: 2026-04-22

---

1. Qualitaetsziele (Priorisiert)

Prio	Ziel	Beschreibung
1	Diskriminierungsverbot	Gleichbehandlung DB-eigener und externer EVU (Performance, Verfuegbarkeit, Funktionalitaet)
2	24/7 Verfuegbarkeit	Unternehmenskritische Anwendung (UKA) mit SL1 (Gold), auch ausserhalb Geschaeftszeiten
3	Interoperabilitaet	Kompatibel mit TAF/TAP TSI Standard und RNE Common Interface
4	Mandantenfaehigkeit	Strikte Datentrennung nach Kundennummern
5	Unveraenderbarkeit	Kundenauftraege nachvollziehbar und unveraenderbar
6	Fehlertoleranz	Automatische Reaktion auf HW/SW-Fehler
7	Kapazitaet	Genuegend Kapazitaet fuer Netzfahrplan-Deadlines
8	Ressourcenverbrauch	Effiziente Nutzung, dynamische Skalierung
9	Bedienbarkeit	Effizient fuer Power-User
10	Erlernbarkeit	Leicht fuer Gelegenheitsnutzer

2. Service Levels

Umgebung	Service Level	Verfuegbarkeit	RTO
Produktion	DB Silber (ab 03/2026), Silber Plus (ab 08/2026)	99.38% / 99.73%	6h
WGK-Ausweich	DB Bronze Plus	98.90%	24h
Sonstige	DB Bronze	98.75%	24h

3. Subdomaenen-Architektur

Das System ist in 4 Subdomaenen zerlegt:

TAF/TAP Schnittstellen (Team Zero)

• Common Interface (SOAP/XML, Mutual SSL)
• TAF/TAP TDM Konverter
• Partnerverwaltung, Zertifikatsverwaltung

Bestellportal (Team 404)

• Portal UI (Angular)
• Portal Middleware (Spring Boot)
• Entwuerfe und Vorlagen

Prozesse (Team CIB)

• Steuerung Vertrieb (Camunda 8, BPMN)
• IFP Connector
• Archivierungsservice

Backend (Team CIB/Zero)

• Auftrags-Verwaltung-Trasse
• Kundendaten-Bereitstellung
• Stammdaten-Bereitstellung
• Rabattnummern-Bereitstellung
• Vertragsdaten-Verteiler

4. Teams (aus Runbook bestaetigt)

Team	Verantwortung	Schwerpunkt
Team Zero	TAF/TAP Schnittstellen, Stammdaten	Common Interface, Stammdaten-Bereitstellung
Team 404	Bestellportal	Portal UI, Portal Middleware
Team CIB	Prozesse, Backend	Steuerung Vertrieb, Auftrags-Verwaltung
Team STeam	Infrastruktur, DevOps, Security	CI/CD, Deployment, Keycloak, Monitoring
Team BSSUPPORT	Support	2nd Level Support

5. Umgebungslandschaft (17+ Umgebungen!)

DEV Stage

• BU (Build-Umgebungen) — temporaer, pro MR
• EU/BASE-* (Review) — temporaer, pro MR
• Demo — dauerhaft, manuelle Tests
• BASE-AT (Integrationstest) — temporaer, pro MR
• LUP (Last & Performance) — temporaer
• IEU (Integrierte Entwicklung) — dauerhaft, auto-deploy bei Master-Merge
• SIT (Systemintegration) — dauerhaft, manuelles Deployment
• SIT2 — dauerhaft, automatisiert

ABN Stage

• E2E (TTT-ITU1) — dauerhaft, TTT-abgestimmt
• SAT1 (Alarm ITU) — dauerhaft, Hotfix-Tests
• SAT2 (Release ITU) — dauerhaft, Feature-Release-Tests
• SAT3 — dauerhaft, LuP/Pentest/DRT
• ABN1 (TTT-KTU) — dauerhaft, Kundentests mit EVUs
• ABN2 (Release ABN) — dauerhaft, TTT-E2E
• ABN4 — dauerhaft, Alarm-Patches
• ABN8 — dauerhaft, EVU-Integrationstests
• PREPROD — dauerhaft, Sondertests mit Fahrplan-IT

PROD Stage

• PROD — Produktionsumgebung

Erkenntnis: 17+ Umgebungen erklaeren die Deployment-Komplexitaet!

6. Externe Schnittstellen (detailliert)

Name	Technologie	Auth	SLA
EVU-Eingang	SOAP/XML	Mutual SSL (RNE-Zertifikate)	SL1
EVU-Ausgang	SOAP/XML	Mutual SSL	SL1
Portal-App	HTML5/REST	JWT (OIDC)	SL1
IM Stammdaten	REST/JSON	JWT, Client-ID/Secret	SL3+
Benutzer-Auth	OpenID Connect	Benutzername/Passwort	SL1
NuR-Service	REST/JSON	Entra ID Client-Credential	SL3
KDV (CRM)	REST/JSON	Basic-Auth	SL3
NVN-Tool	REST/JSON	Basic-Auth + JSON Token	SL3
TPN Produktionsauftraege	AWS MSK (Kafka)	IAM:Role	SL1
TPN Vertriebsauftraege	AWS MSK (Kafka)	IAM:Role	SL1
AC Trasse Archiv	REST/JSON	BizHub ClientID/Secret	SL3
Stammdaten extern	REST/JSON	Keine Auth	SL1
BEP	REST/JSON	BizHub ClientID/Secret	SL3
Stationsportal	AWS MSK (Kafka)	IAM:Role	SL1
TBV	AWS MSK (Kafka)	IAM:Role	SL1

7. Kafka-Topologie

Interne Topics (25+)

Wichtigste Datenfluesse:

• eingangsnachricht: TTK/PMW → SV, Archivierungsservice
• versandauftrag: SV → TTK, PMW
• versandergebnis: CI/TTK → SV
• auftragsverwaltung: SV → AV, TBV-Konverter, Archivierungsservice
• produktionsauftrag-to-connector: SV → IFP-Connector
• vertriebsauftrag-to-sv: IFP-Connector → SV
• process-eingangsnachricht: SV → SV (Camunda)
• camunda-events: Camunda Zeebe → SV
• vertragsdaten-to-stationsportal: VDV → Stationsportal

Kafka-Cluster (12+)

• bsz-dev (IEU, SIT, Demo)
• bsz-dev-e2e (E2E)
• bsz-dev-2 (SIT, SIT2)
• bsz-abn-abn1, abn2, sat1, sat2, sat3, abn8, preprod
• bsz-prod

8. Datenbank-Architektur

Produktions-Setup (3 separate Cluster!)

• bsz-prod-production: Alle ausser SV, IFP, AV, PMW (db.m6gd.large, 200GB)
• bsz-prod-production-avt: AV + PMW (db.m6gd.large, 200GB)
• bsz-prod-production-sv: SV + IFP-Connector (db.m6gd.large, 200GB)

Erkenntnis: DB-Split nach Performance-Anforderungen (SV und AV sind die lastintensivsten)

Persistenz-Strategie

• Shared-Nothing: Jede Anwendung eigene DB
• TAF/TAP-Daten als JSON/XML BLOBs (nicht relationales Modell!)
• Flyway fuer Migrationen
• Append-Only fuer Kundenauftraege (Unveraenderbarkeit)

9. Sicherheitsarchitektur

Authentifizierung

• Portal: DB WebSSO (OIDC) via SIPS Access Proxy + NuR
• Common Interface: Mutual SSL mit RNE-Zertifikaten
• Intern: Keycloak (Test), Entra ID (Prod)
• Kafka: AWS IAM Roles
• DB: Technische User pro Anwendung (DML only)

Verschluesselung

• TLS ueberall (ISGW → ALB → App)
• Data-at-Rest: AWS-managed Encryption
• Secrets: age + sops + Helm Secrets Plugin

Mandantentrennung

• Basierend auf Kundennummern
• Alle Zugriffe gefiltert nach Berechtigungen
• Backend-seitige Validierung (Browser nicht vertrauenswuerdig)

10. Bekannte Technische Schulden (aus Runbook)

Kategorie	Problem	Massnahme
TAF/TAP TSI	Veraltete Technologie (SOAP, unvollstaendige Specs)	CI als Adapter
AppMesh	AWS EOL, CNP arbeitet an Alternative	O2CBS-555
CI/CD Pipelines	Zu komplex (pipeship + CNB)	Vereinfachungen

11. Offene Punkte / Risiken (aus Runbook)

• Common Interface: SOAP als Altlast, bidirektionale async Kommunikation fragil
• Stammdaten: Performance-Probleme beim Strecken-Import (zu viele kleinteilige API-Calls)
• Portal-Middleware: Haeufige Schnittstellenaenderungen von SV und AV
• Kundendaten/Rabattdaten: Koennen kurzzeitig veraltet sein (akzeptiert)
• Performance: Keine systematische Performance-Messung bei mehreren Services
• Click&Ride: Anbindungsdetails noch nicht geklaert
• BEP: Anbindung noch in Arbeit

12. Architecture Decision Records (75 ADRs!)

Wichtigste aktive ADRs:

• ADR-29: Internes Datenmodell TDM
• ADR-35: Zugriffskontrolle interne Schnittstellen
• ADR-36: Trennung Build/Deployment Pipelines
• ADR-53: Hybride Anbindung Eingangskaenaele
• ADR-56: CI an Backend ueber Kafka (In Arbeit)
• ADR-58: Deployment und Release
• ADR-61: Signieren von Nachrichten
• ADR-63: Camunda 8 als Workflow Engine
• ADR-70: Weiterentwicklung Testvorgehen (In Arbeit)
• ADR-72: Click&Ride Anbindung (In Arbeit)
• ADR-74: TrassenPortal Anbindung (In Arbeit)