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)